STM32F407与LAN8720嵌入式以太网方案：FreeRTOS+LWIP实现UDP通信

简介：一套基于正点原子STM32F4探索者开发板，使用标准库和MDK5构建的FreeRTOS+LWIP 1.4.1网络工程，核心功能包括DHCP动态获取IP与UDP数据收发，以LAN8720作为物理层收发器，面向需要快速搭建嵌入式以太网通信的开发者，解决LWIP协议栈在FreeRTOS上的适配、驱动及验证问题。压缩包共548个文件，以156个H头文件和138个C源文件为主，同时包含axf、hex、map、lst等编译输出与uvprojx、uvoptx、sct等MDK配置，还附带readme说明、clean脚本等，整体仅16.1MB。工程参考了ALIENTEK LWIP开发手册和社区移植笔记，在FreeRTOS多任务环境中挂载LWIP网络任务，并完成LAN8720的PHY驱动配置；资源保留完整启动文件、库文件和链接脚本，便于对照学习DHCP状态机、UDP接口回调、LWIP内存堆调整、任务优先级以及收发流程。目前已有1617人学习下载，适合嵌入式工程师、毕业设计及电赛备赛者，既可作为STM32F407网络开发的基础工程修改复用，也是研究RTOS与TCP/IP协议栈协同工作的实用样例。

1. 这套组合盘活了什么：STM32F407 以太网方案的选型真相

STM32F407 自带 MAC 控制器，但物理层还得靠一颗 PHY 芯片，标题里这颗 LAN8720 就是最常见的百兆 PHY；再配上 FreeRTOS 管任务、LWIP1.4.1 管网络协议栈、DHCP 免去手动配 IP、UDP 做轻量收发，最后用标准库在 MDK5 里完成编译下载——这套组合几乎是入门嵌入式以太网最成熟的路线。

它解决的核心问题是：让一颗不带操作系统的单片机，在跑实时任务的同时，稳定地完成网络报文的收发，而不需要去啃 Linux 那一整套网络栈。适合的人也很明确——做物联网网关、设备远程升级、数据采集终端，或者在学校实验室里想快速验证网络通信方案的开发者。很多人在这一步会纠结要不要换 HAL 库、要不要上最新版 LWIP，但我直接说结论：这套配置老归老，却是网上资料最多、翻车后最容易找到答案的搭配。先把这条路走通，再去考虑更现代的方案。

2. 硬件先立住：F407 与 LAN8720 的 RMII 连接和时钟选型

2.1 RMII 接口的 7 根线怎么接：从 F407 引脚到 LAN8720

STM32F407 的以太网 MAC 支持 MII 和 RMII 两种接口。MII 需要 16 根数据线，RMII 只要 7 根，减少引脚占用是选 RMII 的第一理由。

RMII 的数据线宽度是 2 位，时钟固定为 50MHz。STM32F407 的 RMII 接口信号分配是固定的，不能任意映射，这是硬件设计时最容易出错的地方。常见的对应关系是：TX_EN 走 PB11，TX_D0 走 PB12，TX_D1 走 PB13，RX_D0 走 PC4，RX_D1 走 PC5，CRS_DV 走 PD8，MDC 走 PC1，MDIO 走 PA2，REF_CLK 走 PA1。LAN8720 那边则是 ETH_RXER 脚必须接地，否则芯片会进入错误的模式。

LAN8720 的物理地址由 PHYAD0 引脚决定，一般将 PHYAD0 接地，地址就是 0x00。MDIO 在 STM32 标准库的以太网驱动里会被读出来用于 PHY 通信，如果读不到 ID，多半是 MDIO 的时序或引脚复用没配好。

2.2 50MHz 参考时钟的两种来源：MCO 输出还是外部晶振

LAN8720 的 REF_CLK 必须由外部提供 50MHz 时钟，它自己不能产生。STM32F407 这边有两种常见做法：一是用 PA8 复用功能输出 MCO，把 PLL 分频后的 50MHz 引给 LAN8720；二是直接用一颗 50MHz 有源晶振同时喂给 STM32F407 的 REF_CLK 引脚和 LAN8720。

