先说结论把 STM32H7 和 LAN8720A 这一套跑通难点不在协议栈而在对硬件细节和 CubeMX 生成代码的敬畏心。ETH LWIP 这种组合用好了是低成本入网利器用不好就是 ping 不通、掉线、内存错乱的劝退现场。这篇作为整个 ETH 与 LWIP 配置系列的收尾我不再从一个空工程开始讲基础操作而是直接把最终定案的配置、调通的思路、踩过的坑全部摊开给正在折腾 H7 以太网的朋友一条能直接走的近路。这个组合的适用场景很明确需要板子通过网线接入局域网跑 TCP/UDP、HTTP、MQTT 这类应用。适合遇到 CubeMX 配完之后 ping 不通、DHCP 拿不到地址、收发一段时间就死机这类问题的开发者也适合刚准备用 LAN8720A 做第一块以太网板子的朋友。整套配置基于 STM32H743 和 LAN8720A用 RMII 接口配合最新版 STM32CubeMX当时用的 6.x 系列生成的工程下面所有内容都按这个前提展开。1. 整体设计思路与方案定案1.1 为什么选 STM32H7 LAN8720A 这个组合选型这事光看参数容易上头。STM32H7 系列内置了 10/100M 以太网 MAC 控制器支持 MII 和 RMII 两种接口模式。MAC 已经内置我们要做的只是外挂一颗 PHY 芯片把 MAC 的数字信号转成网线上的模拟差分信号。LAN8720A 是 SMSC现为 Microchip一颗很成熟的 10/100M 以太网 PHY 芯片采用 RMII 接口功耗低外围电路简单和 STM32 几乎全系都能配。选择这个组合最核心的理由只有一个成本低、引脚省、资料多。RMII 接口相比 MII 少了将近一半的信号线MII 需要 16 根数据线加控制线RMII 只需要 7 根。对于 STM32H7 这种大封装动辄一百多个引脚的芯片来说引脚不是问题但 PCB 上少走 8 根线还是能省不少事布线压力小EMC 问题也少一些。另外 LAN8720A 在 STM32 生态里被用了很多年CubeMX 直接内置了对这颗 PHY 的支持网上能搜到大量实际验证过的方案遇到问题不容易孤立无援。我实际用下来这颗 PHY 在千兆时代看起来有点老但做工业设备、网关、物联网节点完全够用。10/100M 以太网在绝大多数场景下都不会成为性能瓶颈反而因为技术成熟、协议栈完善调试起来比新的 2.5G PHY 顺手得多。1.2 硬件连接与原理图核对要点软件调不通很多时候是硬件布线埋的雷。LAN8720A 和 STM32H7 走 RMII 接口信号线就这几根TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO加上 REF_CLK 时钟线。这里有个关键选择REF_CLK 从哪来两种常见接法。第一种用外部 50MHz 有源晶振直接把时钟送给 LAN8720A 的 XI 引脚然后由 PHY 内部生成 50MHz 的 REF_CLK 输出给 STM32H7 的 ETH_RMII_REF_CLK 引脚。第二种用 STM32H7 的 MCO2 引脚输出 50MHz 给 LAN8720A。我个人不太推荐第二种因为 MCO2 的时钟源要精确配到 50MHz牵扯到 PLL 的配置稍有不慎时钟就偏了而且 MCO 引脚的驱动能力有限走线稍长就容易信号劣化。最稳的还是外部有源晶振方案一劳永逸。还有一个关键引脚是 PHYAD0它决定 PHY 的地址。LAN8720A 的 PHY 地址由 PHYAD0 引脚的电平决定默认接地为 0x00。这个地址后面在 CubeMX 里要填写在代码里要通过 MDIO 总线访问 PHY 寄存器地址不对读写全是无效操作。硬件上最容易踩的坑是网口变压器的中心抽头。LAN8720A 是 3.3V 供电的 PHY网口变压器中心抽头要按 LAN8720A 数据手册的要求接一般是接一个 1k 电阻上拉到 3.3V不能直接接 3.3V也不能直接接地。这个细节做原理图时必须对着数据手册的参考电路核对我见过不少板子因为中心抽头接错导致网络完全不通或者通信极不稳定。1.3 CubeMX 工程前置准备进 CubeMX 配置 ETH 之前先把时钟树搞定。STM32H7 的时钟树比 F1/F4 复杂得多ETH 外设本身对时钟有一定要求。我的习惯是在 Clock Configuration 页面先确认 AHB 总线的时钟频率然后确保 ETH 的 APB 时钟配置合理。对于以太网 MAC内核时钟会由系统时钟分频得到CubeMX 会自动计算但前提是系统时钟源和 PLL 配置正确。调试口也要提前想好。H7 系列默认的调试口是 SWD有些板子为了省引脚会把 PA13/PA14 复用成其他功能这样调试器就进不去了。建议在 CubeMX 里先把 SYS 的 Debug 设置为 Serial Wire再去做其他的引脚分配否则后面烧录都成问题。如果你要在 RTOS 上跑 LWIP我建议先把裸机的 ETH 调通再裁剪 CubeMX 里的 FreeRTOS 配置。裸机调通意味着 PHY 能 link 上、能 ping 通、收发数据没问题这时候再上 RTOS 和 LWIP 的协作问题范围会小很多。我在实际调试中见过太多人裸机都没通就把 RTOS 打开出了问题根本分不清是协议栈的问题还是任务调度的问题。2. CubeMX 工程配置细节与 LWIP 参数调优2.1 ETH 外设参数配置要点CubeMX 里 ETH 配置页面的内容不算多但每一项都不能含糊。第一个是 Mode选 RMII。如果需要 MII引脚分配都会变但用 LAN8720A 就老老实实选 RMII。第二个是 PHY Address填 0。这个就是前面说的 PHYAD0 引脚决定的默认地址。如果你的原理图上 PHYAD0 接的是高电平这里就要填 1否则 MDIO 读写失败PHY 无法初始化。第三个是 PHY 芯片选择CubeMX 里直接搜 LAN8720A。选择了具体的 PHY 型号之后HAL 库会编译对应的 PHY 驱动代码会定义 PHY 的读写超时时间、复位延时这些参数。第四个是 MAC Address这个随便填一个合法的单播地址就行只要局域网内不冲突即可。注意不要填成组播或广播地址最低字节的最低两位必须是 01 结尾单播 全局唯一。另外还要注意 Ethernet Configuration 里的 PHY 时钟和功耗选项。LAN8720A 的 RMII 模式需要 50MHz 参考时钟如果走的是外部有源晶振方案CubeMX 里不需要额外生成时钟但要在初始化代码里确认 ETH 的时钟配置正确。2.2 LAN8720A 的寄存器差异与 PHY 驱动适配很多人配置完 ETH发现 HAL_ETH_Init 卡在 PHY 通信超时或者读出来的 PHY ID 不对这时候就需要了解 LAN8720A 的寄存器特性。LAN8720A 是标准 IEEE 802.3 定义的 PHY基础寄存器布局和大多数 PHY 相同BCR地址 0x00、BMSR地址 0x01、PHY ID1地址 0x02、PHY ID2地址 0x03、ANAR地址 0x04、ANLPAR地址 0x05等。但它的具体位定义和某些大厂 PHY 有细微差别特别是自动协商状态和速度/双工状态的判断。我在实际调试中遇到过一个经典问题用 CubeMX 生成代码后HAL_ETH_ReadPHYRegister 去读 BMSR发现自动协商完成位bit 5一直不置位。排查了一圈发现是 LAN8720A 的上电时序问题。这颗 PHY 的 nRST 引脚复位后需要等待一段时间才能稳定响应 MDIO 读写时间不够就读取失败。解决办法是把复位延时调大或者在上电后显式地对 PHY 做一次软复位BCR 的 bit 15 置 1然后等待自协商完成。LAN8720A 的自协商默认是开启的BCR 的 bit 12ANEN默认值为 1也就是上电后 PHY 会自动协商速度和双工模式。如果想固定百兆全双工可以关掉自协商并手动设置 BCR 的速度位和双工位。但除非你有特殊用途我建议保持默认的自协商模式因为绝大多数交换机都能协商到百兆全双工。2.3 LWIP 关键参数内存池、PBUF、MSS 与超时LWIP 的参数配置是整个以太网工程的重中之重。CubeMX 的 LWIP 配置页面里有一堆参数看起来密密麻麻但真正决定稳定性的就那么几个。内存相关参数我直接给出一个经过验证的保守配置参数推荐值说明MEM_SIZE1024 * 2020KBLWIP 堆内存用于协议控制块和动态内存分配MEMP_NUM_PBUF20同时允许的 PBUF 数量MEMP_NUM_UDP_PCB8UDP 控制块数量MEMP_NUM_TCP_PCB8TCP 控制块数量MEMP_NUM_TCP_SEG16TCP 分段数量MEMP_NUM_NETBUF16网络缓冲区数量PBUF_POOL_SIZE32PBUF 池大小PBUF_POOL_BUFSIZE1512单个 PBUF 池缓冲区大小要能装下最大以太网帧这些参数不是越大越好因为每加一个数量静态分配的 RAM 就多一块。如果内存充足可以适当放大 PBUF_POOL_SIZE但不要盲目把 MEM_SIZE 开到 100KB因为 LWIP 的堆是通过内存池管理实现的堆太大不仅浪费 RAM还会导致分配效率下降。TCP 相关参数也很关键。TCP_MSS 默认 1460 是正确的不要改大。TCP_WND 是 TCP 接收窗口默认通常是一个 MSS 的倍数建议设置为 10 个 MSS 以上否则 TCP 传输会被窗口限制拖慢。TCP_SND_BUF 建议和 TCP_WND 匹配否则发送和接收能力不一致会导致吞吐量低下。还有一个容易被忽略的参数是 LWIP_DHCP。CubeMX 里默认关闭如果你要自动获取 IP把它改成 Enabled并且在初始化代码里调用dhcp_start()而不是用静态 IP 的方式。反过来如果调试阶段建议先用静态 IP固定一个局域网内不冲突的地址减少 DHCP 这种不确定因素等 ping 通了之后再切换到 DHCP。2.4 不能忽视的 D-Cache 与 MPU 配置STM32H7 的 D-Cache 是 ETH 调试中最大的坑没有之一。H7 内置了 I-Cache 和 D-Cache默认情况下 CubeMX 生成的代码甚至会帮你打开这两路 Cache。问题在于ETH 的 DMA 会直接访问 RAM绕过 CPU 的 Cache。当 DMA 从网络收到数据并写入 RAMCPU 去读这段数据时如果 D-Cache 里缓存了旧数据CPU 读到的就是脏数据。反过来CPU 写了一包数据准备让 DMA 发出去DMA 从 RAM 里读到的可能是旧数据因为新数据还躺在 D-Cache 里没有回写。这就是 H7 上 ping 不通、收发乱码、数据校验失败的隐形凶手。而且这个问题特别恶心的地方在于表现不稳定有时候能通有时候不能通跟你代码里访问网络的频率和时机有关。解决办法有两个。最简单粗暴的是把 ETH 的 DMA 描述符和缓冲区所在的内存区域配置为 non-cacheable。在 CubeMX 里打开 MPUMemory Protection Unit然后添加一个 Region把 ETH 使用的 RAM 区域设置成 Device 或 Strongly-ordered 属性。但实际更推荐设置成 Normal memory non-cacheable因为 Device 类型的访问性能和访问宽度有特殊限制不太适合以太网这种高吞吐场景。具体操作要看你把 DMA 描述符和 buffer 放在哪块 RAM。STM32H7 的 RAM 分布有几个域ETH 的 DMA 复杂操作建议放在 D2 域的 RAM因为 ETH 外设挂载在 D2 域的 AHB 总线上这样 DMA 访问不需要跨总线域切换延迟和功耗都更优。CubeMX 里可以在链接脚本里指定以太网缓冲区的放置区域或者在代码里用 section 属性把描述符和 buffer 定义到指定地址段。如果你不想动 MPU也可以不开启 D-Cache但 H7 主频跑那么高不开启 D-Cache 性能会打折扣。所以正确做法还是开 D-Cache 的同时配好 MPU这是性能与稳定兼顾的唯一正解。3. 实践中的常见问题与排查记录3.1 物理层问题REF_CLK 缺失、Link 灯不亮低级问题最容易卡住人。如果板子上电后网口的 Link 灯不亮第一步不是看软件而是拿起示波器量 PHY 的 REF_CLK 引脚。正常情况下能量到一个稳定的 50MHz 方波或正弦波。没有时钟PHY 就是死了后面全是白搭。如果有源晶振方案确认了时钟没问题再量一下 LAN8720A 的供电是否正常。这颗芯片有模拟电源和数字电源都是 3.3V上电时序要求 3.3V 先稳定nRST 释放后 PHY 才能正常工作。很多板子为了让 PHY 复位可控会把 nRST 接到 MCU 的 GPIO用代码控制复位。这时候要在代码里确认复位时序是对的拉低 nRST 至少 10ms再拉高然后延时至少 100ms 让 PHY 完成内部初始化再初始化 ETH 外设。LAN8720A 的复位还有个细节nRST 拉高的上升沿要足够陡峭。如果 nRST 引脚上接了太大的电容上升沿会变缓可能导致 PHY 复位不彻底。数据手册里对复位脉冲宽度有明确要求做硬件时不要为了滤波在这个引脚上并大电容。3.2 能 Link 但 Ping 不通从 ARP 开始查Link 灯亮了说明物理层没问题但 ping 不通这是最常见的状态。我的排查顺序是先看 ARP再看 LWIP 收包再看发包。在电脑上 ping 开发板如果 IP 不通先抓包看有没有 ARP 请求发出来、有没有 ARP 响应。最简单的办法是在电脑上用 Wireshark 抓包过滤 ARP 协议。如果能看到开发板回 ARP 响应但 ping 还是超时说明 ICMP echo request 可能没有正确处理或者 echo reply 发出去了但出问题。这时候再看 MCU 侧代码。LWIP 的运行需要调用sys_check_timeouts()或者tcpip_thread和信号量的机制以及ethernetif_input()或者中断里调用HAL_ETH_ReadData后交给netif-input。如果主循环里忘了调用这些处理函数LWIP 协议栈就永远不会推进ping 自然不通。另外一个隐蔽的问题是 DMA 描述符的环形队列没有正确初始化。CubeMX 生成的代码一般没问题但如果你自己改过初始化顺序例如在 ETH 外设使能之前就启动了 DMA或者描述符链表的指针没有正确回环DMA 就不知道往哪写数据收包中断永远不会触发。3.3 数据收发不稳定、频繁丢包收发不稳定优先怀疑 D-Cache其次怀疑内存对齐。D-Cache 的问题前面说过了如果 MPU 没配好收发数据就是有概率出错。特别是 DHCP 这类需要多发几次请求的流程表现会非常诡异有时候能拿到 IP 有时候拿不到拿到的 IP 也可能是错误的。内存对齐问题也很常见。DMA 描述符在 STM32H7 的 HAL 库实现中有对齐要求通常需要 4 字节对齐有些配置要求 32 字节对齐。如果你自己定义内存池数组要确保编译器分配时满足对齐要求建议直接用ALIGN_32BYTES之类的宏修饰或者放到单独的 section 里。ARMCC 和 GCC 的对齐语法不一样从 CubeMX 生成代码里抄就行。中断优先级也是丢包的重灾区。ETH 的中断如果优先级太低在中断密集的情况下可能会被其他中断抢占太久导致 DMA 接收描述符溢出新收到的包直接被丢弃。我的习惯是把 ETH 中断优先级设置得比串口高和定时器中断持平。如果你用 FreeRTOS注意中断优先级不要和可管理中断的阈值冲突否则会触发断言失败。3.4 DHCP 分配不到 IP静态 IP 能 ping 通但开启 DHCP 后一直分配不到地址这个问题很多人在 RTOS 环境下遇到过。先说一个容易误导人的点网上搜索 LWIP DHCP 问题时经常会关联到“页面文件配置”之类的词。这其实是两码事LWIP 的 DHCP 和 Windows 的虚拟内存一点关系都没有。LWIP 要的是足够的 PBUF 池和 MEMP_NUM_UDP_PCB因为 DHCP 是基于 UDP 的协议需要 UDP PCB 资源。如果你把 MEMP_NUM_UDP_PCB 减到 4 以下DHCP 可能因为资源不足而失败。DHCP 失败还有一个常见原因LWIP 的 DHCP 状态机需要周期性调用超时处理函数。如果你用的是裸机必须在主循环里每隔几百毫秒调用一次sys_check_timeouts()否则 DHCP 的定时器不会运转永远停留在 DISCOVER 或 REQUEST 状态。如果用的是 RTOS 的 tcpip 线程这个函数会在tcpip_thread中被周期调用一般不用操心。另外板子的 MAC 地址如果全零或者非法某些 DHCP 服务器会拒绝分配。CubeMX 里默认的 MAC 地址虽然随机但格式是正确的不用改。如果你在初始化代码里把 MAC 地址覆盖成全零DHCP 很可能挂掉。3.5 长时间运行后断网或死机这个问题的本质通常是内存泄漏或者 DMA 描述符没有合理回收。LWIP 本身是一个成熟协议栈正常情况下不会随意崩溃但如果应用层分配 PBUF 后没有正确释放或者发送数据时用了tcp_write之后没有处理tcp_sent回调发送缓冲会被逐渐耗尽最终表现为 TCP 断开或无法建立新连接。裸机环境还要注意 ETH 全局中断标志的处理。HAL 库的中断处理函数和 DMA 中断、MAC 中断混在一起如果中断标志没有被正确清除可能导致中断反复触发把 CPU 的老底拖垮。建议在中断服务函数里加上__HAL_ETH_DMA_CLEAR_FLAG这类操作参照 HAL 库例程中的写法。最后也别忽略堆栈溢出。LWIP 内部线程用 RTOS 时需要足够大的栈空间默认给 1024 够用但如果你在回调函数里做了重量级操作比如打印大量日志或者格式化字符串栈可能不够。我的习惯是给 LWIP 线程分配 2048 字节的栈调试阶段留足余量。4. 最终验证与长期稳定运行4.1 完整的验证流程设计调试完成后不要直接认为就万事大吉我觉得至少要跑这样一轮系统验证。第一步是物理层验证。连续 ping 1000 次大包1472 字节 payload对应以太网最大速载荷确保 0 丢包。再 ping 1 万次小包确认 ARP 缓存、ICMP 处理没有问题。第二步是 TCP 层验证。在电脑上开一个 TCP 调试助手主动连接开发板进行双向大量数据收发。比如连续发送 10MB 随机数据确认开发板接收后回传的数据没有一位错误。这个步骤能暴露 DMA 描述符回收、内存池耗尽、校验和处理这类隐患。第三步是长时间稳定性测试。让板子 7x24 小时运行每一小时通过脚本监控一次网络连通性记录掉线次数和恢复情况。如果掉线后能自动恢复要确认是 LWIP 的自动重连机制还是你在应用层做了看门狗如果掉线后无法恢复大概率是底层初始化有问题需要进一步排查。4.2 实际测试中遇到的现象记录我在这套配置上做的实测结果值得分享一下。静态 IP 192.168.1.10电脑直连交换机ping 大包和小包均无丢包。TCP 单向吞吐测试用 iperf 跑发送方向开发板发送电脑接收约 88Mbps接收方向约 84Mbps基本跑满了百兆以太网的实际可用带宽。作为对比板子的主频跑在 400MHzCPU 占用率在收发 80Mbps 数据时大约为 35% 到 45%说明 H7 的以太网吞吐能力不是瓶颈。长时间运行测试跑了 72 小时中间经历了交换机重启、网线热插拔、DHCP 租约到期续约都没有出现死机或者协议栈崩溃。网线拔掉重插之后PHY 的 link 状态从 down 变 upLWIP 的 netif 也能正确感知并继续工作。这要归功于 HAL 库的 ETH 链路状态回调机制以及我在应用层对 link 状态变化做了日志记录。4.3 后续扩展建议这套以太网工程跑通之后能扩展的方向很多。最常用的是 HTTP 服务器可以在板子上内置一个简单的网页用来显示传感器数据或者设备状态。LWIP 自带的 httpd 模块比较简陋但作为调试页面或者小型设备配置页面足够用了。建议直接使用 httpd 的 CGI 机制把动态数据通过网页展示出来。MQTT 也是一个很好的方向适合做物联网设备上云。LWIP 跑 MQTT 客户端本身不复杂消耗的资源很有限在一个 200MHz 的 MCU 上都能跑得很顺更别说 H7。唯一要注意的是 MQTT 的 keepalive 机制依赖 LWIP 的定时器稳定性测试时重点关注长时间无人通信后能否正常维持连接。OTA 固件升级算是以太网带来的最大价值。有了稳定的 TCP/IP 通信就可以设计一个简单的固件升级流程设备端运行一个 TFTP 客户端或 HTTP 客户端从服务器下载新的固件镜像写入外部 Flash然后跳转执行。这个方向建议放在网络调通之后作为下一个里程碑来做。最后再说一点个人体会调试 STM32H7 LAN8720A 这套组合大部分时间花在排查隐性问题上而不是配置本身。CubeMX 生成代码已经解决了 80% 的配置工作量剩下的 20% 往往是 MPU 和 Cache 一致性、PHY 上电时序、内存分配这类需要具备一定系统知识才能定位的问题。我踩过好几次 D-Cache 的坑之后现在只要看到 H7 平台第一件事就是查 MPU 配置。如果你也卡在某个诡异的现象上我的建议是先简化环境。把 DHCP 换成静态 IP把 LWIP 的 TCP 服务关掉只保留最基本的 ICMP ping然后从物理层一步一步往上排查每层验证通过之后再叠加功能。这个思路看着慢实际上是最快的。最后分享一个小技巧在用 Wireshark 抓包时不要只看 ping 的 request 和 reply多留意 ARP 报文。很多网络问题在 ARP 阶段就已经暴露了只是被上层现象掩盖。把抓包当成日常调试工具而不是出问题才想起来。这一套走完你的 H7 网络基础就算是彻底扎实了。
先说结论把 STM32H7 和 LAN8720A 这一套跑通难点不在协议栈而在对硬件细节和 CubeMX 生成代码的敬畏心。ETH LWIP 这种组合用好了是低成本入网利器用不好就是 ping 不通、掉线、内存错乱的劝退现场。这篇作为整个 ETH 与 LWIP 配置系列的收尾我不再从一个空工程开始讲基础操作而是直接把最终定案的配置、调通的思路、踩过的坑全部摊开给正在折腾 H7 以太网的朋友一条能直接走的近路。这个组合的适用场景很明确需要板子通过网线接入局域网跑 TCP/UDP、HTTP、MQTT 这类应用。适合遇到 CubeMX 配完之后 ping 不通、DHCP 拿不到地址、收发一段时间就死机这类问题的开发者也适合刚准备用 LAN8720A 做第一块以太网板子的朋友。整套配置基于 STM32H743 和 LAN8720A用 RMII 接口配合最新版 STM32CubeMX当时用的 6.x 系列生成的工程下面所有内容都按这个前提展开。1. 整体设计思路与方案定案1.1 为什么选 STM32H7 LAN8720A 这个组合选型这事光看参数容易上头。STM32H7 系列内置了 10/100M 以太网 MAC 控制器支持 MII 和 RMII 两种接口模式。MAC 已经内置我们要做的只是外挂一颗 PHY 芯片把 MAC 的数字信号转成网线上的模拟差分信号。LAN8720A 是 SMSC现为 Microchip一颗很成熟的 10/100M 以太网 PHY 芯片采用 RMII 接口功耗低外围电路简单和 STM32 几乎全系都能配。选择这个组合最核心的理由只有一个成本低、引脚省、资料多。RMII 接口相比 MII 少了将近一半的信号线MII 需要 16 根数据线加控制线RMII 只需要 7 根。对于 STM32H7 这种大封装动辄一百多个引脚的芯片来说引脚不是问题但 PCB 上少走 8 根线还是能省不少事布线压力小EMC 问题也少一些。另外 LAN8720A 在 STM32 生态里被用了很多年CubeMX 直接内置了对这颗 PHY 的支持网上能搜到大量实际验证过的方案遇到问题不容易孤立无援。我实际用下来这颗 PHY 在千兆时代看起来有点老但做工业设备、网关、物联网节点完全够用。10/100M 以太网在绝大多数场景下都不会成为性能瓶颈反而因为技术成熟、协议栈完善调试起来比新的 2.5G PHY 顺手得多。1.2 硬件连接与原理图核对要点软件调不通很多时候是硬件布线埋的雷。LAN8720A 和 STM32H7 走 RMII 接口信号线就这几根TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO加上 REF_CLK 时钟线。这里有个关键选择REF_CLK 从哪来两种常见接法。第一种用外部 50MHz 有源晶振直接把时钟送给 LAN8720A 的 XI 引脚然后由 PHY 内部生成 50MHz 的 REF_CLK 输出给 STM32H7 的 ETH_RMII_REF_CLK 引脚。第二种用 STM32H7 的 MCO2 引脚输出 50MHz 给 LAN8720A。我个人不太推荐第二种因为 MCO2 的时钟源要精确配到 50MHz牵扯到 PLL 的配置稍有不慎时钟就偏了而且 MCO 引脚的驱动能力有限走线稍长就容易信号劣化。最稳的还是外部有源晶振方案一劳永逸。还有一个关键引脚是 PHYAD0它决定 PHY 的地址。LAN8720A 的 PHY 地址由 PHYAD0 引脚的电平决定默认接地为 0x00。这个地址后面在 CubeMX 里要填写在代码里要通过 MDIO 总线访问 PHY 寄存器地址不对读写全是无效操作。硬件上最容易踩的坑是网口变压器的中心抽头。LAN8720A 是 3.3V 供电的 PHY网口变压器中心抽头要按 LAN8720A 数据手册的要求接一般是接一个 1k 电阻上拉到 3.3V不能直接接 3.3V也不能直接接地。这个细节做原理图时必须对着数据手册的参考电路核对我见过不少板子因为中心抽头接错导致网络完全不通或者通信极不稳定。1.3 CubeMX 工程前置准备进 CubeMX 配置 ETH 之前先把时钟树搞定。STM32H7 的时钟树比 F1/F4 复杂得多ETH 外设本身对时钟有一定要求。我的习惯是在 Clock Configuration 页面先确认 AHB 总线的时钟频率然后确保 ETH 的 APB 时钟配置合理。对于以太网 MAC内核时钟会由系统时钟分频得到CubeMX 会自动计算但前提是系统时钟源和 PLL 配置正确。调试口也要提前想好。H7 系列默认的调试口是 SWD有些板子为了省引脚会把 PA13/PA14 复用成其他功能这样调试器就进不去了。建议在 CubeMX 里先把 SYS 的 Debug 设置为 Serial Wire再去做其他的引脚分配否则后面烧录都成问题。如果你要在 RTOS 上跑 LWIP我建议先把裸机的 ETH 调通再裁剪 CubeMX 里的 FreeRTOS 配置。裸机调通意味着 PHY 能 link 上、能 ping 通、收发数据没问题这时候再上 RTOS 和 LWIP 的协作问题范围会小很多。我在实际调试中见过太多人裸机都没通就把 RTOS 打开出了问题根本分不清是协议栈的问题还是任务调度的问题。2. CubeMX 工程配置细节与 LWIP 参数调优2.1 ETH 外设参数配置要点CubeMX 里 ETH 配置页面的内容不算多但每一项都不能含糊。第一个是 Mode选 RMII。如果需要 MII引脚分配都会变但用 LAN8720A 就老老实实选 RMII。第二个是 PHY Address填 0。这个就是前面说的 PHYAD0 引脚决定的默认地址。如果你的原理图上 PHYAD0 接的是高电平这里就要填 1否则 MDIO 读写失败PHY 无法初始化。第三个是 PHY 芯片选择CubeMX 里直接搜 LAN8720A。选择了具体的 PHY 型号之后HAL 库会编译对应的 PHY 驱动代码会定义 PHY 的读写超时时间、复位延时这些参数。第四个是 MAC Address这个随便填一个合法的单播地址就行只要局域网内不冲突即可。注意不要填成组播或广播地址最低字节的最低两位必须是 01 结尾单播 全局唯一。另外还要注意 Ethernet Configuration 里的 PHY 时钟和功耗选项。LAN8720A 的 RMII 模式需要 50MHz 参考时钟如果走的是外部有源晶振方案CubeMX 里不需要额外生成时钟但要在初始化代码里确认 ETH 的时钟配置正确。2.2 LAN8720A 的寄存器差异与 PHY 驱动适配很多人配置完 ETH发现 HAL_ETH_Init 卡在 PHY 通信超时或者读出来的 PHY ID 不对这时候就需要了解 LAN8720A 的寄存器特性。LAN8720A 是标准 IEEE 802.3 定义的 PHY基础寄存器布局和大多数 PHY 相同BCR地址 0x00、BMSR地址 0x01、PHY ID1地址 0x02、PHY ID2地址 0x03、ANAR地址 0x04、ANLPAR地址 0x05等。但它的具体位定义和某些大厂 PHY 有细微差别特别是自动协商状态和速度/双工状态的判断。我在实际调试中遇到过一个经典问题用 CubeMX 生成代码后HAL_ETH_ReadPHYRegister 去读 BMSR发现自动协商完成位bit 5一直不置位。排查了一圈发现是 LAN8720A 的上电时序问题。这颗 PHY 的 nRST 引脚复位后需要等待一段时间才能稳定响应 MDIO 读写时间不够就读取失败。解决办法是把复位延时调大或者在上电后显式地对 PHY 做一次软复位BCR 的 bit 15 置 1然后等待自协商完成。LAN8720A 的自协商默认是开启的BCR 的 bit 12ANEN默认值为 1也就是上电后 PHY 会自动协商速度和双工模式。如果想固定百兆全双工可以关掉自协商并手动设置 BCR 的速度位和双工位。但除非你有特殊用途我建议保持默认的自协商模式因为绝大多数交换机都能协商到百兆全双工。2.3 LWIP 关键参数内存池、PBUF、MSS 与超时LWIP 的参数配置是整个以太网工程的重中之重。CubeMX 的 LWIP 配置页面里有一堆参数看起来密密麻麻但真正决定稳定性的就那么几个。内存相关参数我直接给出一个经过验证的保守配置参数推荐值说明MEM_SIZE1024 * 2020KBLWIP 堆内存用于协议控制块和动态内存分配MEMP_NUM_PBUF20同时允许的 PBUF 数量MEMP_NUM_UDP_PCB8UDP 控制块数量MEMP_NUM_TCP_PCB8TCP 控制块数量MEMP_NUM_TCP_SEG16TCP 分段数量MEMP_NUM_NETBUF16网络缓冲区数量PBUF_POOL_SIZE32PBUF 池大小PBUF_POOL_BUFSIZE1512单个 PBUF 池缓冲区大小要能装下最大以太网帧这些参数不是越大越好因为每加一个数量静态分配的 RAM 就多一块。如果内存充足可以适当放大 PBUF_POOL_SIZE但不要盲目把 MEM_SIZE 开到 100KB因为 LWIP 的堆是通过内存池管理实现的堆太大不仅浪费 RAM还会导致分配效率下降。TCP 相关参数也很关键。TCP_MSS 默认 1460 是正确的不要改大。TCP_WND 是 TCP 接收窗口默认通常是一个 MSS 的倍数建议设置为 10 个 MSS 以上否则 TCP 传输会被窗口限制拖慢。TCP_SND_BUF 建议和 TCP_WND 匹配否则发送和接收能力不一致会导致吞吐量低下。还有一个容易被忽略的参数是 LWIP_DHCP。CubeMX 里默认关闭如果你要自动获取 IP把它改成 Enabled并且在初始化代码里调用dhcp_start()而不是用静态 IP 的方式。反过来如果调试阶段建议先用静态 IP固定一个局域网内不冲突的地址减少 DHCP 这种不确定因素等 ping 通了之后再切换到 DHCP。2.4 不能忽视的 D-Cache 与 MPU 配置STM32H7 的 D-Cache 是 ETH 调试中最大的坑没有之一。H7 内置了 I-Cache 和 D-Cache默认情况下 CubeMX 生成的代码甚至会帮你打开这两路 Cache。问题在于ETH 的 DMA 会直接访问 RAM绕过 CPU 的 Cache。当 DMA 从网络收到数据并写入 RAMCPU 去读这段数据时如果 D-Cache 里缓存了旧数据CPU 读到的就是脏数据。反过来CPU 写了一包数据准备让 DMA 发出去DMA 从 RAM 里读到的可能是旧数据因为新数据还躺在 D-Cache 里没有回写。这就是 H7 上 ping 不通、收发乱码、数据校验失败的隐形凶手。而且这个问题特别恶心的地方在于表现不稳定有时候能通有时候不能通跟你代码里访问网络的频率和时机有关。解决办法有两个。最简单粗暴的是把 ETH 的 DMA 描述符和缓冲区所在的内存区域配置为 non-cacheable。在 CubeMX 里打开 MPUMemory Protection Unit然后添加一个 Region把 ETH 使用的 RAM 区域设置成 Device 或 Strongly-ordered 属性。但实际更推荐设置成 Normal memory non-cacheable因为 Device 类型的访问性能和访问宽度有特殊限制不太适合以太网这种高吞吐场景。具体操作要看你把 DMA 描述符和 buffer 放在哪块 RAM。STM32H7 的 RAM 分布有几个域ETH 的 DMA 复杂操作建议放在 D2 域的 RAM因为 ETH 外设挂载在 D2 域的 AHB 总线上这样 DMA 访问不需要跨总线域切换延迟和功耗都更优。CubeMX 里可以在链接脚本里指定以太网缓冲区的放置区域或者在代码里用 section 属性把描述符和 buffer 定义到指定地址段。如果你不想动 MPU也可以不开启 D-Cache但 H7 主频跑那么高不开启 D-Cache 性能会打折扣。所以正确做法还是开 D-Cache 的同时配好 MPU这是性能与稳定兼顾的唯一正解。3. 实践中的常见问题与排查记录3.1 物理层问题REF_CLK 缺失、Link 灯不亮低级问题最容易卡住人。如果板子上电后网口的 Link 灯不亮第一步不是看软件而是拿起示波器量 PHY 的 REF_CLK 引脚。正常情况下能量到一个稳定的 50MHz 方波或正弦波。没有时钟PHY 就是死了后面全是白搭。如果有源晶振方案确认了时钟没问题再量一下 LAN8720A 的供电是否正常。这颗芯片有模拟电源和数字电源都是 3.3V上电时序要求 3.3V 先稳定nRST 释放后 PHY 才能正常工作。很多板子为了让 PHY 复位可控会把 nRST 接到 MCU 的 GPIO用代码控制复位。这时候要在代码里确认复位时序是对的拉低 nRST 至少 10ms再拉高然后延时至少 100ms 让 PHY 完成内部初始化再初始化 ETH 外设。LAN8720A 的复位还有个细节nRST 拉高的上升沿要足够陡峭。如果 nRST 引脚上接了太大的电容上升沿会变缓可能导致 PHY 复位不彻底。数据手册里对复位脉冲宽度有明确要求做硬件时不要为了滤波在这个引脚上并大电容。3.2 能 Link 但 Ping 不通从 ARP 开始查Link 灯亮了说明物理层没问题但 ping 不通这是最常见的状态。我的排查顺序是先看 ARP再看 LWIP 收包再看发包。在电脑上 ping 开发板如果 IP 不通先抓包看有没有 ARP 请求发出来、有没有 ARP 响应。最简单的办法是在电脑上用 Wireshark 抓包过滤 ARP 协议。如果能看到开发板回 ARP 响应但 ping 还是超时说明 ICMP echo request 可能没有正确处理或者 echo reply 发出去了但出问题。这时候再看 MCU 侧代码。LWIP 的运行需要调用sys_check_timeouts()或者tcpip_thread和信号量的机制以及ethernetif_input()或者中断里调用HAL_ETH_ReadData后交给netif-input。如果主循环里忘了调用这些处理函数LWIP 协议栈就永远不会推进ping 自然不通。另外一个隐蔽的问题是 DMA 描述符的环形队列没有正确初始化。CubeMX 生成的代码一般没问题但如果你自己改过初始化顺序例如在 ETH 外设使能之前就启动了 DMA或者描述符链表的指针没有正确回环DMA 就不知道往哪写数据收包中断永远不会触发。3.3 数据收发不稳定、频繁丢包收发不稳定优先怀疑 D-Cache其次怀疑内存对齐。D-Cache 的问题前面说过了如果 MPU 没配好收发数据就是有概率出错。特别是 DHCP 这类需要多发几次请求的流程表现会非常诡异有时候能拿到 IP 有时候拿不到拿到的 IP 也可能是错误的。内存对齐问题也很常见。DMA 描述符在 STM32H7 的 HAL 库实现中有对齐要求通常需要 4 字节对齐有些配置要求 32 字节对齐。如果你自己定义内存池数组要确保编译器分配时满足对齐要求建议直接用ALIGN_32BYTES之类的宏修饰或者放到单独的 section 里。ARMCC 和 GCC 的对齐语法不一样从 CubeMX 生成代码里抄就行。中断优先级也是丢包的重灾区。ETH 的中断如果优先级太低在中断密集的情况下可能会被其他中断抢占太久导致 DMA 接收描述符溢出新收到的包直接被丢弃。我的习惯是把 ETH 中断优先级设置得比串口高和定时器中断持平。如果你用 FreeRTOS注意中断优先级不要和可管理中断的阈值冲突否则会触发断言失败。3.4 DHCP 分配不到 IP静态 IP 能 ping 通但开启 DHCP 后一直分配不到地址这个问题很多人在 RTOS 环境下遇到过。先说一个容易误导人的点网上搜索 LWIP DHCP 问题时经常会关联到“页面文件配置”之类的词。这其实是两码事LWIP 的 DHCP 和 Windows 的虚拟内存一点关系都没有。LWIP 要的是足够的 PBUF 池和 MEMP_NUM_UDP_PCB因为 DHCP 是基于 UDP 的协议需要 UDP PCB 资源。如果你把 MEMP_NUM_UDP_PCB 减到 4 以下DHCP 可能因为资源不足而失败。DHCP 失败还有一个常见原因LWIP 的 DHCP 状态机需要周期性调用超时处理函数。如果你用的是裸机必须在主循环里每隔几百毫秒调用一次sys_check_timeouts()否则 DHCP 的定时器不会运转永远停留在 DISCOVER 或 REQUEST 状态。如果用的是 RTOS 的 tcpip 线程这个函数会在tcpip_thread中被周期调用一般不用操心。另外板子的 MAC 地址如果全零或者非法某些 DHCP 服务器会拒绝分配。CubeMX 里默认的 MAC 地址虽然随机但格式是正确的不用改。如果你在初始化代码里把 MAC 地址覆盖成全零DHCP 很可能挂掉。3.5 长时间运行后断网或死机这个问题的本质通常是内存泄漏或者 DMA 描述符没有合理回收。LWIP 本身是一个成熟协议栈正常情况下不会随意崩溃但如果应用层分配 PBUF 后没有正确释放或者发送数据时用了tcp_write之后没有处理tcp_sent回调发送缓冲会被逐渐耗尽最终表现为 TCP 断开或无法建立新连接。裸机环境还要注意 ETH 全局中断标志的处理。HAL 库的中断处理函数和 DMA 中断、MAC 中断混在一起如果中断标志没有被正确清除可能导致中断反复触发把 CPU 的老底拖垮。建议在中断服务函数里加上__HAL_ETH_DMA_CLEAR_FLAG这类操作参照 HAL 库例程中的写法。最后也别忽略堆栈溢出。LWIP 内部线程用 RTOS 时需要足够大的栈空间默认给 1024 够用但如果你在回调函数里做了重量级操作比如打印大量日志或者格式化字符串栈可能不够。我的习惯是给 LWIP 线程分配 2048 字节的栈调试阶段留足余量。4. 最终验证与长期稳定运行4.1 完整的验证流程设计调试完成后不要直接认为就万事大吉我觉得至少要跑这样一轮系统验证。第一步是物理层验证。连续 ping 1000 次大包1472 字节 payload对应以太网最大速载荷确保 0 丢包。再 ping 1 万次小包确认 ARP 缓存、ICMP 处理没有问题。第二步是 TCP 层验证。在电脑上开一个 TCP 调试助手主动连接开发板进行双向大量数据收发。比如连续发送 10MB 随机数据确认开发板接收后回传的数据没有一位错误。这个步骤能暴露 DMA 描述符回收、内存池耗尽、校验和处理这类隐患。第三步是长时间稳定性测试。让板子 7x24 小时运行每一小时通过脚本监控一次网络连通性记录掉线次数和恢复情况。如果掉线后能自动恢复要确认是 LWIP 的自动重连机制还是你在应用层做了看门狗如果掉线后无法恢复大概率是底层初始化有问题需要进一步排查。4.2 实际测试中遇到的现象记录我在这套配置上做的实测结果值得分享一下。静态 IP 192.168.1.10电脑直连交换机ping 大包和小包均无丢包。TCP 单向吞吐测试用 iperf 跑发送方向开发板发送电脑接收约 88Mbps接收方向约 84Mbps基本跑满了百兆以太网的实际可用带宽。作为对比板子的主频跑在 400MHzCPU 占用率在收发 80Mbps 数据时大约为 35% 到 45%说明 H7 的以太网吞吐能力不是瓶颈。长时间运行测试跑了 72 小时中间经历了交换机重启、网线热插拔、DHCP 租约到期续约都没有出现死机或者协议栈崩溃。网线拔掉重插之后PHY 的 link 状态从 down 变 upLWIP 的 netif 也能正确感知并继续工作。这要归功于 HAL 库的 ETH 链路状态回调机制以及我在应用层对 link 状态变化做了日志记录。4.3 后续扩展建议这套以太网工程跑通之后能扩展的方向很多。最常用的是 HTTP 服务器可以在板子上内置一个简单的网页用来显示传感器数据或者设备状态。LWIP 自带的 httpd 模块比较简陋但作为调试页面或者小型设备配置页面足够用了。建议直接使用 httpd 的 CGI 机制把动态数据通过网页展示出来。MQTT 也是一个很好的方向适合做物联网设备上云。LWIP 跑 MQTT 客户端本身不复杂消耗的资源很有限在一个 200MHz 的 MCU 上都能跑得很顺更别说 H7。唯一要注意的是 MQTT 的 keepalive 机制依赖 LWIP 的定时器稳定性测试时重点关注长时间无人通信后能否正常维持连接。OTA 固件升级算是以太网带来的最大价值。有了稳定的 TCP/IP 通信就可以设计一个简单的固件升级流程设备端运行一个 TFTP 客户端或 HTTP 客户端从服务器下载新的固件镜像写入外部 Flash然后跳转执行。这个方向建议放在网络调通之后作为下一个里程碑来做。最后再说一点个人体会调试 STM32H7 LAN8720A 这套组合大部分时间花在排查隐性问题上而不是配置本身。CubeMX 生成代码已经解决了 80% 的配置工作量剩下的 20% 往往是 MPU 和 Cache 一致性、PHY 上电时序、内存分配这类需要具备一定系统知识才能定位的问题。我踩过好几次 D-Cache 的坑之后现在只要看到 H7 平台第一件事就是查 MPU 配置。如果你也卡在某个诡异的现象上我的建议是先简化环境。把 DHCP 换成静态 IP把 LWIP 的 TCP 服务关掉只保留最基本的 ICMP ping然后从物理层一步一步往上排查每层验证通过之后再叠加功能。这个思路看着慢实际上是最快的。最后分享一个小技巧在用 Wireshark 抓包时不要只看 ping 的 request 和 reply多留意 ARP 报文。很多网络问题在 ARP 阶段就已经暴露了只是被上层现象掩盖。把抓包当成日常调试工具而不是出问题才想起来。这一套走完你的 H7 网络基础就算是彻底扎实了。
