企业官网建设流程全解析

简介：一份面向STM32F407开发者的以太网与LWIP协议栈实战资源包，涵盖固件库驱动到网络协议栈的完整代码，适合嵌入式初学者及希望在ARM平台实现联网功能的中级开发者。压缩包内共2000个文件，包括1041个头文件、881个C源文件和78个文本说明，头文件与C源文件构成HAL/LL驱动和LWIP主体，文本文件辅助配置阅读，整体大小28.86MB，结构清晰便于导入工程。已有447人学习与浏览，适用于工业控制、物联网设备及局域网通信等场景。资源重点展示硬件以太网MAC初始化流程，指导开发者设置MAC地址、子网掩码等网络参数，并基于LWIP建立TCP或UDP连接，同时提供DHCP、DNS等上层服务及HTTP服务器示例。通过研读这些代码，开发者可快速掌握在Cortex-M4平台上移植网络协议栈的方法，减少底层驱动调试时间，为毕业设计或产品原型验证提供完整参考。

1. STM32F407固件库里的LWIP以太网，究竟值不值得折腾

做物联网网关或者工业数据采集时，很多工程师第一反应是上Linux，但有些现场只需要把几十个字节的报文稳定传出去，单片机加一个以太网口就足够。STM32F407固件库里的ETH外设负责把MAC从芯片里拉起来，LWIP负责把TCP/IP协议栈跑明白，这份工程模板的价值在于：它把标准外设库、ETH驱动和LWIP缝合成一个能直接打开的完整项目，而不是让你从零对照数据手册拼寄存器。它不仅适合F407上需要联网的老项目迁移，也适合新手在现有硬件上快速验证协议栈。一句话说清定位：这是一条从寄存器配置到TCP通信都能复现的落地链路，踩坑点主要集中在时钟、内存和中断三个地方，提前知道能省掉一整周的排查时间。

2. 先看清ETH外设：固件库里以太网是怎么被拉起来的

2.1 三层分工：MAC、PHY、LWIP协议栈各管什么

F407芯片内部集成的ETH外设，本质上是一个以太网MAC控制器加上配套的DMA引擎，它不包含物理层收发器。也就是说，你必须在板子上外接一颗PHY芯片，MAC通过MII或RMII接口和PHY连接。PHY负责把数字信号变成差分信号送上网线，MAC负责组帧、校验、地址过滤，而LWIP负责的是更上层的事：IP分片重组、ARP缓存、TCP状态机、重传超时。这三层之间互相不认识，全靠固件库把MAC初始化好，再把LWIP收到的数据包交给DMA去收发。

很多人在F407上首次跑以太网时容易犯一个错误：把PHY和MAC混为一谈，以为换一颗PHY只要改引脚就行。实际上PHY的寄存器地址、复位时序、时钟来源甚至自动协商行为都不同，换PHY意味着驱动层要跟着改。固件库提供的ETH驱动只覆盖MAC本身，对PHY的操作通常还是直接用MDIO总线读写PHY寄存器来完成，很少能靠库函数一套通吃。

固件库和HAL库在以太网初始化上差异也很大。HAL库把DMA描述符、发送接收缓冲区都封装成结构体，你只需要调用HAL_ETH_Init。而固件库的做法是让你自己定义描述符数组和缓冲数组，然后把这些数组的地址填进初始化结构体。第二步有个隐藏要求：描述符必须放在DMA能访问的内存区域，并且按4字节对齐，否则传输一启动就是HardFault或者全乱码。

2.2 RMII还是MII：引脚减半，但参考时钟必须算清

STM32F407的ETH外设同时支持MII和RMII两种物理接口，芯片通过复用的方式把两组引脚映射到GPIO上，同一时间只能启用其中一种。MII需要16根信号线，TXD[3:0]、RXD[3:0]、TX_EN、RX_DV、TX_CLK、RX_CLK、CRS、COL再加MDIO和MDC；RMII把数据线砍到各2根，总共只需要9根信号线。引脚数量差了一半，对PCB布局和IO占用来说RMII优势明显，所以绝大多数F407开发板和自研板都选了RMII。

