画一块带网口的板子硬件打样回来插上网线PC 端 ping 一下没反应链路灯却亮着——这种情况我遇到过不止一次。STM32 的以太网 ETH 外设看着只是外设树里的一个勾选项但从 MAC 层的 DMA 描述符到板子上那对 100Ω 差分线再到 lwIP 里的内存池大小任何一环出问题现象都长得几乎一模一样ping 不通、丢包、跑一会儿就断。所以这篇东西我不打算按“先介绍后总结”的顺序写而是按我实际调试的顺序来先把 ETH 外设的骨架讲清楚再回到原理图阶段哪些地方最容易埋雷然后是 CubeMX 里那几个真正影响成败的参数最后是 lwIP 联调时踩过的坑。适合刚接触 STM32 以太网、准备自己画板或者正在被 ping 不通困扰的人看硬件和软件的朋友都能对号入座。1. 先把 ETH 外设的骨架讲透MAC、DMA 和 PHY 谁干什么活1.1 三个角色分工谁收包谁搬包谁翻译电平很多人一上来就调 CubeMX其实连 ETH 外设内部有几块东西都没分清。STM32 的以太网外设本质上是一个MAC 控制器加一套 DMA 引擎它只处理数字逻辑层面的帧组装和校验物理层的电平转换、编码、自协商全部交给外部的 PHY 芯片。三者关系可以这么理解PHY 是翻译官负责把双绞线上的模拟波形翻译成 0/1MAC 是收发室的文员负责给数据加上帧头帧尾、算 CRC、判断这个包是不是发给自己的DMA 是搬运工负责把文员整理好的数据整块搬到内存里不占用 CPU 一个字节一个字节去读寄存器。这个分工决定了调试点位的划分。链路灯亮不亮是 PHY 的事能不能收到 CRC 正确的帧是 MAC 的事收到了但应用层看不见是 DMA 描述符和 lwIP 的事。我习惯在排查前先问一句“现在卡在哪一层”而不是直接翻 lwIP 源码。链条上任何一环断掉最终表现都是 ping 不通但排查路径完全不同。还有一点常被忽略MAC 和 PHY 之间的接口有两种MII 和 RMII。MII 是 4 位数据宽、需要 25MHz 时钟RMII 精简到 2 位数据宽但时钟要 50MHz。对 STM32 这类引脚紧张的芯片绝大多数项目选 RMII代价是对时钟质量要求更高——50MHz 走线稍微长一点、阻抗不连续眼图就塌了。选型时如果板子面积充裕、又不想在时钟上折腾MII 反而省心但如果你用的是 100 脚以内的封装基本只有 RMII 可选。1.2 DMA 描述符才是吞吐的真正天花板ETH 外设的 DMA 用的是描述符环结构内存里预先摆好一圈描述符每个描述符记录一个缓冲区的地址、长度和所有权标志。收包时 DMA 顺着环往下写写完一个就把所有权还给 CPU 并触发中断发包时反过来CPU 填好描述符把所有权交给 DMADMA 发完再归还。这套机制的好处是零拷贝——数据直接从网口进内存CPU 只处理指针。但它也带来一个非常隐蔽的坑描述符和缓冲区必须放在 DMA 能访问、且不会被 Cache 捣乱的内存区域。在 F4 这类没有 D-Cache 的芯片上把描述符随便放全局变量区通常没事到了 H7、F7D-Cache 一开DMA 写进内存的数据 CPU 可能读到旧值表现就是“明明抓包看到有数据进来程序里却是空的”。这不是 lwIP 的 bug是 Cache 一致性没处理。缓冲区数量也有讲究。以 100Mbps 全双工为例最小帧 64 字节加前导码和帧间隙约 84 字节理论上限接近每秒 14.8 万个包。如果你的接收缓冲区只有 2 个、每个 1524 字节来一波突发小包立刻就溢出DMA 只能丢包。我一般至少配 4 个接收缓冲做 TCP 吞吐测试时给到 8 个代价是几 KB 内存很划算。1.3 中断、轮询和混合模式怎么挑ETH 的 DMA 支持三种工作方式中断模式、轮询模式、混合模式。裸机小数据量场景我倾向接收用中断、发送用轮询的混合模式因为发送完成中断触发太频繁每发一个包进一次中断CPU 全耗在进出中断上了而接收必须及时响应晚一点缓冲区就被覆盖。CubeMX 里对应的是ETH_RXINTERRUPT_MODE和ETH_TXPOLLING_MODE这组宏默认值就是混合很多人没注意过。如果跑 RTOS中断里绝对不能直接跑协议栈。标准做法是中断里只释放一个信号量让 lwIP 的接收线程去处理。这里有个优先级陷阱ETH 中断的 NVIC 优先级数值必须大于等于 RTOS 的configMAX_SYSCALL_INTERRUPT_PRIORITY数值越大优先级越低否则中断里调用带 FromISR 后缀的 API 会直接触发断言。我见过有人把 ETH 中断设成最高优先级结果一插网线就 HardFault查了两天才发现是这一行配置。2. 硬件设计原理图阶段就能拦掉一半的调试问题2.1 50MHz 参考时钟到底由谁供给谁RMII 模式下MAC 和 PHY 必须共享同一个 50MHz 参考时钟这个时钟叫 REF_CLK。它有两种来源PHY 侧提供PHY 外挂 25MHz 晶振内部倍频到 50MHz 从 REF_CLK 引脚输出给 MCU或者MCU 侧提供MCU 用 MCO 引脚输出 50MHz 给 PHY。第一种方案最常见因为省一个引脚配置而且 PHY 的时钟质量通常比自己用 MCO 分频出来的好。但要注意如果选第一种MCU 的 REF_CLK 引脚必须配置成ETH_REF_CLK 复用功能输入而不是普通 GPIO更不能配成输出。我见过一块板子把 PA1 误配成推挽输出结果 MCU 和 PHY 两个输出对打时钟波形畸变链路能起来但疯狂丢包。第二种方案适合 PHY 没有时钟输出、或者你希望 MCU 做主时钟源的场合。这时候 MCO 输出的 50MHz 必须来自 PLL 的合适分频且要注意 MCO 引脚的驱动能力走线长了要加缓冲。实际项目里我优先选第一种把复杂度留给 PHY。还有一类低成本 PHY 支持无晶振模式直接用 25MHz 外部时钟输入内部 PLL 倍频。这种方案省一颗晶振但对输入时钟的抖动要求更严如果时钟源是从 MCU 分频来的抖动会累积放大不建议在工业环境用。提示REF_CLK 走线尽量短、尽量不走过孔长度控制在允许范围内并做包地处理。这条线是整个 RMII 接口的节拍器它抖一下数据就错一片。2.2 PHY 复位、地址 strap 和 MDIO 上拉PHY 的复位引脚一定要接到 MCU 的 GPIO 上不要图省事直接接 RC 上电复位。原因很简单MCU 复位和 PHY 复位不同步时PHY 可能还停留在上一次的状态尤其是热复位调试时你按了复位键MCU 重新初始化 ETHPHY 却还在自协商寄存器读出来全是错的。标准做法是 MCU 启动后先拉低复位引脚保持一段时间一般 10ms 以上具体看手册再拉高等 100ms 以上让 PHY 完成内部初始化然后才去读寄存器。PHY 地址由 strap 引脚在上电复位瞬间的电平决定常见的是把某个引脚拉高或拉低对应地址 0 或 1。这里最容易出事的是strap 引脚和 MCU 的 BOOT 引脚复用同一个网络——上电瞬间两边抢电平PHY 地址变成了你没预期的值CubeMX 里填的地址和实际对不上HAL_ETH_ReadPHYRegister一直返回错误。我的做法是原理图评审时专门标出所有 strap 引脚确认上电瞬间的电平由谁决定必要时加隔离电阻。MDIO 是开漏结构必须有上拉电阻典型值 1.5kΩ 到 10kΩ。有些 PHY 内部自带弱上拉但驱动能力很弱走线一长上升沿就变缓读寄存器时好时坏。我一般外部再加一个 4.7kΩ 上拉成本几分钱省掉一堆玄学问题。2.3 差分走线、网络变压器和电源去耦RMII 的 TX、RX 是两组差分对要求 100Ω 差分阻抗、对内等长、对间不严格但尽量短。这些都是常规要求真正容易翻车的是网络变压器和 RJ45 的连接方式。带变压器的 RJ45 座子内置变压器的那种接线时要注意中心抽头的处理电流型驱动的 PHY变压器初级中心抽头要接电源电压型驱动的中心抽头要通过电容到地。接反了不会立刻烧但链路质量差、距离一长就断。这个细节在 PHY 手册的典型应用电路里写得很清楚照着抄就行别自己发挥。电源方面PHY 通常要 3.3V 模拟供电内部再有 LDO 产生 1.2V 给内核。3.3V 这路一定要单独去耦每个电源引脚配 0.1μF再并一个 10μF 的钽电容做储能。我遇到过一块板子把 PHY 电源和 MCU 的数字电源直接并联、只放了一个 0.1μF结果跑 TCP 大流量时丢包率飙升换成独立走线加足量去耦后就正常了。数字电路对电源噪声的容忍度比模拟前端高得多别在这上面省。2.4 一份能照着核对的硬件自查清单检查项正确做法常见错误REF_CLK 方向明确由 PHY 或 MCU 单向提供两端都配成输出对打PHY 复位GPIO 控制复位保持 ≥10ms直接接 RC 或接电源PHY 地址核对 strap 引脚上电电平与 BOOT 引脚冲突MDIO 上拉外部 4.7kΩ 上拉只靠内部弱上拉差分阻抗100Ω对内等长走线过长、跨分割变压器中心抽头按 PHY 类型接电源或电容电流型/电压型搞混电源去耦每脚 0.1μF 10μF 储能与数字电源混用单个电容晶振负载电容按晶振规格书选随手用 22pF这张表我在每次打样前都会过一遍硬件阶段多花二十分钟软件阶段能省两天。3. CubeMX 配置从引脚到协议栈的完整落地3.1 时钟树和时基两个必须先想清楚的前提CubeMX 里配 ETH 之前先把时钟树定死。RMII 要求 ETH 的时钟来自 REF_CLK 引脚所以在时钟树里 ETH 那一路要选External PHY 提供的 50MHz而不是内部 PLL。这一步如果选错生成代码里 ETH 的时钟配置就是错的初始化直接卡在HAL_ETH_Init里出不来。时基这一块是另一个高频坑。lwIP 内部大量依赖sys_now()获取毫秒时间戳用来做超时重传、ARP 老化、TCP 定时器。CubeMX 生成的 lwIP 移植层默认把sys_now()映射到HAL_GetTick()。裸机下没问题跑 FreeRTOS 就有隐患HAL_GetTick()依赖 SysTick 中断而 FreeRTOS 也会接管 SysTick两者优先级和调用上下文要仔细核对。我的做法是给 lwIP 单独一个时基源比如用一个 1kHz 的定时器中断累加一个 32 位变量sys_now()直接返回这个变量。这样不管跑不跑 RTOS、SysTick 怎么配lwIP 的时间轴都是独立的不会因为调度器被关中断而停走。代码很简单static volatile uint32_t s_lwip_tick 0; void TIM_LwIP_TickCallback(void) /* 1kHz 定时器中断里调用 */ { s_lwip_tick; } uint32_t sys_now(void) { return s_lwip_tick; }注意这个变量必须是volatile且在 32 位 MCU 上读写是原子的不用加锁。如果是 16 位平台就需要临界区保护了。3.2 ETH 参数逐项说明哪些必须改哪些别动CubeMX 的 ETH 配置页有几个参数我按重要程度排一下PHY 地址必须和硬件 strap 一致这是零容忍项。如果你不确定有个笨办法把地址从 0 到 31 全试一遍能正确读出 PHY 的 ID 寄存器地址 2 和 3的那个就是。正常情况读出来应该是一个固定值全 0 或全 0xFFFF 说明 MDIO 通信根本没建立。自动协商建议开启。开启后 PHY 会和交换机协商出最高的公共速率和双工模式。手动指定速率只在你明确知道对端能力、或者做故障复现时用得上。开着自动协商时如果链路一直起不来先怀疑对端设备或者网线别急着改代码。接收缓冲区数量和大小CubeMX 默认是 4 个描述符每个 1524 字节。做普通控制类应用够用做数据吞吐就要加。我在做文件传输测试时配到 8 个接收描述符配合后面 lwIP 的 pbuf 池调大丢包率才降下来。校验和卸载这块硬件支持 IP/TCP/UDP 校验和由 MAC 自动计算但要注意接收方向的校验和卸载在 lwIP 里需要对应配置 CHECKSUM_CHECK_IP 等宏如果硬件已经校验过软件再校验一次会判为错误包全被丢掉。这个坑很隐蔽现象是“能 ping 通小包但 TCP 大包全部失败”。稳妥起见初期调试可以全部关掉硬件卸载等链路跑通再逐项打开。3.3 lwIP 内存配置默认值几乎一定不够用CubeMX 里 lwIP 的默认配置是给最小系统准备的MEM_SIZE只有 1600 字节左右拿来跑 ping 勉强够跑 TCP 立刻内存分配失败。我一般按下面这组值起步宏默认值建议值作用MEM_SIZE160016384堆内存总量MEMP_NUM_PBUF1632pbuf 结构体数量PBUF_POOL_SIZE1632pbuf 池元素数MEMP_NUM_TCP_PCB510并发 TCP 连接数TCP_MSS5361460单段最大负载TCP_SND_BUF10245840发送缓冲TCP_WND20485840接收窗口这些值的逻辑是这样的TCP_MSS设成 1460 是扣掉 20 字节 IP 头和 20 字节 TCP 头之后的 MTU 余量TCP_SND_BUF至少要是 MSS 的 4 倍左右否则发送队列一直满吞吐上不去TCP_WND决定对端一次能发多少不被确认的数据窗口太小等于自己给自己限速。内存总量要能兜住最坏情况。粗略估算TCP 收发缓冲各 5.8KB加上 pbuf 池 32×1524 约 48KB再加上堆里其他开销MEM_SIZE给到 16KB 是底线做高吞吐给到 32KB。STM32F407 有 192KB RAM完全放得下如果你用的是 64KB RAM 的小型号就得在并发连接数和缓冲大小之间做取舍。注意MEM_SIZE调大之后要确认链接脚本里的堆区足够否则 lwIP 初始化时mem_init会失败而 CubeMX 生成的代码默认不检查这个返回值你会看到程序正常运行但一个连接都建不起来。3.4 生成代码后必须手工补的几处CubeMX 生成的MX_LWIP_Init()里会调用netif_add和ethernetif_init但有几处它不会帮你做第一确认网卡结构体的初始化顺序。MX_LWIP_Init()必须在 ETH 外设初始化之后调用且要在中断使能之前完成ethernetif_init否则早期到来的中断会访问未初始化的网卡结构。CubeMX 一般能排对但你如果手工调整过初始化顺序就要留意。第二静态 IP 还是 DHCP。直连 PC 调试时用静态 IP 最省事避免 DHCP 超时等半天。配置里把LWIP_DHCP关掉手动填 IP、掩码、网关。用 DHCP 的话记得检查dhcp_start有没有被调用以及超时后的回退逻辑。第三MPU 配置仅 H7/F7。如果用带 D-Cache 的芯片必须把 ETH 描述符和缓冲区所在的 RAM 区域配成 non-cacheable或者每次 DMA 操作前后手工维护 Cache。前者的代码大概长这样MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress 0x30040000; MPU_InitStruct.Size MPU_REGION_SIZE_256KB; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsShareable MPU_ACCESS_SHAREABLE; MPU_InitStruct.Number MPU_REGION_NUMBER0; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL1; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_DISABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);这段配置的意思是把 0x30040000 开始的 256KB 区域标成不缓存、可共享专门给 DMA 用。描述符和缓冲区都放到这个段里Cache 一致性就不用操心了。H7 的 D2 SRAM 正好在这个地址段CubeMX 的链接脚本里可以加一个 section 把相关变量定位过去。4. lwIP 联调实录从 ping 通到长时间跑 TCP4.1 第一关链路状态和自协商到底成没成代码烧进去第一件事不是 ping是读 PHY 的状态寄存器确认链路已建立。大部分 PHY 的状态寄存器第 2 位是 Link Status第 3 位是 Auto-Negotiate Complete。如果这两位是 0说明物理层就没通后面所有软件调试都是白费。我在实际项目里写了一个小函数上电后循环打印 PHY 的 BMSR 和自协商结果串口一看就知道卡在哪uint16_t bmsr 0, bmcr 0; HAL_ETH_ReadPHYRegister(heth, PHY_ADDR, PHY_BMSR_REG, (uint32_t *)bmsr); if (!(bmsr PHY_LINK_STATUS)) { printf(link down, check cable/PHY power\r\n); } else { HAL_ETH_ReadPHYRegister(heth, PHY_ADDR, PHY_SPEC_STATUS_REG, (uint32_t *)bmcr); printf(link up, speed%d, duplex%d\r\n, (bmcr 0x4000) ? 100 : 10, (bmcr 0x2000) ? 1 : 0); }常见现象是接交换机链路正常直连 PC 起不来。原因多半是 PC 网卡和 PHY 的自协商能力不匹配或者 PC 端网卡被强制设成了固定速率。还有一个更隐蔽的某些 PHY 在自协商失败后会回退到 10M 半双工这时候链路灯是亮的但 RMII 的 50MHz 时钟和 10M 模式下的时序对不上收到的包全是错。所以看到链路亮了别高兴太早一定要把速率和双工读出来确认。4.2 第二关ARP 和 IP 配置ping 不通的分水岭链路通了下一步是 ping。PC 端ping 192.168.1.100返回“请求超时”这时候要分两种可能根本没收到 ARP 请求或者收到了但没回。排查方法是抓包。在 PC 上开抓包工具看有没有 ARP 广播出去、有没有回应。如果只有请求没有回应问题在 MCU 侧如果有回应但 ping 还是不通问题在 IP 层。MCU 侧收不到 ARP最常见的三个原因IP 地址和 PC 不在同一网段这个低级错误我犯过、netif 没有正确设置 up 状态、接收中断没使能。前两个查配置第三个查代码——CubeMX 生成的MX_LWIP_Init里会调用netif_set_up但如果你在后面又调了一次netif_set_down做重连逻辑忘了恢复就一直是 down 状态。还有一种情况是 ARP 能通、ping 不通这时候看 ICMP 校验和。如果开了硬件接收校验和卸载而 lwIP 配置里又开了软件校验两者打架ICMP 包会被判为坏包丢弃。我一般调试阶段把所有硬件校验和卸载全关等 ping 通了再逐项开每次开一项测一次出问题立刻能定位。4.3 第三关内存和中断优先级跑一会儿就断的元凶ping 通了觉得大功告成结果挂机跑一晚上第二天发现连不上了。这类“跑一会儿就断”的问题八成是内存泄漏或者优先级配置错误。内存这块lwIP 的 pbuf 有专门的释放函数pbuf_free每次接收数据后必须调用漏一次就少一块内存。如果内存泄漏表现是刚开始一切正常跑几十分钟后连接建立失败、mem_malloc返回 NULL。我一般会在调试版本里加一个统计把MEM_SIZE的剩余量和最大使用量定期打印出来看是不是单调递减。中断优先级的问题更隐蔽。ETH 中断里调用了 FreeRTOS 的xSemaphoreGiveFromISR如果 ETH 中断优先级数值小于configMAX_SYSCALL_INTERRUPT_PRIORITY会触发断言configASSERT( ucCurrentPriority ucMaxSysCallPriority )。有些工程把断言关掉了于是不报错但信号量实际没给出接收线程永远等不到通知表现为“能发不能收”或者“跑着跑着不收了”。配置原则记一句话ETH 中断优先级数值必须大于等于 RTOS 允许调用 API 的最高优先级数值。以常见的配置为例configMAX_SYSCALL_INTERRUPT_PRIORITY是 5那么 ETH 中断设成 5 或 6 都行设成 4 就错了。注意这里说的是优先级数值不是优先级高低数值越大优先级越低很多人在这上面绕晕。还有一处容易忽略的lwIP 的接收线程优先级不能太低。如果系统里有其他高优先级任务长期占用 CPU接收线程得不到调度DMA 缓冲区被写满就会丢包。我一般把网络线程放在中等偏上的优先级既不会被饿死也不会挤占实时控制任务。4.4 做一次 TCP 回环压测验证长时间跑的能力功能通了不等于能用必须做压测。我的标准流程是在 MCU 上跑一个 TCP echo 服务PC 端用工具连续发数据跑半小时以上同时统计吞吐、丢包、内存占用。测试结果怎么看100Mbps 全双工的物理上限是 12.5MB/s实际能做到 3~8MB/s 就算不错因为 lwIP 是单线程轮询处理每个包都要走一遍协议栈。如果只有几百 KB/s瓶颈通常在三个地方TCP_SND_BUF太小、每次发送的块太小小于 MSS 会浪费、接收线程被频繁打断。我做过一组对比同样硬件下把TCP_SND_BUF从 1024 调到 5840吞吐从 1.2MB/s 提到 3.5MB/s再把接收描述符从 4 个加到 8 个丢包率从千分之三降到接近零。这两个参数的收益比换芯片还明显。压测期间还要盯着一个指标连接数增长。如果每次断开重连都留下一条残留 PCB跑几小时后MEMP_NUM_TCP_PCB就耗尽了。这通常是因为没有正确处理 FIN 包或者没有调用tcp_close。调试时可以把当前 PCB 数量打印出来看是否随连接次数线性增长。5. 常见问题速查与几年踩坑经验5.1 一张能对着现象找原因的速查表现象最可能的原因排查动作链路灯不亮PHY 供电、复位、变压器接线量 PHY 电源读 BMSR 寄存器链路灯亮但 ping 不通网段不一致、netif 未 up抓 ARP打印本机 IP 配置小包通、大包失败校验和卸载冲突、MTU 配置关硬件校验和逐步打开能发不能收接收中断没使能、RTOS 优先级错查 NVIC查 configMAX_SYSCALL跑一段时间后断连内存泄漏、PCB 未释放打印剩余堆内存和 PCB 数量直连 PC 不通、接交换机正常自协商降级到 10M 半双工读速率和双工寄存器重启后第一次能通后续失败PHY 复位时序不同步加长复位保持时间重新初始化大流量下偶发丢包接收描述符太少、电源噪声增加缓冲数检查 PHY 去耦5.2 几条写不进手册但真能救命的经验第一条永远先确认物理层再动软件。我见过太多人一上来就改 lwIP 配置改了一下午发现是网线水晶头压得不好。花五十块钱买个网络测试仪三十秒就能排除掉线序和通断问题比看代码高效得多。第二条PHY 的复位和初始化顺序要写成固定的状态机。不要依赖上电自然复位也不要假设读一次寄存器就能拿到正确值。我的做法是拉低复位 → 延时 → 拉高 → 轮询等待 PHY 的复位完成位 → 读 ID 校验 → 配置自协商 → 等待链路建立。每一步都有超时超时就报错不往下走。这样出问题的时候串口直接告诉你是哪一步挂了。第三条调试阶段把硬件卸载全部关掉。校验和卸载、中断合并这些优化项等功能全部跑通、稳定性验证过之后再逐项打开每开一项做一轮回归测试。硬件卸载能省 CPU但它出错时的现象和软件 bug 几乎一样混在一起查会很痛苦。第四条给网络部分留一个独立的调试串口输出通道。不要和主业务日志混在一起用环形缓冲加异步输出避免打印本身拖慢网络处理。我一般在网络线程里只记状态变化和错误码详细日志放到低优先级任务里慢慢吐。第五条把重连逻辑当成一等公民来设计。网线被拔掉再插回来是现场最常见的场景。要处理链路 down 时停止 DHCP、释放连接、清空缓冲链路恢复后重新初始化。如果这套逻辑没做现场表现就是“拔一次网线必须重启设备”。实现上可以起一个低优先级任务每秒查一次链路状态状态变化时走对应的处理分支比在中断里做要安全得多。我自己在做这类项目时还有个习惯把每次调试遇到的问题和最终原因记在一个表格里按“现象—排查路径—根因”三列记。同一个坑第二次遇到时翻表比翻代码快。以太网这部分的问题尤其如此因为现象高度同质化能快速区分是物理层、MAC 层还是协议栈层问题就解决一大半了。后面如果要在同一套硬件上跑 UDP 广播或者做多连接服务前面积累的这组参数基本可以直接复用只需要把并发连接数和 pbuf 池按实际负载再调一轮。
画一块带网口的板子硬件打样回来插上网线PC 端 ping 一下没反应链路灯却亮着——这种情况我遇到过不止一次。STM32 的以太网 ETH 外设看着只是外设树里的一个勾选项但从 MAC 层的 DMA 描述符到板子上那对 100Ω 差分线再到 lwIP 里的内存池大小任何一环出问题现象都长得几乎一模一样ping 不通、丢包、跑一会儿就断。所以这篇东西我不打算按“先介绍后总结”的顺序写而是按我实际调试的顺序来先把 ETH 外设的骨架讲清楚再回到原理图阶段哪些地方最容易埋雷然后是 CubeMX 里那几个真正影响成败的参数最后是 lwIP 联调时踩过的坑。适合刚接触 STM32 以太网、准备自己画板或者正在被 ping 不通困扰的人看硬件和软件的朋友都能对号入座。1. 先把 ETH 外设的骨架讲透MAC、DMA 和 PHY 谁干什么活1.1 三个角色分工谁收包谁搬包谁翻译电平很多人一上来就调 CubeMX其实连 ETH 外设内部有几块东西都没分清。STM32 的以太网外设本质上是一个MAC 控制器加一套 DMA 引擎它只处理数字逻辑层面的帧组装和校验物理层的电平转换、编码、自协商全部交给外部的 PHY 芯片。三者关系可以这么理解PHY 是翻译官负责把双绞线上的模拟波形翻译成 0/1MAC 是收发室的文员负责给数据加上帧头帧尾、算 CRC、判断这个包是不是发给自己的DMA 是搬运工负责把文员整理好的数据整块搬到内存里不占用 CPU 一个字节一个字节去读寄存器。这个分工决定了调试点位的划分。链路灯亮不亮是 PHY 的事能不能收到 CRC 正确的帧是 MAC 的事收到了但应用层看不见是 DMA 描述符和 lwIP 的事。我习惯在排查前先问一句“现在卡在哪一层”而不是直接翻 lwIP 源码。链条上任何一环断掉最终表现都是 ping 不通但排查路径完全不同。还有一点常被忽略MAC 和 PHY 之间的接口有两种MII 和 RMII。MII 是 4 位数据宽、需要 25MHz 时钟RMII 精简到 2 位数据宽但时钟要 50MHz。对 STM32 这类引脚紧张的芯片绝大多数项目选 RMII代价是对时钟质量要求更高——50MHz 走线稍微长一点、阻抗不连续眼图就塌了。选型时如果板子面积充裕、又不想在时钟上折腾MII 反而省心但如果你用的是 100 脚以内的封装基本只有 RMII 可选。1.2 DMA 描述符才是吞吐的真正天花板ETH 外设的 DMA 用的是描述符环结构内存里预先摆好一圈描述符每个描述符记录一个缓冲区的地址、长度和所有权标志。收包时 DMA 顺着环往下写写完一个就把所有权还给 CPU 并触发中断发包时反过来CPU 填好描述符把所有权交给 DMADMA 发完再归还。这套机制的好处是零拷贝——数据直接从网口进内存CPU 只处理指针。但它也带来一个非常隐蔽的坑描述符和缓冲区必须放在 DMA 能访问、且不会被 Cache 捣乱的内存区域。在 F4 这类没有 D-Cache 的芯片上把描述符随便放全局变量区通常没事到了 H7、F7D-Cache 一开DMA 写进内存的数据 CPU 可能读到旧值表现就是“明明抓包看到有数据进来程序里却是空的”。这不是 lwIP 的 bug是 Cache 一致性没处理。缓冲区数量也有讲究。以 100Mbps 全双工为例最小帧 64 字节加前导码和帧间隙约 84 字节理论上限接近每秒 14.8 万个包。如果你的接收缓冲区只有 2 个、每个 1524 字节来一波突发小包立刻就溢出DMA 只能丢包。我一般至少配 4 个接收缓冲做 TCP 吞吐测试时给到 8 个代价是几 KB 内存很划算。1.3 中断、轮询和混合模式怎么挑ETH 的 DMA 支持三种工作方式中断模式、轮询模式、混合模式。裸机小数据量场景我倾向接收用中断、发送用轮询的混合模式因为发送完成中断触发太频繁每发一个包进一次中断CPU 全耗在进出中断上了而接收必须及时响应晚一点缓冲区就被覆盖。CubeMX 里对应的是ETH_RXINTERRUPT_MODE和ETH_TXPOLLING_MODE这组宏默认值就是混合很多人没注意过。如果跑 RTOS中断里绝对不能直接跑协议栈。标准做法是中断里只释放一个信号量让 lwIP 的接收线程去处理。这里有个优先级陷阱ETH 中断的 NVIC 优先级数值必须大于等于 RTOS 的configMAX_SYSCALL_INTERRUPT_PRIORITY数值越大优先级越低否则中断里调用带 FromISR 后缀的 API 会直接触发断言。我见过有人把 ETH 中断设成最高优先级结果一插网线就 HardFault查了两天才发现是这一行配置。2. 硬件设计原理图阶段就能拦掉一半的调试问题2.1 50MHz 参考时钟到底由谁供给谁RMII 模式下MAC 和 PHY 必须共享同一个 50MHz 参考时钟这个时钟叫 REF_CLK。它有两种来源PHY 侧提供PHY 外挂 25MHz 晶振内部倍频到 50MHz 从 REF_CLK 引脚输出给 MCU或者MCU 侧提供MCU 用 MCO 引脚输出 50MHz 给 PHY。第一种方案最常见因为省一个引脚配置而且 PHY 的时钟质量通常比自己用 MCO 分频出来的好。但要注意如果选第一种MCU 的 REF_CLK 引脚必须配置成ETH_REF_CLK 复用功能输入而不是普通 GPIO更不能配成输出。我见过一块板子把 PA1 误配成推挽输出结果 MCU 和 PHY 两个输出对打时钟波形畸变链路能起来但疯狂丢包。第二种方案适合 PHY 没有时钟输出、或者你希望 MCU 做主时钟源的场合。这时候 MCO 输出的 50MHz 必须来自 PLL 的合适分频且要注意 MCO 引脚的驱动能力走线长了要加缓冲。实际项目里我优先选第一种把复杂度留给 PHY。还有一类低成本 PHY 支持无晶振模式直接用 25MHz 外部时钟输入内部 PLL 倍频。这种方案省一颗晶振但对输入时钟的抖动要求更严如果时钟源是从 MCU 分频来的抖动会累积放大不建议在工业环境用。提示REF_CLK 走线尽量短、尽量不走过孔长度控制在允许范围内并做包地处理。这条线是整个 RMII 接口的节拍器它抖一下数据就错一片。2.2 PHY 复位、地址 strap 和 MDIO 上拉PHY 的复位引脚一定要接到 MCU 的 GPIO 上不要图省事直接接 RC 上电复位。原因很简单MCU 复位和 PHY 复位不同步时PHY 可能还停留在上一次的状态尤其是热复位调试时你按了复位键MCU 重新初始化 ETHPHY 却还在自协商寄存器读出来全是错的。标准做法是 MCU 启动后先拉低复位引脚保持一段时间一般 10ms 以上具体看手册再拉高等 100ms 以上让 PHY 完成内部初始化然后才去读寄存器。PHY 地址由 strap 引脚在上电复位瞬间的电平决定常见的是把某个引脚拉高或拉低对应地址 0 或 1。这里最容易出事的是strap 引脚和 MCU 的 BOOT 引脚复用同一个网络——上电瞬间两边抢电平PHY 地址变成了你没预期的值CubeMX 里填的地址和实际对不上HAL_ETH_ReadPHYRegister一直返回错误。我的做法是原理图评审时专门标出所有 strap 引脚确认上电瞬间的电平由谁决定必要时加隔离电阻。MDIO 是开漏结构必须有上拉电阻典型值 1.5kΩ 到 10kΩ。有些 PHY 内部自带弱上拉但驱动能力很弱走线一长上升沿就变缓读寄存器时好时坏。我一般外部再加一个 4.7kΩ 上拉成本几分钱省掉一堆玄学问题。2.3 差分走线、网络变压器和电源去耦RMII 的 TX、RX 是两组差分对要求 100Ω 差分阻抗、对内等长、对间不严格但尽量短。这些都是常规要求真正容易翻车的是网络变压器和 RJ45 的连接方式。带变压器的 RJ45 座子内置变压器的那种接线时要注意中心抽头的处理电流型驱动的 PHY变压器初级中心抽头要接电源电压型驱动的中心抽头要通过电容到地。接反了不会立刻烧但链路质量差、距离一长就断。这个细节在 PHY 手册的典型应用电路里写得很清楚照着抄就行别自己发挥。电源方面PHY 通常要 3.3V 模拟供电内部再有 LDO 产生 1.2V 给内核。3.3V 这路一定要单独去耦每个电源引脚配 0.1μF再并一个 10μF 的钽电容做储能。我遇到过一块板子把 PHY 电源和 MCU 的数字电源直接并联、只放了一个 0.1μF结果跑 TCP 大流量时丢包率飙升换成独立走线加足量去耦后就正常了。数字电路对电源噪声的容忍度比模拟前端高得多别在这上面省。2.4 一份能照着核对的硬件自查清单检查项正确做法常见错误REF_CLK 方向明确由 PHY 或 MCU 单向提供两端都配成输出对打PHY 复位GPIO 控制复位保持 ≥10ms直接接 RC 或接电源PHY 地址核对 strap 引脚上电电平与 BOOT 引脚冲突MDIO 上拉外部 4.7kΩ 上拉只靠内部弱上拉差分阻抗100Ω对内等长走线过长、跨分割变压器中心抽头按 PHY 类型接电源或电容电流型/电压型搞混电源去耦每脚 0.1μF 10μF 储能与数字电源混用单个电容晶振负载电容按晶振规格书选随手用 22pF这张表我在每次打样前都会过一遍硬件阶段多花二十分钟软件阶段能省两天。3. CubeMX 配置从引脚到协议栈的完整落地3.1 时钟树和时基两个必须先想清楚的前提CubeMX 里配 ETH 之前先把时钟树定死。RMII 要求 ETH 的时钟来自 REF_CLK 引脚所以在时钟树里 ETH 那一路要选External PHY 提供的 50MHz而不是内部 PLL。这一步如果选错生成代码里 ETH 的时钟配置就是错的初始化直接卡在HAL_ETH_Init里出不来。时基这一块是另一个高频坑。lwIP 内部大量依赖sys_now()获取毫秒时间戳用来做超时重传、ARP 老化、TCP 定时器。CubeMX 生成的 lwIP 移植层默认把sys_now()映射到HAL_GetTick()。裸机下没问题跑 FreeRTOS 就有隐患HAL_GetTick()依赖 SysTick 中断而 FreeRTOS 也会接管 SysTick两者优先级和调用上下文要仔细核对。我的做法是给 lwIP 单独一个时基源比如用一个 1kHz 的定时器中断累加一个 32 位变量sys_now()直接返回这个变量。这样不管跑不跑 RTOS、SysTick 怎么配lwIP 的时间轴都是独立的不会因为调度器被关中断而停走。代码很简单static volatile uint32_t s_lwip_tick 0; void TIM_LwIP_TickCallback(void) /* 1kHz 定时器中断里调用 */ { s_lwip_tick; } uint32_t sys_now(void) { return s_lwip_tick; }注意这个变量必须是volatile且在 32 位 MCU 上读写是原子的不用加锁。如果是 16 位平台就需要临界区保护了。3.2 ETH 参数逐项说明哪些必须改哪些别动CubeMX 的 ETH 配置页有几个参数我按重要程度排一下PHY 地址必须和硬件 strap 一致这是零容忍项。如果你不确定有个笨办法把地址从 0 到 31 全试一遍能正确读出 PHY 的 ID 寄存器地址 2 和 3的那个就是。正常情况读出来应该是一个固定值全 0 或全 0xFFFF 说明 MDIO 通信根本没建立。自动协商建议开启。开启后 PHY 会和交换机协商出最高的公共速率和双工模式。手动指定速率只在你明确知道对端能力、或者做故障复现时用得上。开着自动协商时如果链路一直起不来先怀疑对端设备或者网线别急着改代码。接收缓冲区数量和大小CubeMX 默认是 4 个描述符每个 1524 字节。做普通控制类应用够用做数据吞吐就要加。我在做文件传输测试时配到 8 个接收描述符配合后面 lwIP 的 pbuf 池调大丢包率才降下来。校验和卸载这块硬件支持 IP/TCP/UDP 校验和由 MAC 自动计算但要注意接收方向的校验和卸载在 lwIP 里需要对应配置 CHECKSUM_CHECK_IP 等宏如果硬件已经校验过软件再校验一次会判为错误包全被丢掉。这个坑很隐蔽现象是“能 ping 通小包但 TCP 大包全部失败”。稳妥起见初期调试可以全部关掉硬件卸载等链路跑通再逐项打开。3.3 lwIP 内存配置默认值几乎一定不够用CubeMX 里 lwIP 的默认配置是给最小系统准备的MEM_SIZE只有 1600 字节左右拿来跑 ping 勉强够跑 TCP 立刻内存分配失败。我一般按下面这组值起步宏默认值建议值作用MEM_SIZE160016384堆内存总量MEMP_NUM_PBUF1632pbuf 结构体数量PBUF_POOL_SIZE1632pbuf 池元素数MEMP_NUM_TCP_PCB510并发 TCP 连接数TCP_MSS5361460单段最大负载TCP_SND_BUF10245840发送缓冲TCP_WND20485840接收窗口这些值的逻辑是这样的TCP_MSS设成 1460 是扣掉 20 字节 IP 头和 20 字节 TCP 头之后的 MTU 余量TCP_SND_BUF至少要是 MSS 的 4 倍左右否则发送队列一直满吞吐上不去TCP_WND决定对端一次能发多少不被确认的数据窗口太小等于自己给自己限速。内存总量要能兜住最坏情况。粗略估算TCP 收发缓冲各 5.8KB加上 pbuf 池 32×1524 约 48KB再加上堆里其他开销MEM_SIZE给到 16KB 是底线做高吞吐给到 32KB。STM32F407 有 192KB RAM完全放得下如果你用的是 64KB RAM 的小型号就得在并发连接数和缓冲大小之间做取舍。注意MEM_SIZE调大之后要确认链接脚本里的堆区足够否则 lwIP 初始化时mem_init会失败而 CubeMX 生成的代码默认不检查这个返回值你会看到程序正常运行但一个连接都建不起来。3.4 生成代码后必须手工补的几处CubeMX 生成的MX_LWIP_Init()里会调用netif_add和ethernetif_init但有几处它不会帮你做第一确认网卡结构体的初始化顺序。MX_LWIP_Init()必须在 ETH 外设初始化之后调用且要在中断使能之前完成ethernetif_init否则早期到来的中断会访问未初始化的网卡结构。CubeMX 一般能排对但你如果手工调整过初始化顺序就要留意。第二静态 IP 还是 DHCP。直连 PC 调试时用静态 IP 最省事避免 DHCP 超时等半天。配置里把LWIP_DHCP关掉手动填 IP、掩码、网关。用 DHCP 的话记得检查dhcp_start有没有被调用以及超时后的回退逻辑。第三MPU 配置仅 H7/F7。如果用带 D-Cache 的芯片必须把 ETH 描述符和缓冲区所在的 RAM 区域配成 non-cacheable或者每次 DMA 操作前后手工维护 Cache。前者的代码大概长这样MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress 0x30040000; MPU_InitStruct.Size MPU_REGION_SIZE_256KB; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsShareable MPU_ACCESS_SHAREABLE; MPU_InitStruct.Number MPU_REGION_NUMBER0; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL1; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_DISABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);这段配置的意思是把 0x30040000 开始的 256KB 区域标成不缓存、可共享专门给 DMA 用。描述符和缓冲区都放到这个段里Cache 一致性就不用操心了。H7 的 D2 SRAM 正好在这个地址段CubeMX 的链接脚本里可以加一个 section 把相关变量定位过去。4. lwIP 联调实录从 ping 通到长时间跑 TCP4.1 第一关链路状态和自协商到底成没成代码烧进去第一件事不是 ping是读 PHY 的状态寄存器确认链路已建立。大部分 PHY 的状态寄存器第 2 位是 Link Status第 3 位是 Auto-Negotiate Complete。如果这两位是 0说明物理层就没通后面所有软件调试都是白费。我在实际项目里写了一个小函数上电后循环打印 PHY 的 BMSR 和自协商结果串口一看就知道卡在哪uint16_t bmsr 0, bmcr 0; HAL_ETH_ReadPHYRegister(heth, PHY_ADDR, PHY_BMSR_REG, (uint32_t *)bmsr); if (!(bmsr PHY_LINK_STATUS)) { printf(link down, check cable/PHY power\r\n); } else { HAL_ETH_ReadPHYRegister(heth, PHY_ADDR, PHY_SPEC_STATUS_REG, (uint32_t *)bmcr); printf(link up, speed%d, duplex%d\r\n, (bmcr 0x4000) ? 100 : 10, (bmcr 0x2000) ? 1 : 0); }常见现象是接交换机链路正常直连 PC 起不来。原因多半是 PC 网卡和 PHY 的自协商能力不匹配或者 PC 端网卡被强制设成了固定速率。还有一个更隐蔽的某些 PHY 在自协商失败后会回退到 10M 半双工这时候链路灯是亮的但 RMII 的 50MHz 时钟和 10M 模式下的时序对不上收到的包全是错。所以看到链路亮了别高兴太早一定要把速率和双工读出来确认。4.2 第二关ARP 和 IP 配置ping 不通的分水岭链路通了下一步是 ping。PC 端ping 192.168.1.100返回“请求超时”这时候要分两种可能根本没收到 ARP 请求或者收到了但没回。排查方法是抓包。在 PC 上开抓包工具看有没有 ARP 广播出去、有没有回应。如果只有请求没有回应问题在 MCU 侧如果有回应但 ping 还是不通问题在 IP 层。MCU 侧收不到 ARP最常见的三个原因IP 地址和 PC 不在同一网段这个低级错误我犯过、netif 没有正确设置 up 状态、接收中断没使能。前两个查配置第三个查代码——CubeMX 生成的MX_LWIP_Init里会调用netif_set_up但如果你在后面又调了一次netif_set_down做重连逻辑忘了恢复就一直是 down 状态。还有一种情况是 ARP 能通、ping 不通这时候看 ICMP 校验和。如果开了硬件接收校验和卸载而 lwIP 配置里又开了软件校验两者打架ICMP 包会被判为坏包丢弃。我一般调试阶段把所有硬件校验和卸载全关等 ping 通了再逐项开每次开一项测一次出问题立刻能定位。4.3 第三关内存和中断优先级跑一会儿就断的元凶ping 通了觉得大功告成结果挂机跑一晚上第二天发现连不上了。这类“跑一会儿就断”的问题八成是内存泄漏或者优先级配置错误。内存这块lwIP 的 pbuf 有专门的释放函数pbuf_free每次接收数据后必须调用漏一次就少一块内存。如果内存泄漏表现是刚开始一切正常跑几十分钟后连接建立失败、mem_malloc返回 NULL。我一般会在调试版本里加一个统计把MEM_SIZE的剩余量和最大使用量定期打印出来看是不是单调递减。中断优先级的问题更隐蔽。ETH 中断里调用了 FreeRTOS 的xSemaphoreGiveFromISR如果 ETH 中断优先级数值小于configMAX_SYSCALL_INTERRUPT_PRIORITY会触发断言configASSERT( ucCurrentPriority ucMaxSysCallPriority )。有些工程把断言关掉了于是不报错但信号量实际没给出接收线程永远等不到通知表现为“能发不能收”或者“跑着跑着不收了”。配置原则记一句话ETH 中断优先级数值必须大于等于 RTOS 允许调用 API 的最高优先级数值。以常见的配置为例configMAX_SYSCALL_INTERRUPT_PRIORITY是 5那么 ETH 中断设成 5 或 6 都行设成 4 就错了。注意这里说的是优先级数值不是优先级高低数值越大优先级越低很多人在这上面绕晕。还有一处容易忽略的lwIP 的接收线程优先级不能太低。如果系统里有其他高优先级任务长期占用 CPU接收线程得不到调度DMA 缓冲区被写满就会丢包。我一般把网络线程放在中等偏上的优先级既不会被饿死也不会挤占实时控制任务。4.4 做一次 TCP 回环压测验证长时间跑的能力功能通了不等于能用必须做压测。我的标准流程是在 MCU 上跑一个 TCP echo 服务PC 端用工具连续发数据跑半小时以上同时统计吞吐、丢包、内存占用。测试结果怎么看100Mbps 全双工的物理上限是 12.5MB/s实际能做到 3~8MB/s 就算不错因为 lwIP 是单线程轮询处理每个包都要走一遍协议栈。如果只有几百 KB/s瓶颈通常在三个地方TCP_SND_BUF太小、每次发送的块太小小于 MSS 会浪费、接收线程被频繁打断。我做过一组对比同样硬件下把TCP_SND_BUF从 1024 调到 5840吞吐从 1.2MB/s 提到 3.5MB/s再把接收描述符从 4 个加到 8 个丢包率从千分之三降到接近零。这两个参数的收益比换芯片还明显。压测期间还要盯着一个指标连接数增长。如果每次断开重连都留下一条残留 PCB跑几小时后MEMP_NUM_TCP_PCB就耗尽了。这通常是因为没有正确处理 FIN 包或者没有调用tcp_close。调试时可以把当前 PCB 数量打印出来看是否随连接次数线性增长。5. 常见问题速查与几年踩坑经验5.1 一张能对着现象找原因的速查表现象最可能的原因排查动作链路灯不亮PHY 供电、复位、变压器接线量 PHY 电源读 BMSR 寄存器链路灯亮但 ping 不通网段不一致、netif 未 up抓 ARP打印本机 IP 配置小包通、大包失败校验和卸载冲突、MTU 配置关硬件校验和逐步打开能发不能收接收中断没使能、RTOS 优先级错查 NVIC查 configMAX_SYSCALL跑一段时间后断连内存泄漏、PCB 未释放打印剩余堆内存和 PCB 数量直连 PC 不通、接交换机正常自协商降级到 10M 半双工读速率和双工寄存器重启后第一次能通后续失败PHY 复位时序不同步加长复位保持时间重新初始化大流量下偶发丢包接收描述符太少、电源噪声增加缓冲数检查 PHY 去耦5.2 几条写不进手册但真能救命的经验第一条永远先确认物理层再动软件。我见过太多人一上来就改 lwIP 配置改了一下午发现是网线水晶头压得不好。花五十块钱买个网络测试仪三十秒就能排除掉线序和通断问题比看代码高效得多。第二条PHY 的复位和初始化顺序要写成固定的状态机。不要依赖上电自然复位也不要假设读一次寄存器就能拿到正确值。我的做法是拉低复位 → 延时 → 拉高 → 轮询等待 PHY 的复位完成位 → 读 ID 校验 → 配置自协商 → 等待链路建立。每一步都有超时超时就报错不往下走。这样出问题的时候串口直接告诉你是哪一步挂了。第三条调试阶段把硬件卸载全部关掉。校验和卸载、中断合并这些优化项等功能全部跑通、稳定性验证过之后再逐项打开每开一项做一轮回归测试。硬件卸载能省 CPU但它出错时的现象和软件 bug 几乎一样混在一起查会很痛苦。第四条给网络部分留一个独立的调试串口输出通道。不要和主业务日志混在一起用环形缓冲加异步输出避免打印本身拖慢网络处理。我一般在网络线程里只记状态变化和错误码详细日志放到低优先级任务里慢慢吐。第五条把重连逻辑当成一等公民来设计。网线被拔掉再插回来是现场最常见的场景。要处理链路 down 时停止 DHCP、释放连接、清空缓冲链路恢复后重新初始化。如果这套逻辑没做现场表现就是“拔一次网线必须重启设备”。实现上可以起一个低优先级任务每秒查一次链路状态状态变化时走对应的处理分支比在中断里做要安全得多。我自己在做这类项目时还有个习惯把每次调试遇到的问题和最终原因记在一个表格里按“现象—排查路径—根因”三列记。同一个坑第二次遇到时翻表比翻代码快。以太网这部分的问题尤其如此因为现象高度同质化能快速区分是物理层、MAC 层还是协议栈层问题就解决一大半了。后面如果要在同一套硬件上跑 UDP 广播或者做多连接服务前面积累的这组参数基本可以直接复用只需要把并发连接数和 pbuf 池按实际负载再调一轮。
