做嵌入式这几年，凡是涉及网络功能，我脑子里第一个蹦出来的 MCU 永远是 STM32F407，搭配一颗 LAN8720A 就能组出标准的 10M/100M 以太网口，成本低、资料多、性能也够用。但这套组合有个绕不开的门槛，就是 RMII 接口的配置与调试。很多人第一次点亮网口，面对的往往是 PHY ID 读不出来、网线插上灯不亮、或者 Link 起来了却 ping 不通之类的问题。这篇文章算是我自己踩过几轮坑之后，把 CubeMX 生成配置、HAL 库初始化、LAN8720 驱动移植以及现场排查思路整理成的一份完整操作记录。如果你是刚接触 F407 以太网，或者板子到手后网口死活不通，按这套流程走一遍，大概率能把问题范围缩小到具体哪一个环节。
1. 为什么 RMII 会让 F407 和 LAN8720 的组合变成老大难
1.1 这网口到底由哪几段组成
以太网链路从大的方向看，是 MAC、PHY、网络变压器和 RJ45 座子共同组成。STM32F407 内部自带的是一个 MAC 控制器，负责封装、解析以太网帧；LAN8720 是物理层收发器，负责把数字信号转换成差分电平送上网线。MCU 的 MAC 和 LAN8720 之间通过 RMII 接口连接，然后再由 LAN8720 连接到带隔离变压器的 RJ45 座。这样一拆就能明白，网口不通可能发生在任何一个环节。硬件上有供电、时钟、复位、差分线的问题，软件上有引脚复用、PHY 寄存器、DMA 描述符、协议栈配置的问题。调试时如果一上来就翻协议栈的代码，很容易把方向带偏。
RMII 的意思是简化媒体独立接口，相比传统的 MII 少了一堆信号线，只保留了 TXD、RXD、TX_EN、CRS_DV、REF_CLK、MDC、MDIO 这几组，尤其是数据线只有 2 位，引脚占用大幅减少。但少一根引脚意味着每一位数据都要在更高的速率下工作，因此 RMII 模式强制要求外部提供一个 50MHz 的参考时钟，这个时钟是所有收发时序的基准。如果说 MII 像一条宽敞的大马路，那 RMII 就是一条单车道，路上所有车都必须严格按同一个时钟节拍运行，时钟一旦乱了，整个链路就会崩掉。
1.2 为什么很多人都卡在 REF_CLK 上
F407 的 ETH_RMII_REF_CLK 引脚是 PA1，这个引脚在 RMII 模式下必须输入 50MHz，MAC 侧本身不能直接产生这个时钟，它必须由 PHY 或者外部有源晶振供给。这一点和很多人的直觉完全相反。有的板子是 LAN8720 外接 25MHz 晶振，PHY 内部 PLL 倍频到 50MHz，再由 REF_CLK 引脚输出给 PA1；有的板子则是在 PC9（MCO2）上输出 50MHz 直接连到 LAN8720 和 PA1；还有的板子干脆用一颗 50MHz 有源晶振同时给 PHY 和 MAC 提供时钟。三种方案在 CubeMX 里的配置基本一样，但硬件上的区别很大，这直接导致同样的代码放在不同板子上效果完全不同。
所以拿到任何一块 F407+LAN8720 的板子，第一件事不是看代码，也不是打开 CubeMX，而是去看原理图。确认板上 LAN8720 用的是 25MHz 晶振还是外部 50MHz 时钟，PA1 有没有接过去，复位引脚 RC 电路时间常数大概多长，PHY 地址是 0x00 还是 0x01，这几项不确定，后面怎么查都是盲人摸象。
2. 动手配置前的硬件核查与原理图阅读
2.1 LAN8720 的引脚与复位时序
LAN8720A 的 RMII 信号有 ETH_RMII_TX_EN（PA11 或 PB11）、ETH_RMII_TXD0（PA12 或 PB12）、ETH_RMII_TXD1（PA13 或 PB13）、ETH_RMII_RXD0（PA14 或 PB14）、ETH_RMII_RXD1（PA15 或 PB15）、ETH_RMII_CRS_DV（PA7 或 PB10），加上 PA1 的 REF_CLK、PC1 的 MDC、PA2 的 MDIO。我劝大家不要死记，因为同一颗芯片在不同开发板上的引脚映射完全不同，有些板子用 PA 组，有些板子为了避开调试器引脚而改用 PB 组。最靠谱的办法是打开 CubeMX，根据原理图把对应引脚逐个勾选，然后让工具自动生成代码。
LAN8720 的复位时序也特别容易踩坑。很多板子在 nRST 上接了一个简单的 RC 延时电路，上电后 PHY 的复位解除时间可能高达几十毫秒甚至上百毫秒。而 MCU 启动速度比 PHY 快得多，所以在主函数里如果上电后立刻发起 MDIO 读写、立刻读 PHY ID，很容易读回 0xFFFF。我的习惯是在初始化以太网外设之前，先对复位引脚做一次明确的软件复位，低电平保持 100ms 以上，再拉高，然后再延时 200ms 左右等 PHY 内部 PLL 稳定，最后才去访问 PHY 寄存器。
HAL_GPIO_WritePin(LAN8720_RESET_GPIO_Port, LAN8720_RESET_Pin, GPIO_PIN_RESET); HAL_Delay(120); HAL_GPIO_WritePin(LAN8720_RESET_GPIO_Port, LAN8720_RESET_Pin, GPIO_PIN_SET); HAL_Delay(200);如果板子复位引脚没有引出到 MCU，那就只能靠上电 RC 延时，但要注意软件里必须留足延时，不要一上电就急着操作。
2.2 PHY 地址和时钟拓扑的确认方法
LAN8720 的 PHY 地址由 PHYAD0 引脚决定，默认内部下拉，所以绝大多数设计地址是 0x00。但有些厂商的评估板会把 PHYAD0 上拉，地址变成 0x01。CubeMX 的 ETH 配置界面里有一个 PHY Address 下拉框，很多人直接让它保持默认值，这就埋下了一个隐患。正确做法是在原理图上搜 PHYAD 相关字眼，或者在 CubeMX 的 ETH 配置中反复测试 0x00 和 0x01 哪个能读回正确的 PHY ID。
时钟拓扑的确认稍微复杂一些。如果板上 LAN8720 附近有 25MHz 的无源晶振，并且 PA1 确实连到了 LAN8720 的 REF_CLK 输出，那就是 PHY 倍频给 MAC 供时钟的方案，这时 PA1 是输入，不需要配置任何时钟输出。如果板上只有 50MHz 有源晶振，通常这个晶振会同时接到 LAN8720 的 XTAL1/CLKIN 和 PA1，这种方案 PA1 同样是输入。还有一种方案是 STM32F407 的 PC9 用 MCO2 输出 50MHz 给 PHY，这种情况下除了把 PC9 配置成 MCO 输出，还要确认这个 50MHz 是否同时回馈到了 PA1。搞清楚这三者，再去分析为什么网口不工作，就不会一头雾水。
3. CubeMX 配置实操：从新建工程到产生初始化代码
3.1 工程建立与外设时钟树设置
打开 STM32CubeMX，先选择 F407 对应的具体型号，一般常用的是 STM32F407VGT6 或者 STM32F407ZGT6。时钟配置这里我直接说结论：系统主频做到 168MHz，即 HCLK=168MHz、APB1=42MHz、APB2=84MHz，这是 F407 最常规的配置。以太网 MAC 的外设时钟挂在 AHB1 上，所以 APB 分频不影响 MAC 主干，但如果你要用 MCO2 输出 50MHz 给 LAN8720，就需要注意 PLL 的配置，MCO2 可以选择输出 PLLCLK/2，也就是 168MHz 除以 2 等于 84MHz，并不是 50MHz，这一点很多参考例程里并没有说清楚。
如果是靠 PHY 自身倍频的时钟方案，CubeMX 时钟树基本不用为以太网做特别处理，只要保证主频和 USB 需要的 48MHz（如果用到 USB 的话）正确即可。我给的建议是，除非你的原理图明确把 PC9 连到了 PHY 的时钟输入，否则不要轻易去动 MCO2。很多时候网口不工作，不是没有时钟，而是调试者为了让 PA1 有时钟，特意去开了 MCO2，结果输出频率又不是 50MHz，反而把问题搞复杂。
3.2 ETH 外设的模式和参数设置
在 Connectivity 分类下找到 ETH，把它使能为 RMII。这里有两个地方需要重点检查：一个是 PHY Address 的值，要根据原理图填 0x00 或 0x01；另一个是 MAC Address 的默认值，CubeMX 会随机给一个，我建议把它改成自己规划的地址，比如 02:00:00:12:34:56，避免和局域网内其他设备冲突。剩下的 Advanced Parameters 里，自动协商、全双工、100Mbps 这些默认配置一般不需要改，但如果你是在测试裸机回环，可以关闭自动协商，强制设置成 100M 全双工，这样更容易定位问题。
ETH 的 DMA 参数也很关键，但 CubeMX 里这几个参数的暴露程度依赖版本。新版 CubeMX 的 ETH 配置页在高级参数里提供了 Tx、Rx Descriptor 数量，默认值 4 一般够用。DMA 描述符和缓冲区最终会分配在哪块内存，CubeMX 不会替你决定，这需要在 HAL 初始化代码里手动指定，稍后我会详细展开。把这些配好之后，记得给 ETH 的全局中断使能打钩（如果你打算用中断方式接收），然后生成工程。
3.3 引脚自动生成与冲突排查
CubeMX 生成代码后，打开 gpio.c 检查 PA1、PA7、PA11、PA12、PA13、PA14、PA15、PA2、PC1 等引脚是否都正确配置成了复用功能。这里要特别提醒，PA13 和 PA14 默认是 SWD 调试引脚，如果你的板子把 RMII 信号放在 PA13/PA14 上，而调试器又占用了这两脚，在调试时可能会发生冲突。我实际碰到过一种情况：MDIO 和 MDC 默认复用没问题，但某个引脚的 GPIO 速度没有调到 High，导致高速时钟沿变缓，偶尔丢掉一帧。所以生成代码后，建议把 ETH 相关引脚的速度统一改成 Very High。
PA8 这个引脚和 RMII 没有任何关系，但很多 F407 核心板会用 PA8 做 USB Type-C 的 VBUS 检测。如果你在音频、USB 或者自定义代码里也初始化了 PA8，并且它的模式被覆盖成了输入或输出，那只是影响 USB 检测逻辑，不会造成网口不通。不过排查问题时还是要注意，有时代码一多，某个外设的初始化函数把别的引脚状态改了，造成奇怪的副作用。最稳妥的做法是在 main 函数里一层层注释，确定只有 ETH 初始化执行的时候，网口相关引脚的状态才是正确的。
4. HAL 库里的 PHY 驱动到底要怎么改
4.1 CubeMX 生成的 ETH 初始化代码能直接跑吗
坏消息是，F407 的 HAL 库虽然把 MAC、DMA、MDIO 的底层初始化都做好了，但并没有把 LAN8720 这种具体 PHY 芯片的驱动全部封装好。生成代码后，MX_ETH_Init 函数做的事情是初始化 MAC 控制器和 DMA 描述符，但它不会去配置 LAN8720 的寄存器，更不会帮你自动协商。所以你需要手动写一个简单的 PHY 驱动，至少包含四个功能：复位 PHY、读取 PHY ID、获取 Link 状态、配置 PHY 工作模式。
在较新的 CubeF4 固件包里，旧式 HAL_ETH_ReadPHYRegister 和 HAL_ETH_WritePHYRegister 仍然可用，但在更早一点的版本里，这两个函数需要你先调用 HAL_ETH_ReadPHYRegister，而且参数顺序稍有不同。为了避免版本差异带来的困惑，我一般直接在自己的驱动文件里封装一层函数，内部统一调用 HAL 库的读写接口，这样以后换芯片或者换库版本，只需要改这个地方。
uint8_t LAN8720_ReadReg(uint16_t reg, uint32_t *value) { return HAL_ETH_ReadPHYRegister(&heth, reg, value) == HAL_OK; } uint8_t LAN8720_WriteReg(uint16_t reg, uint32_t value) { return HAL_ETH_WritePHYRegister(&heth, reg, value) == HAL_OK; }4.2 自定义 LAN8720 驱动：读取 PHY ID 和 Link 状态
上电复位完成后，第一件事是读 PHY 的标识寄存器。LAN8720A 的 PHY ID 由寄存器 2 和寄存器 3 组成，读回来应该是 0x0007 和 0xC0F1。如果读到的不是这个值，说明 MDIO/MDC 通路有问题，或者 PHY 根本没工作。如果读到的是 0x0000，可能是 PHY 地址没设对；如果读到的是 0xFFFF，大概率是复位没完成，或者 MDIO 引脚配置有问题。
Link 状态的判断用寄存器 1（Basic Status Register）的 bit 2，这一位置 1 表示链路已建立。实际项目中我不建议只查一次就做出判断，因为网线插拔瞬间这一位会有延迟，我会写一个循环等待函数，设定超时时间，在超时时间内反复读取，直到这一位稳定为 1。这样在应用层才能减少误判。
uint8_t LAN8720_WaitLinkUp(uint32_t timeout_ms) { uint32_t reg = 0; uint32_t tick = HAL_GetTick(); while (HAL_GetTick() - tick < timeout_ms) { LAN8720_ReadReg(0x01, ®); if (reg & 0x04) return 1; HAL_Delay(10); } return 0; }除了 Link 状态，你还可以通过寄存器 0（Basic Control Register）强制 PHY 工作在半双工、全双工、10M、100M 等模式。但常规用途下建议就用自动协商，让 PHY 自己和交换机去协商速率。这里有一个细节：LAN8720 的自动协商需要一点时间，polling 等待不能太激进，否则容易误判为协商失败。
4.3 DMA 描述符发送缓冲区和接收缓冲区怎么分配
HAL 库提供的收发接口基于 DMA 描述符，描述符实际上是一组结构体数组，每个描述符指向一块缓冲区。CubeMX 生成的代码里，这些描述符和缓冲区要么默认分配在某个数组里，要么需要你手动指定。我见过很多程序编译没问题，跑起来却收不到数据，原因就是描述符数组没有 4 字节对齐。
虽然 F407 没有 D-Cache，不存在 Cache 一致性问题，但 DMA 控制器对内存对齐有要求，描述符尤其如此。我习惯把一个完整的 DMA 缓冲区结构定义成 4 字节对齐，并且缓冲区大小留足一整帧，比如 1524 字节的空闲接收缓冲区，防止超大帧把后续内存踩掉。
__attribute__((aligned(4))) ETH_DMADescTypeDef TxDesc[ETH_TX_DESC_CNT]; __attribute__((aligned(4))) ETH_DMADescTypeDef RxDesc[ETH_RX_DESC_CNT]; __attribute__((aligned(4))) uint8_t TxBuf[ETH_TX_DESC_CNT][ETH_MAX_PACKET_SIZE]; __attribute__((aligned(4))) uint8_t RxBuf[ETH_RX_DESC_CNT][ETH_MAX_PACKET_SIZE];CubeMX 生成的 ETH 初始化函数里，有一个 HAL_ETH_DescAssignMemory 或者通过 HAL_ETH_Init 之后的显式赋值过程。不同固件包差异比较大，但只要描述符地址和缓冲地址与上面的数组对应上，底层收发就能正常工作。我在裸机程序里推荐使用轮询方式接收，也就是在主循环中不断调用 HAL_ETH_GetRxDataBuffer、HAL_ETH_Receive 和 HAL_ETH_ReleaseRxBuffer，这样不依赖中断的优先级配置，逻辑也容易理解。
5. 调试实录：网口不通常见的几个坑怎么排查
5.1 读 PHY ID 失败的排查顺序
如果 LAN8720_WaitLinkUp 调用后连接不上，或者读 ID 返回 0xFFFF，先不要急着改寄存器配置。我一般按顺序检查四项：第一是量 LAN8720 的供电，VDD 要 3.3V，VDDCR 输出要 1.2V 左右，如果 VDDCR 异常，PHY 内部数字逻辑可能完全没起来；第二是量复位引脚的波形，确认复位解除后是不是高电平稳定；第三是用示波器量 PA1 或者 REF_CLK 引脚有没有 50MHz 方波，如果没有，说明时钟通路有问题；第四是核对 MDIO 和 MDC 的 GPIO 复用配置，确认没被其他初始化覆盖。这一套下来，基本能定位是硬件问题还是软件问题。
有一个经验值得单独说：MDIO 和 MDC 上因为需要和 PHY 通信，如果外部上拉电阻没接，或者接的电阻值过大，在高速通信时波形沿会变差，偶尔出现 CRC 错误或寄存器读回乱码。我遇到过一块板子，读 PHY ID 时好时坏，最后发现是 MDIO 上拉电阻焊错了，改成 10kΩ 上拉后立刻稳定。
5.2 Link 起不来，网口灯不亮怎么办
Link 灯不亮，首先确认网线另一头是不是可靠设备，比如交换机、路由器、直连电脑的网卡。然后检查 LAN8720 的差分信号是否正常，RX+/RX- 和 TX+/TX- 要成对出现在 RJ45 座子上，中间还要经过网络变压器。如果你用的是一块现成开发板，这一步大概率没问题，但如果是自己画的板子，就需要仔细核对 RJ45 座和变压器之间的绕线，接反或者断开都会导致 Link 起不来。
还有一个容易忽略的问题是 LAN8720 和对端设备的协商能力。有些老交换机只支持 10M 半双工，而 PHY 默认自动协商又没有回退机制，可能导致灯不亮。此时可以用寄存器把 PHY 强制设成 10M 全双工试试，如果强制后灯亮了，说明变压器和网口座没问题，问题在协商过程。另一个隐蔽点是 LAN8720 的 CLK/PHYAD1 引脚，如果这个引脚的电平决定了 PHY 使用外部时钟还是内部晶振，当 PHYAD1 拉高时 PHY 默认从 XTAL1/CLKIN 输入时钟，如果你板子上实际使用 25MHz 晶振并且 PHYAD1 恰好拉高，PHY 就无法正常工作。这个引脚很容易被忽略，原理图上看一眼就能排除。
5.3 能 Link 上但 ping 不通，该从哪里切
Link 上来之后，问题就进入软件协议栈层面了。如果用的是 lwIP，第一件事是确认 MAC 地址被正确设置，不能全 0。第二件事是确认 IP 地址和电脑的 IP 在同一个网段，比如开发板配置 192.168.1.10，电脑手动设置 192.168.1.2，掩码都是 255.255.255.0。第三件事是关闭电脑防火墙，很多第一次调试的人会发现 ping 请求发出去没回应，其实包到了电脑网卡，但被系统防火墙拦了。
裸机环境下，没有协议栈，可以先做一个最简单的回环测试。把发送缓冲区的目的 MAC 和源 MAC 都填成本机的 MAC 地址，让 MAC 处于回环模式，然后看能不能在接收缓冲区里收到自己发的帧。如果回环能收到，说明 MAC 到 DMA 的收发送通路是通的，剩下的问题就在 PHY 或协议栈上。F407 的 HAL 库没有直接提供一键回环 API，但你可以通过设置 MAC 配置寄存器的相关位来实现，这在验证底层时非常有帮助。
5.4 能收到数据但 CRC 错误频繁，可能是什么原因
CRC 错误频繁，大多数情况集中在两个原因：一是时钟抖动，REF_CLK 不是标准的 50MHz，或者占空比严重偏差，这会让 PHY 在采样数据时出现位错误；二是 PCB 走线导致信号完整性问题，RMII 数据线虽然只有几根，但布线时如果和高速时钟靠太近，串扰会造成偶发误码。遇到这类问题不要急着改代码，先用示波器看 REF_CLK 波形，再看数据线波形，50MHz 时钟如果幅度不足或者边沿过缓，就先把时钟通路处理好。
软件上也有一点要注意：DMA 描述符的环形链表必须正确初始化，如果接收描述符被意外改写，DMA 可能会把数据写到错误的缓冲区，然后 CRC 校验也相当于完全错位。我遇到过一次诡异的现象，接收到的前几帧正常，后面每帧 CRC 都错，最后发现是我的代码在中断里修改了同一个缓冲区，而 HAL_ETH_ReleaseRxBuffer 还没被调用，导致描述符指向的缓冲区被上层覆盖。先释放再处理数据，顺序千万不能反。
5.5 插上网线开机，程序跑飞或者卡死在以太网初始化怎么办
有一种典型现象是，代码里在 MX_ETH_Init 之后立即开始读 PHY 寄存器，但板子上电顺序导致 PHY 还没完成内部初始化，软件就一直卡在等待循环里。这个问题在带 PoE 供电的设计中尤其常见，PHY 的供电由网线供电模块输出，和 MCU 上电时序不一样，往往 MCU 已经跑起来几秒钟，PHY 才刚开始上电复位。我的建议是 PHY 驱动里的所有等待都带超时，超时后即使没有 Link 也要返回错误码，而不是死循环，否则整个系统会在初始化阶段被卡住。
另一个原因是 MPU 配置。很多从 F7 或 H7 平台转过来的同事会习惯性地配上 MPU 和 Cache，但在 F407 上根本没有这些模块，CubeMX 也不会生成相关代码。如果你在网上看到 F4 的例程里有人写了 SCB_EnableDCache 之类的函数，那大概率是拿别的平台代码硬改的，直接忽略就好。F407 只需要关注对齐，不需要处理 Cache 一致性问题。
6. 调试工具与最后的经验清单
6.1 一个有用的串口调试手段
调试以太网最痛苦的地方在于你看不到 PHY 和 MAC 内部状态，所以我习惯在串口上把关键信息全部打出来。上电后打印 PHY ID、Link 状态、自动协商结果、收到的帧计数、CRC 错误计数，这样程序跑到任何位置，我都能从串口日志里判断是底层的哪一环出了问题。很多人觉得 printf 太土，但实际项目里最快定位问题的往往是这些简单的辅助输出。
有些 HAL 版本里，ETH 外设会提供一些统计寄存器，比如接收错误计数、CRC 错误计数，直接把对应寄存器的值读出来打印，就能判断误码来自物理层还是 DMA 层。配合 Wireshark 抓包，如果电脑端能收到开发板发出的 ARP 请求，说明发送链路基本通了；如果抓不到任何包，但 MDIO 和 Link 都正常，那就回到 DMA 描述符和缓冲区分配的逻辑上去查。
6.2 我在实际操作里的几条经验
第一，不要相信网上任何一份现成代码能直接在你的板子上跑通，F407 以太网的引脚映射、PHY 地址、时钟方案在不同板子之间差异太大，最可靠的依据永远是原理图。第二，调试顺序应该是先确认 PHY ID，再确认 Link，再做回环测试，最后才跑协议栈，跳过任何一步都可能导致问题放大，让你在协议栈里找出根本不在协议栈里的问题。第三，HW 上的坑远比软件多，LM8720 这种 PHY 芯片对电源去耦和时钟质量很敏感，如果软件排查到 PHY ID 都正常但仍然偶发丢包，回头去量电源纹波往往比盯代码效率高得多。
我之前做的一块板子，就是因为在 LAN8720 的 VDDCR 引脚上少放了一颗 0.1uF 电容，导致 PHY 核心电压不稳定，现象是冷启动偶尔 Link 不上，跑几分钟后网络自动恢复，查了整整两天才发现是器件布局的问题。所以说，FLAN8720 + F407 这套方案只要硬件是正常的，软件层面按部就班就能调通；硬件有问题的时候，再优秀的协议栈也撑不住。希望这份记录能让你少走一点弯路。