我一般建议用 MCO 输出，理由比较实际：少一颗晶振，BOM 成本低一点，而且 F407 的 PLL 配置在初始化时已经固定，MCO 分频系数只要算好就行。MCO 输出的时序抖动在绝大多数应用场景下不会导致丢包，除非你在做极端苛刻的电磁兼容测试，否则不用专门上高精度有源晶振。

MCO 输出 50MHz 的关键是 PLL 配置。常见时钟树配置为：外部 8MHz 晶振，PLLM=8，PLLN=336，PLLP=2，得到 168MHz 系统时钟；此时 PLLQ=7，得到 48MHz，不是 50MHz。需要调整 PLL 参数，让系统时钟保持 168MHz 的同时，PLLQ 分频出 50MHz。具体做法是让 VCO 输出 400MHz，PLLQ=8，即 400/8=50MHz；PLLN 就要取 100，PLLM=8，100/8=12.5MHz 作为 VCO 输入，VCO=12.5*32=400MHz，这里需要重新核算，不要把 48MHz 的 USB 时钟配丢了。F407 的以太网 MAC 对时钟要求不算苛刻，但 MCO 引脚必须复用为 MCO_1，且在 RCC 里开启相关时钟。

RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_OscInitTypeDef RCC_OscInitStruct; // 外部晶振 HSE 8MHz，PLL 输入分频 M=8，倍频 N=336，系统时钟分频 P=2，得到 168MHz RCC_OscInitStruct.PLL.PLLM = 8; RCC_OscInitStruct.PLL.PLLN = 336; RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; RCC_OscInitStruct.PLL.PLLQ = 7; // 48MHz 供 USB 使用 // 配置 MCO1 输出 PLL 时钟的 Q 分频，得到 48MHz // 如果需要 50MHz，需要同步调整 PLLN、PLLQ，本例以 48MHz 跑通为先 RCC_MCO1Config(RCC_MCO1Source_PLLCLK, RCC_MCO1_Div2); // 按实际时钟树调整

代码逻辑说明：先初始化系统时钟，再单独配置 MCO1 的输出源和分频。MCO1 的输出频率不是随便配的，它受限于 PLL 的 VCO 频率范围（192MHz~432MHz），分频系数只能是 1~5。调试时先用逻辑分析仪或者示波器量 PA8 的频率，确认为 50MHz 再继续，否则 PHY 起不来，后面所有网络操作全是白费。

2.3 上电时序与复位电路：LAN8720 起不来的典型原因

LAN8720 对复位时序比较敏感，这是实际调试中第一个容易翻车的地方。

现象是：网口灯不亮，MDIO 读不到 PHY 的 ID，程序卡在 PHY 初始化等待循环里。原因多半是复位脉冲宽度不够，或者复位释放后立刻去访问 PHY，芯片还没准备好。LAN8720 的复位要求低电平至少保持一定宽度，我一般让 GPIO 输出低电平延时 10ms 以上，再拉高，拉高后再延时 100ms 才去访问 PHY。

另一个更容易被忽略的问题：REF_CLK 必须在复位释放前就稳定输出。若 MCO 配置在 PHY 复位之后才完成，PHY 可能会进入错误的配置状态。所以在初始化代码里，务必先配置 RCC 和 MCO，再操作 PHY 的复位引脚。这个顺序一错，PHY 有时能工作有时不行，就是典型的时序玄学。

3. FreeRTOS 与 LWIP1.4.1 的移植：把任务调度和网络协议栈串起来

3.1 标准库工程里移植 FreeRTOS：关键配置项与最小文件集

很多人在这一步纠结标准库还是 HAL 库。我讲一句实在话：这套方案最早、最完整的参考实现几乎都是基于标准库的，MDK5 里建工程时选对应型号的标准库固件包，反而少了很多 HAL 库版本差异带来的坑。标准库的 ETH 驱动函数名和寄存器操作更直接，出问题时翻手册更快。

FreeRTOS 移植进标准库工程，核心就是三件事：提供堆内存、提供 SysTick 或其它定时器作为时钟节拍、提供 PendSV 上下文切换。MDK5 里最省事的做法是直接把 FreeRTOS 源码放到工程里，把 FreeRTOSConfig.h 里的配置项过一遍。