但这背后有个容易忽略的坑：RMII要求一个50MHz的参考时钟，这个时钟的方向必须明确。常见的两颗PHY芯片行为完全相反：LAN8720A这类PHY通过外部25MHz晶振在内部倍频，然后由PHY主动向MCU输出50MHz的REF_CLK；而DP83848这类PHY则需要MCU或者外部振荡器提供50MHz给它。方向搞反，PHY的链路状态寄存器可能都是正常的，但RMII接口上根本没有有效时钟，数据收发全部失败。

2.3 固件库初始化ETH的最小代码：结构体、时钟、MAC地址

在固件库工程模板里，ETH初始化一般分三步走：配置GPIO复用功能，配置MAC和DMA，最后配置MAC地址并启动。GPIO部分没有太多悬念，把对应引脚全部设成复用推挽输出，然后调用GPIO_PinAFConfig绑定到GPIO_AF_ETH。引脚分配以开发板原理图为准，下面这段是RMII模式下常见的一组配置。

// 以固件库（标准外设库）方式初始化ETH的GPIO，RMII模式 void ETH_GPIO_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; // 使能ETH用到的GPIOA/GPIOC/GPIOB时钟 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA | RCC_AHB1Periph_GPIOB | RCC_AHB1Periph_GPIOC, ENABLE); // 把RMII相关引脚全部复用为ETH功能 GPIO_PinAFConfig(GPIOA, GPIO_PinSource1, GPIO_AF_ETH); // PA1: RMII_REF_CLK GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_ETH); // PA2: MDIO GPIO_PinAFConfig(GPIOA, GPIO_PinSource7, GPIO_AF_ETH); // PA7: RMII_CRS_DV GPIO_PinAFConfig(GPIOB, GPIO_PinSource11, GPIO_AF_ETH); // PB11: RMII_TX_EN GPIO_PinAFConfig(GPIOB, GPIO_PinSource12, GPIO_AF_ETH); // PB12: RMII_TXD0 GPIO_PinAFConfig(GPIOB, GPIO_PinSource13, GPIO_AF_ETH); // PB13: RMII_TXD1 GPIO_PinAFConfig(GPIOC, GPIO_PinSource1, GPIO_AF_ETH); // PC1: MDC GPIO_PinAFConfig(GPIOC, GPIO_PinSource4, GPIO_AF_ETH); // PC4: RMII_RXD0 GPIO_PinAFConfig(GPIOC, GPIO_PinSource5, GPIO_AF_ETH); // PC5: RMII_RXD1 // 统一配置为复用推挽，速度50MHz，RMII对IO翻转速度有一定要求 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_7; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11 | GPIO_Pin_12 | GPIO_Pin_13; GPIO_Init(GPIOB, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_4 | GPIO_Pin_5; GPIO_Init(GPIOC, &GPIO_InitStructure); }

这段代码的逻辑很直接：RCC开时钟，AFIO绑定复用功能，然后GPIO_Init批量配置。注意PA1在别的外设里也被用作定时器通道，启用ETH之后这组引脚就不能同时给别的外设。GPIO_Speed设成50MHz是因为RMII的REF_CLK有50MHz，太慢的IO翻转速率会直接导致数据采样错误。

然后是ETH_MAC和DMA的初始化。

// 固件库ETH初始化：配置MAC模式、DMA描述符、MAC地址 void ETH_Config(void) { ETH_InitTypeDef ETH_InitStructure; // 打开ETH时钟，注意不是AHB1外设时钟，是单独的MAC时钟 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_Tx, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_Rx, ENABLE); // 使能PHY的MDIO时钟，MDC时钟由APB2分频得到 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_PHY, ENABLE); ETH_DeInit(); // 复位ETH模块，保证从干净状态开始 // 配置MAC核心参数 ETH_InitStructure.ETH_AutoNegotiation = ETH_AutoNegotiation_Enable; ETH_InitStructure.ETH_Mode = ETH_Mode_FullDuplex; ETH_InitStructure.ETH_Speed = ETH_Speed_100M; ETH_InitStructure.ETH_MediaInterface = ETH_MediaInterface_RMII; ETH_InitStructure.ETH_TxDesc = eth_tx_desc; // 描述符数组首地址 ETH_InitStructure.ETH_RxDesc = eth_rx_desc; // 接收描述符数组首地址 ETH_InitStructure.ETH_TxBufferLength = ETH_TX_BUF_SIZE; ETH_InitStructure.ETH_RxBufferLength = ETH_RX_BUF_SIZE; if (ETH_Init(&ETH_InitStructure) == ETH_SUCCESS) { // 设置MAC地址为单播MAC，02开头是本地管理地址，不会和真实网卡冲突 ETH_MACAddressConfig(ETH_MAC_Address0, eth_mac_addr); } // 启动DMA发送和接收 ETH_DMACmd(ETH_DMA_Tx, ENABLE); ETH_DMACmd(ETH_DMA_Rx, ENABLE); }

