正点原子STM32F407探索者板上跑通uCOS-III+LwIP 1.4.1多连接TCP服务端工程-CSDN博客

本文还有配套的精品资源，点击获取

简介：基于正点原子STM32F407探索者开发板，整合uCOS-III实时操作系统与LwIP 1.4.1轻量级TCP/IP协议栈，实现可稳定响应多个TCP客户端并发连接的服务端功能。工程包含完整KEIL MDK项目文件（.uvprojx及相关编译配置），已适配F407芯片系统时钟、以太网MAC/PHY驱动（DP83848）、LwIP底层硬件接口封装、uCOS-III任务创建与调度管理，以及应用层TCP Server逻辑（含监听、接收、回显等基础处理）。所有源码结构清晰、模块职责明确，无外部闭源库依赖，关键部分如网卡初始化、内存池配置、任务堆栈分配、LwIP回调绑定等均有对应实现。配套README.txt提供编译环境要求（如MDK版本建议）、下载步骤、默认IP地址（192.168.1.10）、测试方法（可用网络调试助手或telnet连接验证），适合嵌入式初学者理解RTOS与网络协议栈协同运行机制，也适用于工业远程监控、传感器数据汇聚、简易IoT终端等实际场景快速验证网络通信能力。

1. 项目概述：为什么在STM32F407上跑通uCOS-III+LwIP TCP服务器，是嵌入式网络开发的“分水岭”级实操？

你手头有一块正点原子STM32F407探索者开发板，它不是一块玩具板——它有真正的以太网口（DP83848 PHY）、足够跑起RTOS的192KB SRAM、1MB Flash，以及成熟稳定的硬件设计。但光有硬件，不等于你会用它做网络通信。很多初学者卡在“能ping通”和“能收发数据”之间，更别说让多个客户端同时连上来、稳定运行几天不出错。这个工程，就是帮你跨过那道坎的完整脚手架。

它不是一个Demo，而是一个可直接用于工业场景验证的最小可行系统（MVP）。核心关键词——STM32F407、uCOS-III、LwIP、TCP服务器、嵌入式网络——不是堆砌术语，而是五根咬合紧密的齿轮：STM32F407提供硬件平台；uCOS-III负责把CPU时间切片分给不同任务，不让网络收包阻塞LED闪烁；LwIP 1.4.1是轻量但完整的TCP/IP协议栈，专为资源受限设备设计；TCP服务器是最终呈现的功能形态；而“嵌入式网络”，则是贯穿始终的设计哲学——一切都要考虑内存碎片、中断延迟、堆栈溢出、PHY寄存器配置时序这些真实世界里的“毛刺”。

我带过不少刚从51单片机转过来的工程师，他们第一次看到自己的板子在串口打印出“Client 192.168.1.100:52345 connected”时，那种兴奋不是因为代码多炫酷，而是因为他们终于亲手把“协议栈”从教科书里拽了出来，放在了真实的芯片上跑起来了。这个工程的价值，正在于它把所有晦涩的抽象概念——比如“netif结构体初始化”、“sys_sem_create()信号量创建”、“tcp_accept_callback回调绑定”——全部落实到.c和.h文件里，每一行都有注释，每一个宏定义都指向具体寄存器或内存地址。它不教你LwIP源码怎么写，但它教会你怎么让它为你所用；它不讲uCOS-III内核调度算法，但它让你亲眼看到一个TCP接收任务如何被唤醒、处理完数据后又如何让出CPU给另一个LED翻转任务。这才是嵌入式网络开发最该打牢的地基：不是调通一个函数，而是理解整个数据流在硬件、驱动、协议栈、RTOS、应用层之间的穿梭路径。

2. 整体架构与设计思路：为什么选uCOS-III而不是FreeRTOS？为什么是LwIP 1.4.1而不是2.x？

这套工程不是简单地把两个开源库拼在一起，它的整体架构是一次经过权衡取舍的系统性设计。我们先看顶层模块划分：

