STM32H7+LAN8720A以太网调试实战：从PHY寄存器到LWIP稳定百兆-北京尧图网络

从PHY寄存器读回来全是0xFFFF到局域网里能稳定跑到接近100M带宽这块STM32H7加LAN8720A的网口前前后后折腾了我挺长时间。作为这个系列文章的最后一篇我把ETH外设和LWIP协议栈配置过程中踩过的坑、排查思路、最终怎么解决的按实际操作顺序完整记录下来如果你正在调H7系列配LAN8720A这篇应该能帮你少走不少弯路。先说清楚这篇文章适合谁看用STM32H743/H750这类H7芯片做以太网通信PHY选的是LAN8720A在STM32CubeMX里配ETH和LWIP然后发现网口要么ping不通、要么通了但一跑大流量就崩。硬件和软件层面的问题我都会覆盖但不会讲太多协议栈内部实现的理论重点是把能复现的步骤和能直接抄的配置给出来。1. 硬件先排雷RMII引脚、时钟与PHY地址的三方博弈1.1 原理图上必须查三处的连接关系很多ETH和LWIP的问题表面看是软件配置不对实际上根子在硬件上。先看原理图LAN8720A只支持RMII模式不支持MII所以STM32H7的ETH外设必须工作在RMII模式。RMII比MII少了一半信号线数据引脚只要RXD0/RXD1、TXD0/TXD1、CRS_DV、TX_EN再加上一个50MHz的REF_CLK以及MDC/MDIO两根管理引脚总共九根线。我调试时第一个发现就是RXD1和CRS_DV这两根线特别容易被画反。因为很多参考原理图上它们的排列顺序不一样如果画板时照着某个开发板抄但抄的是不同厂商的网络标号很容易出问题。RMII模式下RXD1和CRS_DV是两个独立的信号接反了PHY也能识别出物理链路但收包的数据完全不对表现为能ping通但丢包极其严重或者干脆只能发不能收。MDC和MDIO这两根管理总线上一般要各接一个4.7k到10k的上拉电阻到3.3V。这两个引脚是开漏/开集输出没有上拉的话MDIO通信会不稳定现象是偶尔能读到PHY寄存器、偶尔读到0xFFFF非常折磨人。还有LAN8720A的REGOFF引脚这个脚决定PHY内部1.2V稳压器是否启用。REGOFF接低电平时用内部稳压器VDDCR引脚需要配一个10uF加0.1uF的退耦电容REGOFF接高电平则需要外部单独供1.2V。很多低成本的模块直接下拉REGOFF但电容没接够导致PHY上电后工作不稳定link状态时有时无。1.2 LAN8720A的时钟架构为什么50MHz这么纠结RMII协议规定REF_CLK必须是50MHz这一点和MII的25MHz/2.5MHz不一样。LAN8720A拿到这50MHz参考时钟无非三条路。第一条路也是我在板子上用的方案LAN8720A的XTAL1和XTAL2接一颗25MHz无源晶振芯片内部通过PLL倍频到50MHz从CLK_OUT引脚输出接到STM32H7的ETH_RMII_REF_CLK通常对应PA1。这个方案的好处是STM32这边只做输入不参与时钟生成MCU只需要保证HSE正常启动就行。第二条路用一颗50MHz有源晶振输出直接同时接到LAN8720A的REF_CLK引脚和STM32H7的ETH_RMII_REF_CLK引脚。这个方案最省事但对有源晶振的精度和驱动能力有点要求而且多一颗有源晶振成本更高。第三条路用STM32的MCO引脚输出50MHz给LAN8720A。这个我试过一次能跑通但容易引入额外干扰而且MCO和ETH引脚的复用关系在不同封装上有差异不推荐新手用。重点是第一颗25MHz无源晶振的负载电容。很多人随便焊两个20pF上去结果晶振不起振。我遇到过一次比较隐蔽的情况示波器测LAN8720A的CLK_OUT引脚有50MHz波形但幅值只有一两百毫伏PHY内部逻辑根本没工作。最后是换了晶振并联的电阻位置才解决。所以碰到PHY完全没反应先不要怀疑STM32配置用示波器看CLK_OUT有没有一个干净的50MHz方波出来。1.3 PHY地址不是随便拉的LAN8720A的PHY地址由PHYAD0和PHYAD1两个引脚决定。默认情况下PHYAD0下拉到地PHY地址就是0x00。如果你的板子上PHYAD0接上拉那地址就变成1PHYAD1也接的话又不一样。这个地址必须和STM32CubeMX里ETH配置的PHY Address保持一致。我见过最典型的错误是参考一个开发板的原理图开发板上PHYAD0接了上拉ETH配置里地址也写了1但自己画板时把这个引脚改成下拉CubeMX里还留着1结果MDIO永远找不到PHY。调试初期建议直接把PHY地址固定下来不要指望代码里动态扫描多个地址。LAN8720A的PHY ID1寄存器REG 2读出来通常是0x0007PHY ID2REG 3低四位可能有差异。如果MDIO能读到这两个值说明物理层已经通了。2. CubeMX配置ETH的正确姿势与翻车现场2.1 引脚复用RMII模式下没有太多自由打开STM32CubeMX选好芯片型号左侧Categories找到Connectivity里的ETHMode选RMII这时CubeMX会自动分配引脚。以常见的STM32H743来说RMII信号基本是固定的ETH_RMII_REF_CLKPA1ETH_RMII_CRS_DVPA7ETH_RMII_RXD0PC4ETH_RMII_RXD1PC5ETH_RMII_TX_ENPB11ETH_RMII_TXD0PB12ETH_RMII_TXD1PB13ETH_MDCPC1ETH_MDIOPA2原理图设计前就要对着这个引脚表查一遍尤其是PA1这个REF_CLK脚。很多人在CubeMX里发现PA1既能复用成ETH_RMII_REF_CLK也能复用成其他功能于是怀疑是不是要选MCO输出实际上如果你的时钟方案是LAN8720A的CLK_OUT输出50MHz给MCUPA1就是纯粹的输入引脚不需要配置MCO。CubeMX里还有个容易忽略的点ETH外设的GPIO Alternate Function要选对。如果PA7、PC4这些引脚旁的AF设置不对编译能过但实际信号根本到不了ETH外设内部。检查方式是CubeMX的Pinout视图里选中引脚后看Alternate Function是不是ETH_RMII对应的AF值不要手动去改除非你对这个芯片的AF映射非常熟。2.2 ETH参数设置PHY Address只是开始在ETH的Parameter Settings里除了PHY AddressCubeMX还会要求填PHY的BSR寄存器和BCR寄存器地址以及复位延迟时间。这个是新版本CubeMX增加的内容因为HAL库的HAL_ETH_ConfigPHY需要知道这些信息来操作PHY。LAN8720A的BCR寄存器是0x00BSR寄存器是0x01PHY Address如果硬件是默认下拉就是0。复位延迟毫秒数一般填100到500都行太短的话PHY还没准备好HAL_ETH_Init直接报超时。这里有个坑如果你用的是旧版本CubeMX生成的代码里面可能没有这些字段直接裸用新版本HAL库编译会报错所以工程模板跟着CubeMX版本走不要混着升级。还有一个参数是MAC地址CubeMX默认生成一个00:80:E1:00:00:00之类的地址。如果你同时调多块板子这个地址必须改不然ARP缓存会冲突。建议用一个固定的自定义地址比如自己公司分配的OUI段或者至少保证同一局域网内不重复。2.3 生成代码后的HAL_ETH_Init配置CubeMX生成的MX_ETH_Init函数里核心是这句heth.Init.MediaInterface HAL_ETH_RMII_MODE; heth.Init.PhyAddress 0;如果PHY地址和硬件不一致这里就要改。改完还要注意HAL_ETH_Init调用的时机必须在HAL_ETH_Start或HAL_ETH_Start_IT之前。很多人把ETH初始化放在main函数里靠前的位置但RTOS还没启动一旦初始化卡住整个系统就起不来。我见过一个问题CubeMX生成的MX_ETH_Init里HAL_ETH_Init返回HAL_TIMEOUT原因不是PHY坏了而是此时MDIO所依赖的时钟还没使能完全。CubeMX会自动处理时钟使能但如果你在配置时钟树时把ETH的时钟源给关掉了HAL_ETH_Init就会一直超时。检查时钟树时确认ETH外设的时钟被勾选不要只看原理图上有信号。3. LWIP参数调整与FreeRTOS集成中的暗坑3.1 内存池参数小马拉大车的下场在CubeMX里启用LWIP后第一件事是确认General配置里NO_SYS选的是OS而不是None。如果你要在FreeRTOS环境里跑LWIPNO_SYS必须为OS这样才能生成tcpip_thread和对应的信号量机制。然后是Key Options里的几个内存参数这里最容易出问题。CubeMX默认生成的MEM_SIZE是1600PBUF_POOL_SIZE是16在一来一回的简单通信场景够用但一旦TCP收发大文件或者同时建多个连接内存池很快耗尽。PBUF不足时现象很典型板子刚上电能ping通传输几KB数据后PC端就显示超时板子再也收不到包。我这边实际跑的项目里最终把PBUF_POOL_SIZE调到24MEMP_NUM_PBUF调到32MEMP_NUM_TCP_SEG也调到24MEM_SIZE改成6400。注意这几个参数不是越大越好因为STM32H7的RAM虽然有几百KB但DMA描述符、各种任务栈、协议栈静态内存都从里面分配胃口太大反而挤占了其他功能。如果是从CubeMX生成的lwipopts.h里手动改改完必须重新编译整个工程LWIP的宏定义不是运行时动态调整的。如果改用ST的扩展包X-CUBE-AZURE或者移植了其他版本的LWIP这些参数的命名可能略有差异本质含义一样把内存段扩大到Ping不掉包为止。3.2 LWIP与FreeRTOS任务优先级和信号量CubeMX生成的LWIP线程默认优先级是osPriorityNormal堆栈大小是1024字。这个数值在H7上偏小特别是你还在LWIP线程里做了域名解析或者MQTT这类操作时很容易触发栈溢出。我建议直接改成2048H7的任务栈按字算2048字即8KB对几百KB RAM的H7来说完全承受得起。优先级方面如果LWIP线程优先级比DMA中断的优先级低太多中断里释放信号量后LWIP线程迟迟得不到调度就会出现网口明明有收包但ping的响应时间忽高忽低甚至有些ARP请求回不过去。我的做法是把LWIP线程优先级保持在Normal但ETH的中断优先级不要设成最高因为H7的中断里如果做太多操作会影响整个系统的实时性。LWIP中断里只做信号量释放实际协议栈处理都在tcpip_thread里这一点CubeMX生成的ethernetif.c已经处理好了不要去改它的回调函数。另外必须确认HAL的时间基准和FreeRTOS的时间基准不冲突。CubeMX里默认HAL timebase source是SysTick而FreeRTOS也要用SysTick如果不改程序跑起来之后HAL_Delay直接卡死。在Project Manager里把HAL timebase改成TIM6或TIM7这个坑不解决后面所有的调试全是空中楼阁。3.3 DHCP还是静态IP调试阶段我强烈建议先用静态IP把板子固定成192.168.1.100子网掩码255.255.255.0网关192.168.1.1PC端网卡设置成192.168.1.50。这样可以把变量降到最低因为你一旦开着DHCP路由器地址池满、DHCP报文被防火墙拦、板子发送DHCP Discover但是没人应答这些都可能是ping不通的原因但都不是你ETH和LWIP配置本身的问题。等静态IP完全通了再回到CubeMX里把LWIP_DHCP打开。打开DHCP后板子获取IP需要几秒到几十秒不等不要一上电就ping先等一下再看。实际观察发现LAN8720A的link建立速度很快但DHCP整个过程受路由器响应影响很大我甚至见过某个路由器要等一分多钟才给地址这种情况下直接怀疑DHCP配置有问题就冤枉了。4. ping不通的完整排查链路以及最终根因4.1 第一步PHY寄存器能不能正常读任何网口调试第一步都是确认MDIO链路正常。MCU和PHY之间的管理通道都没通后面全是空中楼阁。CubeMX生成的工程里可以直接用HAL库函数读PHY寄存器uint32_t phy_val 0; HAL_StatusTypeDef status; status HAL_ETH_ReadPHYRegister(heth, 2, phy_val); if (status HAL_OK) { printf(PHY ID1: 0x%04X\r\n, phy_val); } else { printf(Read PHY register failed, status%d\r\n, status); }LAN8720A的寄存器2是PHY ID1正常应该读到0x0007寄存器3是PHY ID2一般是0xA0xx或者0x0202之类的值。如果读出来是0xFFFF或者0x0000先不要怀疑PHY芯片坏了按这个顺序查PHY Address对不对、MDC/MDIO上拉电阻有没有、LAN8720A复位脚是否在正常电平、25MHz晶振有没有起振、CLK_OUT有没有50MHz输出。4.2 第二步检查Link状态与自动协商MDIO通了之后再查物理链路状态。LAN8720A的寄存器1是BSR寄存器bit2是Link Statusbit5是Auto-Negotiation Complete。我通常这样判断HAL_ETH_ReadPHYRegister(heth, 1, phy_val); printf(BSR: 0x%04X\r\n, phy_val);如果Link Status为0说明PHY没有和交换机/路由器协商上问题大概率在网线、变压器、RJ45座或者LAN8720A电源这一侧。你可以观察开发板上的网口指示灯LAN8720A一般有两个LED引脚一个指示Link一个指示Active如果Link灯都不亮软件再怎么调也没用。这一步还有一个容易忽略的地方有些路由器端口是百兆自适应但个别老交换机需要强制双工模式。如果LAN8720A的自动协商一直失败可以用寄存器0BCR强制设置但正常情况不要动自动协商处理不了的情况极少。我这边基本没遇到需要强制设置双工的场景更多是网线本身问题换根线就好了。4.3 第三步ARP抓包确认MAC层收发PHY和Link都没问题但ping还是不通这时候打开PC端的Wireshark跑一下ping看PC有没有发出ARP请求以及板子有没有回ARP应答。PC发了ARP请求板子没回ARP问题在板子的接收或发送路径重点查LWIP线程是否正常运行DMA描述符是否有数据进来。PC没发ARP请求可能PC端网卡配置不对IP不在同一网段或者PC防火墙屏蔽了ICMP。PC发了ARP板子回了ARP但ping timeout说明IP层通了但ICMP回包有问题查LWIP的ICMP和内存配置。我调这块板子时Wireshark里能抓到板子发出的ARP但PC的ARP应答板子收不到。网卡抓包能看到交换机一直在发广播但板子就是没有任何回应。这就把问题缩小到了板子的接收路径。4.4 第四步DMA描述符与Cache一致性这才是H7特有的坑拿到STM32H7上问题一下就明朗了。H7的CPU带D-CacheETH的DMA外设通过AXI总线访问RAM普通SRAM区域默认是cacheable的。这就导致一个经典的数据一致性问题DMA把收到的数据写进内存了但CPU读的时候走的还是cache里的旧数据看起来就是数据没收到反过来CPU把数据写到cache里还没flush到内存DMA就去读内存发出去的全是垃圾数据。现象就是ARP不发、ping完全不通或者通了但数据错乱而且非常随机重启后表现都不一致。CubeMX生成的工程里默认MPU配置可能没有把ETH相关的内存段设为non-cacheable所以必须手动改MPU配置。我这边是把LWIP内存池所在的那个RAM段直接配成non-cacheable。在CubeMX的MPU Configuration里可以配也可以直接在代码里写MPU_Region_InitTypeDef MPU_InitStruct {0}; MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress 0x24000000; MPU_InitStruct.Size MPU_REGION_SIZE_64KB; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable MPU_REGION_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable MPU_REGION_NOT_CACHEABLE; MPU_InitStruct.IsShareable MPU_REGION_NOT_SHAREABLE; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL0; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_ENABLE; HAL_MPU_ConfigRegion(MPU_InitStruct);这里有几个要点第一BaseAddress要和你工程里LWIP使用的RAM段对应。CubeMX默认的H7内存布局里AXI SRAM在0x24000000DMA描述符和pbuf很可能就在这个区域。第二配置MPU必须在使能Cache之前或者至少保证初始化顺序正确CubeMX生成的main函数里通常是先执行MPU_Config再执行CPU_CACHE_Enable不要颠倒。第三如果不想整段non-cacheable也可以保留cacheable但在DMA收发前后手动调用SCB_CleanDCache和SCB_InvalidateDCache但如果每个包都手动刷Cache代码会很啰嗦我首选还是直接MPU配置成non-cacheable一劳永逸。4.5 最终根因复盘最后定位到我这个板子ping不通的根因就是D-Cache一致性。在这之前PHY地址、时钟、Link状态全部正常LWIP参数也调过好几轮但板子就是收不到PC的ARP应答。因为H7的Cache问题不像线路问题那么明显它不影响PHY寄存器读取不影响发送只影响接收方向上DMA写内存和CPU读内存的一致性。这也是为什么在F1/F4上跑同样的代码完全没问题换到H7就各种诡异现象这张板卡最终是通过MPU配置解决了。如果你在排查时也走到了这一步一定要确认MPU配置里有没有覆盖ETH实际用的内存区域。有时CubeMX生成的工程里MPU只配置了TCM RAM或者外部SDRAMLWIP内存却在另一个段等于没配。5. 调试技巧、常见问题速查与量产经验5.1 用串口把寄存器状态打出来调试ETH和LWIP串口是你最好的朋友。我习惯在初始化流程和关键环节打几行关键信息printf([ETH] Start init...\r\n); status HAL_ETH_Init(heth); printf([ETH] HAL_ETH_Init status %d\r\n, status); HAL_ETH_ReadPHYRegister(heth, 2, phy_vals); printf([PHY] ID1 0x%04X\r\n, phy_vals); HAL_ETH_ReadPHYRegister(heth, 1, phy_vals); printf([PHY] BSR 0x%04X\r\n, phy_vals); printf([LINK] %s\r\n, (phy_vals 0x04) ? UP : DOWN);初始化成功之后在LWIP线程启动并配置完网络接口时打印出当前IPprintf([LWIP] IP address: %s\r\n, ipaddr_ntoa(netif_ip_addr4(gnetif)));如果这里打印出来的IP是0.0.0.0说明DHCP还没拿到地址或者静态IP配置没生效。用串口打印可以在不借助任何调试器的情况下快速判断问题所在。5.2 常见问题速查表根据我这段时间的调试经验把几种高频问题和对应排查方向整理如下现象可能原因排查顺序PHY ID读成0xFFFFPHY地址不对、MDC/MDIO上拉缺失、PHY没复位、晶振没起振先量CLK_OUT和复位脚电平再查MDIOLink灯不亮网线、RJ45座、变压器、PHY电源、晶振换网线、量VDDCR、看CLK_OUTLink灯亮但ping不通D-Cache一致性、LWIP内存不足、PC防火墙、IP网段抓包看ARP查MPU配置改静态IP能ping通但大流量断流PBUF池不足、DMA描述符不足、任务栈溢出调大PBUF_POOL_SIZE和MEMP_NUM_PBUFDHCP获取不到IP路由器DHCP池满、LWIP_DHCP未使能、获取时间不够先用手动IP测试再开DHCP等30秒系统启动卡死HAL timebase和FreeRTOS都用SysTick把HAL timebase改成TIM6/TIM7频繁系统崩溃LWIP任务栈不足、中断里做了耗时操作栈改2048字中断只释放信号量这个表是我遇到问题的真实汇总每一条几乎都在不同项目里出现过不是理论推导。5.3 量产部署时的一些经验ETH和LWIP配置调通只是第一步真正量产时还要注意几件事。MAC地址必须在生产阶段写入唯一值不能所有设备用同一个MAC否则同一局域网内设备多了会互相干扰表现为随机掉线、ARP表疯狂跳动。可以把MAC地址存到EEPROM或者Flash的独立扇区出厂时烧录代码里读出来再填进ETH配置结构体。PHY的复位时序也要重视。如果MCU和PHY共用一个电源上电时MCU的GPIO可能还没配置成输出模式PHY复位脚处于不确定状态。我习惯用一个专门的GPIO控制PHY复位在初始化ETH之前先拉低复位至少10ms再拉高然后等待PHY稳定。这个过程不要在RTOS启动之前做太久否则影响启动时间。还有一个容易被忽略的点PHY的LED灯和MCU的引脚如果有复用冲突CubeMX会报错但如果你用的是其他功能复用比如把LAN8720A的nINT引脚接到PC13上而LED也接到了同一个引脚PC13在H7上默认好像还有别的功能这样调试时可能互相干扰。量产设计时把PHY的中断、LED等辅助信号引到专属引脚不要和用户交互用的IO混用。再说一句关于网线的事。我调试过程中遇到过一对明明是好的网线插上去Link灯却不亮的情况最后发现是线序不对百兆只用了四根线但工程现场经常有劣质网线只有两对线导通。量产测试时建议用至少超五类标准的成品网线同时做线序和连通性测试避免把网络问题误判成硬件故障。最后分享一个我个人比较喜欢的验证方法调通之后不要急着跑复杂应用先让板子持续ping PC端半小时同时用Iperf或者类似工具打一下网络吞吐。如果带宽能稳定在90Mbps以上且没有明显丢包说明ETH和LWIP这套配置基本是健康的。之后你再去跑TCP长连接、MQTT这些上层协议心里就有底了。

STM32H7+LAN8720A以太网调试实战：从PHY寄存器到LWIP稳定百兆

相关推荐

从零搭建OpenRig开放式硬件平台：散热、走线与避坑全指南

ESD防静电烘箱全流程解析：从静电防护到调试交付

51单片机驱动SYN6288实现倒车雷达语音播报实战

更多资讯

AI Agent 架构设计与实战：从核心原理到并发避坑指南

基于STM32的仓库环境控制系统：温湿度粉尘监测与ESP8266上云

拼多多新店访客多少正常？2026最新阶段标准+流量优化实操指南

GPT4 Turbo的128K上下文实测：从推特评测到斯坦福论文，TaoToken统一Key复现长上下文验证

告别Claude Cowork！用DeepSeek+LangGraph手搓免费编程Agent（附源码）

LLM之Agent（五十七）｜Claude Code 智能体循环：从入门到精通的实战指南

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？