eth_tx_desc和eth_rx_desc这两个数组需要在文件作用域定义，常见的大小是ETH_TXBUFNB个描述符，每个描述符关联一块ETH_TX_BUF_SIZE大小的缓冲。固件库要求这些数组从4字节边界开始，所以定义时要用__align(4)或者放在独立的SRAM区里。

MAC地址的配置有一个容易被忽略的点：F407的MAC模块默认会对接收帧做地址过滤，全零MAC地址会导致过滤逻辑异常，多播地址（第一个字节最低位为1）又会导致只收组播不发单播。最稳妥的做法是使用02开头的本地管理单播地址，类似02:00:00:12:34:56，既能保证单播属性，又不会蹭到真实网络设备的厂商OUI。

3. LWIP移植的关键拼接：从驱动到能ping通

3.1 内存布局：为什么网卡DMA缓冲不能放在CCM

LWIP本身是一套独立于硬件的协议栈，它只关心内存、时间基准和一个能接收发送数据包的网卡驱动接口。移植LWIP到F407固件库工程里，最难的部分不是协议栈，而是把LWIP的netif接口和固件库的ETH驱动缝在一起。

动手之前先想清楚内存布局。F407内部有一块64KB的CCM内存，地址从0x10000000开始，它的特点是访问速度接近零等待，但是只有一个CPU内核入口，AHB总线上的外设全部访问不到它，包括ETH的DMA。如果你的网卡描述符、DMA缓冲区或者LWIP的pbuf池被链接到了CCM区域，最常见的结果是：程序启动后ETH初始化正常，PHY也能连上，但一收发数据就是内存乱码，甚至直接HardFault。

解决方法是把ETH相关数组明确放到0x20000000起始的SRAM区。固件库模板里已经做了这件事，但如果你在这个基础上跑FreeRTOS，还要注意任务栈和堆也不要往CCM里分配。很多带RTOS的LWIP模板会把系统堆放在启动文件里指定的Heap_Size，这个大小决定了tcpip_thread能否正常创建。建议保留模板默认的内存分配方案，至少要检查linker脚本里的RAM区间定义是否只包含了SRAM而排除了CCM。

内存对齐是第二个隐藏要求。ETH DMA描述符必须按4字节对齐，缓冲区的起始地址最好也对齐到4字节。固件库模板里用到__align(4)修饰数组，这是标准做法。如果你自己重写了描述符数组，不要省略这个修饰符，否则在某些编译优化级别下，数组地址从2字节边界开始，DMA就会在第一次收发时报总线错误。

3.2 low_level_init：网卡驱动怎么和一个协议栈对接

LWIP对网卡驱动的抽象是struct netif，netif_add时传入的init函数负责填充硬件信息和回调函数。在标准移植模板里，这个函数叫ethernetif_init，它内部又调用了low_level_init。low_level_init的核心职责有四个：设置MTU、设置MAC地址、注册linkoutput回调、准备好DMA描述符环。