硬件抽象层（HAL）：基于ST官方标准外设库（不是HAL库），直接操作寄存器完成RCC时钟配置、GPIO复用、ETH外设初始化。之所以不用CubeMX生成的HAL，是因为LwIP 1.4.1对底层驱动接口有明确要求（如ethernetif_input()必须是裸中断服务函数），而CubeMX HAL封装过深，容易引入不可控延迟。
LwIP适配层（LwIP Port）：这是最关键的胶水层。它实现了sys_arch.c（uCOS-III兼容的系统模拟层）、ethernetif.c（DP83848 PHY驱动+MAC DMA描述符管理）、lwipopts.h（精细内存池配置）。这里没有魔法，只有对每个#define背后含义的反复推敲。
uCOS-III任务管理层：共创建5个核心任务：AppTaskStart（启动任务，只运行一次）、AppTaskLED（控制LED闪烁，验证RTOS调度）、AppTaskEthInit（以太网初始化，完成后删除自身）、AppTaskTCPServer（主TCP服务端逻辑）、AppTaskLwIPThread（LwIP的tcpip_thread，处理协议栈核心事件）。任务优先级、堆栈大小、创建顺序，全部按实时性需求严格设定。
应用层TCP Server：采用非阻塞+轮询模式（非LwIP的callback-heavy风格），在AppTaskTCPServer中循环调用tcp_accept()、tcp_recv()、tcp_write()，配合uCOS-III信号量同步，确保多连接下内存安全。

那么，为什么是这个组合？先说uCOS-III。很多人第一反应是FreeRTOS，它生态好、资料多。但在这个特定场景下，uCOS-III有三个不可替代的优势：第一，它的OSTaskCreate()接口更直观，堆栈检查机制（OS_CFG_TASK_STK_CHK_EN）能直接捕获栈溢出，这对调试网络任务这种内存大户极其关键；第二，它的信号量和消息队列API命名统一（OSSemPend()/OSSemPost()），不像FreeRTOS的xSemaphoreTake()/xQueueSend()混用，降低新手认知负荷；第三，Micrium（uCOS作者）官方提供了针对STM32F4系列的完整移植例程（你看到的Micrium_STM3240G-EVAL_OS3目录就是），省去了大量底层汇编适配工作。

再看LwIP版本。LwIP 2.x功能更强，支持IPv6、多网卡、更完善的Socket API。但代价是代码体积膨胀40%，内存占用翻倍。LwIP 1.4.1是最后一个“极简主义”版本，整个协议栈ROM仅约80KB，RAM峰值占用可压到32KB以内（本工程实测28.7KB）。更重要的是，它的API更“嵌入式友好”：tcp_new()返回struct tcp_pcb*指针，你可以直接把它存进数组索引客户端；tcp_arg()绑定的void *arg可以是任意结构体指针，方便你挂载自定义会话状态；而2.x强制使用struct netconn抽象层，多一层间接寻址，在F407这种Cortex-M4上虽无性能瓶颈，但对理解底层数据流反而增加了障碍。所以，这不是守旧，而是精准匹配——用最精悍的工具，解决最实际的问题。

3. 核心细节解析与实操要点：从PHY寄存器配置到LwIP内存池，每一步都是经验之谈

真正决定这个工程能否稳定运行的，从来不是主循环里的几行tcp_write()，而是那些藏在.c文件深处、注释只有“// Init PHY”的几十行代码。我把最关键的五个细节拆解出来，告诉你它们为什么重要，以及我踩过的坑。

3.1 DP83848 PHY初始化：别只盯着BMCR寄存器，BMSR才是真相

DP83848的初始化绝不是写个0x1200到BMCR（Basic Mode Control Register）就完事。很多工程在这里栽跟头，现象是“能ping通但无法建立TCP连接”。根本原因在于，PHY的链路状态（Link Status）和协商结果（Speed/Duplex）必须被MCU准确读取并反馈给LwIP。关键寄存器是BMSR（Basic Mode Status Register，地址0x01）。标准流程是：

复位PHY（写BMCR[15]=1，等待至少1ms）；
检查BMSR[0]（Link Status）是否为1，若否，说明物理连接断开或PHY未供电；
若Link已建立，读取BMSR[14:13]（Extended Capability）判断是否支持100BASE-TX；
最后，读取ANLPAR（Auto-Negotiation Link Partner Ability Register, 0x05）确认对端能力，并据此设置MAC的ETH_MACCR寄存器（如ETH_SPEED_100M、ETH_DUPLEX_FULL）。

我在调试时遇到过一次诡异问题：板子接路由器能通，接PC直连就不行。抓包发现ARP请求发出去了，但没收到回复。最后定位到是BMSR读取超时——因为DP83848上电后需要约300ms才能稳定，而我的初始化代码里只等了100ms。解决方案是在ethernetif_init()开头加了一个OSTimeDlyHMSM(0, 0, 0, 300)硬延时，问题立刻消失。这提醒我们：PHY数据手册里的“tRST”参数，不是建议，是铁律。

