企业官网建设流程全解析

如果你最近在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_CLK），MII则需要16根。PCB布线压力小很多，引脚占用也更友好。代价是RMII模式需要外部提供一个50MHz的参考时钟，而STM32F429可以通过MCO1引脚直接输出这个50MHz，省掉一颗有源晶振。这个方案在绝大多数应用场景下是够用的，也是CubeMX生成的默认配置方式。

1.2 软件架构：裸机先通，再进RTOS

刚接触这套组合的人最容易犯的错误是：一上来就把FreeRTOS、LWIP、ETH全堆在一起，用CubeMX一次性生成所有代码，然后发现ping不通，根本不知道是哪一层出了问题。我的建议流程很简单：先裸机跑LWIP，ping通了，再移植到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输出400MHz，PLLP分频后主频168MHz，同时还有一个分频选项把PLLCLK四分频输出50MHz——这个“4分频”取决于PLL的VCO频率，VCO如果是200MHz，200/4=50MHz。我踩过的坑是只盯着主频，没看MCO1输出，结果示波器一量只有42MHz，PHY当然不干活。

所以我在CubeMX里首选的稳妥做法是：MCO1选择PLLCLK，把PLL的VCO输出配成200MHz，PLLP=2得到100MHz主频——不对，F429主频要168MHz，这样主频就对不上。我再说一个更省心的配置：MCO1直接用HSE的8MHz，这样REF_CLK就不是50MHz，走RMII根本不行。说到这里，我直接给一个我反复验证过的参数组合：HSE=8MHz，PLLM=4，PLLN=168，PLLP=2，这样VCO=8/4*168=336MHz，主频=336/2=168MHz。然后MCO1时钟源选PLLCLK，在MCO1的分频器选“/4”，336/4=84MHz，还是不对。

这块参数确实麻烦，容易把自己绕进去。实际调试时，我建议直接放弃用MCO1，改用外部50MHz有源晶振给LAN8720提供REF_CLK，STM32的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全是0xFFFFFFFF，LWIP自然无法正确初始化。

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，再DHCP

LWIP的配置在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服务器没有半毛钱关系。如果一开始就开DHCP，ping不通时你还得怀疑是不是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跑LWIP+FreeRTOS时，网络处理的任务优先级要高于普通业务任务，但不建议高于中断能处理的实时任务，具体看项目需求。

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时好时坏。后来改成10k+1uF，也就是拉低时间的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 Reset，bit14是Loopback，bit13是Speed Selection，bit12是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是0x3100，BSR的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调得很大（比如64KB），LWIP的MEM_SIZE也调得很大（比如80KB），加上协议栈任务栈、以太网收发缓冲区，F429的192KB SRAM很容易爆掉。编译器一般不会报错，因为C库的malloc和FreeRTOS的堆是独立的配置，但运行一瞬间就死机。所以我的经验是：先确定FreeRTOS堆的管理方式为heap_4（CubeMX默认生成的就是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任务设为osPriorityLow，ETH接收中断的抢占优先级设为5（在FreeRTOS可管理范围内）。ETH中断处理函数里不要做任何耗时操作，只负责清中断标志位并释放信号量。如果一个项目中存在实时性要求更高的硬实时任务，那它应该由硬件定时器中断或更高优先级中断去处理，不建议和网络任务争同一个优先级。

还有一个小细节：ETH发送完成的中断或DMA传输完成回调里，不要直接调用LWIP的API函数，而是通过事件标志组或消息队列把“发送完成”这个事件通知给协议栈线程处理。直接在一二级中断里操作LWIP内部数据结构，偶尔会崩溃，而且这种崩溃极难复现，排查起来非常痛苦。

4.4 问题速查表：按现象直接定位

这个表格里的每一项我都实际踩过，有些甚至交叉出现。最麻烦的一次是Link灯正常、MAC地址正常、PHY寄存器正常，但TCP就是只能连上然后立刻断开。后来查了整整一个下午才发现是局域网里另一台设备的IP和网关冲突，导致ARP表刷错了。这类环境问题代码查不出来，所以要学会抓包，学会看Wireshark，网络栈的调试工具和嵌入式调试工具一样重要。

另一个高频坑在CubeMX本身：如果你在配置界面把ETH的“DMA Rx/Tx buffer”改成了非默认值，生成的代码可能有bug，表现为初始化后网卡发送数据时卡死。遇到这类诡异问题，我通常会把相关参数全部恢复默认，重新生成一遍代码，只改不能绕过的选项，很多莫名其妙的问题就消失了。

4.5 从CubeMX到工程落地的剩余步骤

CubeMX生成完代码只是开始，真正让整个网络栈跑起来还需要做几件收尾工作。第一步是在main.c里确认MX_LWIP_Init()函数调用时能拿到正确的MAC地址，如果在项目中有唯一性要求（比如多台设备需要走不同IP），MAC地址要支持从外部存储器读取或者按产品序列号生成。第二步是启动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. 写在最后的个人体会

折腾完这套F429+LAN8720+LWIP+FreeRTOS之后，我最大的感受是：嵌入门这行，真正能让你拉开差距的不是用什么芯片、什么协议栈，而是遇到ping不通这种基础问题时，你能不能快速判断出问题出在硬件、驱动、协议栈还是业务代码。硬件好查但容易被忽略，软件好改但变量很多，最大的敌人其实就是综合性问题。

如果你现在正卡在一个诡异的现象上，我给三个建议。第一，先简化环境：关掉DHCP、固定IP、不跑业务逻辑，只跑ping，然后从下往上逐层验证。第二，大胆看寄存器，不要怕写调试函数，PHY的寄存器会告诉你很多真相。第三，善用抓包工具，很多时候不是设备的问题，而是局域网、网关、防火墙的问题。网络通信这种东西，调试手段比代码本身更值钱。

这套组合在我手里已经稳定跑了很久，F429虽然性能不算强，但承担小规模的产品级网络通信完全够用。希望这篇避坑文章能帮你早点跑通，少熬几个夜。