// LWIP网卡驱动初始化：把固件库ETH驱动挂到netif上 static err_t low_level_init(struct netif *netif) { // 设置MAC地址长度和MAC地址内容，必须和固件库配置的一致 netif->hwaddr_len = ETHARP_HWADDR_LEN; memcpy(netif->hwaddr, eth_mac_addr, ETHARP_HWADDR_LEN); // MTU按照标准以太网帧来，1500字节 netif->mtu = 1500; // 网卡能力标志：支持广播、ARP、链路自动检测 netif->flags = NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_LINK_UP; // linkoutput负责把LWIP封好的帧发出去 netif->linkoutput = low_level_output; // DHCP或静态IP场景下由ARP拿到MAC后走etharp_output netif->output = etharp_output; // 初始化DMA描述符环，固件库在ETH_Init里已经做了一部分， // 这里需要把描述符的地址、状态位重新清一遍，防止热启动残留 for (int i = 0; i < ETH_RXBUFNB; i++) { eth_rx_desc[i].Status = ETH_DMA_RX_OWN; // 把描述符还给DMA } return ERR_OK; }

这段代码的要点在linkoutput和output两个回调。low_level_output（在模板里实现）做的事情是：把LWIP传入的pbuf链拆成一段一段连续内存，填入DMA描述符的缓冲区地址，然后触发DMA发送。理解和这个实现有助于排查发送超时的问题——如果你发现ARP能通但TCP很慢，先检查low_level_output里是不是把超长pbuf链拆错了。

数据接收方向由另一个函数负责。最常见的设计是裸机轮询：主循环里不断调用ethernetif_input(&eth_netif)，这个函数检查DMA接收描述符状态，有数据就把pbuf作为netif->input的参数交给上层。如果跑FreeRTOS，通常换成ETH中断里给信号量、独立线程里调用ethernetif_input，两种方式各有取舍。

3.3 最小配置表：一组能开机自通的LWIP参数

LWIP的lwipopts.h是移植过程中最容易被改坏的配置文件。模板自带的默认值往往基于大内存平台，而F407只有不到128KB可用SRAM，参数开得太大会直接编译不过，开得太小又会出现TCP连上但传数据就断的问题。下面这组参数是很多F407模板里的常见组合，适合裸机或带FreeRTOS的场景。

修改参数之后需要重新编译整个工程。这里有一个经验：PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE的乘积就是系统能缓冲的流量上限，如果板子在突发数据时会丢包，优先加大这两个，而不是去加大MEM_SIZE。MEM_SIZE堆再大，数据包没有足够的pbuf池也照样进不来。

裸机上把LWIP跑起来的启动代码很简单，核心是lwip_init、netif_add、netif_set_up三个步骤。注意netif_add的第四个参数指向一个和网卡绑定的状态结构体，模板里传的是NULL，大多数场景不需要额外状态，保持NULL即可。

// LWIP初始化：创建netif并设置IP地址，固定IP示例 struct netif eth_netif; ip4_addr_t ipaddr, netmask, gw; // 把IP地址拆成4段填入，顺序不能反 IP4_ADDR(&ipaddr, 192, 168, 1, 88); IP4_ADDR(&netmask, 255, 255, 255, 0); IP4_ADDR(&gw, 192, 168, 1, 1); // 1. 初始化协议栈内部内存和定时器 lwip_init(); // 2. 注册网卡，ethernetif_init是上一节写的驱动入口 netif_add(&eth_netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, ethernet_input); // 3. 把默认网卡指向eth_netif并启动 netif_set_default(&eth_netif); netif_set_up(&eth_netif);

裸机模式下，主循环还需要做两件事：周期性调用sys_check_timeouts()处理TCP超时重传，以及调用ethernetif_input(&eth_netif)轮询收包。如果跑的是FreeRTOS这类RTOS，这两个动作会被tcpip_thread和网卡接收线程替代。我在F407上裸机跑过一段时间，CPU占用率很低，但代价是代码结构里多了两个分散的调用点，忘记任何一个都会表现为“能发送但收不到回复”。

IP地址的规划也有讲究。模板里经常默认192.168.1.88，但如果你把开发板直接插到公司局域网，网关、子网掩码和本机IP一旦和局域网冲突，ARP就会一直得不到回应。调试初期建议用独立路由器或者直接把电脑网卡设成静态IP，和板卡放在同一网段，避免各种隔离策略干扰。

4. F407以太网跑不通？五个高频坑的排错记录

