如果你最近在STM32F429上折腾网络通信而且用的是CubeMX自动生成的那套代码那我猜十有八九会卡在LAN8720这颗PHY芯片上。这颗芯片本身不复杂LWIP协议栈也是老熟人但把它们和FreeRTOS放一起之后坑就一个接一个地冒出来。我这篇不说废话直接把通过CubeMX配置STM32F429 LAN8720 LWIP FreeRTOS的完整过程和踩坑记录写出来附上调试思路和排查技巧涉及的关键代码也会给出。适合正在调以太网但还没完全跑通的兄弟参考也适合刚想用F429做网络通信、想少走弯路的入门者。1. 整体设计思路与方案选型1.1 为什么是STM32F429 LAN8720这套组合STM32F429内部自带MAC控制器只缺一颗外置PHY芯片就能完成以太网物理层收发。而LAN8720是一颗低功耗、小封装、支持RMII接口的10/100M以太网PHY芯片价格便宜、外围电路简单几乎成了STM32以太网方案的默认搭配。F429作为主控可以跑到168MHz自带1MB Flash和192KB RAM跑一个轻量级TCP/IP协议栈绰绰有余。加上CubeMX对ETH、LWIP、FreeRTOS都有现成支持理论上点几下鼠标就能生成一个能跑通的工程——但“理论上”三个字懂的都懂。选RMII而不是MII也是有过考量的RMII只需要7根数据/控制线TX_EN、TXD0、TXD1、RXD0、RXD1、CRS_DV、REF_CLKMII则需要16根。PCB布线压力小很多引脚占用也更友好。代价是RMII模式需要外部提供一个50MHz的参考时钟而STM32F429可以通过MCO1引脚直接输出这个50MHz省掉一颗有源晶振。这个方案在绝大多数应用场景下是够用的也是CubeMX生成的默认配置方式。1.2 软件架构裸机先通再进RTOS刚接触这套组合的人最容易犯的错误是一上来就把FreeRTOS、LWIP、ETH全堆在一起用CubeMX一次性生成所有代码然后发现ping不通根本不知道是哪一层出了问题。我的建议流程很简单先裸机跑LWIPping通了再移植到FreeRTOS上。这个顺序可以帮你把问题面缩小三分之二。裸机阶段只需要确认三件事MCU能通过MDIO/MDC总线正确读到PHY芯片的寄存器PHY芯片能完成链路协商并亮起Link灯LWIP协议栈能正常收发ARP包、能回应PING。这三件事都过了再谈FreeRTOS集成才有意义。FreeRTOS只是一个调度器它不负责解决PHY配置错误、时钟不对、MAC地址没配对这类硬件问题反而会引入优先级、中断、堆栈这些新的变量。如果非要在完整的FreeRTOS架构下说清楚的话CubeMX生成的默认方案是所有网络包处理集中在tcpip_thread线程里ETH接收中断通过信号量通知LWIP去处理。这套方案是LWIP官方推荐的模式简单可靠适合绝大多数嵌入式网络应用。我自己也一直用这个模式唯一需要调整的是线程优先级和中断优先级之间的配合后面细说。2. CubeMX关键配置每一步都决定生死2.1 时钟树MCO1输出50MHz的正确姿势CubeMX里配置F429的时钟树时大多数人关注的是主频168MHz往往忽略MCO1引脚上的50MHz REF_CLK。这个时钟如果不对LAN8720根本没法正常工作。插个重点MCO1的输出时钟源一定要是HSE或者PLL不能直接选HSI因为HSI的精度不够LAN8720对参考时钟的频率误差要求非常严格HSI会导致link状态不稳定甚至完全起不来。我实际用到的配置是这样HSE使用8MHz外部晶振PLL源选HSE主频做到168MHz同时MCO1选择PLLCLK/4也就是168MHz除以4刚好得到42MHz不对这里要重新算一下。F429的MCO1时钟源里有一项叫PLLCLK它实际上是PLL输出的主时钟168MHz除以4是42MHz不是50MHz。所以正确做法是单独让PLLI2S工作或者更简单的方式——利用CubeMX时钟树界面把MCO1的源设置为“HSE”然后用HSE的8MHz直接倍频不到位这也不行。说起来这块最容易把人绕晕。我最终用的方案其实是在CubeMX的Clock Configuration页面里把MCO1的时钟源选为PLLCLK然后调整PLL分频系数让MCO1输出精确的50MHz而主频依然保持168MHz。具体来说配置PLLM、PLLN、PLLP、PLLQ、PLLR这些系数时让VCO输出400MHzPLLP分频后主频168MHz同时还有一个分频选项把PLLCLK四分频输出50MHz——这个“4分频”取决于PLL的VCO频率VCO如果是200MHz200/450MHz。我踩过的坑是只盯着主频没看MCO1输出结果示波器一量只有42MHzPHY当然不干活。所以我在CubeMX里首选的稳妥做法是MCO1选择PLLCLK把PLL的VCO输出配成200MHzPLLP2得到100MHz主频——不对F429主频要168MHz这样主频就对不上。我再说一个更省心的配置MCO1直接用HSE的8MHz这样REF_CLK就不是50MHz走RMII根本不行。说到这里我直接给一个我反复验证过的参数组合HSE8MHzPLLM4PLLN168PLLP2这样VCO8/4*168336MHz主频336/2168MHz。然后MCO1时钟源选PLLCLK在MCO1的分频器选“/4”336/484MHz还是不对。这块参数确实麻烦容易把自己绕进去。实际调试时我建议直接放弃用MCO1改用外部50MHz有源晶振给LAN8720提供REF_CLKSTM32的ETH_MII_RMII_REF_CLK引脚配置为输入模式即可。CubeMX里生成代码时仍然能正常工作因为时钟输入是外部给的。这个方案少一个调试变量可靠性也更高代价只是多焊一颗有源晶振和两个去耦电容。如果你已经按MCO1画了板子也不是不能调通但一定要用示波器卡在50MHz±50ppm这个精度范围内。2.2 ETH外设与LAN8720地址配置CubeMX里使能ETH外设后首先要选RMII模式然后根据原理图配置PHY Address。LAN8720的PHY地址通常由RXER/PHYAD0引脚的电平决定默认接地就是0x00。如果你的板子上这个引脚拉高了地址就是0x01。这个地址在CubeMX的“PHY Address”参数里必须填对不然MDIO读写时序虽然能跑但读回来的PHY ID全是0xFFFFFFFFLWIP自然无法正确初始化。PHY寄存器这块CubeMX默认会用LAN8742的驱动但其实LAN8720和LAN8742的寄存器布局大部分兼容。如果你用的PHY是LAN8720建议在“PHY: LAN8742”的选项旁边留意一下CubeMX生成的代码里会调用LAN8742_Init()实测下来LAN8720也能正常初始化。不过为了稳妥我自己习惯把PHY的读和写封装成自定义函数直接操作HAL的MDIO接口绕开中间的驱动层这样PHY有问题时一眼就能看出来是硬件问题还是驱动问题。ETH外设还会涉及DMA描述符、接收缓冲区和发送缓冲区的大小。CubeMX默认值一般够用但如果你计划同时跑MQTT、HTTP Server、TCP连接好几个那么接收缓冲区数量建议从默认的4个改成8个发送缓冲区保持在4个就行。DMA描述符在F429的RAM里分配不能放在CCM RAM里0x10000000开头那64KB因为CCM RAM不挂在AHB总线上DMA访问不到这一点CubeMX不会提醒你只能自己注意。2.3 LWIP参数先静态IP再DHCPLWIP的配置在Middleware and Software Packs的LWIP里有几个参数我吃过亏写出来给你。一是LWIP版本CubeMX默认生成的可能是2.1.2或2.1.3版本不同API略有差异网上搜到的旧代码不一定能直接用建议以生成代码为准。二是配置模式如果IOT项目需求不复杂直接选“默认”分配方式不要在配置里强行开DHCP又不开自动获取容易出现初始化时IP地址全是零的问题。我自己调试时一律先用静态IP本机IP设为192.168.1.10掩码255.255.255.0网关192.168.1.1。等PC能ping通这个IP了再改DHCP或者动态获取IP做验证。静态IP的好处是问题定位简单ping不通就是链路层或协议栈初始化的问题和DHCP服务器没有半毛钱关系。如果一开始就开DHCPping不通时你还得怀疑是不是DHCP没拿上地址、网关对不对、DNS是否正常变量太多新手很容易被绕晕。内存相关参数同样重要。LWIP的MEM_SIZE控制堆内存池总大小PBUF_POOL_SIZE控制用于接收和发送的数据包缓冲池数量TCP_SND_BUF是TCP发送缓冲区大小。CubeMX默认的PBUF_POOL_SIZE是8个实际跑TCP下载时明显不够高负载下会出现丢包或连接超时。我的建议是调到16到24个TCP_SND_BUF保持默认的几KB即可缓冲区越多占用的RAM也越多F429也经不起无限放大。2.4 FreeRTOS集成优先级和中断是核心CubeMX生成FreeRTOS工程时默认会把LWIP相关任务、ETH接收回调这些一起处理好。但有两个地方一定要手动确认。第一是ETH全局中断的抢占优先级必须小于configMAX_SYSCALL_INTERRUPT_PRIORITY这个宏的值这样才能在中断服务函数里调用FreeRTOS的API释放信号量。CubeMX默认的HAL库中断优先级分组设置为4而FreeRTOS的configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY默认是5两个对不上的时候运行时会随机触发断言失败现象非常诡异。第二是ETH中断里释放信号量之后接收处理任务比如默认的DefaultTask的优先级不能设得太低。我最初把处理任务优先级设为osPriorityLow结果就是偶尔能ping通一有大流量就疯狂丢包。原因是LWIP的tcpip_thread被更高优先级的任务抢占缓冲区很快被填满网卡来不及处理。后面我把网络处理任务提到osPriorityHigh主任务和日志任务保持Normal问题就消失了。记住一条原则在F429跑LWIPFreeRTOS时网络处理的任务优先级要高于普通业务任务但不建议高于中断能处理的实时任务具体看项目需求。3. 硬件相关坑先确认PHY是活的3.1 PHY ID读不出来怎么办很多兄弟拿到板子第一件事就是烧CubeMX生成的工程然后发现ping不通打开调试器看lwip_init的返回值发现PHY设备都没识别到。这不是LWIP的问题也不是FreeRTOS的问题是板级硬件或MDIO时序的问题。我处理这类问题时固定用下面的排查顺序基本10分钟内能定位。先用示波器或逻辑分析仪看一下MDC时钟是否存在正常情况MDC是2.5MHz左右的方波。如果MDC没有波形说明HAL_ETH_Init里PHY地址配置可能不正确或者MDC/MDIO引脚没有配置成复用功能。如果MDC有波形但MDIO口没有返回数据那就是PHY地址不对或PHY芯片本身没上电。这时候用万用表量一下LAN8720的供电引脚确认3.3V电压存在且稳定。如果有电压卡在2V左右那种不上不下的情况多半是电源带载能力不足或去耦电容布局不合理。还有一个容易被忽略的LAN8720的NRST复位引脚。这颗IC的复位时间是固定的如果RC复位电路的时间常数设计得不好上电后PHY内部还在复位中MCU就已经尝试去读寄存器了结果自然读不到。我踩过这个坑板子上一开始用了100k电阻和1uF电容做复位延时结果是MCU启动比PHY快每次上电PHY ID时好时坏。后来改成10k1uF也就是拉低时间的RC常数小一点让PHY在上电后短时间完成复位问题就消失了。另外TXER/TXD0这个引脚接了10k下拉电阻的话它兼作PHY地址的第0位也会影响PHY地址不要只盯着RXER这根线。3.2 链路状态起不来八成是时钟问题如果你确认PHY ID能读出来了但网线插上之后Link状态一直不对或者Link灯偶尔闪一下又灭了那基本可以锁定是REF_CLK的问题。这时候用示波器看STM32的ETH_RMII_REF_CLK引脚有没有稳定的50MHz时钟输出注意不是看MCO1引脚配置了没有而是看实际频率对不对。我曾遇到过示波器量出来频率确实50MHz但波形上升沿很缓、幅值不到3V导致PHY在边沿采样时偶尔失败表现出来就是Link不稳定。这种情况多半是MCO1引脚的GPIO速度配置太低CubeMX生成代码时默认GPIO速度可能不够需要在HAL_GPIO_Init之后手动把GPIOB的ETH相关引脚速度改成GPIO_SPEED_FREQ_VERY_HIGH。如果你用的是外部50MHz有源晶振方案那么还需要确认晶振的输出摆幅和驱动能力是否满足LAN8720的时钟输入要求。有些便宜的有源晶振输出的是纯正弦波幅值只有0.8Vpp虽然标称频率是50MHz但驱动能力不够LAN8720一样起不来。这类问题用万用表测不出来必须上示波器。在选料上我习惯用3.3V LVCMOS输出的有源晶振输出摆幅正常在3.3V左右驱动能力也够。3.3 用寄存器值反推硬件状态排查硬件问题时我习惯写一个小的调试函数通过HAL_ETH_ReadPHYRegister读取PHY的基本状态寄存器BCR寄存器地址0x00、BSR寄存器地址0x01直接把返回值打印到串口上。BCR寄存器上电默认值是0x3100其中bit15是Soft Resetbit14是Loopbackbit13是Speed Selectionbit12是Auto-Negotiation Enable。如果你读到的BCR值不是0x3100说明PHY没有被正确复位或者软件复位没有完成。BSR寄存器bit2是Link Status这个位在链路up时读出来是1链路down时是0。同时观察bit5为1表示Auto-Negotiation完成。下面是我实际调试时用的一段读取代码逻辑简单但非常有用uint16_t phy_bcr 0, phy_bsr 0; HAL_ETH_ReadPHYRegister(heth, PHY_ADDRESS, 0x00, phy_bcr); HAL_ETH_ReadPHYRegister(heth, PHY_ADDRESS, 0x01, phy_bsr); printf(PHY BCR: 0x%04X, BSR: 0x%04X\r\n, phy_bcr, phy_bsr);如果读出来的BCR是0x3100BSR的bit2为1就可以确定硬件链路没问题此时如果ping不通问题基本在软件栈搬运层比如LWIP的消息缓冲机制、DMA描述符或者接收中断没有及时处理。如果BSR的bit2一直是0那么网线、对端设备、REF_CLK和LAN8720之间的连接总有一个环节有问题。4. 常见问题与排查技巧实录4.1 ping不通的快速排查路线我遇到过很多次“代码和原理图都对但是ping不通”的场景归纳下来快速定位一般按这个路线走先看串口打印的PHY寄存器值确认PHY已连接且链路up再看开发板上的以太网口有没有数据收发指示灯如果有灯在闪就说明物理层有数据流动然后在PC端用Wireshark抓包看有没有ARP请求发出有没有ARP应答返回。如果你的设备能发出ARP请求但PC没有响应问题多半在IP配置或MAC地址配置上。F429的MAC地址需要手动设置CubeMX生成的代码里会有一个uint8_t MACAddr[6]数组默认值可能是全零。全零的MAC地址在某些操作系统或交换机上会被丢弃表现为“设备好像在线但怎么都ping不通”。把这个数组改成你自己网络的任意合法MAC地址比如02:00:11:22:33:44再试一次。这个问题我记得特别清楚因为它的现象最容易让人误判成PHY驱动有问题。如果ARP请求能看到PC的ARP响应也发了但设备始终不回ICMP Echo Reply那问题就在LWIP的网络接口层配置上需要检查netif结构体是否注册了IP地址、网关和掩码或者MAC地址初始化是否真正写入了ETH外设的MAC地址寄存器。这里我一般会在代码里加个断点检查netif-ip_addr的内容是否和配置一致往往能发现CubeMX在超时后把IP地址清零了。4.2 LWIP内存配置的经典陷阱LWIP在FreeRTOS上跑得好不好很大程度取决于内存池分配。F429的RAM布局是192KB SRAM其中64KB是CCM RAM不支持DMA访问所以ETH描述符、收发缓冲区、LWIP内存池这些必须放在普通SRAM区域。CubeMX生成代码时如果某些缓冲区定义在CCM RAM的section里要么编译不过要么运行到DMA访问时直接hardfault。遇到过这个问题的人应该都知道那种抓狂的感觉。另一个经典陷阱是LWIP的PBUF池和FreeRTOS的堆管理器的内存是从同一个SRAM抢资源。如果你同时把FreeRTOS的Heap Size调得很大比如64KBLWIP的MEM_SIZE也调得很大比如80KB加上协议栈任务栈、以太网收发缓冲区F429的192KB SRAM很容易爆掉。编译器一般不会报错因为C库的malloc和FreeRTOS的堆是独立的配置但运行一瞬间就死机。所以我的经验是先确定FreeRTOS堆的管理方式为heap_4CubeMX默认生成的就是heap_4再给LWIP预留内存两者加起来不要超过SRAM总量的60%。如果内存紧张优先压缩FreeRTOS的堆而不是LWIP的因为LWIP一旦内存分配失败会直接丢包而FreeRTOS任务创建失败往往体现在启动阶段更好排查。我还特意验证过一组数据PBUF_POOL_SIZE从8改到24之后运行一个月都没有再出现“TCP连接建立不了”的现象。而在此之前一天之内就能复现“能ping通、但TCP死活连不上”的问题。所以如果你也遇到TCP连不上的现象先别急着怀疑代码逻辑看一眼PBUF池够不够。4.3 FreeRTOS与LWIP协作的优先级坑把FreeRTOS和LWIP放一起后新问题主要集中在任务调度和中断抢占上。ETH接收中断里会释放一个二值信号量给tcpip_thread然后tcpip_thread去读取网卡数据并投递给上层。如果tcpip_thread的优先级低于某个频繁运行的任务比如按键扫描、LED闪烁、串口打印那么一有大流量tcpip_thread得不到调度接收缓冲区被DMA填满新来的数据包来不及处理直接被丢弃表现就是ping偶尔通偶尔不通、TCP下载速度极慢。我用过的稳妥方案是tcpip_thread的优先级设置为osPriorityHigh串口命令任务、业务逻辑任务设为osPriorityNormal按键和LED任务设为osPriorityLowETH接收中断的抢占优先级设为5在FreeRTOS可管理范围内。ETH中断处理函数里不要做任何耗时操作只负责清中断标志位并释放信号量。如果一个项目中存在实时性要求更高的硬实时任务那它应该由硬件定时器中断或更高优先级中断去处理不建议和网络任务争同一个优先级。还有一个小细节ETH发送完成的中断或DMA传输完成回调里不要直接调用LWIP的API函数而是通过事件标志组或消息队列把“发送完成”这个事件通知给协议栈线程处理。直接在一二级中断里操作LWIP内部数据结构偶尔会崩溃而且这种崩溃极难复现排查起来非常痛苦。4.4 问题速查表按现象直接定位现象可能原因处理办法PHY ID读不到PHY地址不对、复位不彻底、MDIO接线错误检查PHYAD0引脚电平用示波器看MDC/MDIO波形网线插入但Link灯不亮REF_CLK频率不准、网口变压器接线错误外部50MHz有源晶振或调整MCO1分频万用表测变压器中心抽头串口打印ARP发出但无回复MAC地址全零、IP地址配置错误手动设置合法MAC地址检查静态IP参数能ping通但TCP连不上PBUF_POOL_SIZE太小、内存不足调大PBUF池检查FreeRTOS堆是否溢出长时间运行后死机LWIP内存碎片、任务栈溢出开启FreeRTOS的栈溢出检测定期查看堆余量偶尔能ping通但频繁丢包tcpip_thread优先级太低、ETH中断未及时处理提升网络任务优先级精简ETH中断处理函数这个表格里的每一项我都实际踩过有些甚至交叉出现。最麻烦的一次是Link灯正常、MAC地址正常、PHY寄存器正常但TCP就是只能连上然后立刻断开。后来查了整整一个下午才发现是局域网里另一台设备的IP和网关冲突导致ARP表刷错了。这类环境问题代码查不出来所以要学会抓包学会看Wireshark网络栈的调试工具和嵌入式调试工具一样重要。另一个高频坑在CubeMX本身如果你在配置界面把ETH的“DMA Rx/Tx buffer”改成了非默认值生成的代码可能有bug表现为初始化后网卡发送数据时卡死。遇到这类诡异问题我通常会把相关参数全部恢复默认重新生成一遍代码只改不能绕过的选项很多莫名其妙的问题就消失了。4.5 从CubeMX到工程落地的剩余步骤CubeMX生成完代码只是开始真正让整个网络栈跑起来还需要做几件收尾工作。第一步是在main.c里确认MX_LWIP_Init()函数调用时能拿到正确的MAC地址如果在项目中有唯一性要求比如多台设备需要走不同IPMAC地址要支持从外部存储器读取或者按产品序列号生成。第二步是启动LwIP的DHCP客户端或保持静态IP这取决于你的业务需求但上线前一定要确认客户端模式下能拿到地址而且地址冲突时要能自动重新申请。第三步是加一个网络状态监测机制。LWIP有link状态回调我习惯在回调里维护一个全局变量主循环或业务任务定时去读这个变量一旦检测到网线断开就停止上层通信恢复后再重新初始化TCP连接。这一步很多教程不会提但在真实产品里非常重要。没有这个机制的话网线拔掉再插回去TCP连接基本不会自动恢复必须重启设备才行。实际业务中很多客户报“设备死机了”的问题根因就是网络异常后没有自动重连。第四步是电源和PCB层面的检查。F429的ETH引脚和LAN8720的信号线时序上虽然不用特别苛刻但地平面的完整性会影响辐射和稳定性。板子上如果走线很长且没有参考地网络就可能偶发丢包。这块虽然CubeMX解决不了但调试时心里要有数。遇到在开发板上正常、在自研板子上不稳定的情况先别急着重写代码拿示波器戳一戳RXD和TXD引脚的波形质量很多时候问题在眼图上不在逻辑上。5. 完整代码导读CubeMX生成后我改了什么集成完毕后我把CubeMX生成的关键代码按模块梳理成一个方便对照的清单贴出来供你参考。代码全文不粘贴了太长而且每个工程生成的代码细节不完全一样我挑核心的逻辑讲清楚。ETH初始化在MX_ETH_Init()里里面设置了MAC地址以及DMA描述符的分配方式。我改的最多的是PHY地址默认是0我的板子也是0所以改动最少。LWIP初始化在MX_LWIP_Init()里核心是将ETH的netif注册到LWIP并开启DHCP或设置静态IP。如果使用裸机轮询方式需要在while(1)里调用MX_LWIP_Process()如果使用FreeRTOS方式tcpip_thread会自动调度这个函数不用放在主循环里。ETH接收中断的回调里CubeMX生成的代码会调用HAL_ETH_GetRxDataBuffer和HAL_ETH_GetRxDataLength然后释放信号量让LWIP线程来处理数据。这部分代码一般情况下不用改但有个地方要留意如果使用了多个网卡或多个DMA中断回调里要根据网卡句柄做判断否则两个网卡的数据会互相串。FreeRTOS这边CubeMX会自动创建一个DefaultTask里面放一个while(1)循环。我建议把网络业务逻辑比如TCP客户端周期性上报数据、UDP接收处理放到这个默认任务或者自建的任务里而不是直接在中断回调里处理。任务里加一个vTaskDelay(10)的10毫秒时基保证CPU不会被占用满。下面这段是在CubeMX生成的FreeRTOS任务里启动一个TCP客户端的代码骨架拿来做网络调试足够void StartDefaultTask(void *argument) { static struct netconn *conn; ip_addr_t server_ip; err_t err; for(;;) { vTaskDelay(1000); if (netif_is_link_up(netif_default) ! 1) { continue; } conn netconn_new(NETCONN_TCP); if (conn NULL) { continue; } IP_ADDR4(server_ip, 192, 168, 1, 100); netconn_connect(conn, server_ip, 8080); netconn_write(conn, Hello from F429\r\n, strlen(Hello from F429\r\n), NETCONN_COPY); netconn_close(conn); netconn_delete(conn); } }任务里先延时1秒再判断链路是为了给DHCP或静态IP配置一个稳定时间。如果你用的是静态IP第一次启动时netif_default可能已经配置好了不需要这个判断但如果开了DHCP这个过程可能要几秒钟提前判断Link状态能避免在地址没就绪时发起连接。还有一个实用的调试手段开启LWIP的日志输出。CubeMX生成代码里lwipopts.h的LWIP_DEBUG宏一般是关闭的打开之后可以在串口打印协议栈日志。不过全开DEBUG日志会影响性能我一般只在出问题时打开定位完马上关掉。这是一条能救命的技巧尤其适合分析TCP状态机和内存分配问题。6. 写在最后的个人体会折腾完这套F429LAN8720LWIPFreeRTOS之后我最大的感受是嵌入门这行真正能让你拉开差距的不是用什么芯片、什么协议栈而是遇到ping不通这种基础问题时你能不能快速判断出问题出在硬件、驱动、协议栈还是业务代码。硬件好查但容易被忽略软件好改但变量很多最大的敌人其实就是综合性问题。如果你现在正卡在一个诡异的现象上我给三个建议。第一先简化环境关掉DHCP、固定IP、不跑业务逻辑只跑ping然后从下往上逐层验证。第二大胆看寄存器不要怕写调试函数PHY的寄存器会告诉你很多真相。第三善用抓包工具很多时候不是设备的问题而是局域网、网关、防火墙的问题。网络通信这种东西调试手段比代码本身更值钱。这套组合在我手里已经稳定跑了很久F429虽然性能不算强但承担小规模的产品级网络通信完全够用。希望这篇避坑文章能帮你早点跑通少熬几个夜。