#define configUSE_PREEMPTION 1 #define configUSE_TIME_SLICING 1 #define configTICK_RATE_HZ (1000) #define configMAX_PRIORITIES (5) #define configMINIMAL_STACK_SIZE (128) #define configTOTAL_HEAP_SIZE (40 * 1024) #define configUSE_MUTEXES 1 #define configUSE_TIMERS 1 #define configUSE_CO_ROUTINES 0

配置说明：时钟节拍设 1000Hz 即 1ms 一个 tick，网络任务里常用的延时单位就是毫秒，这个频率比较直观。任务优先级数量先给 5 个，够用；堆大小给 40KB，是给 LWIP 和任务栈一起用的，后面不够再调。这里有个经验：LWIP 的 TCP/IP 任务和 DHCP 相关任务需要较大的栈，所以堆不能配得太小，但也不要盲目加到 100KB，F407 的 RAM 是 192KB，还要留一部分给接收和发送的 DMA 描述符。

3.2 LWIP1.4.1 的内存池配置：三个必调参数

LWIP1.4.1 在标准库工程里最常见的移植方式，是直接使用源码包里自带的 LAN8720 驱动和 ethernetif 接口。这个版本的 LWIP 对内存的配置方式比较粗暴，主要是三个宏定义：MEM_SIZE、MEMP_NUM_PBUF、PBUF_POOL_SIZE。

这三个参数直接影响能同时处理多少个网络报文。如果配置太小，接收稍多数据就会出现丢包；配置太大，RAM 又不够。我常用的起点值是：MEM_SIZE 给 16KB，PBUF_POOL_SIZE 给 16，单个 PBUF 的大小在 lwipopts.h 里通过 PBUF_POOL_BUFSIZE 设置，默认一般是 1500 字节左右，这样能覆盖一个完整以太网帧。MEMP_NUM_PBUF 给 32，用于协议栈内部临时缓冲。如果设备要跑稍大的数据吞吐，MEM_SIZE 调到 32KB 也不过分，但这会挤占任务栈和文件系统缓冲的空间，必须整体规划。

#define MEM_SIZE (16 * 1024) #define MEMP_NUM_PBUF (32) #define PBUF_POOL_SIZE (16) #define LWIP_DHCP 1 #define LWIP_UDP 1 #define LWIP_TCP 0 #define LWIP_STATS 0 #define LWIP_DEBUG 0 #define CHECKSUM_GEN_IP 1 #define CHECKSUM_GEN_UDP 1 #define CHECKSUM_CHECK_ICMP 1

参数说明：LWIP_DHCP 置 1 才能用 DHCP 自动获取地址，LWIP_UDP 置 1 才编译 UDP 协议栈支持。如果场景只需要 UDP，LWIP_TCP 可以关掉来省内存，但如果后面要扩展 TCP 功能就得再打开——我更建议一开始就打开 LWIP_TCP，省得后面来回改。LWIP_DEBUG 默认关掉，排查问题时再打开，打开后日志输出会占用串口和 CPU。

3.3 以太网中断怎么喂给协议栈：二值信号量与中断优先级

LWIP 的接收路径是：F407 的以太网 DMA 收到帧，产生 ETH 中断；中断服务函数里需要读取帧并交给 LWIP 的 tcpip_thread。这里有一个设计选择：是在中断里直接处理，还是通过信号量通知协议栈任务处理。

在 FreeRTOS 环境下，标准做法是创建一个二值信号量，在 ETH 中断里只做一件事：释放信号量。tcpip_thread 或专门的网络接收任务阻塞等待这个信号量，一旦拿到就去调用接收函数。

// 中断服务函数，注意只做置位操作 void ETH_IRQHandler(void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; // 清除 ETH DMA 接收中断标志 ETH_DMAClearITPendingBit(ETH_DMA_IT_R); // 通知网络接收任务 xSemaphoreGiveFromISR(xRxSemaphore, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

这段代码的逻辑：中断里绝对不能调用 LWIP 的复杂处理函数，那些函数不是中断安全的，而且耗时不可控。只释放信号量，把实际的数据接收留给优先级较高的网络任务去执行。xHigherPriorityTaskWoken 用来判断是否需要在退出中断时进行一次任务切换，保证网络任务的响应延迟最低。ETH 中断的优先级建议设置成低于 SysTick，但高于普通外设中断，否则在任务切换时可能产生时序问题。实际值我一般设成 5（数字越大优先级越低，具体看 NVIC 配置），这样系统节拍不会被网络中断长时间阻塞。