4.1 现象：网线插上Link灯亮，但MDIO读PHY ID失败，ping不通

Link灯亮说明PHY和网线变压器之间正常，但芯片读不到PHY ID，问题几乎都出在MDIO或RMII参考时钟上。MDIO读不到ID，先确认MDC时钟频率，MDC是由APB2时钟分频得到的，固件库ETH_Init里会根据APB2频率自动配置，但你要保证ETH时钟已经打开。RMII的REF_CLK方向反了也会出现类似现象，因为MAC没有时钟就无法完成和PHY之间的数据同步。

解决方法是先写一个比LWIP更早执行的PHY ID读取函数，用MDIO读PHY寄存器2和3，打印出来对比PHY数据手册上的值。这一步能同时验证MDIO总线和PHY上电状态。如果ID读出来是0xFFFF，基本是MDC或PHY地址不对；如果ID正确但ping不通，再回头查REF_CLK方向。我习惯在eth_init之前做这个检查，把潜在的硬件问题在协议栈启动前暴露出来。

4.2 现象：MAC地址配成了02开头，ARP还是不通

这个坑更容易出现在有人改过MAC地址的场景。固件库的ETH_MACAddressConfig设置的是MAC地址过滤器，LWIP的netif里还有一份MAC地址拷贝，两处必须保持一致。如果只改了一处，ARP请求到了MAC层会因为地址过滤不匹配被硬件丢弃，而网卡驱动以为自己已经把数据发出去了。

解决方法是把MAC地址定义成一个全局数组，固件库初始化和low_level_init都引用同一个变量，从源头上避免两份拷贝不一致。另外检查这个数组的第一个字节，最低位必须是0，否则就是多播地址，ARP应答根本不会进来。我踩过一次这个坑，当时把MAC地址写成了03开头，整整查了两天才意识到是多播位问题。

4.3 现象：ETH_DMACmd使能DMA后程序直接HardFault

典型原因有两个：一是DMA描述符或缓冲数组没有4字节对齐，二是数组被链接到了CCM区域。固件库模板里通常用__align(4)处理了第一个问题，但如果你改了启动文件里的内存布局，比如把大数组定义到了0x10000000段，ETH DMA一启动就会访问非法地址，MCU立刻进HardFault。

解决方法是先看map文件，确认eth_tx_desc、eth_rx_desc和缓冲数组的实际地址在0x20000000到0x2001FFFF之间，并且首地址末两位是0。如果地址不对，回到C文件把__align(4)加上，或者用attribute指定段。还有一个判断技巧：HardFault发生的时间点很关键，如果是ETH_Init之后就挂，基本就是描述符位置不对；如果是第一次发送数据才挂，可能是不小心把发送缓冲区也放进CCM了。

4.4 现象：FreeRTOS下TCP收发正常，串口打印偶尔卡顿，ETH中断不触发

F407的ETH中断号是ETH_IRQn，需要单独在NVIC里配置。很多人沿用HAL库里的习惯，把中断优先级设成了最高抢占优先级，结果在FreeRTOS里把所有任务都饿死了，现象是系统反应迟钝但TCP还能勉强跑。另有一种情况是中断服务函数里忘记清DMA中断标志位，导致中断标志一直挂着，ETH_IRQHandler反复进入但根本没完成收发流程。

解决方法是给ETH中断一个适中的优先级，比如抢占优先级5、子优先级0，确保它低于系统节拍中断，但高于普通外设中断。中断服务函数里用ETH_DMAClearITPendingBit把接收和发送的标志位清掉，再交给信号量或消息队列唤醒接收线程。另一个容易漏掉的细节是，调试时开着Keil的断点，如果断在ETH中断里不动，DMA描述符会被其他中断的执行打断，恢复运行时状态已经错乱，这种情况下出现任何怪问题都先别急着改代码。

4.5 现象：TCP连接一建立，立刻HardFault或者连接马上断开

这类问题十有八九出在tcpip_thread的任务栈大小上。LWIP在RTOS模式下会创建tcpip_thread，任务栈大小由TCPIP_THREAD_STACKSIZE控制。栈太小，TCP握手还没走完，栈就被压爆。很多模板里的默认值是256或512字节，这在F407上跑极简场景勉强够，但只要你打开netconn API或者加了DHCP，瞬间就崩。