3.2 LwIP内存池配置：`MEMP_NUM_TCP_PCB`不是越大越好，要算“连接生命周期”

LwIP用静态内存池管理所有协议栈对象，lwipopts.h里一堆MEMP_NUM_xxx宏定义，新手常盲目调大。但内存是有限的，尤其F407的SRAM只有192KB，还要分给uCOS-III任务堆栈、全局变量、LwIP的pbuf池。本工程的关键配置如下：

#define MEMP_NUM_TCP_PCB        8    // 最大并发TCP连接数
#define MEMP_NUM_TCP_PCB_LISTEN 2    // 监听PCB数量（通常1个足够）
#define MEMP_NUM_NETBUF         16   // 网络缓冲区描述符
#define MEMP_NUM_NETCONN        8    // Netconn结构体（本工程未启用，设为0更省）
#define PBUF_POOL_SIZE          16   // pbuf内存池大小（每个pbuf约512字节）

为什么是8个TCP PCB？计算依据是：每个TCP PCB结构体约200字节，8个共1.6KB；每个pbuf约512字节，16个共8KB；加上TCP发送/接收窗口缓存（TCP_SND_BUF=4096, TCP_RCV_BUF=4096），总RAM占用约28KB。如果你设成16，pbuf池就得翻倍，RAM立刻突破40KB，留给uCOS-III任务的空间就捉襟见肘了。更重要的是，“并发连接数”不等于“同时传输数据的连接数”。TCP连接建立后，大部分时间处于空闲（Idle）状态，真正消耗CPU和内存的是数据收发瞬间。所以，8个连接足以支撑一个传感器汇聚终端（1个主站+7个子节点）。

3.3 uCOS-III任务堆栈分配：`OS_CFG_TASK_STK_CHK_EN`开启后，堆栈不是“够用就行”

uCOS-III的任务堆栈，不能像裸机编程那样凭感觉估。本工程中，AppTaskTCPServer堆栈设为2048U（单位是CPU_STK，即4字节），表面看很大，但这是必须的。原因有三：第一，LwIP的tcp_write()内部会深度调用，涉及内存拷贝、校验和计算、DMA描述符更新，函数调用栈很深；第二，当多个客户端同时发来大数据包（如1KB JSON），tcp_recv()回调里临时变量会占用大量栈空间；第三，开启OS_CFG_TASK_STK_CHK_EN后，uCOS-III会在每个任务栈底写入“魔数”，并在每次任务切换时检查是否被覆盖——如果堆栈不足，魔数被改写，系统会触发OS_ERR_STK_OVF错误并停止。我在测试时故意把堆栈降到1024，结果第3个客户端连上来就死机，串口打印出[ERR] Task TCPServer stack overflow!。所以，2048不是冗余，是安全边际。

3.4 LwIP底层接口绑定：`sys_arch.c`里的`sys_sem_create()`为何必须用`OSSemCreate()`？

LwIP需要操作系统提供基本同步原语：信号量（semaphore）、互斥锁（mutex）、消息队列（mbox）。在sys_arch.c中，sys_sem_create()的实现必须调用uCOS-III的OSSemCreate()，而非自己用全局变量模拟。为什么？因为LwIP的tcpip_thread是一个高优先级任务，它需要在中断上下文（如ETH DMA接收完成中断）中通过sys_sem_post()唤醒。如果信号量是纯软件模拟，中断里修改全局变量会导致竞态条件。uCOS-III的OSSemPost()是原子操作，内部禁用中断，确保安全。本工程中，tcpip_thread的优先级设为OS_CFG_PRIO_MAX - 2（即比最高优先级低2级），就是为了保证它能及时响应网络事件，又不至于饿死其他应用任务。

3.5 TCP Server应用逻辑：为什么用“轮询+信号量”而非纯Callback？

LwIP原生推荐用tcp_accept_callback()和tcp_recv_callback()注册回调函数。但本工程选择在AppTaskTCPServer中主动轮询，原因很实在：可控性。Callback模式下，回调函数在tcpip_thread上下文中执行，如果回调里做了耗时操作（如解析JSON、写Flash），会阻塞整个协议栈，导致新包丢失。而轮询模式下，AppTaskTCPServer是一个独立任务，你可以精确控制它每次循环处理多少数据、是否让出CPU（OSTimeDly(1)）、甚至在检测到内存紧张时主动丢弃低优先级连接。代码结构也更线性：

