简介：针对STM32F407外接LAN8720A的常用硬件组合，使用STM32CubeIDE整合FreeRTOS与LwIP协议栈，实现TCP Server网络数据与串口数据双向透传的完整开发资料。资源面向需要快速落地MCU联网功能的嵌入式工程师，尤其适合参考典型PHY芯片方案进行项目原型验证，可有效缩短从外设配置到网络通信调通的周期。包内共971个文件，以C/C++源码、头文件、CubeIDE工程配置文件（.ioc/.cproject/.ld）和PDF详解文档为主，同时包含编译中间文件、调试记录及启动相关文件，压缩包整体32.83MB。文档和工程相互对照，从CubeMX配置到代码实现均有说明，覆盖时钟树配置、ETH外设初始化、PHY复位引脚处理、FreeRTOS任务划分、LwIP参数设置，以及TCP客户端与TCP服务端两种角色初始化代码，并给出PC端IP设置、ping包测试和网络调试助手联调实测记录，目录划分清晰，便于按模块查阅。已有391人学习，适合希望基于STM32F407+LAN8720A快速搭建TCP透传通道的开发者直接参考或二次开发。 干了这么多年嵌入式，我发现自己最常被问到的组合就是：STM32F407 + LAN8720A + FreeRTOS + LwIP，目标是做一个TCP Server，把网络数据转成串口数据下发出去。这套组合之所以这么多人用，是因为F407自带以太网MAC，加上一颗几块钱的LAN8720A PHY芯片，就能让设备以极低的成本稳定接入局域网，再配合串口跟下位机通信，本质上就是一台简易的协议转换网关。
我最早是在正点原子的探索者板子上跑通这套方案的，当时用的还是Keil+标准库。后来项目要量产，需要换到STM32CubeIDE+HAL库+LwIP的现代工具链，按CubeMX自动生成的代码写起来确实比手撸寄存器轻松不少，但中间踩的坑也不少——时钟源配置、PHY地址、FreeRTOS任务优先级、数据转发丢包，每个环节都能折腾你一整天。
这篇文章我不打算重复CubeIDE的操作手册，而是把从零搭建到最终跑通的完整过程、以及那些文档不会写清楚的技术细节全部梳理一遍。适合手里有F407开发板、准备做以太网通信，或者已经生成好CubeMX工程但数据打通不了的读者。
1. 先理清这套方案的硬件底细：引脚映射和时钟源是第一个大坑
网上关于F407以太网的教程一抓一大把，但很多都卡在同一个地方：硬件连好了，网络却始终ping不通。原因九成不是代码问题，而是时钟源和引脚映射没配对，尤其RMII接口对硬件接线的要求非常严格。
1.1 RMII接口为什么省引脚，也为什么难配
F407内置的以太网MAC支持MII和RMII两种接口模式，用RMII可以省掉一半引脚，所以LAN8720A这种PHY芯片配合RMII几乎是标配。RMII只需要TXD0/TXD1、RXD0/RXD1、TX_EN、CRS_DV、REF_CLK这七根信号线，比MII少了一堆。
但这七根线在F407上的位置是固定的，你不能随便接。最常见的一组RMII映射是：
- PA1：REF_CLK，50MHz参考时钟
- PA2：MDIO，管理接口数据线
- PA7：CRS_DV，载波侦听/数据有效
- PC4：RXD0，接收数据位0
- PC5：RXD1，接收数据位1
- PG11：TX_EN，发送使能
- PG13：TXD0，发送数据位0
- PG14：TXD1，发送数据位1
- PB13：MDC，管理接口时钟
我在CubeMX里配置完RMII后，跟原理图一比对，发现PA1这一根没接对，导致REF_CLK没信号，PHY芯片完全不工作。很多开发板的原理图上REF_CLK是PHY芯片自己输出给MCU的，有些则是MCU输出给PHY的，这两种接法在CubeMX里的配置方向完全不同，必须查清楚自己板子的接线方式再动手。
1.2 50MHz时钟：到底谁给谁
这是整个硬件初始化里最容易被忽略的一环。LAN8720A的REF_CLK需要50MHz的参考时钟，而F407虽然有MCO1和MCO2可以输出时钟，但MCO输出到PA8或者PC9再给LAN8720A，会增加一个引脚开销。更常见的做法是用LAN8720A自带的25MHz晶振，让PHY芯片内部通过PLL倍频出50MHz，再从它的CLK_OUT引脚反馈给MCU的PA1。
在CubeMX中，当你选择RMII模式后，软件上还需要在以太网配置里正确选择PHY的时钟源。如果板子上的REF_CLK是从PHY反馈回来的，那么CubeMX只需要把PA1配置为ETH_RMII_REF_CLK复用功能即可。千万别在主时钟树里把MCO1打开去输出50MHz，那样反而会和PHY反馈的时钟打架，导致系统时钟错乱。
这里有个简单的判断方法：看LAN8720A的X1/X2引脚上接的是25MHz晶振还是50MHz有源晶振。如果是25MHz晶振，说明PHY内部有PLL，REF_CLK大概率是PHY输出给MCU的；如果是50MHz有源晶振，那MCU和PHY可能共用外部时钟，配置思路又不一样了。我建议你拿到一块板子时，第一时间做两件事：量PHY的CLK_OUT引脚有没有50MHz波形，再用示波器确认PA1上有无时钟输入。没有这两步，后面写多少代码都是白搭。
2. CubeMX初始化里最容易埋雷的配置点：PHY地址和延时时序
第一次用CubeMX生成F407+LwIP工程时，我几乎把默认参数全用了，结果PHY读不到ID，网络死活起不来。后来翻LAN8720A的数据手册，才发现PHY地址和复位时序都存在问题。
2.1 PHY地址为0还是为1，取决于你的硬件
CubeMX里有一个"PHY Address"选项，默认是0。这对LAN8720A来说通常是对的，因为LAN8720A的PHYAD0引脚内部下拉，默认地址就是0。但如果你的板子把PHYAD0拉高了，那地址就是1。
我当时在自制的板子上，PHYAD0悬空没接，LAN8720A内部下拉生效，地址为0，和CubeMX默认值匹配。后来给另一个客户做的板子，硬件工程师把PHYAD0接VCC，立方体MX里还是填0，于是MDIO通信全部失败。这类问题不会报编译错误，只会表现为网络初始化卡死或者link状态永远为down，排查起来特别隐蔽。
最好在初始化代码里加一段PHY ID读取，LAN8720A的PHY ID寄存器地址是2和3，读出来应该分别是0x0007和0xC0F1。如果读到的全是0xFFFF，说明MDIO通信没建立，优先检查PHY地址和MDIO引脚配置，而不是去查LwIP协议栈。
2.2 上电复位时序，差50ms都不行
LAN8720A的复位引脚通常接到MCU的某个GPIO上。硬件上电后，PHY需要一段稳定时间才能响应MDIO，而F407那边可能早就跑起来开始读PHY寄存器了。如果你在CubeMX的以太网配置里没有把复位引脚处理妥当，就会出现"偶尔能联网，偶尔不行"的怪现象。
我的做法是在主程序初始化以太网之前，用GPIO手动控制复位：
void LAN8720A_Reset(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_RESET); GPIO_InitStruct.Pin = GPIO_PIN_0; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_RESET); HAL_Delay(100); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_SET); HAL_Delay(200); }注意两个延时：拉低复位脚后至少保持100ms让PHY完成内部上电复位，拉高后至少要等PHY启用时钟稳定，我一般给200ms。有些资料说50ms就够，但实际量产和开发时，延时留足一点能省掉很多"偶发连不上"的麻烦。整个过程本质是等待PHY内部上电时序完成，急不得。
3. FreeRTOS任务划分：网络线程、串口线程和优先级怎么排才不打架
CubeMX可以一键生成FreeRTOS+LwIP的工程，但生成出来的默认任务结构只保证能编译通过，离"稳定转发数据"还差着一大截。任务划分和优先级设置才是真正影响系统健壮性的地方。
3.1 至少需要三个任务
我的工程里在默认的tcpip_thread和ethernetif_thread之外，又建了三个任务：
| 任务名 | 优先级 | 栈大小 | 功能 |
|---|---|---|---|
| tcp_server_task | 正常优先级 | 512字 | 创建TCP Server，接受连接，接收网络数据 |
| uart_tx_task | 正常优先级 | 256字 | 从网络接收环形缓冲取数据，通过串口发送 |
| uart_rx_task | 略高优先级 | 256字 | 从串口接收环形缓冲取数据，通过TCP发送 |
注意这里的优先级顺序：网络协议栈的tcpip_thread优先级要高于普通任务，因为LwIP内部的数据包处理都在这个线程里。但你的业务任务不能比它高太多，否则一旦业务繁忙，协议栈数据包处理被抢占，网络吞吐就会崩。
串口接收任务的优先级我设得比TCP服务器任务高一点。原因很简单：串口数据如果接收不及时，硬件FIFO会溢出丢数据；而网络数据有协议栈缓冲和TCP重传机制兜底，晚一点点处理并不会丢。这就是FreeRTOS任务优先级设计的核心原则：把不能等待的数据源放前面，把可以缓冲的数据源放后面。
3.2 栈大小别再拍脑袋了，用系统自带检测
CubeMX默认给FreeRTOS任务分配的栈可能是128字，跑个简单GPIO翻转还行，跑LwIP调用链就等着溢出。我习惯在每个任务的while循环里加一个uxTaskGetStackHighWaterMark调用，把剩余栈的最小值打印出来，然后用"剩余值的三倍"来调整栈大小。
UBaseType_t highWaterMark = uxTaskGetStackHighWaterMark(NULL); printf("tcp_server_task stack high water: %d\n", highWaterMark);实测下来，tcp_server_task调用netconn_recv时，一个正常栈至少要512字。如果你开了较多LwIP调试输出或者用了snprintf之类的格式化函数，栈需求会直接翻倍。栈给少了，系统跑几天突然HardFault，查起来比改配置痛苦一万倍。
3.3 信号量还是队列，我推荐队列
串口和网络之间的数据传递，很多人喜欢用全局数组加标志位，这在裸机时代没问题，进了RTOS就容易出现竞争。FreeRTOS的队列机制天然就是线程安全的，读写两端一个阻塞等待、一个发送，配合中断里用FromISR版本函数，几乎不用额外加锁。
我实际用的方案是：串口接收中断里，把数据字节写入FreeRTOS队列，网络发送任务阻塞在队列读取上；网络接收回调里，把数据写入另一个队列，串口发送任务阻塞读取。这样两个方向的数据流完全解耦，各跑各的，不会互相抢资源。
4. 用netconn API写TCP Server：比socket更省心，比裸回调更直观
LwIP提供三种API：原始回调API、netconn API和socket API。在FreeRTOS环境下，netconn API是最平衡的选择。socket API在大内存系统上很舒服，但F407只有192KB RAM，多开几个socket就捉襟见肘；原始回调API性能最高，但代码写成状态机嵌套，维护起来容易让人崩溃。
4.1 netconn_server的核心流程
下面是我在tcp_server_task里跑的主逻辑，省略了错误处理细节，但完整展示了netconn API的使用顺序：
void tcp_server_task(void *argument) { struct netconn *conn = NULL; struct netconn *newconn = NULL; struct net_buf *buf = NULL; err_t err; ip_addr_t local_ip; IP4_ADDR(&local_ip, 192, 168, 1, 100); netconn_bind(conn, &local_ip, 8080); conn = netconn_new(NETCONN_TCP); if (conn == NULL) { vTaskDelete(NULL); } err = netconn_bind(conn, IP_ADDR_ANY, 8080); if (err != ERR_OK) { netconn_delete(conn); vTaskDelete(NULL); } err = netconn_listen(conn); if (err != ERR_OK) { netconn_delete(conn); vTaskDelete(NULL); } while (1) { err = netconn_accept(conn, &newconn); if (err == ERR_OK) { // 处理这个连接直到对方关闭 while (1) { err = netconn_recv(newconn, &buf); if (err != ERR_OK) break; // 把buf里的数据发送到串口 // 这里用队列通知uart_tx_task netbuf_delete(buf); } netconn_close(newconn); netconn_delete(newconn); } } }几个关键节点要说明：
netconn_bind的IP可以指定本机地址，但客户端连的时候用的也是这个IP。如果想自动获取IP，就用DHCP，绑定地址填IP_ADDR_ANY即可。netconn_listen只做一次，放在while外面。netconn_accept是阻塞调用，没有客户端连接时，这个任务会挂起不占CPU，完全符合RTOS的省电哲学。netconn_recv读到的buf可能是链式缓冲，遍历的时候要用netbuf_first和netbuf_next，别直接当线性buffer访问。
4.2 多客户端怎么办：单连接先跑通，再做accept循环
如果你只需要一个TCP客户端来连接，上面的代码足够了。但真实场景里，往往有设备端、调试端多个连接同时访问。netconn的accept循环天然支持多次accept，你可以在每次accept后创建一个专门的客户端处理任务，把newconn传进去，由那个任务单独收发。
要注意的是，每个连接任务都要有自己的栈，F407的资源有限，我一般限制最多4个并发连接。超出就netconn_close新来的连接并打印日志，避免资源耗尽。
5. 数据的双向流转：打破"网络到串口"单向思维
标题写的是"网络数据转串口数据"，但实际项目里十有八九是双向的：上位机通过TCP下发指令给设备，设备通过串口上报数据给上位机。如果你只做单向，回头加反向通道时又要大改结构，所以我从一开始就按双向设计。
5.1 两个环形缓冲加两个队列，数据流不乱
整个数据流我用四个核心对象管理：
queue_net_to_uart：网络收到的数据放入此队列，串口发送任务取出并通过串口发出。queue_uart_to_net：串口收到的数据放入此队列，网络发送任务取出并通过TCP发出去。
串口接收用中断方式，每收到一个字节就调用xQueueSendFromISR，把数据压入queue_uart_to_net。这个函数可以在中断里安全调用，只有队列满时才返回errQUEUE_FULL。队列长度我设成256，配合串口波特率115200，给网络发送任务足够的反应时间。
网络收发的处理就依赖netconn API本身的阻塞特性：netconn_recv阻塞等待数据，收到后压入queue_net_to_uart；netconn_write则直接把queue_uart_to_net里的数据打包发送。
5.2 串口发送的串口锁问题
很多人刚开始会把串口发送写在多个任务里，最后发现字符交错、数据乱码。正确的做法是：所有串口发送操作集中到一个任务里，通过队列串行化。即使你有多个数据源要发送，也统一先压队列，由uart_tx_task独占串口外设，这样根本不需要加互斥锁，因为原子性由队列保证了。
这里有个血泪教训：千万别在多个FreeRTOS任务里直接调用HAL_UART_Transmit，即使你确保同一时刻只有一个任务调用，HAL的阻塞发送也会拖住整个调度，导致网络任务饿死。串口发送统一走队列+独立任务，是我在这类网关项目上的固定套路。
6. 联调排错：从ping不通到TCP连不上，完整排查链路
就算代码全写对了，第一次上电联调大概率还是会有问题。我把实际调试中遇到的高频故障整理成一份排查路径，按照这个顺序找问题，能省下大量盲试时间。
6.1 先确认PHY层：link状态是down，代码不用往下看
拿到运行中的设备，第一件事不是改代码，而是看串口打印里PHY的link状态。CubeMX生成的代码里会打印Link is up或者Link is down。如果一直是down，排查顺序是：
- 用示波器量LAN8720A的CLK_OUT引脚，无波形说明PHY没起振，查晶振和电源。
- 量复位引脚电平，确保PHY不在复位状态。
- 读PHY的Basic Mode Status寄存器（地址1）的bit2，确认自动协商是否完成。
- 检查RMII引脚映射，特别是TX_EN和CRS_DV这两根，接错就完全不通。
6.2 能ping通但TCP连不上：看LwIP的监听状态
如果ping通了，说明IP层和ARP已经正常，TCP连不上往往是应用层问题。我用STM32CubeIDE的调试器直接暂停在tcp_server_task里，查看conn->state是什么。如果一直停在LISTEN状态，说明代码确实在监听，只是accept没被触发，那就要检查客户端是否连对了IP和端口；如果state变成了CLOSE_WAIT，说明连接建立过但被异常关闭，大概率是客户端没发数据就断开了。
6.3 串口数据乱码或丢字节：多半是FIFO溢出
串口转发数据出现丢字节，最常见的原因是HAL_UART_Receive_IT只使能了一个字节的接收中断，数据稍多就顾不过来。更好的方案是用DMA+空闲中断，听起来复杂，但CubeMX里配置其实很顺。
// 开启DMA接收，缓冲区256字节，串口空闲时触发中断 HAL_UART_Receive_DMA(&huart2, uart_rx_buf, 256); __HAL_UART_ENABLE_IT(&huart2, UART_IT_IDLE);在UART_IDLE中断回调里，计算当前DMA接收了多少字节，把数据压入queue_uart_to_net，再重新开启DMA接收。这样串口不管来多少字节，只要在DMA缓冲区大小范围内，一个都不会丢。唯一要注意的是DMA缓冲区里的数据必须先完整拷贝出来，再清空缓冲区指针，否则新数据会覆盖未处理的旧数据。
6.4 TCP传输速度上不去：查LwIP内存和窗口
实测下来，默认配置的LwIP在F407上，TCP吞吐量大概在2~4Mbps，做一个低频传感器数据上传、命令下发已经绰绰有余。如果非要跑更高吞吐，可以做两件事：
- 在
lwipopts.h里把TCP_WND从默认的2048调到8192，接收窗口变大，吞吐量会明显提升。 MEM_SIZE如果太小，分配大包时会失败，表现为连接建立后一传送就断。- 把以太网描述符数量
ETH_RX_DESC_CNT配置成8个以上，丢包率会下降不少。
F407的CCM RAM是一块不经过AXI总线、专供CPU访问的高速内存，可以把LwIP的PBUF池分配到那里，实测对吞吐提升有帮助。不过要特别注意，CCM RAM不能被DMA访问，所以不能存放以太网描述符或者DMA缓冲区，只能放协议栈内部的PBUF结构。很多人不了解这个限制，直接把整个LwIP堆放到CCM，结果网络直接跑崩。
7. 基于实际项目的几个补充说明
现在这套方案已经在我手头的协议转换设备上稳定跑了大半年，中间遇到过一些场景性问题，这里做几个补充。
7.1 波特率自适应怎么处理
我的设备需要适配9600到921600各种波特率的下位机。最笨的办法是每次手动改代码重新编译，后来我加了一个简单的串口命令解析功能：上位机通过TCP发送特定格式的命令，比如AT+BAUD=115200，设备收到后保存到EEPROM，重启后用新波特率初始化串口。这样在产线上就不用反复刷固件了。
7.2 断线重连和看门狗
TCP连接在长时间空闲时，偶尔会被运营商或者交换机断开，但设备这边不知道，还傻傻地等。我的做法是在tcp_server_task里加入定时器，如果5秒内没有收到任何TCP数据，就主动关闭连接，重新回到accept等待状态。配合FreeRTOS的软件定时器实现，非常简单。另外，主循环里别忘了喂独立看门狗IWDG，防止某次协议栈卡死导致设备彻底失联。
7.3 日志和在线调试
量产项目最怕现场黑盒问题。我在设备里保留了一个很小的调试串口，把PHY状态、TCP连接状态、队列使用率定期打印出来。调试口的输出频率要克制，最好用周期任务每秒打一次，否则在高频日志输出时反而会影响主业务的时序。这台设备的调试串口日志，帮我远程定位过三次现场问题，全都是PHY没有link导致的。
这套F407+LAN8720A+FreeRTOS+LwIP的TCP转串口方案，本质上没有太玄乎的技术，难的是把硬件时钟、驱动时序、RTOS调度、协议栈配置和数据通路这五个环节全部咬合好。你在自己项目上跑通后，会发现后续无论是加Modbus解析、增加Web配置页面，还是往TCP里叠加TLS，都是在这套骨架上添砖加瓦。希望这篇过程详解能帮助你少走几个我走过的弯路，一次点亮网络链路。
本文还有配套的精品资源，点击获取