解决方法是把TCPIP_THREAD_STACKSIZE调到1024甚至2048，并且真机测试时在栈顶填上固定值，任务运行一段时间后检查剩余量。LWIP的栈溢出和普通任务栈溢出表现不太一样，它不一定立刻HardFault，有时表现为连接建立后收几包数据就断，因为某个回调里栈帧太大把关键变量覆盖了。另外，如果你在recv回调里调用了阻塞型API，也要确认这个回调运行在tcpip_thread上下文中，栈需求会更敏感。

5. 从ping通到真正能用：一个TCP服务端的正确起步姿势

5.1 最小TCP echo server：验证链路通不通的关键代码

ping通了只说明ARP和ICMP链路正常，TCP的收发送缓冲、窗口管理、分段重传全是另一套逻辑，需要单独验证。最稳妥的验证方式是一个TCP echo server：客户端发什么，服务端原样回什么。它能同时覆盖收、发、窗口更新、pbuf释放四个核心路径。

// 最简TCP echo server回调实现 static err_t echo_recv_cb(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (p == NULL) { // p为NULL表示对端关闭连接，这里释放pcb并返回 tcp_close(tpcb); return ERR_OK; } // 1. 先把收到的数据写入发送缓冲 // 最后一个参数1表示允许在发送缓冲满时排队，防止频繁超时 tcp_write(tpcb, p->payload, p->len, 1); // 2. 立即触发发送，避免等TCP定时器超时 tcp_output(tpcb); // 3. 告诉协议栈这段数据已经处理完，可以更新接收窗口 tcp_recved(tpcb, p->len); // 4. 释放pbuf，这一步漏掉会造成内存池泄漏 pbuf_free(p); return ERR_OK; }

service开始监听的代码有三个关键步骤：tcp_new、tcp_bind、tcp_listen。bind的IP地址是IP_ADDR_ANY，端口选一个不容易冲突的高位端口，比如6000。accept回调里不需要额外处理连接状态，在echo场景下，accept回调只需要返回ERR_OK，真正收数据的地方就是echo_recv_cb。这个实现把tcp_write放在tcp_recved前面，先尝试发送再释放窗口，好处是发送缓冲满时不会出现窗口已经更新但数据还没写进缓冲的竞态。

裸机环境下这个回调跑在主循环或以太网中断的上下文里，一定不要在里面调用延时函数。TCP重传机制本身是靠sys_check_timeouts驱动的，如果你在回调里加了一个毫秒级延时，整个协议栈都会跟着停顿，客户端就会出现规律性的超时重传。

5.2 收发缓冲参数怎么调：TCP_MSS、PBUF池、窗口大小

TCP收发性能的瓶颈在内存，不在CPU。F407跑在168MHz，对于100Mbps以太网来说CPU完全够用，真正限制吞吐的是pbuf池不够大和TCP窗口太小。TCP_MSS建议保持1460，这是MTU 1500减去IPv4头20字节再减去TCP头20字节后的最大值，调小会降低单包效率，调大则可能让IP分片，性能反而更差。

接收路径上最关键的参数是PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE。每个接收到的以太网帧都会占用一个pbuf，PBUF_POOL_SIZE决定同时能缓冲多少帧。如果客户端用大包连续发送，接收方向的pbuf池会被瞬间占满，后续帧直接丢弃。TCP_WND决定对端在没有收到ACK前最多能发送多少数据，建议设为TCP_MSS的两倍或四倍，也就是2920或5840字节，这样能充分利用窗口而不至于让缓冲压力过大。

发送路径上TCP_SND_BUF和MEMP_NUM_TCP_SEG是协作关系。TCP_SND_BUF是发送缓冲区总量，MEMP_NUM_TCP_SEG是能同时存在多少个待发送分段。每个分段都有自己的TCP头信息，分段池不够时tcp_write会返回ERR_MEM，客户端表现为发送阻塞。实际调试中，我一般先跑echo测试，通过串口打印tcp_write的返回值，只要出现ERR_MEM就按两倍步进加大MEMP_NUM_TCP_SEG，直到连续收发一整天不再报错。

