我是去年底拿到的STM32H750B-DK这块板子板载资源确实丰富主控频率高、外设全、带LCD和音频本来想着用它做个网络音频传输的小项目结果刚把网线插上去准备测TCP通信电脑端ping就一直超时刚开始以为是网线问题换了好几根线又换交换机口始终不通。折腾了整整两天从硬件排查到协议栈配置最后定位到的原因其实相当隐蔽也让我把整个以太网启动链路彻底理了一遍。这篇就完整记录一下我当时的排查思路和最终解决方式给同样被这块板子卡住的兄弟们一个参考。先交代一下环境和现象方便你对号入座。我的开发环境是STM32CubeIDE 1.15HAL库版本1.11.3在CubeMX里使能了ETH外设并配置为RMII模式协议栈用的LwIP不带操作系统版本就是裸机轮询模式PHY芯片是板载的LAN8742A。板子上电后LCD屏正常点亮串口打印运行日志也没问题LED在闪烁说明MCU跑起来了。网线插到电脑直连Windows端显示“网络电缆被拔出”的状态倒没有说明链路层是有信号的但ping 192.168.1.10板子静态IP结果一直是“请求超时”。同一根网线插到另一块开发板上马上就能ping通所以问题基本锁定在STM32H750B-DK这一侧的以太网配置上。我这里先做个简单的分类方便后面逐步排查。以太网通信分为三个层级硬件物理层PHY芯片、MAC控制器层STM32内部的以太网MAC、网络协议栈层LwIP。ping不通的原因可能出现在任何一个层级而且上层的问题往往也会表现为底层的“假象”所以排查顺序必须是自底向上。下面我把每个层级的具体排查方法、我用到的代码、以及坑点全部展开说清楚。1. 问题描绘与初步判断板子“不响应”之前先确认它想不想响应拿到这个现象首先不要急着怀疑协议栈而是先确认板子本身的网络行为是否正常。我当时用了一个比较粗暴但有效的方法——把板子串口日志的调试等级调到最详细同时使用Wireshark在电脑端抓包看看板子到底有没有发出ARP请求或者ARP应答。这里特别提醒一下ping的第一步是ARP如果你电脑端发出去的是ARP请求而板子完全没有回应那说明链路层以下就没通。如果板子有ARP回应但ICMP回显无响应问题就在协议栈上层。从实际结果来看我的电脑端持续发出ARP广播但Wireshark里看不到来自板子MAC地址的任何回应报文。这就很有意思了——意味着板子可能根本没有正确接收到ARP请求或者收下来了但上层协议栈没处理也或者PHY/MAC层数据收发环节本身就有问题。为了进一步缩小范围我直接读取板子PHY芯片LAN8742A的寄存器检查Link状态和自动协商结果。LAN8742A的寄存器1Basic Mode Status Register的bit2就是Link Status位寄存器31可以读取PHY的ID如果这些值都能读出来说明MDIO通信是通的问题大概不在PHY硬件上。我的读取结果寄存器0的值为0x1000bit13为1表示自动协商完成寄存器1的bit2为1表示链路已建立PHY工作正常。这就基本排除了物理连接和PHY自动协商的问题。不过这里也有个容易踩的坑PHY的Link Status只是“网线插好了信号有连接”并不代表数据通路是通的。RMII接口一共有9根信号线包括TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO以及REF_CLK。这些信号只要有一根虚焊、配置错误或者引脚冲突都会导致收不到数据。我在检查PCB原理图时发现STM32H750B-DK的以太网引脚和SDMMC的引脚部分复用另外和USART的某个引脚也有冲突可能。所以我强烈建议拿到板子后第一步先去核对你的CubeMX工程里有没有把外部引脚正确配置成ETH的复用功能而不是被其他外设抢占。很多时候板子出厂自带例程能ping通一旦你自己新建工程配置稍有问题网络就“死”了。2. 硬件链路排查从RMII信号到PHY寄存器逐个确认2.1 STM32H750B-DK的以太网硬件拓扑和关键引脚这块开发板用的是LAN8742A是一款非常常见的10/100M以太网PHY芯片支持RMII和MII两种接口模式通过一个25MHz的无源晶振提供时钟。在RMII模式下PHY的REF_CLK可以由外部晶振提供也可以由MAC芯片的MCO引脚输出50MHz时钟给PHY官方默认是看硬件设计的。STM32H750B-DK的原理图上明确写着PHY的REF_CLK由STM32H750的MCO2引脚PA5输出50MHz时钟提供这一点非常关键。记住如果你的CubeMX配置里没有使能MCO2的50MHz输出PHY芯片将完全没有时钟MDIO通信读回来的寄存器全部是0xFFFF或0x0000Link状态永远是Down更不用说ping通了。我最初排查时光顾着检查ETH外设的引脚配置完全忽略了MCO2这一路时钟结果绕了不少弯路。所以拿到板子后的第一个动作我建议先检查RCC配置中MCO2的输出源是不是HSE分频系数是否正确确保PA5上能测到50MHz的方波。当然这不是说所有板子都必须用MCO2如果你的板子PHY自己带晶振那就不需要MCO2了但STM32H750B-DK属于前者。RMII接口的另一个特性是数据线宽度只有2位加上控制信号一共9根线连线少布线方便但代价是REF_CLK必须严格保持50MHz精度要求更高信号完整性对时钟抖动更敏感。实际测量时我用示波器看了PA5引脚的波形频率确实是50.00MHz幅度3.3V没有问题。但如果你拿逻辑分析仪去抓RX信号的时序会发现CRS_DV信号在接收数据时应该保持高电平如果一直是低说明PHY没有向MAC提供有效的数据指示。不过这些都是后话先确保能正常通信再看波形也不迟。2.2 通过MDIO读取PHY寄存器验证PHY是否存活在嵌入式环境里和PHY芯片交互的通道是MDIOManagement Data Input/Output总线它由MDC时钟线和MDIO数据线组成通过一系列寄存器读写操作来配置和监控PHY。HAL库已经封装好了底层接口用HAL_ETH_ReadPHYRegister可以直接读取PHY的寄存器。下面是我写的读取PHY ID和状态的代码片段uint32_t phy_id_1, phy_id_2, bmsr, bcr; HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BSR, bmsr); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_ID1, phy_id_1); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_ID2, phy_id_2); printf(PHY BCR: 0x%04x\r\n, bcr); printf(PHY BSR: 0x%04x\r\n, bmsr); printf(PHY ID1: 0x%04x\r\n, phy_id_1); printf(PHY ID2: 0x%04x\r\n, phy_id_2);如果PHY的ID1读出来是0x0007ID2是0xC133LAN8742A的具体ID值说明MDIO通路正常PHY基本是活的。BSR的低两位代表扩展状态bit2是Link状态为1表示链路建立。如果你把这一组读出来都正常就可以说硬件链路已经通了80%。但别忘了MDIO通信正常不代表RMII数据通路正常这是两个概念。数据通路的问题要么是引脚配置错误要么是信号质量问题要么是PHY工作在错误的模式全双工、半双工、协商模式等。我在调试时故意把LAN8742A设置为强制100M全双工模式看看Link是否依然正常。方法是改写BCR寄存器关闭自动协商强制设置速度和双工模式uint32_t bcr_val 0; HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr_val); bcr_val ~0x1000; // 关闭自动协商 bcr_val | 0x0100; // 强制100Mbps bcr_val | 0x0100 1; // 设置全双工 HAL_ETH_WritePHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr_val);这里要注意强制设置后电脑网卡那边必须和PHY保持一致的速率和双工模式否则会协商失败出现大量的CRC错误和碰撞。测试完记得把自动协商恢复不然软件重启后可能因为模式不匹配导致网络异常。2.3 PHY地址和芯片型号先确认你的PHY不是“玄学”STM32H750B-DK官方的PHY是LAN8742APHY地址是0。但如果你用的是其他板子或者自己画的板子PHY地址可能会不一样比如某些板子用LAN8720A地址也是0还有一些用KSZ8081地址可能是0x01~0x1F需要通过板级硬件配置来确认。PHY地址不对MDIO读写全会失败返回0xFFFF或者根本无响应。这个事我当年第一次调以太网时踩过因为板子的PHY地址其实在硬件上通过PHYAD[0:4]引脚上下拉决定不同厂家的默认值不一样不能想当然。如果你不确定PHY地址可以通过扫描的方式从地址0到31依次读取PHY_ID1寄存器如果读到的ID合理比如0x0007就说明这个地址有PHY。我写过一个简单的扫描函数for (uint8_t addr 0; addr 32; addr) { uint32_t id1 0, id2 0; if (HAL_ETH_ReadPHYRegister(heth, addr, PHY_ID1, id1) HAL_OK HAL_ETH_ReadPHYRegister(heth, addr, PHY_ID2, id2) HAL_OK) { if (id1 ! 0x0000 id1 ! 0xFFFF) { printf(Found PHY at addr %d, ID10x%04x ID20x%04x\r\n, addr, id1, id2); } } }这个技巧调试中非常实用特别适合你手头板子来源不明、原理图不全的情况。总之PHY硬件链路排查的目标是确认三件事PHY芯片存在且能和MCU通信、Link状态正常、RMII数据引脚无异常。这三件事全部确认后才能放心地去查软件配置。3. 软件配置复盘MAC地址、中断和DMA一个都不能少3.1 MAC地址与ARP机制的深层关联很多朋友在调试STM32以太网时往往会忽略MAC地址的配置觉得随便填个地址就行。但实际上MAC地址设置错误会导致非常诡异的网络故障。我的板子在CubeMX里默认生成的代码中MAC地址是全部为0的。如果MAC地址全0PHY和链路层通讯也正常但LwIP协议栈发送ARP响应时ARP报文的Sender MAC地址会是00:00:00:00:00:00电脑端接收到这样一个ARP响应通常会直接丢弃因为源MAC地址全0被认为是无效的。这就是为什么我Wireshark里看不到任何响应报文。正确的做法是在初始化MAC之前设置一个合法且唯一的MAC地址。合法意味着第一个字节的低两位有特殊含义bit0是单播/多播标志bit1是全局/本地管理标志。对于用户自分配的本地管理地址第一个字节的bit1应该置1bit0置0也就是第一个字节的二进制格式是xxxxxx10。一个省心的做法是直接用Cortex M7内核芯片的UID来生成MAC地址这样可以确保每块板子烧录固件之后自动获得不同的MAC地址尤其在生产多台设备时非常有用。下面是我当时的做法从STM32的UID寄存器中读取96位唯一标识然后组合出一个MAC地址void GetUniqueMAC(uint8_t mac[6]) { uint32_t uid[3]; uid[0] HAL_GetUIDw0(); uid[1] HAL_GetUIDw1(); uid[2] HAL_GetUIDw2(); mac[0] 0x02; // 本地管理单播 mac[1] (uint8_t)(uid[0] 0xFF); mac[2] (uint8_t)((uid[0] 8) 0xFF); mac[3] (uint8_t)((uid[0] 16) 0xFF); mac[4] (uint8_t)(uid[1] 0xFF); mac[5] (uint8_t)((uid[1] 8) 0xFF); }然后在MX_LWIP_Init里用生成的MAC地址替换默认的全0地址。这一步解决后板子开始回应ARP了但ping依然超时说明还有下一个坑在等我。3.2 中断优先级与DMA描述符系统稳定性的隐患STM32H750的以太网MAC支持DMA方式收发数据内部有独立的DMA描述符列表RX/TX Descriptor数据从一个缓冲区到另一个缓冲区完全靠DMA搬运CPU只在收发完成中断或者轮询状态时介入。初始化的关键是正确配置DMA描述符的地址、长度和环回缓冲区结构。如果描述符配置错误比如缓冲区大小和描述符的Buffer1/2长度字段不一致就会造成数据截断或者接收描述符无法正常返回Ready状态最终表现为收不到任何数据包。在裸机轮询模式下LwIP会周期性地调用ethernetif_input来检查是否有接收完的数据包这个函数最终调用HAL_ETH_ReadData从DMA描述符里取数据。如果DMA描述符因为配置错误而枯竭没有Ready状态的描述符那后续数据包都会直接被丢弃ping自然不通。我当时打印了RX描述符的状态寄存器发现全部处于Normal状态但其中一个描述符的Buffer Length字段是0导致HAL库在解析时跳过了这个描述符形成了一个“断环”。这个问题最坑的地方在于它不是必现的取决于网卡和电脑端发送ARP请求的时机以及数据包到达的速率有时候重启一下就“好了”过一会又不行。解决办法是重新初始化DMA描述符确保每个描述符的Buffer1地址有效且长度正确。HAL库的HAL_ETH_Init内部会调用HAL_ETH_InitDMA来自动设置描述符但前提是你的接收缓冲区数组大小必须按EthBuffSize来定义且字节对齐。这里强烈建议不要改动CubeMX生成的默认描述符数量和数据缓冲大小如果你需要增加收发缓冲区一定要同步修改eth.h里的ETH_RX_DESC_CNT和ETH_TX_DESC_CNT宏以及EthBuffSize否则HAL库内部和外部数组长度不匹配会出现越界访问直接跑飞。中断优先级的配置同样重要。STM32H750的以太网中断请求是ETH_IRQn如果你使用了中断模式有操作系统时常用必须确保ETH中断优先级比系统心跳中断高或者至少不能被其他高频中断无限抢占。否则在极端情况下ETH中断一直被挂起DMA接收数据无法及时处理缓冲区溢出数据包丢失。裸机轮询模式下则不存在这个问题但要注意LwIP的sys_check_timeouts函数要周期调用否则TCP的定时器事件无法触发即使ping通了TCP连接也建立不起来。我当时就遇到了这个坑——ping包突然全通但TCP客户端死活连不上最后发现是我主循环里只喂了ethernetif_input忘了调用sys_check_timeoutsTCP的SYN重传机制一直没启动连接始终处于SYN_SENT状态。3.3 LwIP配置的隐性要求以及内存池大小的权衡LwIP的内存配置直接影响到网络功能的稳定性很多人只是套用CubeMX默认配置遇到问题就往上游查其实陷阱可能就在内存池大小上。LwIP的内存分为两类一种是MEM_LIBC_MALLOC为0时的自定义堆内存通过mem_malloc分配另一种是MEM_SIZE定义的整个堆的大小以及PBUF_POOL_SIZE定义的pbud缓冲池大小。在CubeMX里LWIP_MEM_SIZE默认值通常是1600字节左右用于TCP控制块、UDP控制块、ARP表等结构体的分配。如果这个值设得太小ARP表项分配失败会导致ARP缓存无法记录对端MAC地址ping的第一个包丢、后续包通或者完全不通。我当时把LWIP_MEM_SIZE直接改到40960字节LWIP_PBUF_POOL_SIZE设为16个每个PBUF_POOL_BUFSIZE默认是1500字节这样所有协议控制块和缓冲池都绰绰有余。对于STM32H750这种RAM高达1MB的MCU来说多分配点内存给LwIP完全不是问题没必要抠抠搜搜的。但也不能无限加大因为mem_malloc是从一个大数组中分配内存如果这个数组太大静态RAM占用过多其他任务的栈空间就会变小。我用的是H750配置为外部SDRAM 内部RAM的方案把LwIP的内存池放到SDRAM里这样内部RAM的压力就小了很多网络处理速度也不受影响。需要注意的是如果你的LwIP内存池放在外部SDRAM里初始化顺序一定要确保SDRAM先初始化完成再执行LwIP的初始化否则LwIP会访问未初始化的SDRAM区域表现同样是各种诡异故障。4. 协议栈层调试Wireshark抓包、回环测试和经典故障模式4.1 抓包定位问题的层次不要再瞎猜了调试网络问题时Wireshark是必备利器它能在电脑端看到所有发往和来自开发板的数据包。在我的排查过程中Wireshark发挥了决定性作用第一次我看到了电脑发出的ARP请求但没有板子的回应修改MAC地址后看到了ARP回应但随后ICMP Echo Request到了板子却看不到Echo Reply。这说明板子的链路层已经通了问题出在IP层或者ICMP处理上。当时我还怀疑是LwIP没有正确注册网卡、IP地址没有正确赋值或者是netif-flags没有设置NETIF_FLAG_LINK_UP导致协议栈认为链路未就绪从而不处理任何收发。解决方式是在MX_LWIP_Init中初始化netif后调用netif_set_link_up和netif_set_up让协议栈明确知道当前网卡是活跃的。这里还涉及一个容易被忽略的点netif-output函数是否被正确初始化。LwIP的netif_add会指定ip_input等回调但IP层输出的函数指针在low_level_output和etharp_output之间要经过一个绑定过程。如果你在调用netif_add时传入的回调参数有误或者netif-linkoutput没有赋值IP包就永远无法真正发出去。最简单的方法是使用CubeMX生成的默认LwIP初始化函数不要自己去手动注册回调和netif除非你非常熟悉LwIP的源码结构。我见过不少人为了追求“轻量级”而自行裁剪LwIP结果遗漏了必要的回调导致网络完全不通最后又花一天时间对比源码得不偿失。我建议在排查时先在LwIP初始化的最后加一个打印打印出当前netif的IP地址、网关、MAC地址和链接状态确认这些全部正确后再去做下一步协议测试。比如printf(netif-ip_addr: %s\r\n, ip4addr_ntoa(netif_ip_addr4(gnetif))); printf(netif-gw_addr: %s\r\n, ip4addr_ntoa(netif_ip_gw4(gnetif))); printf(netif-netmask: %s\r\n, ip4addr_ntoa(netif_ip_netmask4(gnetif))); printf(netif-mac: %02x:%02x:%02x:%02x:%02x:%02x\r\n, gnetif.hwaddr[0], gnetif.hwaddr[1], gnetif.hwaddr[2], gnetif.hwaddr[3], gnetif.hwaddr[4], gnetif.hwaddr[5]); printf(netif flags: 0x%08x\r\n, gnetif.flags);如果netif的flags包含NETIF_FLAG_UP和NETIF_FLAG_LINK_UP分别是0x1和0x2那就说明协议栈认为自己可以通信用了。这两步检查之后如果ping还是不通那几乎可以确定是底层驱动的问题而不是LwIP配置问题。4.2 回环测试三板斧从MAC回环到PHY回环当排查陷入僵局时可以引入“回环测试”来拆分问题。回环测试分为三个层级MAC内部回环、PHY回环和外部网线对通回环。MAC内部回环可以测试MAC到DMA、DMA到内存这条数据链路PHY回环可以测试PHY到MAC的数据通路外部网线对通回环则需要一根交叉网线或者通过交换机把TX和RX连接起来能全面验证整个物理链路。在HAL库中MAC回环的配置方式是在HAL_ETH_Init后把heth.Init.ChecksumMode设为ETH_CHECKSUM_BY_HARDWARE并在ETH_MACCR寄存器中设置ETH_MACCR_ECRSFD或类似位具体要看HAL版本。更简单的方式是通过HAL_ETH_ConfigMAC来配置ETH_MACConfigTypeDef mac_conf; HAL_ETH_GetMACConfig(heth, mac_conf); mac_conf.Mode ETH_MODE_FULLDUPLEX; mac_conf.Speed ETH_SPEED_100M; mac_conf.LoopbackMode ETH_MAC_LOOPBACK_DISABLE; // 或者某种回环模式 HAL_ETH_SetMACConfig(heth, mac_conf);PHY回环则需要通过MDIO改写PHY的BCR寄存器的bit14Loopback位为1这样PHY收到的数据会立刻转发出去不经过网线。这样可以验证从MCU发出的数据经过MAC、PHY后能否直接收回来。我的实测经验是MAC内部回环通常是可用的PHY回环在部分PHY上可能由于硬件bug或者配置时序问题导致不兼容如果你是第一次调试不建议直接用回环作为唯一判断标准它更适合在怀疑某个硬件节点时才去启用。我最终在解决自己的问题时其实并没有用到回环测试而是通过逻辑分析仪抓RMII信号发现了问题。RMII的RXD0和RXD1在接收数据时应该是变化的如果它们是恒定的低电平说明PHY根本没有为MAC提供任何数据。在我最初PHY寄存器正常、Link状态正常的情况下RXD0和RXD1纹丝不动这就直接锁定了问题不在PHY的Link协商而在于PHY并没有正确解析到数据。最后追查到PHY的REF_CLK虽然测量出50MHz但和MAC侧的参考时钟不同源导致时序不匹配。这个问题的根源在于CubeMX的RCC配置里MCO2的输出分频并不是从HSE直接分出50MHz而是经过PLL后才分频得到和RMII要求的同步时钟存在相位偏移。所有外部信号都看似正常但数据就是通不了。解决方式是将MCO2的时钟源直接配置为HSE然后分频为50MHz而不是用PLLCLK这确实算是一步非常隐蔽的坑。4.3 二层、三层转发原理与ping不通的常见组合故障理解ping的整个过程对定位问题也很有帮助。当电脑ping板子的IP时如果两者在同一网段电脑首先查自己的ARP表如果没有板子的MAC地址就发一个ARP广播询问“谁是192.168.1.10”。板子的LwIP协议栈收到ARP请求后检查目标IP是否匹配本地IP如果匹配就回复ARP应答。电脑收到ARP应答后更新ARP缓存然后发送ICMP Echo Request。板子的LwIP收到后经过IP层校验发现协议号是ICMP交给ICMP模块处理ICMP模块生成Echo Reply原路返回。这个过程涉及多个函数调用任何一步出错表现都是ping不通但具体现象略有不同。举个例子如果ARP请求能通但ICMP不通你会看到Wireshark里有电脑发出的ICMP请求但没有回应而ARP通讯正常。这种情况多半是LwIP的icmp_input处理有问题比如IP头校验失败、网络字节序问题、或者回显请求的Identifier/Sequence Number没有被正确回填。如果ARP都不通说明问题在更底层。还有一种组合故障板子ping电脑通但电脑ping板子不通这种情况往往是板子的默认网关或子网掩码设置错误电脑发回来的包板子错误地判断成了不同网段直接丢掉了或者做了错误的路由转发。所以配置静态IP时一定要确保子网掩码、网关、IP三者和电脑在同一网段且逻辑自洽。我在调STM32网络时习惯于每次修改完网络配置后在板子端串口打印当前netif的IP和mask再对比电脑端的ipconfig输出确保两个数字完全对得上。很多问题的根源其实就是一个数字的差异——比如电脑是192.168.1.100/24板子配成了192.168.0.10/24看起来都在192.168网段但实际子网划分已经不同了。等你排查到协议栈内部时再去回头检查这种基础配置才能高效解决。5. 排查工具与定位思路汇总附问题速查表我把这次排查过程中用到的工具和步骤做一个完整梳理方便大家直接照着做。第一步确认PHY存活并能通过MDIO访问。使用Nucleo或Discovery板自带的ST-LINK虚拟串口打印PHY寄存器值重点关注BCR、BSR和PHY ID。如果PHY ID读取正常但Link Status为0检查网线、交换机端口、对端设备是否正常工作。如果Link Status为1跳到第二步。第二步检查RMII接口的信号。用示波器或逻辑分析仪测量PA5MCO2是否有50MHz时钟输出测量PA1、PA7、PG11或者你板上的TXD0/TXD1/TX_EN是否有数据活动。试着从电脑ping板子观察CRS_DV接收信号是否有脉冲。如果无脉冲说明PHY没有向MAC提供接收数据问题大概率还是PHY侧的时钟或配置如果有脉冲说明PHY收到了数据问题在MAC或协议栈侧进入第三步。第三步打开Wireshark抓包观察是否有ARP请求到达电脑端是否有板子的ARP回应。有ARP请求但没有回应基本是MAC地址配置问题或LwIP没有正确处理ARP有回应但ping不通继续查ICMP处理环节检查IP层和ICMP校验和。第四步检查LwIP的配置netif的IP、子网掩码、网关是否正确MAC地址是否唯一且有效LWIP_MEM_SIZE和LWIP_PBUF_POOL_SIZE是否够用sys_check_timeouts是否在主循环中周期调用。把netif的标志位打印出来确认NETIF_FLAG_UP和NETIF_FLAG_LINK_UP已置位。第五步如果以上全部正常可以尝试回环测试来隔离问题。先启用MAC回环在板子上用LwIP的raw API或netconn API主动发送一个UDP包看本地能否收到。若收不到则问题在MAC/DMA驱动若能收到再启用PHY回环若还是能收到则可以排除PHY和MAC之间的问题剩下的可能性就是外部网络环境或信号完整性问题。下面把我想到的典型故障汇总成一张表格方便对照查找现象可能原因排查方向MDIO读不到PHY IDPHY地址错误、MCO2时钟缺失、I2C/MDIO引脚占用扫描PHY地址检查时钟输出查看CubeMX引脚配置PHY Link Status0网线未插好、对端设备没电、自动协商失败换线检查对端设备强制设置速率双工模式Link1但数据不通RMII时序问题、PHY数据线连接错误示波器抓RX/TX信号看REF_CLK是否同源电脑发ARP请求无回应MAC地址全0、ARP表创建失败、LwIP未初始化设置有效MAC增大MEM_SIZE检查netif初始化ARP有回应但ICMP无回应IP配置错误、ICMP校验和问题、网络字节序问题检查IP/掩码/网关打印netif配置板子ping电脑通电脑ping板子不通子网掩码或网关配置错误导致回包路由错误对比两端IP配置确保同网段偶尔通偶尔不通DMA描述符配置错误、中断优先级问题检查描述符循环结构增加内存池检查底层中断TCP连接建立不了但ping通主循环未调用sys_check_timeouts在while循环中周期调用sys_check_timeouts6. 别忽略的细节虚拟机和交叉网线的特殊场景排查过程中我还遇到过一种“假性故障”就是电脑端用的是虚拟机网络。比如你电脑上装了VMware或VirtualBox宿主机网卡绑定了VirtualBox Host-Only Ethernet Adapter或者选择了桥接模式但桥接到了错误的物理网卡上此时从虚拟机里ping板子除非全部网络都配置正确否则很容易出现ping不通的情况。我当时有一段时间就是从VMware里ping的结果发现VMware的桥接网络把数据转发到了Wi-Fi而不是有线网卡上当然ping不通。后来我换回宿主机直连ping才继续正常排查。这个点特别容易被忽略一旦你把方向搞错可能就会在板子的驱动上做很多无用功。此外如果你的电脑网卡支持节能以太网Energy Efficient EthernetEEE或者流控功能有时在低速通信时会出现掉线或者异常。可以在电脑网卡的高级设置里关闭“环保节能”和“流量控制”把速度和双工模式直接固定为100Mbps Full Duplex这样和开发板的协商就相对稳定。我当时把网卡直接设置为千兆全双工模式如果电脑网卡是千兆结果和板子的百兆PHY无法协商导致Link灯明明亮了但数据传输不稳定。把电脑网卡强制设为100Mbps Full Duplex后问题立刻改善。这点听起来很玄学但实际调试中特别常见。还有一个容易忽略的点是交叉网线和直通网线的区别。现在的网卡和交换机基本都支持Auto MDI-X功能不管你是直通线还是交叉线都能自动切换但如果你用的是很老旧的设备或者网线内部线路本身有问题就会出现“插上去了Link灯亮但数据不通”的局面。解决办法是换一根已知质量良好的网线最好在另一块开发板上先验证过。这个操作成本最低但往往能帮你节省大量时间。7. 最后的经验总结和一些额外建议经过这几天的折腾我算是把STM32H750B-DK以太网启动的每一个环节都摸透了。从我这次的经历来看ping不通的根因最终是MAC地址全0和MCO2时钟配置不当两个问题叠加造成的。单独看任何一个都不至于导致完全不通但叠加在一起就让整个问题变得极其隐蔽而且现象不稳定有时候连Link灯都正常但就是没有任何数据回包。所以我写这篇博客的核心目的就是提醒大家遇到这种问题不要只盯住某一个点一定要从硬件时钟、PHY寄存器、MAC配置、LwIP协议栈四个维度系统性排查并且充分利用Wireshark和逻辑分析仪这两个工具去定位层次。对于新手我还有几条实用建议。一是学会看原理图STM32H750B-DK的原理图文件可以在ST官网下载网络部分一定要去核对PHY的型号、地址、REF_CLK来源这些信息直接决定了你的CubeMX配置。二是串口日志一定要保持开启在关键函数入口和出口打印状态比如HAL_ETH_Init返回的HAL_StatusTypeDef、HAL_ETH_ReadPHYRegister返回值、LwIP初始化结果这些打印能帮你快速缩小范围。三是多利用HAL库的返回值不要忽略任何HAL_ERROR或HAL_BUSY我见过很多人只要串口打印通了就默认硬件初始化成功其实以太网初始化可能早就失败了只是你忽视了返回值。最后再分享一个实用小技巧。如果你怀疑网络不稳定可以在电脑端用连续ping和TTL值来测试延迟和丢包率例如输入ping 192.168.1.10 -t观察有没有时通时不通的现象。如果连续ping了100个包全部通而且延迟稳定在1ms以内说明链路没问题。如果出现个别丢包可以再用ping 192.168.1.10 -n 100 -l 1400来测试大包传输稳定性大包更容易暴露DMA缓冲区不足或描述符配置错误的问题。我实测中当我把LwIP的PBUF_POOL_BUFSIZE从默认的1500改成1518后大包传输的成功率有了明显提升这也是一个经常被忽略的细节。希望我的这段经历能帮你少踩几个坑早日让你的STM32H750B-DK在网络世界里“活”过来。 STM32H750B-DK以太网ping不通？从ARP到RMII的完整排查实战
我是去年底拿到的STM32H750B-DK这块板子板载资源确实丰富主控频率高、外设全、带LCD和音频本来想着用它做个网络音频传输的小项目结果刚把网线插上去准备测TCP通信电脑端ping就一直超时刚开始以为是网线问题换了好几根线又换交换机口始终不通。折腾了整整两天从硬件排查到协议栈配置最后定位到的原因其实相当隐蔽也让我把整个以太网启动链路彻底理了一遍。这篇就完整记录一下我当时的排查思路和最终解决方式给同样被这块板子卡住的兄弟们一个参考。先交代一下环境和现象方便你对号入座。我的开发环境是STM32CubeIDE 1.15HAL库版本1.11.3在CubeMX里使能了ETH外设并配置为RMII模式协议栈用的LwIP不带操作系统版本就是裸机轮询模式PHY芯片是板载的LAN8742A。板子上电后LCD屏正常点亮串口打印运行日志也没问题LED在闪烁说明MCU跑起来了。网线插到电脑直连Windows端显示“网络电缆被拔出”的状态倒没有说明链路层是有信号的但ping 192.168.1.10板子静态IP结果一直是“请求超时”。同一根网线插到另一块开发板上马上就能ping通所以问题基本锁定在STM32H750B-DK这一侧的以太网配置上。我这里先做个简单的分类方便后面逐步排查。以太网通信分为三个层级硬件物理层PHY芯片、MAC控制器层STM32内部的以太网MAC、网络协议栈层LwIP。ping不通的原因可能出现在任何一个层级而且上层的问题往往也会表现为底层的“假象”所以排查顺序必须是自底向上。下面我把每个层级的具体排查方法、我用到的代码、以及坑点全部展开说清楚。1. 问题描绘与初步判断板子“不响应”之前先确认它想不想响应拿到这个现象首先不要急着怀疑协议栈而是先确认板子本身的网络行为是否正常。我当时用了一个比较粗暴但有效的方法——把板子串口日志的调试等级调到最详细同时使用Wireshark在电脑端抓包看看板子到底有没有发出ARP请求或者ARP应答。这里特别提醒一下ping的第一步是ARP如果你电脑端发出去的是ARP请求而板子完全没有回应那说明链路层以下就没通。如果板子有ARP回应但ICMP回显无响应问题就在协议栈上层。从实际结果来看我的电脑端持续发出ARP广播但Wireshark里看不到来自板子MAC地址的任何回应报文。这就很有意思了——意味着板子可能根本没有正确接收到ARP请求或者收下来了但上层协议栈没处理也或者PHY/MAC层数据收发环节本身就有问题。为了进一步缩小范围我直接读取板子PHY芯片LAN8742A的寄存器检查Link状态和自动协商结果。LAN8742A的寄存器1Basic Mode Status Register的bit2就是Link Status位寄存器31可以读取PHY的ID如果这些值都能读出来说明MDIO通信是通的问题大概不在PHY硬件上。我的读取结果寄存器0的值为0x1000bit13为1表示自动协商完成寄存器1的bit2为1表示链路已建立PHY工作正常。这就基本排除了物理连接和PHY自动协商的问题。不过这里也有个容易踩的坑PHY的Link Status只是“网线插好了信号有连接”并不代表数据通路是通的。RMII接口一共有9根信号线包括TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO以及REF_CLK。这些信号只要有一根虚焊、配置错误或者引脚冲突都会导致收不到数据。我在检查PCB原理图时发现STM32H750B-DK的以太网引脚和SDMMC的引脚部分复用另外和USART的某个引脚也有冲突可能。所以我强烈建议拿到板子后第一步先去核对你的CubeMX工程里有没有把外部引脚正确配置成ETH的复用功能而不是被其他外设抢占。很多时候板子出厂自带例程能ping通一旦你自己新建工程配置稍有问题网络就“死”了。2. 硬件链路排查从RMII信号到PHY寄存器逐个确认2.1 STM32H750B-DK的以太网硬件拓扑和关键引脚这块开发板用的是LAN8742A是一款非常常见的10/100M以太网PHY芯片支持RMII和MII两种接口模式通过一个25MHz的无源晶振提供时钟。在RMII模式下PHY的REF_CLK可以由外部晶振提供也可以由MAC芯片的MCO引脚输出50MHz时钟给PHY官方默认是看硬件设计的。STM32H750B-DK的原理图上明确写着PHY的REF_CLK由STM32H750的MCO2引脚PA5输出50MHz时钟提供这一点非常关键。记住如果你的CubeMX配置里没有使能MCO2的50MHz输出PHY芯片将完全没有时钟MDIO通信读回来的寄存器全部是0xFFFF或0x0000Link状态永远是Down更不用说ping通了。我最初排查时光顾着检查ETH外设的引脚配置完全忽略了MCO2这一路时钟结果绕了不少弯路。所以拿到板子后的第一个动作我建议先检查RCC配置中MCO2的输出源是不是HSE分频系数是否正确确保PA5上能测到50MHz的方波。当然这不是说所有板子都必须用MCO2如果你的板子PHY自己带晶振那就不需要MCO2了但STM32H750B-DK属于前者。RMII接口的另一个特性是数据线宽度只有2位加上控制信号一共9根线连线少布线方便但代价是REF_CLK必须严格保持50MHz精度要求更高信号完整性对时钟抖动更敏感。实际测量时我用示波器看了PA5引脚的波形频率确实是50.00MHz幅度3.3V没有问题。但如果你拿逻辑分析仪去抓RX信号的时序会发现CRS_DV信号在接收数据时应该保持高电平如果一直是低说明PHY没有向MAC提供有效的数据指示。不过这些都是后话先确保能正常通信再看波形也不迟。2.2 通过MDIO读取PHY寄存器验证PHY是否存活在嵌入式环境里和PHY芯片交互的通道是MDIOManagement Data Input/Output总线它由MDC时钟线和MDIO数据线组成通过一系列寄存器读写操作来配置和监控PHY。HAL库已经封装好了底层接口用HAL_ETH_ReadPHYRegister可以直接读取PHY的寄存器。下面是我写的读取PHY ID和状态的代码片段uint32_t phy_id_1, phy_id_2, bmsr, bcr; HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BSR, bmsr); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_ID1, phy_id_1); HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_ID2, phy_id_2); printf(PHY BCR: 0x%04x\r\n, bcr); printf(PHY BSR: 0x%04x\r\n, bmsr); printf(PHY ID1: 0x%04x\r\n, phy_id_1); printf(PHY ID2: 0x%04x\r\n, phy_id_2);如果PHY的ID1读出来是0x0007ID2是0xC133LAN8742A的具体ID值说明MDIO通路正常PHY基本是活的。BSR的低两位代表扩展状态bit2是Link状态为1表示链路建立。如果你把这一组读出来都正常就可以说硬件链路已经通了80%。但别忘了MDIO通信正常不代表RMII数据通路正常这是两个概念。数据通路的问题要么是引脚配置错误要么是信号质量问题要么是PHY工作在错误的模式全双工、半双工、协商模式等。我在调试时故意把LAN8742A设置为强制100M全双工模式看看Link是否依然正常。方法是改写BCR寄存器关闭自动协商强制设置速度和双工模式uint32_t bcr_val 0; HAL_ETH_ReadPHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr_val); bcr_val ~0x1000; // 关闭自动协商 bcr_val | 0x0100; // 强制100Mbps bcr_val | 0x0100 1; // 设置全双工 HAL_ETH_WritePHYRegister(heth, LAN8742A_PHY_ADDR, PHY_BCR, bcr_val);这里要注意强制设置后电脑网卡那边必须和PHY保持一致的速率和双工模式否则会协商失败出现大量的CRC错误和碰撞。测试完记得把自动协商恢复不然软件重启后可能因为模式不匹配导致网络异常。2.3 PHY地址和芯片型号先确认你的PHY不是“玄学”STM32H750B-DK官方的PHY是LAN8742APHY地址是0。但如果你用的是其他板子或者自己画的板子PHY地址可能会不一样比如某些板子用LAN8720A地址也是0还有一些用KSZ8081地址可能是0x01~0x1F需要通过板级硬件配置来确认。PHY地址不对MDIO读写全会失败返回0xFFFF或者根本无响应。这个事我当年第一次调以太网时踩过因为板子的PHY地址其实在硬件上通过PHYAD[0:4]引脚上下拉决定不同厂家的默认值不一样不能想当然。如果你不确定PHY地址可以通过扫描的方式从地址0到31依次读取PHY_ID1寄存器如果读到的ID合理比如0x0007就说明这个地址有PHY。我写过一个简单的扫描函数for (uint8_t addr 0; addr 32; addr) { uint32_t id1 0, id2 0; if (HAL_ETH_ReadPHYRegister(heth, addr, PHY_ID1, id1) HAL_OK HAL_ETH_ReadPHYRegister(heth, addr, PHY_ID2, id2) HAL_OK) { if (id1 ! 0x0000 id1 ! 0xFFFF) { printf(Found PHY at addr %d, ID10x%04x ID20x%04x\r\n, addr, id1, id2); } } }这个技巧调试中非常实用特别适合你手头板子来源不明、原理图不全的情况。总之PHY硬件链路排查的目标是确认三件事PHY芯片存在且能和MCU通信、Link状态正常、RMII数据引脚无异常。这三件事全部确认后才能放心地去查软件配置。3. 软件配置复盘MAC地址、中断和DMA一个都不能少3.1 MAC地址与ARP机制的深层关联很多朋友在调试STM32以太网时往往会忽略MAC地址的配置觉得随便填个地址就行。但实际上MAC地址设置错误会导致非常诡异的网络故障。我的板子在CubeMX里默认生成的代码中MAC地址是全部为0的。如果MAC地址全0PHY和链路层通讯也正常但LwIP协议栈发送ARP响应时ARP报文的Sender MAC地址会是00:00:00:00:00:00电脑端接收到这样一个ARP响应通常会直接丢弃因为源MAC地址全0被认为是无效的。这就是为什么我Wireshark里看不到任何响应报文。正确的做法是在初始化MAC之前设置一个合法且唯一的MAC地址。合法意味着第一个字节的低两位有特殊含义bit0是单播/多播标志bit1是全局/本地管理标志。对于用户自分配的本地管理地址第一个字节的bit1应该置1bit0置0也就是第一个字节的二进制格式是xxxxxx10。一个省心的做法是直接用Cortex M7内核芯片的UID来生成MAC地址这样可以确保每块板子烧录固件之后自动获得不同的MAC地址尤其在生产多台设备时非常有用。下面是我当时的做法从STM32的UID寄存器中读取96位唯一标识然后组合出一个MAC地址void GetUniqueMAC(uint8_t mac[6]) { uint32_t uid[3]; uid[0] HAL_GetUIDw0(); uid[1] HAL_GetUIDw1(); uid[2] HAL_GetUIDw2(); mac[0] 0x02; // 本地管理单播 mac[1] (uint8_t)(uid[0] 0xFF); mac[2] (uint8_t)((uid[0] 8) 0xFF); mac[3] (uint8_t)((uid[0] 16) 0xFF); mac[4] (uint8_t)(uid[1] 0xFF); mac[5] (uint8_t)((uid[1] 8) 0xFF); }然后在MX_LWIP_Init里用生成的MAC地址替换默认的全0地址。这一步解决后板子开始回应ARP了但ping依然超时说明还有下一个坑在等我。3.2 中断优先级与DMA描述符系统稳定性的隐患STM32H750的以太网MAC支持DMA方式收发数据内部有独立的DMA描述符列表RX/TX Descriptor数据从一个缓冲区到另一个缓冲区完全靠DMA搬运CPU只在收发完成中断或者轮询状态时介入。初始化的关键是正确配置DMA描述符的地址、长度和环回缓冲区结构。如果描述符配置错误比如缓冲区大小和描述符的Buffer1/2长度字段不一致就会造成数据截断或者接收描述符无法正常返回Ready状态最终表现为收不到任何数据包。在裸机轮询模式下LwIP会周期性地调用ethernetif_input来检查是否有接收完的数据包这个函数最终调用HAL_ETH_ReadData从DMA描述符里取数据。如果DMA描述符因为配置错误而枯竭没有Ready状态的描述符那后续数据包都会直接被丢弃ping自然不通。我当时打印了RX描述符的状态寄存器发现全部处于Normal状态但其中一个描述符的Buffer Length字段是0导致HAL库在解析时跳过了这个描述符形成了一个“断环”。这个问题最坑的地方在于它不是必现的取决于网卡和电脑端发送ARP请求的时机以及数据包到达的速率有时候重启一下就“好了”过一会又不行。解决办法是重新初始化DMA描述符确保每个描述符的Buffer1地址有效且长度正确。HAL库的HAL_ETH_Init内部会调用HAL_ETH_InitDMA来自动设置描述符但前提是你的接收缓冲区数组大小必须按EthBuffSize来定义且字节对齐。这里强烈建议不要改动CubeMX生成的默认描述符数量和数据缓冲大小如果你需要增加收发缓冲区一定要同步修改eth.h里的ETH_RX_DESC_CNT和ETH_TX_DESC_CNT宏以及EthBuffSize否则HAL库内部和外部数组长度不匹配会出现越界访问直接跑飞。中断优先级的配置同样重要。STM32H750的以太网中断请求是ETH_IRQn如果你使用了中断模式有操作系统时常用必须确保ETH中断优先级比系统心跳中断高或者至少不能被其他高频中断无限抢占。否则在极端情况下ETH中断一直被挂起DMA接收数据无法及时处理缓冲区溢出数据包丢失。裸机轮询模式下则不存在这个问题但要注意LwIP的sys_check_timeouts函数要周期调用否则TCP的定时器事件无法触发即使ping通了TCP连接也建立不起来。我当时就遇到了这个坑——ping包突然全通但TCP客户端死活连不上最后发现是我主循环里只喂了ethernetif_input忘了调用sys_check_timeoutsTCP的SYN重传机制一直没启动连接始终处于SYN_SENT状态。3.3 LwIP配置的隐性要求以及内存池大小的权衡LwIP的内存配置直接影响到网络功能的稳定性很多人只是套用CubeMX默认配置遇到问题就往上游查其实陷阱可能就在内存池大小上。LwIP的内存分为两类一种是MEM_LIBC_MALLOC为0时的自定义堆内存通过mem_malloc分配另一种是MEM_SIZE定义的整个堆的大小以及PBUF_POOL_SIZE定义的pbud缓冲池大小。在CubeMX里LWIP_MEM_SIZE默认值通常是1600字节左右用于TCP控制块、UDP控制块、ARP表等结构体的分配。如果这个值设得太小ARP表项分配失败会导致ARP缓存无法记录对端MAC地址ping的第一个包丢、后续包通或者完全不通。我当时把LWIP_MEM_SIZE直接改到40960字节LWIP_PBUF_POOL_SIZE设为16个每个PBUF_POOL_BUFSIZE默认是1500字节这样所有协议控制块和缓冲池都绰绰有余。对于STM32H750这种RAM高达1MB的MCU来说多分配点内存给LwIP完全不是问题没必要抠抠搜搜的。但也不能无限加大因为mem_malloc是从一个大数组中分配内存如果这个数组太大静态RAM占用过多其他任务的栈空间就会变小。我用的是H750配置为外部SDRAM 内部RAM的方案把LwIP的内存池放到SDRAM里这样内部RAM的压力就小了很多网络处理速度也不受影响。需要注意的是如果你的LwIP内存池放在外部SDRAM里初始化顺序一定要确保SDRAM先初始化完成再执行LwIP的初始化否则LwIP会访问未初始化的SDRAM区域表现同样是各种诡异故障。4. 协议栈层调试Wireshark抓包、回环测试和经典故障模式4.1 抓包定位问题的层次不要再瞎猜了调试网络问题时Wireshark是必备利器它能在电脑端看到所有发往和来自开发板的数据包。在我的排查过程中Wireshark发挥了决定性作用第一次我看到了电脑发出的ARP请求但没有板子的回应修改MAC地址后看到了ARP回应但随后ICMP Echo Request到了板子却看不到Echo Reply。这说明板子的链路层已经通了问题出在IP层或者ICMP处理上。当时我还怀疑是LwIP没有正确注册网卡、IP地址没有正确赋值或者是netif-flags没有设置NETIF_FLAG_LINK_UP导致协议栈认为链路未就绪从而不处理任何收发。解决方式是在MX_LWIP_Init中初始化netif后调用netif_set_link_up和netif_set_up让协议栈明确知道当前网卡是活跃的。这里还涉及一个容易被忽略的点netif-output函数是否被正确初始化。LwIP的netif_add会指定ip_input等回调但IP层输出的函数指针在low_level_output和etharp_output之间要经过一个绑定过程。如果你在调用netif_add时传入的回调参数有误或者netif-linkoutput没有赋值IP包就永远无法真正发出去。最简单的方法是使用CubeMX生成的默认LwIP初始化函数不要自己去手动注册回调和netif除非你非常熟悉LwIP的源码结构。我见过不少人为了追求“轻量级”而自行裁剪LwIP结果遗漏了必要的回调导致网络完全不通最后又花一天时间对比源码得不偿失。我建议在排查时先在LwIP初始化的最后加一个打印打印出当前netif的IP地址、网关、MAC地址和链接状态确认这些全部正确后再去做下一步协议测试。比如printf(netif-ip_addr: %s\r\n, ip4addr_ntoa(netif_ip_addr4(gnetif))); printf(netif-gw_addr: %s\r\n, ip4addr_ntoa(netif_ip_gw4(gnetif))); printf(netif-netmask: %s\r\n, ip4addr_ntoa(netif_ip_netmask4(gnetif))); printf(netif-mac: %02x:%02x:%02x:%02x:%02x:%02x\r\n, gnetif.hwaddr[0], gnetif.hwaddr[1], gnetif.hwaddr[2], gnetif.hwaddr[3], gnetif.hwaddr[4], gnetif.hwaddr[5]); printf(netif flags: 0x%08x\r\n, gnetif.flags);如果netif的flags包含NETIF_FLAG_UP和NETIF_FLAG_LINK_UP分别是0x1和0x2那就说明协议栈认为自己可以通信用了。这两步检查之后如果ping还是不通那几乎可以确定是底层驱动的问题而不是LwIP配置问题。4.2 回环测试三板斧从MAC回环到PHY回环当排查陷入僵局时可以引入“回环测试”来拆分问题。回环测试分为三个层级MAC内部回环、PHY回环和外部网线对通回环。MAC内部回环可以测试MAC到DMA、DMA到内存这条数据链路PHY回环可以测试PHY到MAC的数据通路外部网线对通回环则需要一根交叉网线或者通过交换机把TX和RX连接起来能全面验证整个物理链路。在HAL库中MAC回环的配置方式是在HAL_ETH_Init后把heth.Init.ChecksumMode设为ETH_CHECKSUM_BY_HARDWARE并在ETH_MACCR寄存器中设置ETH_MACCR_ECRSFD或类似位具体要看HAL版本。更简单的方式是通过HAL_ETH_ConfigMAC来配置ETH_MACConfigTypeDef mac_conf; HAL_ETH_GetMACConfig(heth, mac_conf); mac_conf.Mode ETH_MODE_FULLDUPLEX; mac_conf.Speed ETH_SPEED_100M; mac_conf.LoopbackMode ETH_MAC_LOOPBACK_DISABLE; // 或者某种回环模式 HAL_ETH_SetMACConfig(heth, mac_conf);PHY回环则需要通过MDIO改写PHY的BCR寄存器的bit14Loopback位为1这样PHY收到的数据会立刻转发出去不经过网线。这样可以验证从MCU发出的数据经过MAC、PHY后能否直接收回来。我的实测经验是MAC内部回环通常是可用的PHY回环在部分PHY上可能由于硬件bug或者配置时序问题导致不兼容如果你是第一次调试不建议直接用回环作为唯一判断标准它更适合在怀疑某个硬件节点时才去启用。我最终在解决自己的问题时其实并没有用到回环测试而是通过逻辑分析仪抓RMII信号发现了问题。RMII的RXD0和RXD1在接收数据时应该是变化的如果它们是恒定的低电平说明PHY根本没有为MAC提供任何数据。在我最初PHY寄存器正常、Link状态正常的情况下RXD0和RXD1纹丝不动这就直接锁定了问题不在PHY的Link协商而在于PHY并没有正确解析到数据。最后追查到PHY的REF_CLK虽然测量出50MHz但和MAC侧的参考时钟不同源导致时序不匹配。这个问题的根源在于CubeMX的RCC配置里MCO2的输出分频并不是从HSE直接分出50MHz而是经过PLL后才分频得到和RMII要求的同步时钟存在相位偏移。所有外部信号都看似正常但数据就是通不了。解决方式是将MCO2的时钟源直接配置为HSE然后分频为50MHz而不是用PLLCLK这确实算是一步非常隐蔽的坑。4.3 二层、三层转发原理与ping不通的常见组合故障理解ping的整个过程对定位问题也很有帮助。当电脑ping板子的IP时如果两者在同一网段电脑首先查自己的ARP表如果没有板子的MAC地址就发一个ARP广播询问“谁是192.168.1.10”。板子的LwIP协议栈收到ARP请求后检查目标IP是否匹配本地IP如果匹配就回复ARP应答。电脑收到ARP应答后更新ARP缓存然后发送ICMP Echo Request。板子的LwIP收到后经过IP层校验发现协议号是ICMP交给ICMP模块处理ICMP模块生成Echo Reply原路返回。这个过程涉及多个函数调用任何一步出错表现都是ping不通但具体现象略有不同。举个例子如果ARP请求能通但ICMP不通你会看到Wireshark里有电脑发出的ICMP请求但没有回应而ARP通讯正常。这种情况多半是LwIP的icmp_input处理有问题比如IP头校验失败、网络字节序问题、或者回显请求的Identifier/Sequence Number没有被正确回填。如果ARP都不通说明问题在更底层。还有一种组合故障板子ping电脑通但电脑ping板子不通这种情况往往是板子的默认网关或子网掩码设置错误电脑发回来的包板子错误地判断成了不同网段直接丢掉了或者做了错误的路由转发。所以配置静态IP时一定要确保子网掩码、网关、IP三者和电脑在同一网段且逻辑自洽。我在调STM32网络时习惯于每次修改完网络配置后在板子端串口打印当前netif的IP和mask再对比电脑端的ipconfig输出确保两个数字完全对得上。很多问题的根源其实就是一个数字的差异——比如电脑是192.168.1.100/24板子配成了192.168.0.10/24看起来都在192.168网段但实际子网划分已经不同了。等你排查到协议栈内部时再去回头检查这种基础配置才能高效解决。5. 排查工具与定位思路汇总附问题速查表我把这次排查过程中用到的工具和步骤做一个完整梳理方便大家直接照着做。第一步确认PHY存活并能通过MDIO访问。使用Nucleo或Discovery板自带的ST-LINK虚拟串口打印PHY寄存器值重点关注BCR、BSR和PHY ID。如果PHY ID读取正常但Link Status为0检查网线、交换机端口、对端设备是否正常工作。如果Link Status为1跳到第二步。第二步检查RMII接口的信号。用示波器或逻辑分析仪测量PA5MCO2是否有50MHz时钟输出测量PA1、PA7、PG11或者你板上的TXD0/TXD1/TX_EN是否有数据活动。试着从电脑ping板子观察CRS_DV接收信号是否有脉冲。如果无脉冲说明PHY没有向MAC提供接收数据问题大概率还是PHY侧的时钟或配置如果有脉冲说明PHY收到了数据问题在MAC或协议栈侧进入第三步。第三步打开Wireshark抓包观察是否有ARP请求到达电脑端是否有板子的ARP回应。有ARP请求但没有回应基本是MAC地址配置问题或LwIP没有正确处理ARP有回应但ping不通继续查ICMP处理环节检查IP层和ICMP校验和。第四步检查LwIP的配置netif的IP、子网掩码、网关是否正确MAC地址是否唯一且有效LWIP_MEM_SIZE和LWIP_PBUF_POOL_SIZE是否够用sys_check_timeouts是否在主循环中周期调用。把netif的标志位打印出来确认NETIF_FLAG_UP和NETIF_FLAG_LINK_UP已置位。第五步如果以上全部正常可以尝试回环测试来隔离问题。先启用MAC回环在板子上用LwIP的raw API或netconn API主动发送一个UDP包看本地能否收到。若收不到则问题在MAC/DMA驱动若能收到再启用PHY回环若还是能收到则可以排除PHY和MAC之间的问题剩下的可能性就是外部网络环境或信号完整性问题。下面把我想到的典型故障汇总成一张表格方便对照查找现象可能原因排查方向MDIO读不到PHY IDPHY地址错误、MCO2时钟缺失、I2C/MDIO引脚占用扫描PHY地址检查时钟输出查看CubeMX引脚配置PHY Link Status0网线未插好、对端设备没电、自动协商失败换线检查对端设备强制设置速率双工模式Link1但数据不通RMII时序问题、PHY数据线连接错误示波器抓RX/TX信号看REF_CLK是否同源电脑发ARP请求无回应MAC地址全0、ARP表创建失败、LwIP未初始化设置有效MAC增大MEM_SIZE检查netif初始化ARP有回应但ICMP无回应IP配置错误、ICMP校验和问题、网络字节序问题检查IP/掩码/网关打印netif配置板子ping电脑通电脑ping板子不通子网掩码或网关配置错误导致回包路由错误对比两端IP配置确保同网段偶尔通偶尔不通DMA描述符配置错误、中断优先级问题检查描述符循环结构增加内存池检查底层中断TCP连接建立不了但ping通主循环未调用sys_check_timeouts在while循环中周期调用sys_check_timeouts6. 别忽略的细节虚拟机和交叉网线的特殊场景排查过程中我还遇到过一种“假性故障”就是电脑端用的是虚拟机网络。比如你电脑上装了VMware或VirtualBox宿主机网卡绑定了VirtualBox Host-Only Ethernet Adapter或者选择了桥接模式但桥接到了错误的物理网卡上此时从虚拟机里ping板子除非全部网络都配置正确否则很容易出现ping不通的情况。我当时有一段时间就是从VMware里ping的结果发现VMware的桥接网络把数据转发到了Wi-Fi而不是有线网卡上当然ping不通。后来我换回宿主机直连ping才继续正常排查。这个点特别容易被忽略一旦你把方向搞错可能就会在板子的驱动上做很多无用功。此外如果你的电脑网卡支持节能以太网Energy Efficient EthernetEEE或者流控功能有时在低速通信时会出现掉线或者异常。可以在电脑网卡的高级设置里关闭“环保节能”和“流量控制”把速度和双工模式直接固定为100Mbps Full Duplex这样和开发板的协商就相对稳定。我当时把网卡直接设置为千兆全双工模式如果电脑网卡是千兆结果和板子的百兆PHY无法协商导致Link灯明明亮了但数据传输不稳定。把电脑网卡强制设为100Mbps Full Duplex后问题立刻改善。这点听起来很玄学但实际调试中特别常见。还有一个容易忽略的点是交叉网线和直通网线的区别。现在的网卡和交换机基本都支持Auto MDI-X功能不管你是直通线还是交叉线都能自动切换但如果你用的是很老旧的设备或者网线内部线路本身有问题就会出现“插上去了Link灯亮但数据不通”的局面。解决办法是换一根已知质量良好的网线最好在另一块开发板上先验证过。这个操作成本最低但往往能帮你节省大量时间。7. 最后的经验总结和一些额外建议经过这几天的折腾我算是把STM32H750B-DK以太网启动的每一个环节都摸透了。从我这次的经历来看ping不通的根因最终是MAC地址全0和MCO2时钟配置不当两个问题叠加造成的。单独看任何一个都不至于导致完全不通但叠加在一起就让整个问题变得极其隐蔽而且现象不稳定有时候连Link灯都正常但就是没有任何数据回包。所以我写这篇博客的核心目的就是提醒大家遇到这种问题不要只盯住某一个点一定要从硬件时钟、PHY寄存器、MAC配置、LwIP协议栈四个维度系统性排查并且充分利用Wireshark和逻辑分析仪这两个工具去定位层次。对于新手我还有几条实用建议。一是学会看原理图STM32H750B-DK的原理图文件可以在ST官网下载网络部分一定要去核对PHY的型号、地址、REF_CLK来源这些信息直接决定了你的CubeMX配置。二是串口日志一定要保持开启在关键函数入口和出口打印状态比如HAL_ETH_Init返回的HAL_StatusTypeDef、HAL_ETH_ReadPHYRegister返回值、LwIP初始化结果这些打印能帮你快速缩小范围。三是多利用HAL库的返回值不要忽略任何HAL_ERROR或HAL_BUSY我见过很多人只要串口打印通了就默认硬件初始化成功其实以太网初始化可能早就失败了只是你忽视了返回值。最后再分享一个实用小技巧。如果你怀疑网络不稳定可以在电脑端用连续ping和TTL值来测试延迟和丢包率例如输入ping 192.168.1.10 -t观察有没有时通时不通的现象。如果连续ping了100个包全部通而且延迟稳定在1ms以内说明链路没问题。如果出现个别丢包可以再用ping 192.168.1.10 -n 100 -l 1400来测试大包传输稳定性大包更容易暴露DMA缓冲区不足或描述符配置错误的问题。我实测中当我把LwIP的PBUF_POOL_BUFSIZE从默认的1500改成1518后大包传输的成功率有了明显提升这也是一个经常被忽略的细节。希望我的这段经历能帮你少踩几个坑早日让你的STM32H750B-DK在网络世界里“活”过来。