简介面向 GD32F4 嵌入式开发者的网络应用工程以 GD32F407 为主控芯片完整实现了 LWIP 协议栈与 FreeRTOS 的整合并针对网线热插拔场景给出了链接状态检测、中断响应和连接重建的解决方案。压缩包约 15.49MB共 728 个文件其中包含 243 个头文件与 185 个 C 源文件覆盖以太网驱动、TCP/IP 协议栈、任务调度及 HTTP 服务等模块另含 Keil 工程配置、链接映射文件、编译中间文件与少量说明文档便于直接导入 Keil 查看或二次开发。目前已有 2341 人学习下载适合正在调试 GD32F4 网络功能或希望了解 LWIP 与 FreeRTOS 配合方式的工程师。通过学习这份工程代码可以掌握 GD32F4 以太网 MAC 的初始化流程、LWIP 在 FreeRTOS 中的任务划分方式以及利用 LINK/ACT 信号触发中断、再通过回调更新网络连接的具体写法对开发稳定可靠的嵌入式网络设备有直接参考价值。 搞嵌入式网络设备的朋友应该都有这种经历板子刚调通那会儿LWIPFreeRTOS跑起来PC端ping得通心里挺爽。但真正拿到现场用户随手一拔网线再接回去过几分钟电话就来了——设备掉线了起不来了。我这次做的项目是基于GD32F4系列GD32F450Cortex-M4主频200MHz内置MAC外挂LAN8720A这颗PHY的工业数据采集网关软件侧选了FreeRTOS LWIP这套经典组合其中一个绕不开的需求就是网线热插拔处理。链路状态要准确、插拔之后系统能自动恢复、不能出现线插了但连不上线拔了还显示在线这种问题。这篇文章就从整体设计、任务划分、PHY状态检测、LWIP栈处理、以及我实际踩过的坑这几个方面把整个方案完整拆一遍。适合正在做类似网关、采集器、带网口仪表的朋友参考尤其是那种基础功能跑通容易产品化难的项目。1. 项目到底在解决什么问题1.1 这套组合的选型逻辑先说为什么选GD32F4。这颗芯片内置10/100M以太网MAC支持RMII接口主频能到200MHzFlash和RAM的容量也比较充裕。相比外挂SPI接口网卡芯片的方案内置MAC 外部PHY的方式在吞吐量、稳定性、成本之间取得了一个比较理想的平衡。而且GD32F4的以太网外设寄存器结构和STM32F4/H7系列很接近芯片本身也兼容ST的部分引脚定义调试手段和代码参考资料都比较成熟。FreeRTOS在这个项目里承担的角色是任务调度、信号量同步、软件定时器。LWIP则负责TCP/IP协议栈。两个都是C语言写的、可裁剪的轻量级方案特别适合MCU场景。我在这个项目里还顺便把cJSON集成进去了链路状态、采集数据需要打包成JSON格式通过串口或网络上报LWIP负责传输cJSON负责封包这两个配合起来很顺手。1.2 为什么能ping通不算完事很多人觉得LWIP跑起来、能ping通就完事了。但实际上网络设备产品化的难点往往在异常处理尤其是网线热插拔这种最容易被忽略的场景。网线拔掉再插回去中间涉及到的链路有PHY检测到物理链路断开/恢复、MAC层状态同步、LWIP协议栈的接口状态更新、应用层网络状态上报。任何一个环节没处理干净都会出问题。最典型的现象就是拔线之后重插设备IP还挂在旧状态上DHCP没有重新协商或者PHY的自动协商卡死MAC状态机一直停在错误状态表现就是一直ping不通。完整的热插拔处理应该覆盖这些状态网线拔出、网线插入、PHY自动协商完成、IP地址重新获取、网络连接恢复确认、应用层状态上报。影响范围不只是现场运维还包括远程升级、看门狗策略、设备在线检测这些上层逻辑。2. FreeRTOS与LWIP的协作架构2.1 任务划分优先级怎么定我的任务划分比较常规但优先级顺序是经过实际测试调整过的直接给出来供参考任务名优先级栈大小职责tcpip_thread32048LWIP核心线程处理协议栈消息app_tx_task21024周期发送采集数据link_monitor_task4512轮询PHY链路状态处理热插拔console_task1512串口命令交互优先级上我把链路检测放得比协议栈线程还高一点。原因是这个任务本身很轻只是读寄存器、判断状态、发信号耗时极短。而tcpip_thread要处理TCP重传、ARP请求、IP分片这些耗时操作如果优先级比链路检测高极端情况下链路检测会被饿死导致插拔事件处理不及时。栈大小这里有个容易被忽视的点tcpip_thread的栈不能省。LWIP的协议栈处理会在任务上下文中调用应用层回调如果你在回调里做了耗时操作比如打印、格式化JSON栈用量会明显涨。我一开始给tcpip_thread分配了1024字节跑TCP客户端长连接时直接溢出后来加到2048才稳定。2.2 sys_arch层必须做的事LWIP要跑在FreeRTOS上必须实现sys_arch层也就是操作系统抽象层。这块做的事情核心有这几件信号量、互斥锁、邮箱、系统时间。在FreeRTOS上我用二值信号量模拟LWIP的二值信号量用FreeRTOS队列实现LWIP的mboxsys_now则直接用系统tick毫秒值。接收数据路径是这样以太网中断里只做一件事——释放一个二值信号量然后退出。真正处理数据包的是tcpip_thread里的ethernetif_input函数。这样做可以把中断处理时间压到最短避免丢包。发送路径则用互斥锁保护防止多个任务同时调用netif-linkoutput导致数据错乱。还有一个细节FreeRTOS任务切换的时机。LWIP的阻塞API比如netconn_recv内部会调用sys_arch_mbox_fetch这个函数在FreeRTOS里用xQueueReceive实现一旦队列为空当前任务就会让出CPU触发任务切换。这部分机制是LWIP多任务并发的基础只要你正确实现了sys_arch层任务切换就是自动完成的。2.3 栈空间分配与溢出检测FreeRTOS任务栈溢出是网络项目里最容易踩的雷。我的做法是两层防护一是开启FreeRTOS的栈溢出检测。在FreeRTOSConfig.h里把configCHECK_FOR_STACK_OVERFLOW设为2这样任务切换时如果发现栈指针异常会调用vApplicationStackOverflowHook我在这个钩子里把出错任务名打印出来方便定位。二是在调试阶段用uxTaskGetStackHighWaterMark测量每个任务的历史最小剩余栈空间。跑各种压力测试场景比如长时间TCP收发、反复热插拔网线然后把各任务的水位标尺拉出来看。我实测下来tcpip_thread高水位剩不到400字节app_tx_task剩200多字节都有余量。正式发布前再统一加20%的安全余量。3. 网线热插拔检测的完整实现3.1 硬件链路RMII、PHY与状态引脚硬件上用的是GD32F4内置MAC LAN8720A PHYRMII接口。RMII相比MII接口的优势是引脚少只需要TX_EN、TXD[1:0]、RXD[1:0]、CLK、CRS_DV这几根信号但代价是时钟频率要达到50MHz由外部晶振或MCU提供。这里特别提醒一点PHY的nINT引脚和RESET引脚一定要引出来接到MCU的GPIO不要悬空。nINT引脚在后面的方案里可以作为链路状态变化的中断源RESET引脚则用于异常情况下对PHY做硬件复位。我做的板子把这两个引脚都引到了MCU实际调试时救了好几次。LAN8720A的链路状态信息在寄存器1Basic Status Register的bit2位读出来是1表示链路正常0表示断开。但要注意这个位是锁存型的读一次不会自动刷新要连续读两次第二次的值才是当前真实链路状态。这是PHY芯片的通用特性不光是LAN8720ADP83848、RTL8201这些也都是这样。3.2 PHY链路状态检测的代码实现我采用的方案是轮询。虽然PHY的中断引脚也能用但轮询逻辑更简单、更容易排查问题。用一个软件定时器或者独立任务每200ms读一次PHY状态寄存器。核心代码如下uint8_t phy_check_link_status(void) { uint16_t reg_val1, reg_val2; eth_phy_read(0, 1, reg_val1); // 寄存器1Basic Status Register eth_phy_read(0, 1, reg_val2); // 连续读两次取真实状态 if (reg_val2 (1 2)) { // bit2: Link Status return 1; // 链路正常 } return 0; // 链路断开 }注意这个函数必须要做超时保护。在硬件异常的情况下eth_phy_read可能会卡死在MDIO总线上我实际遇到过一次。所以PHY读操作外面套了一层超时机制超过100次读取无响应就强制复位PHY。链路检测任务的逻辑是记录上一次的链路状态每次读到的状态和上次不一样就认为发生了一次插拔事件然后执行对应的处理流程。void link_monitor_task(void *param) { uint8_t last_state phy_check_link_status(); uint8_t cur_state; while (1) { vTaskDelay(pdMS_TO_TICKS(200)); cur_state phy_check_link_status(); if (cur_state ! last_state) { if (cur_state) { handle_link_up(); // 插入网线 } else { handle_link_down(); // 拔出网线 } last_state cur_state; } } }3.3 拔线/插线后LWIP层怎么收拾残局这是热插拔处理的核心也是很多人容易做漏的地方。网线拔出时要做的事情包括调用netif_set_link_down把LWIP的netif状态置为down如果你的设备使用DHCP动态获取IP要调用dhcp_stop停止DHCP客户端同时记一个时间戳方便后续排查。这里有一个容易忽略的细节拔出网线后原来的IP地址和ARP缓存实际上已经不可用了但LWIP默认不会主动清掉这块状态所以应用层自己要做好标记。网线再次插入时事情要多不少第一步先等PHY自动协商完成。网线插上后PHY需要几百毫秒到2秒的时间完成自协商这个期间读状态寄存器可能是忽好忽坏的所以要轮询等待Link Status稳定为1再继续往下走。第二步调用netif_set_link_up把netif状态恢复。这里有个先后顺序问题必须先等PHY协商完毕再设置netif为up。顺序反了的话LWIP发送数据时DMA会往MAC寄存器里写数据但PHY其实还没准备好容易导致MAC状态机卡死。第三步如果使用DHCP要调用dhcp_start重新发起DHCP请求。有些场景下重插网线后IP网段可能变了DHCP在短时间内拿不到地址会反复重试LWIP内部有超时机制这里不需要额外处理但要确认dhcp_start的返回值。第四步清理ARP表。如果设备的IP地址重新分配了旧IP对应的ARP表项要清掉否则同一个IP的MAC地址映射是旧的通信会异常。可以直接调用etharp_cleanup或者更粗暴一点遍历ARP表手动清空。最后应用层要把当前状态通过JSON格式上报。比如拼一个带有link_status、ip_addr、mac_addr字段的JSON包通过串口发出去。这里用cJSON封装就很自然LWIP负责把同样的JSON包通过网络发到远端串口和网络两条通道的状态是同步的。4. 实战中踩过的坑与排查技巧4.1 拔线重连失败往往卡在PHY软复位我在调试中遇到的第一个大坑就是网线拔掉再插上等了很久链路状态寄存器已经显示正常但就是ping不通。排查到最后发现是网线插上后只做了netif_set_link_up没有对PHY做软复位。正常情况下插入后PHY会自动开始自协商不需要软件干预。但如果系统运行时间长了或者多次快速插拔PHY内部状态机可能卡在错误状态需要写PHY寄存器0BMCR的bit15触发软件复位。复位后要等待一段时间bit15会自动清零然后重新读取自协商状态。我的处理流程是检测到链路插入后先做一次PHY软复位再等待自协商完成最后才设置netif为up。这样处理之后快速插拔几十次都没有再出现卡死现象。4.2 重连后ping不通先查ARP与DHCP另一个典型问题链路状态显示正常、PHY也正常但设备端ping外部主机不通外部主机也ping不进设备。这种情况多半是ARP缓存表的问题。在动态IP场景下网线重插后设备重新DHCP拿到的新IP可能和旧IP不同。但设备端的ARP表还记录着旧IP对应的MAC地址。虽然LWIP的ARP表项有老化机制默认是5分钟但在这5分钟里通信就是不通的。解决方式是在dhcp_start成功获取新IP后主动调用etharp_cleanup清空ARP表或者遍历ARP表删除所有动态表项。还有一种情况是DHCP一直获取不到地址常见原因是设备拔线后没有调用dhcp_stop导致DHCP客户端的重试定时器还在跑插线后再调用dhcp_start两个定时器冲突。这个我调试的时候看了半天才发现是重复启动的问题。所以每次handle_link_up里dhcp_start之前要确保dhcp_stop已经调用过或者用状态标记做保护。4.3 中断优先级、DMA描述符与数据错位的坑以太网中断优先级设置不当会导致高频率网口数据进来时CPU长时间被中断占据低优先级的任务根本得不到调度表现就是系统假死。我的做法是把以太网中断优先级设成比系统tick中断低、比普通外设中断高。这样既不会阻塞系统节拍又能及时响应网络数据。这个优先级参数在NVIC配置里看起来很不起眼但实际对系统稳定性影响极大。DMA描述符的坑更隐蔽。GD32F4的以太网DMA要求描述符和缓冲区地址4字节对齐。如果RX缓冲区的首地址没有对齐DMA搬运数据时会出错出现数据错位或者描述符状态一直显示未完成。我当时在分配RX buffer时加了一个宏做对齐处理用__attribute__((aligned(4)))确保每个缓冲区的起始地址都是4的倍数。这个问题排查起来比较费劲因为现象表现为偶发性数据错误时好时坏但对齐之后就没再出现过。4.4 问题排查速查表整理一个排查对照表遇到问题对号入座现象可能原因解决措施拔线重插后ping不通PHY状态机卡死PHY软复位再等待自协商完成链路状态正常但网络不通ARP缓存表未清理dhcp_start后调用etharp_cleanupDHCP一直获取不到地址未先停止旧DHCP实例确保dhcp_stop在dhcp_start之前调用系统偶发假死以太网中断优先级过高降低以太网中断优先级低于tick中断TCP数据偶尔错位DMA缓冲区未对齐RX/TX缓冲区加4字节对齐声明拔线后应用层仍显示在线未处理netif_set_link_down检测到断开后立即通知LWIP和应用层还有一个排查热插拔问题的万能方法把所有关键状态通过串口打印出来。PHY寄存器值、netif状态、DHCP状态、ARP表项数每个环节的状态变化都打出来。热插拔问题本质上是状态机问题只要把每个状态的变化过程搞清楚问题就解决了一半。提示在实际项目里不要把热插拔检测的周期设置得太短。我用的200ms轮询间隔既保证了响应及时性又不会因为过于频繁读PHY寄存器而干扰MDIO总线的稳定性。如果你想用PHY中断引脚配合GPIO外部中断来实现瞬时响应也是个好方案但要注意处理抖动最好加个10ms左右的滤波延时。最后再分享一个我个人的体会热插拔处理看起来只是一个很小的功能但它把FreeRTOS的任务调度、LWIP的协议栈状态、PHY的硬件行为三个层面完全串在了一起。调试这类问题一定要按照先PHY、再MAC、最后LWIP协议栈的顺序来排查。先把PHY状态读对了再看MAC能不能正常复位和工作最后才去动LWIP层的状态。很多人一上来就去看LWIP代码绕了一大圈最后发现是PHY的软复位没做白费了不少功夫。本文还有配套的精品资源点击获取
简介面向 GD32F4 嵌入式开发者的网络应用工程以 GD32F407 为主控芯片完整实现了 LWIP 协议栈与 FreeRTOS 的整合并针对网线热插拔场景给出了链接状态检测、中断响应和连接重建的解决方案。压缩包约 15.49MB共 728 个文件其中包含 243 个头文件与 185 个 C 源文件覆盖以太网驱动、TCP/IP 协议栈、任务调度及 HTTP 服务等模块另含 Keil 工程配置、链接映射文件、编译中间文件与少量说明文档便于直接导入 Keil 查看或二次开发。目前已有 2341 人学习下载适合正在调试 GD32F4 网络功能或希望了解 LWIP 与 FreeRTOS 配合方式的工程师。通过学习这份工程代码可以掌握 GD32F4 以太网 MAC 的初始化流程、LWIP 在 FreeRTOS 中的任务划分方式以及利用 LINK/ACT 信号触发中断、再通过回调更新网络连接的具体写法对开发稳定可靠的嵌入式网络设备有直接参考价值。 搞嵌入式网络设备的朋友应该都有这种经历板子刚调通那会儿LWIPFreeRTOS跑起来PC端ping得通心里挺爽。但真正拿到现场用户随手一拔网线再接回去过几分钟电话就来了——设备掉线了起不来了。我这次做的项目是基于GD32F4系列GD32F450Cortex-M4主频200MHz内置MAC外挂LAN8720A这颗PHY的工业数据采集网关软件侧选了FreeRTOS LWIP这套经典组合其中一个绕不开的需求就是网线热插拔处理。链路状态要准确、插拔之后系统能自动恢复、不能出现线插了但连不上线拔了还显示在线这种问题。这篇文章就从整体设计、任务划分、PHY状态检测、LWIP栈处理、以及我实际踩过的坑这几个方面把整个方案完整拆一遍。适合正在做类似网关、采集器、带网口仪表的朋友参考尤其是那种基础功能跑通容易产品化难的项目。1. 项目到底在解决什么问题1.1 这套组合的选型逻辑先说为什么选GD32F4。这颗芯片内置10/100M以太网MAC支持RMII接口主频能到200MHzFlash和RAM的容量也比较充裕。相比外挂SPI接口网卡芯片的方案内置MAC 外部PHY的方式在吞吐量、稳定性、成本之间取得了一个比较理想的平衡。而且GD32F4的以太网外设寄存器结构和STM32F4/H7系列很接近芯片本身也兼容ST的部分引脚定义调试手段和代码参考资料都比较成熟。FreeRTOS在这个项目里承担的角色是任务调度、信号量同步、软件定时器。LWIP则负责TCP/IP协议栈。两个都是C语言写的、可裁剪的轻量级方案特别适合MCU场景。我在这个项目里还顺便把cJSON集成进去了链路状态、采集数据需要打包成JSON格式通过串口或网络上报LWIP负责传输cJSON负责封包这两个配合起来很顺手。1.2 为什么能ping通不算完事很多人觉得LWIP跑起来、能ping通就完事了。但实际上网络设备产品化的难点往往在异常处理尤其是网线热插拔这种最容易被忽略的场景。网线拔掉再插回去中间涉及到的链路有PHY检测到物理链路断开/恢复、MAC层状态同步、LWIP协议栈的接口状态更新、应用层网络状态上报。任何一个环节没处理干净都会出问题。最典型的现象就是拔线之后重插设备IP还挂在旧状态上DHCP没有重新协商或者PHY的自动协商卡死MAC状态机一直停在错误状态表现就是一直ping不通。完整的热插拔处理应该覆盖这些状态网线拔出、网线插入、PHY自动协商完成、IP地址重新获取、网络连接恢复确认、应用层状态上报。影响范围不只是现场运维还包括远程升级、看门狗策略、设备在线检测这些上层逻辑。2. FreeRTOS与LWIP的协作架构2.1 任务划分优先级怎么定我的任务划分比较常规但优先级顺序是经过实际测试调整过的直接给出来供参考任务名优先级栈大小职责tcpip_thread32048LWIP核心线程处理协议栈消息app_tx_task21024周期发送采集数据link_monitor_task4512轮询PHY链路状态处理热插拔console_task1512串口命令交互优先级上我把链路检测放得比协议栈线程还高一点。原因是这个任务本身很轻只是读寄存器、判断状态、发信号耗时极短。而tcpip_thread要处理TCP重传、ARP请求、IP分片这些耗时操作如果优先级比链路检测高极端情况下链路检测会被饿死导致插拔事件处理不及时。栈大小这里有个容易被忽视的点tcpip_thread的栈不能省。LWIP的协议栈处理会在任务上下文中调用应用层回调如果你在回调里做了耗时操作比如打印、格式化JSON栈用量会明显涨。我一开始给tcpip_thread分配了1024字节跑TCP客户端长连接时直接溢出后来加到2048才稳定。2.2 sys_arch层必须做的事LWIP要跑在FreeRTOS上必须实现sys_arch层也就是操作系统抽象层。这块做的事情核心有这几件信号量、互斥锁、邮箱、系统时间。在FreeRTOS上我用二值信号量模拟LWIP的二值信号量用FreeRTOS队列实现LWIP的mboxsys_now则直接用系统tick毫秒值。接收数据路径是这样以太网中断里只做一件事——释放一个二值信号量然后退出。真正处理数据包的是tcpip_thread里的ethernetif_input函数。这样做可以把中断处理时间压到最短避免丢包。发送路径则用互斥锁保护防止多个任务同时调用netif-linkoutput导致数据错乱。还有一个细节FreeRTOS任务切换的时机。LWIP的阻塞API比如netconn_recv内部会调用sys_arch_mbox_fetch这个函数在FreeRTOS里用xQueueReceive实现一旦队列为空当前任务就会让出CPU触发任务切换。这部分机制是LWIP多任务并发的基础只要你正确实现了sys_arch层任务切换就是自动完成的。2.3 栈空间分配与溢出检测FreeRTOS任务栈溢出是网络项目里最容易踩的雷。我的做法是两层防护一是开启FreeRTOS的栈溢出检测。在FreeRTOSConfig.h里把configCHECK_FOR_STACK_OVERFLOW设为2这样任务切换时如果发现栈指针异常会调用vApplicationStackOverflowHook我在这个钩子里把出错任务名打印出来方便定位。二是在调试阶段用uxTaskGetStackHighWaterMark测量每个任务的历史最小剩余栈空间。跑各种压力测试场景比如长时间TCP收发、反复热插拔网线然后把各任务的水位标尺拉出来看。我实测下来tcpip_thread高水位剩不到400字节app_tx_task剩200多字节都有余量。正式发布前再统一加20%的安全余量。3. 网线热插拔检测的完整实现3.1 硬件链路RMII、PHY与状态引脚硬件上用的是GD32F4内置MAC LAN8720A PHYRMII接口。RMII相比MII接口的优势是引脚少只需要TX_EN、TXD[1:0]、RXD[1:0]、CLK、CRS_DV这几根信号但代价是时钟频率要达到50MHz由外部晶振或MCU提供。这里特别提醒一点PHY的nINT引脚和RESET引脚一定要引出来接到MCU的GPIO不要悬空。nINT引脚在后面的方案里可以作为链路状态变化的中断源RESET引脚则用于异常情况下对PHY做硬件复位。我做的板子把这两个引脚都引到了MCU实际调试时救了好几次。LAN8720A的链路状态信息在寄存器1Basic Status Register的bit2位读出来是1表示链路正常0表示断开。但要注意这个位是锁存型的读一次不会自动刷新要连续读两次第二次的值才是当前真实链路状态。这是PHY芯片的通用特性不光是LAN8720ADP83848、RTL8201这些也都是这样。3.2 PHY链路状态检测的代码实现我采用的方案是轮询。虽然PHY的中断引脚也能用但轮询逻辑更简单、更容易排查问题。用一个软件定时器或者独立任务每200ms读一次PHY状态寄存器。核心代码如下uint8_t phy_check_link_status(void) { uint16_t reg_val1, reg_val2; eth_phy_read(0, 1, reg_val1); // 寄存器1Basic Status Register eth_phy_read(0, 1, reg_val2); // 连续读两次取真实状态 if (reg_val2 (1 2)) { // bit2: Link Status return 1; // 链路正常 } return 0; // 链路断开 }注意这个函数必须要做超时保护。在硬件异常的情况下eth_phy_read可能会卡死在MDIO总线上我实际遇到过一次。所以PHY读操作外面套了一层超时机制超过100次读取无响应就强制复位PHY。链路检测任务的逻辑是记录上一次的链路状态每次读到的状态和上次不一样就认为发生了一次插拔事件然后执行对应的处理流程。void link_monitor_task(void *param) { uint8_t last_state phy_check_link_status(); uint8_t cur_state; while (1) { vTaskDelay(pdMS_TO_TICKS(200)); cur_state phy_check_link_status(); if (cur_state ! last_state) { if (cur_state) { handle_link_up(); // 插入网线 } else { handle_link_down(); // 拔出网线 } last_state cur_state; } } }3.3 拔线/插线后LWIP层怎么收拾残局这是热插拔处理的核心也是很多人容易做漏的地方。网线拔出时要做的事情包括调用netif_set_link_down把LWIP的netif状态置为down如果你的设备使用DHCP动态获取IP要调用dhcp_stop停止DHCP客户端同时记一个时间戳方便后续排查。这里有一个容易忽略的细节拔出网线后原来的IP地址和ARP缓存实际上已经不可用了但LWIP默认不会主动清掉这块状态所以应用层自己要做好标记。网线再次插入时事情要多不少第一步先等PHY自动协商完成。网线插上后PHY需要几百毫秒到2秒的时间完成自协商这个期间读状态寄存器可能是忽好忽坏的所以要轮询等待Link Status稳定为1再继续往下走。第二步调用netif_set_link_up把netif状态恢复。这里有个先后顺序问题必须先等PHY协商完毕再设置netif为up。顺序反了的话LWIP发送数据时DMA会往MAC寄存器里写数据但PHY其实还没准备好容易导致MAC状态机卡死。第三步如果使用DHCP要调用dhcp_start重新发起DHCP请求。有些场景下重插网线后IP网段可能变了DHCP在短时间内拿不到地址会反复重试LWIP内部有超时机制这里不需要额外处理但要确认dhcp_start的返回值。第四步清理ARP表。如果设备的IP地址重新分配了旧IP对应的ARP表项要清掉否则同一个IP的MAC地址映射是旧的通信会异常。可以直接调用etharp_cleanup或者更粗暴一点遍历ARP表手动清空。最后应用层要把当前状态通过JSON格式上报。比如拼一个带有link_status、ip_addr、mac_addr字段的JSON包通过串口发出去。这里用cJSON封装就很自然LWIP负责把同样的JSON包通过网络发到远端串口和网络两条通道的状态是同步的。4. 实战中踩过的坑与排查技巧4.1 拔线重连失败往往卡在PHY软复位我在调试中遇到的第一个大坑就是网线拔掉再插上等了很久链路状态寄存器已经显示正常但就是ping不通。排查到最后发现是网线插上后只做了netif_set_link_up没有对PHY做软复位。正常情况下插入后PHY会自动开始自协商不需要软件干预。但如果系统运行时间长了或者多次快速插拔PHY内部状态机可能卡在错误状态需要写PHY寄存器0BMCR的bit15触发软件复位。复位后要等待一段时间bit15会自动清零然后重新读取自协商状态。我的处理流程是检测到链路插入后先做一次PHY软复位再等待自协商完成最后才设置netif为up。这样处理之后快速插拔几十次都没有再出现卡死现象。4.2 重连后ping不通先查ARP与DHCP另一个典型问题链路状态显示正常、PHY也正常但设备端ping外部主机不通外部主机也ping不进设备。这种情况多半是ARP缓存表的问题。在动态IP场景下网线重插后设备重新DHCP拿到的新IP可能和旧IP不同。但设备端的ARP表还记录着旧IP对应的MAC地址。虽然LWIP的ARP表项有老化机制默认是5分钟但在这5分钟里通信就是不通的。解决方式是在dhcp_start成功获取新IP后主动调用etharp_cleanup清空ARP表或者遍历ARP表删除所有动态表项。还有一种情况是DHCP一直获取不到地址常见原因是设备拔线后没有调用dhcp_stop导致DHCP客户端的重试定时器还在跑插线后再调用dhcp_start两个定时器冲突。这个我调试的时候看了半天才发现是重复启动的问题。所以每次handle_link_up里dhcp_start之前要确保dhcp_stop已经调用过或者用状态标记做保护。4.3 中断优先级、DMA描述符与数据错位的坑以太网中断优先级设置不当会导致高频率网口数据进来时CPU长时间被中断占据低优先级的任务根本得不到调度表现就是系统假死。我的做法是把以太网中断优先级设成比系统tick中断低、比普通外设中断高。这样既不会阻塞系统节拍又能及时响应网络数据。这个优先级参数在NVIC配置里看起来很不起眼但实际对系统稳定性影响极大。DMA描述符的坑更隐蔽。GD32F4的以太网DMA要求描述符和缓冲区地址4字节对齐。如果RX缓冲区的首地址没有对齐DMA搬运数据时会出错出现数据错位或者描述符状态一直显示未完成。我当时在分配RX buffer时加了一个宏做对齐处理用__attribute__((aligned(4)))确保每个缓冲区的起始地址都是4的倍数。这个问题排查起来比较费劲因为现象表现为偶发性数据错误时好时坏但对齐之后就没再出现过。4.4 问题排查速查表整理一个排查对照表遇到问题对号入座现象可能原因解决措施拔线重插后ping不通PHY状态机卡死PHY软复位再等待自协商完成链路状态正常但网络不通ARP缓存表未清理dhcp_start后调用etharp_cleanupDHCP一直获取不到地址未先停止旧DHCP实例确保dhcp_stop在dhcp_start之前调用系统偶发假死以太网中断优先级过高降低以太网中断优先级低于tick中断TCP数据偶尔错位DMA缓冲区未对齐RX/TX缓冲区加4字节对齐声明拔线后应用层仍显示在线未处理netif_set_link_down检测到断开后立即通知LWIP和应用层还有一个排查热插拔问题的万能方法把所有关键状态通过串口打印出来。PHY寄存器值、netif状态、DHCP状态、ARP表项数每个环节的状态变化都打出来。热插拔问题本质上是状态机问题只要把每个状态的变化过程搞清楚问题就解决了一半。提示在实际项目里不要把热插拔检测的周期设置得太短。我用的200ms轮询间隔既保证了响应及时性又不会因为过于频繁读PHY寄存器而干扰MDIO总线的稳定性。如果你想用PHY中断引脚配合GPIO外部中断来实现瞬时响应也是个好方案但要注意处理抖动最好加个10ms左右的滤波延时。最后再分享一个我个人的体会热插拔处理看起来只是一个很小的功能但它把FreeRTOS的任务调度、LWIP的协议栈状态、PHY的硬件行为三个层面完全串在了一起。调试这类问题一定要按照先PHY、再MAC、最后LWIP协议栈的顺序来排查。先把PHY状态读对了再看MAC能不能正常复位和工作最后才去动LWIP层的状态。很多人一上来就去看LWIP代码绕了一大圈最后发现是PHY的软复位没做白费了不少功夫。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