5.3 性能验证别只看ping：用工具测吞吐，看丢包和延时

ping通说明链路可达，但说明不了链路能承载多少业务流量。我验证F407以太网性能通常分三步：第一步用Wireshark观察ARP和ICMP交互，确认没有重传；第二步用PC端TCP调试工具建立echo连接，连续发送10万包长度不等的随机数据，在板端串口打印正确回显的包数；第三步才谈吞吐——用一个固定大小的TCP窗口连续发送，记录每秒收包数。

第三步有一个常见误区：PC端的TCP调试工具在大学物理层已经把大包分片了，板端收到的包数会远小于发送包数，这不一定是F407的问题。更好的做法是在板端自己统计：每次tcp_recv回调收到的字节数累加，配合一个1ms的定时器，就能算出实际的接收吞吐。当这个数值稳定在900Mbps以下正常，F407的100Mbps网口受限于RMII和DMA效率，跑到80Mbps以上就算正常，低于50Mbps才需要怀疑PBUF池或者描述符数量不够。

丢包测试更直接：PC端一次性发送10000个包，每个包带独立序号，板端只统计序号间隙。如果丢包率超过万分之一，先看以太网PHY的链路质量——很多丢包不是MCU问题，是网线或者变压器焊接虚焊造成的。我遇到过一块板子丢包率奇高，换了一根短网线就完全正常，这种硬件层面的问题在参数调整之前就该排查掉。

6. 进阶：这套固件库方案能做到什么程度

把这套F407固件库加LWIP的模板从ping通推进到真实可用，通常只需要两步：给协议栈配一个DHCP客户端让板卡自适应局域网，或者直接固定IP跑一个应用层协议。工业场景里Modbus TCP是开销最小的选择，LWIP的raw API完全能承载一个从站协议，不需要额外引入RTOS线程，一个listen回调加一个recv回调就能实现整帧处理和响应拼装。跑FreeRTOS时则简单很多，netconn API已经把tcpip_thread的交互封装好了，你只需要在任务里阻塞等待连接和数据。

换到自己做的板子上时，改动清单通常只有四处：PHY芯片型号决定MDIO读ID的时序，RMII参考时钟方向决定RCC配置，PHY复位引脚决定上电顺序，MAC地址决定局域网兼容性。这四处里最花时间的往往是PHY复位，有的板卡把PHY复位和MCU复位绑在一起，看似省事，但PHY在上电后需要几十毫秒完成初始化，如果MCU在它之前就发起MDIO访问，第一笔读写就会丢失。我的习惯是给PHY复位引脚单独接一个GPIO，上电后先拉低再拉高，等100毫秒再做MDIO操作，这套流程能让几乎所有的PHY稳定进入工作状态。

另一个进阶方向是让LWIP跑带操作系统版本，把ethernetif_input从主循环里挪到一个独立线程里，ETH中断只负责释放信号量。这样做的收益是接收路径的阻塞时间变短，不会再出现大量数据突发时主循环处理不过来导致丢包。代价是内存压力上升，tcpip_thread和网卡接收线程各需要一组栈空间，再加上LWIP的pbuf池，整体内存占用会多出10KB以上。F407的SRAM对跑一个TCP server来说够用，但如果你想同时跑一个HTTP服务器加一个MQTT客户端，内存规划就要重新做一遍，建议保留至少20KB的余量。

验证方法建议保留一份长久有效的自测脚本：固定IP下用PC连续echo 10万包，统计丢包率；再开一个Wireshark同时抓包，确认没有TCP快速重传。这两项都稳定通过，这套固件库方案就具备了上真实项目的基础。我个人的习惯是每次移植完成都把这份自测结果存成一条串口日志，后续再动内存和中断相关的代码，都拿这次结果当基准对照。以太网这类问题出现得比较隐蔽，很多时候不是靠看代码想到的，而是靠对比前后两次测试结果定位的，希望这套排查路径能帮到你少走几步弯路。

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