4. DHCP 与 UDP 的代码落地：从获取 IP 到收发报文

4.1 开启 LWIP_DHCP 与网卡初始化：等地址状态机的写法

DHCP 获取 IP 不是瞬间完成的，它是一个状态机：发送 DHCP Discover，等待 DHCP Offer，发送 DHCP Request，等待 DHCP Ack。LWIP 会在内部处理这个过程，但应用层需要周期性调用 dhcp_fine_tmr 来推进超时重传，同时检查 netif 的 IP 地址是否有效。

// 网卡初始化，绑定 MAC 地址 struct netif g_netif; ip_addr_t ipaddr, netmask, gw; IP4_ADDR(&gw, 0, 0, 0, 0); IP4_ADDR(&ipaddr, 0, 0, 0, 0); IP4_ADDR(&netmask, 0, 0, 0, 0); netif_add(&g_netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, tcpip_input); regs320: netif_set_default(&g_netif); netif_set_up(&g_netif); dhcp_start(&g_netif);

代码说明：先初始化 LWIP 内核，再添加网卡接口。IP 地址全填 0 表示由 DHCP 分配。netif_set_default 让该网卡成为默认出口，netif_set_up 激活网卡，最后 dhcp_start 启动 DHCP 流程。很多人忘记 netif_set_up，结果 DHCP 始终不发包。

应用层等待 IP 的做法是写一个循环：读取 netif 的 IP 地址，如果还是 0.0.0.0 就继续等待。要注意超时处理，不能无限等下去。实际产品中如果有人插拔网线、路由器重启，DHCP 可能会重新协商，所以状态判断要放在周期性任务里而不是一次性流程里。