while (DEF_TRUE) {
    // 1. 检查是否有新连接
    if (tcp_accepted_conn != DEF_NULL) {
        tcp_accepted_conn = DEF_NULL;
        // 创建新连接PCB，加入连接列表
    }
    // 2. 遍历所有活动连接，调用tcp_recv()
    for (i = 0; i < MAX_CONN; i++) {
        if (conn_list[i].pcb != DEF_NULL) {
            tcp_recved(conn_list[i].pcb, conn_list[i].recv_len); // 告诉LwIP已接收
            // 处理接收到的数据...
        }
    }
    OSTimeDly(1); // 主动让出1ms，避免占满CPU
}

这种模式牺牲了一点理论上的响应速度，换来了绝对的稳定性和可调试性。对于工业现场，稳定压倒一切。

4. 实操过程与核心环节实现：从KEIL环境搭建到真机运行，一份不跳步的指南

现在，我们把纸面设计变成可运行的二进制。整个过程分为四个阶段：环境准备、工程导入、关键配置修改、真机验证。每一步我都标注了“为什么这么做”，避免你成为只会Ctrl+C/V的搬运工。

4.1 KEIL MDK环境准备：版本、Pack、编译器选项，一个都不能错

MDK版本：必须使用MDK-ARM 5.27a或更高版本。低于此版本，ARMCC编译器对C99支持不全，lwip/src/core/ipv4/ip4.c中的for (int i = 0; ...)语法会报错。我试过5.26，编译失败；升级到5.27a后，一劳永逸。
Device Family Pack：安装Keil.STM32F4xx_DFP.2.16.0.pack。这是ST官方提供的设备支持包，包含F407的启动文件（startup_stm32f407xx.s）、系统初始化代码（system_stm32f4xx.c）和外设寄存器定义。安装方法：KEIL菜单 Pack Installer -> Check for Updates，搜索STM32F4并安装。
编译器选项：
Target页：Code Generation选ARM Compiler 5.06 update 6 (build 750)（即ARMCC）；
C/C++页：Define添加USE_STDPERIPH_DRIVER, STM32F407xx, __UVISION_VERSION__=527；Include Paths添加.\CMSIS\Include, .\STM32F4xx_StdPeriph_Driver\inc, .\LwIP\src\include, .\uCOS-III\Source\os_cfg.h所在路径；
Linker页：Use Memory Layout from Target Dialog勾选，Scatter File指定OS3.sct（这是uCOS-III专用链接脚本，它把RTOS内核代码放在Flash高地址，应用代码在低地址，防止覆盖）。

提示：OS3.sct是本工程的灵魂之一。它把__main入口点、Heap（堆内存）、Stack（栈内存）都做了显式分区。例如，LR_IROM1 +0x00010000表示应用程序代码从Flash偏移64KB处开始，为uCOS-III内核预留了前64KB空间。如果你用默认的STM32F407VE_FLASH.sct，编译能过，但运行必崩——因为uCOS-III的OSCfg_ISRStkBasePtr会被覆盖。

4.2 工程导入与目录结构梳理：看清“谁在调用谁”

解压资源包后，打开STM32F407.uvprojx。KEIL会自动识别项目结构。重点看Project窗口的分组：

User：你的应用代码，main.c是入口，app_tcp_server.c是TCP服务端逻辑；
CMSIS：ARM Cortex-M4内核支持，core_cm4.h等；
STM32F4xx_StdPeriph_Driver：ST标准外设库，stm32f4xx_eth.c是ETH驱动核心；
LwIP：LwIP 1.4.1源码，src/core/是协议栈核心，src/netif/是网卡接口；
uCOS-III：uCOS-III源码，Source/是内核，Ports/ARM-Cortex-M4/Generic/RealView/是ARMCC移植层；
BSP：板级支持包，bsp_eth.c实现了ethernetif_init()，bsp_led.c控制LED。

关键依赖链是：main.c -> app_tcp_server.c -> LwIP/src/api/tcpapi.c -> LwIP/src/core/tcp_in.c -> bsp_eth.c -> STM32F4xx_StdPeriph_Driver/src/stm32f4xx_eth.c。当你想查一个函数来源时，沿着这条链顺藤摸瓜，比全局搜索高效十倍。

4.3 关键配置修改：三处必须改的“硬编码”

工程默认配置是为正点原子探索者板定制的，但你需要根据你的实际环境微调：

IP地址配置（app_tcp_server.c第42行）：
c ip_addr_t ipaddr, netmask, gw; IP4_ADDR(&ipaddr, 192, 168, 1, 10); // 板子IP IP4_ADDR(&netmask, 255, 255, 255, 0); // 子网掩码 IP4_ADDR(&gw, 192, 168, 1, 1); // 网关（通常是路由器IP）
如果你的电脑IP是192.168.0.100，而板子设为192.168.1.10，它们不在同一网段，肯定ping不通。务必改成和你电脑同网段，比如192.168.0.10。
TCP监听端口（app_tcp_server.c第128行）：
c pcb = tcp_new(); err = tcp_bind(pcb, IP_ADDR_ANY, 5001); // 默认监听5001端口
如果你公司防火墙屏蔽了5001，或者你想用更常见的8080，就改这里。记住，端口号<1024是特权端口，普通用户程序无法绑定，所以选5001或8080最稳妥。
串口调试波特率（bsp_usart.c第65行）：
c USART_InitStructure.USART_BaudRate = 115200;
这个必须和你的串口调试助手（如XCOM、SecureCRT）设置一致。我见过太多人因为波特率设成9600，而助手设成115200，串口一片空白，以为程序没跑起来，其实是“鸡同鸭讲”。

4.4 真机下载与运行验证：四步法，快速定位问题

编译通过（0 Error, 0 Warning）只是开始。真机运行才是考验。按以下顺序验证：

第一步：串口输出
下载程序，打开串口助手，设置115200波特率。你应该立即看到：
[INFO] System Clock: 168MHz [INFO] ETH Init OK, MAC: 00:80:E1:00:00:00 [INFO] LwIP Init OK, IP: 192.168.1.10 [INFO] TCP Server listening on port 5001...
如果卡在ETH Init OK之前，检查DP83848供电（3.3V是否正常）、晶振（25MHz）是否起振、网线是否插稳。
第二步：Ping测试
在电脑CMD窗口输入ping 192.168.1.10。如果通，说明PHY、MAC、LwIP的ICMP协议栈工作正常。如果不通，但串口有输出，大概率是netmask或gw配置错误，或者电脑防火墙拦截了ICMP。
第三步：Telnet连接
CMD输入telnet 192.168.1.10 5001。如果成功，你会看到一个黑窗口，此时在键盘敲字，板子会原样回显（因为应用层逻辑是recv -> write）。这是TCP连接建立的铁证。
第四步：多客户端压力测试
打开3个CMD窗口，分别执行telnet 192.168.1.10 5001。在每个窗口输入不同内容（如Client1, Client2, Client3）。观察串口输出，应该依次打印：
Client 192.168.1.100:52345 connected Client 192.168.1.100:52346 connected Client 192.168.1.100:52347 connected
并且每个客户端都能独立收发。如果第3个连不上，检查MEMP_NUM_TCP_PCB是否足够，或用Wireshark抓包看是否收到SYN包但没回SYN-ACK（说明LwIP没响应）。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

即使严格按照上述步骤，你也可能遇到一些“玄学”问题。我把过去三年帮学员远程调试时，高频出现的7个问题整理成速查表，并附上独家排查技巧。这些问题，99%的官方文档都不会提，但它们真实存在，且往往让人抓狂一整天。