void wait_for_dhcp(void) { uint8_t timeout = 50; while (timeout--) { // 等待 DHCP 分配完成，IP 不再是 0.0.0.0 if (g_netif.ip_addr.addr != 0) { break; } vTaskDelay(pdMS_TO_TICKS(200)); } // 超时后可以用静态 IP 兜底，保证设备可访问 if (g_netif.ip_addr.addr == 0) { IP4_ADDR(&g_netif.ip_addr, 192, 168, 1, 200); IP4_ADDR(&g_netif.netmask, 255, 255, 255, 0); IP4_ADDR(&g_netif.gw, 192, 168, 1, 1); } }

这里有个关键点：DHCP 超时后不能直接认为网络不可用，对于 UDP 设备来说，很多场景下静态 IP 兜底反而更可靠。但注意，静态 IP 和 DHCP 分配的 IP 可能会冲突，工业现场最好别混用。

4.2 创建 UDP 控制块：绑定端口、注册接收回调

UDP 在 LWIP 里通过 udp_new 创建控制块，然后绑定本地端口，这样远端发来的数据只要目标端口匹配，协议栈就会主动调用注册的回调函数。

struct udp_pcb *g_udp_pcb; void udp_echoserver_init(void) { g_udp_pcb = udp_new(); // 绑定本地端口 5000 udp_bind(g_udp_pcb, IP_ADDR_ANY, 5000); // 注册接收回调，收到数据后由协议栈自动调用 udp_recv(g_udp_pcb, udp_recv_callback, NULL); }

udp_new 分配控制块可能会失败，返回 NULL 时要检查堆内存是否耗尽。udp_bind 的第二个参数填 IP_ADDR_ANY 表示接收任意 IP 发来的数据，这在大多数设备应用里是合适的，如果只信任特定来源的包，可以在这里指定目标 IP 做过滤。udp_recv 的第三个参数是回调函数的参数指针，可以用来传一些上下文信息，不需要就填 NULL。

接收回调函数是在 tcpip_thread 的上下文里执行的，所以里面不能调用 vTaskDelay 这类阻塞函数，也不要执行太耗时的操作，否则会阻塞所有网络数据的处理。如果要对接收的数据做复杂解析，应该拷贝出来，然后通过队列或信号量交给普通任务处理。

4.3 数据接收与发送：API 的坑和零拷贝注意事项

UDP 的接收回调拿到的 pbuf 是协议栈分配的缓冲，处理完必须释放，否则内存池会被耗尽。发送数据一般用 udp_sendto，但如果数据量较大，可以先 udp_connect 建立连接关系，然后直接 udp_send。

void udp_recv_callback(void *arg, struct udp_pcb *pcb, struct pbuf *p, ip_addr_t *addr, u16_t port) { // 回调上下文，注意不能调用阻塞函数 if (p != NULL) { // 处理收到的数据，p->payload 指向数据区 // 业务解析代码放在这里 // 释放 pbuf 缓冲区，否则内存泄漏 pbuf_free(p); } }

发送 UDP 数据的标准流程是先创建一个 pbuf，填充数据，然后调用 udp_sendto 指定远端 IP 和端口。这里有一个常见的坑：udp_sendto 发送完成后不要立刻 pbuf_free，LWIP 在非阻塞模式下发送成功后会自动释放，重复释放会导致内存崩溃。

struct pbuf *p; char msg[] = "hello udp"; // 创建带数据的 pbuf，类型为 PBUF_TRANSMIT p = pbuf_alloc(PBUF_TRANSMIT, strlen(msg), PBUF_RAM); if (p != NULL) { memcpy(p->payload, msg, strlen(msg)); // 发送到 192.168.1.10 的 6000 端口 err_t err = udp_sendto(g_udp_pcb, p, &remote_ipaddr, 6000); // 发送成功后，pbuf 由 LWIP 释放，不能再 pbuf_free if (err != ERR_OK) { // 发送失败，需要自己释放 pbuf_free(p); } }

pbuf_alloc 的第二个参数是数据长度，注意如果数据超过以太网 MTU（默认 1500 字节减去 IP 头和 UDP 头），LWIP 会自动进行 IP 分片，但是分片会增加丢包概率，吞吐量也上不去。UDP 发送的最大安全载荷是 1472 字节（1500 - 20 - 8），想传大数据就要自己拆包。

5. 避坑指南：这套组合最常见的 5 个翻车现场

5.1 现象：程序死在 ETH_IRQHandler 里，标志位清不掉

标准库版本的 ETH 中断处理里，ETH_DMAClearITPendingBit 不能只清一个标志。ETH DMA 的中断状态寄存器里，读包中断和写包中断是分别独立的，如果只清了接收标志而忘了清发送完成标志，中断会反复进入。

原因：中断服务函数里进入 while 循环，DMA 状态一直有挂起标志，导致 CPU 卡死在中断里，任务全部停止。

解决：在中断里把 ETH DMA 的所有中断标志统一清除，再配合信号量通知。另一个做法是每次进入中断先判断是否有接收事件，没有就直接清标志退出。我现在习惯写成先读状态寄存器，按位处理，最后统一写回清除，不要用库函数里逐个 Clear 的写法。

5.2 现象：DHCP 一直拿不到地址，网口灯还不亮

网口灯不亮基本可以断定是物理层问题。先用示波器量 REF_CLK 引脚，确认 50MHz 时钟到位；如果时钟没有，查 MCO 复用配置和 PLL 分频系数；如果时钟正常，查 LAN8720 的复位引脚是否被外部电路拉低，有些开发板的复位脚默认电平不对。

排除硬件后再看软件：PHY 的初始化是否在 MCO 时钟稳定之后才执行。很多参考代码把 GPIO 初始化、MCO 配置、PHY 复位和 MDIO 通信写在同一个函数里，顺序不对就会出现偶发失败。我的固定写法是：第一步配 RCC 时钟树，第二步配 MCO 输出，第三步延时 200ms 让时钟稳定，第四步复位 PHY，第五步延时，第六步才做 ETH 外设初始化和 PHY 寄存器读写。

5.3 现象：UDP 能收不能发，或者发出去 PC 端抓不到

能收不能发，先查发送完成中断有没有正确触发。标准库的 ETH 发送流程是：配置 DMA 描述符，把数据地址和长度写入描述符，启动发送。如果 DMA 描述符的缓冲区地址没有对齐到 4 字节边界，DMA 传输会异常。

另一个容易被忽略的点：发送的数据量如果很小，比如只有几个字节，LAN8720 会自动做填充到最小以太网帧长度，这个不需要操心；但如果发送缓冲区的内容被 FreeRTOS 优化掉了，或者 pbuf 数据域没有正确写入，PC 端抓到的是全 0 数据。排查方法是先用固定的字节序列测试，比如把 0xAA 0x55 循环填充发送缓冲区，抓包确认内容。另外检查 LWIP 的 CHECKSUM_GEN_UDP 宏，如果关闭，UDP 的校验和是 0，某些抓包软件会直接丢弃显示。

5.4 现象：一开 DHCP 任务就卡死，其他任务不运行

这个问题的根源是优先级配置不合理。LWIP 的 tcpip_thread 优先级如果设置得过高，且它在等待信号量时不主动让出 CPU，其他任务就别想运行。FreeRTOS 是抢占式调度，高优先级任务只要就绪就会一直执行。

解决：检查 tcpip_thread 的优先级在 lwipopts.h 里怎么定义的，同时看 FreeRTOSConfig.h 里的 configMAX_PRIORITIES 是否足够大。我一般把 tcpip_thread 设为中等优先级，把业务逻辑任务设得低一点，把硬件响应任务设得高一点，宁可网络延迟也不让系统整体卡死。

5.5 现象：反复重启后内存耗尽，ping 不通但前几次都正常

典型的 pbuf 泄漏。接收回调里拿到了 pbuf 但处理完忘记 pbuf_free，或者发送失败后重复释放。LWIP 自带的统计功能可以打开 LWIP_STATS 查看内存池的使用量，但标准库版本里它默认是关的。

建议：调试阶段把 LWIP_STATS 打开，周期性打印 MEMP_STATS 里的 avail 和 used 字段。如果 used 值单调递增不回落，那就是有泄漏。另一个常见泄漏路径是 DHCP 周期性任务里新建了 pbuf 但超时后没有释放，这个在 1.4.1 版本里确实存在，建议把 LWIP_DHCP 相关的宏定义和版本更新说明对照检查，或者直接避免频繁重启——很多调试中所谓的泄漏其实是调试方式造成的假象。

6. 收尾：验证这套方案是否稳的 3 个手段

6.1 用抓包工具确认 UDP 报文与 DHCP 四次交互

先把 PC 端 IP 设置好先用静态 IP，方便抓包。抓包能看到完整的 DHCP Discover、Offer、Request、Ack 四次交互，只看结果拿不到地址是不够的。抓包可以顺带验证 MAC 地址是否正确，还能确认发送的 UDP 报文内容、源端口、目标端口是否符合预期。抓包发现 DHCP 是广播交互，但 UDP 业务数据是单播，如果单播报文发不出去，回头检查静态路由表或者目标 IP 有没有填错。

6.2 用连通性测试和压力测试量化稳定性

连通性测试不能只 ping 一下，要连续 ping 几千个包看丢包率。在 MDK5 调试模式下配合串口日志，周期性打印接收到的 UDP 总包数、发送成功包数、丢弃包数，运行几小时后看数据是否平稳增长。

压力测试用小工具以固定间隔向设备发送 UDP 包，逐步加快频率，直到同一时间内出现丢包。这个临界值就是设备实际能承受的吞吐上限。注意 F407 跑这套协议栈理论吞吐能做到几十 Mbps 的百兆以太网速度，但实际受限于 LWIP 处理能力和内存池大小，常用场景下 1Mbps 的数据量是非常宽裕的。如果压测不过，优先调整 PBUF_POOL_SIZE 而不是换更快的芯片。

6.3 从这套方案往其他芯片迁移时，哪些代码值得保留

这套方案里最值得保留的是 LWIP 协议栈与 FreeRTOS 的接口层代码，也就是网卡中断转信号量、tcpip_thread 的粘合逻辑。这部分与硬件无关，换芯片平台只需要改底层的 MAC 驱动，比如从标准库换到 LL 库或驱动库里，上层的任务架构和 UDP 收发逻辑基本可以原封不动搬走。

最后说一个我自己的教训：新手阶段我总想用最新版本的 LWIP，换了一次发现 DHCP 和 UDP 的接口在 2.x 版本里改动不少，网上针对配套案例多。后来做新项目我都优先选与参考驱动配套的协议栈版本，先跑通、再考虑升级，而不是先升级、再排错。这套 F407 方案如果第一次做，最好一块开发板加上一颗 LAN8720 的模块直接调通，不要上来就画整板，硬件调通了再画也不迟。希望帮到你，祝你一次点亮。

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