问题现象	可能原因	排查技巧	我的实操心得
串口无任何输出，但LED也不闪	1. BOOT0/BOOT1跳线错误（未设为从主闪存启动） 2. Flash下载失败（J-Link固件过旧）	用ST-Link Utility连接，看能否识别到芯片；若不能，重置BOOT引脚，或短接NRST引脚1秒	正点原子探索者板的BOOT跳线帽在板子背面，新手常忽略。我建议第一次烧录前，用万用表蜂鸣档测BOOT0对地是否导通（应为0Ω），这是最快确认方式。
能Ping通，但Telnet连接超时（Connection refused）	1. `tcp_bind()`返回错误（err != ERR_OK） 2. `tcp_listen()`未调用 3. 防火墙拦截了目标端口	在`app_tcp_server.c`的`tcp_bind()`后加`if(err != ERR_OK) { printf("[ERR] bind failed: %d\n", err); }`，重新编译下载	`ERR_USE`（地址已在使用）是最常见错误。原因是上次连接没正常关闭，PCB还在TIME_WAIT状态。解决方案：在`tcp_accept_callback()`里调用`tcp_close()`后，再调用`tcp_abort()`强制释放PCB。
单客户端正常，双客户端时第一个断开	1. `MEMP_NUM_TCP_PCB`不足 2. `PBUF_POOL_SIZE`太小，导致接收缓冲区耗尽	用uCOS-III的`OSStatReset()`和`OSStatTaskCreate()`创建统计任务，在串口周期性打印`OSTaskStkChk()`结果，看哪个任务堆栈快满了	我曾遇到一个案例：`AppTaskTCPServer`堆栈显示使用率98%，但没溢出。原因是`tcp_write()`内部调用`pbuf_alloc()`时，`PBUF_POOL_SIZE=16`刚好被两个客户端分完，第三个包到来时`pbuf_alloc()`返回NULL，导致`tcp_write()`失败，连接被静默关闭。把`PBUF_POOL_SIZE`调到24后，问题消失。
连接后能收不能发（客户端收不到回显）	1. `tcp_write()`后未调用`tcp_output()` 2. 发送缓冲区满（`tcp_sndbuf(pcb)`返回0）	在`tcp_recv_callback()`处理完数据后，强制加一行`tcp_output(pcb);`；并在发送前加`if(tcp_sndbuf(pcb) < len) { printf("Send buffer full!\n"); return; }`	LwIP的发送是异步的。`tcp_write()`只是把数据拷贝到发送缓冲区，`tcp_output()`才真正触发DMA发送。很多教程漏掉这一步，导致数据“卡”在缓冲区。
串口打印乱码（如`[INFO] System Clock: 168MHz`变成`[INFO] System Clock: 168MHz`）	1. 串口时钟源配置错误（APB2时钟没开） 2. `USARTDIV`计算错误	检查`RCC->APB2ENR`寄存器的`USART1EN`位是否为1；用示波器测USART1_TX引脚，看波形周期是否符合115200bps（约8.68μs/bit）	F407的USART1挂在APB2总线上，而APB2默认频率是HCLK/2=84MHz。`USARTDIV = (84000000 / (16 * 115200)) = 45.57`，取整后为45，小数部分用`DIV_Fraction`补偿。如果APB2时钟没使能，`USARTDIV`计算就全错了。
Wireshark抓包显示大量TCP Retransmission	1. PHY协商失败（半双工/全双工不匹配） 2. MAC接收缓冲区溢出（`ETH_DMARxDescFrameLength`异常）	用`ethernetif.c`里的`phy_read_reg()`读取DP83848的BMSR（0x01）和ANLPAR（0x05），确认Link和Speed字段	协商失败时，BMSR[14:13]会是`00`（10Mbps Half-Duplex），而MAC却按100Mbps Full-Duplex配置，必然丢包。解决方案：在`phy_init()`里强制写`ANAR=0x01E1`（只支持100M全双工），并关闭自协商（BMCR[12]=0）。
程序运行几分钟后死机，串口停在某一行	1. 内存泄漏（`mem_malloc()`后未`mem_free()`） 2. 信号量未正确释放（`OSSemPost()`缺失）	启用uCOS-III的`OS_CFG_MEM_EN`，创建内存分区，在`tcp_recv_callback()`里每次`malloc`后记录指针，在`free`时校验；用`OSSemPend()`的`timeout`参数，避免无限等待	我的一个学员的代码里，在`tcp_recv_callback()`中`malloc()`了一块内存解析JSON，但忘记在`tcp_err_callback()`中`free()`。运行几小时后，内存池耗尽，`malloc()`返回NULL，后续操作解引用空指针，HardFault。加了内存监控后，问题立现。

最后分享一个小技巧：当你遇到无法解释的问题时，不要急着改代码，先做“最小化验证”。例如，把AppTaskTCPServer任务暂时注释掉，只保留AppTaskLED，确认LED能稳定闪烁；再单独测试ethernetif_init()，用ping验证；最后才加入TCP逻辑。把复杂系统拆解为原子单元，是嵌入式调试的黄金法则。这个工程的价值，不仅在于它能跑起来，更在于它为你提供了一个清晰、可触摸、可调试的嵌入式网络全栈模型。当你能看着串口日志，说出每一行背后的寄存器操作、内存分配、任务切换时，你就真正入门了。

本文还有配套的精品资源，点击获取