拿到这个题目时我第一反应是这又是一篇“老生常谈”的以太网接口文章。但真正动笔前结合我之前在项目里被 LAN8720A 折腾得死去活来的经历我觉得还是有不少细节值得单独拿出来聊一聊的。STM32F407 内置的 MAC 控制器本身不复杂真正决定项目成败的往往是你对 PHY 芯片、RMII 接口时序以及外围电路的理解深度。这篇文章我打算完全从一个实际做项目的工程师视角出发把 STM32F4 的以太网硬件架构拆开揉碎重点讲讲 LAN8720A 这颗 PHY 与 MAC 之间的接口设计、参考电路怎么画、时序怎么对、以及我实际调试中踩过哪些坑。如果你正准备在自己板子上跑以太网或者正在为“为什么我的网口灯不亮”发愁这篇文章应该能帮你省下不少时间。1. 先搞清楚MAC和PHY各管什么再谈架构很多新手拿到 STM32F4 的数据手册看到“以太网外设”这一章就直接懵了。其实你只要搞明白一件事整个架构就清晰了STM32F4 内部只集成了 MAC媒体访问控制层控制器也就是数据链路层那一坨逻辑而真正负责把数字信号变成差分模拟信号送上网线的 PHY物理层芯片是需要你自己外接的。1.1 为什么STM32做以太网必须要外挂一颗PHY这么说吧MAC 和 PHY 的关系就像是“打包员”和“快递员”。MAC 负责把 IP 数据包加上帧头、帧尾、CRC 校验然后塞给 PHYPHY 这颗芯片则负责把这些数字比特流按照 10/100M 以太网的物理层规范进行编码比如 MLT-3、4B/5B并驱动双绞线传输。此外PHY 还承担了链路协商、状态检测、中断上报等脏活累活。STM32F4 系列尤其是 F407、F429、F469 等型号内置的 MAC 支持 10/100Mbps 速率符合 IEEE 802.3 标准。但它对外只提供了 MIIMedia Independent Interface或 RMIIReduced Media Independent Interface接口并没有把物理层的差分信号直接引出来。原因很简单数字工艺难以高效实现模拟前端而且以太网物理层需要独立的隔离变压器和阻抗匹配集成在 MCU 里既不经济也不灵活。所以你需要一颗外置 PHY 芯片来完成“数字→模拟”这一步。1.2 LAN8720A 凭什么成为入门首选市面上兼容的 PHY 芯片实在太多了TI 的 DP83848、Micrel 的 KSZ8081、Marvell 的 88E1512以及今天的主角 LAN8720A。我在几个项目里都用了 LAN8720A选它不是因为它是性能最强的而是因为它“够用、便宜、好买、资料多”。LAN8720A 是 Microchip原 SMSC出品的一颗低功耗 10/100M 以太网 PHY采用 RMII 接口与 MAC 连接。它最大的优势是外围电路极其精简只需要一个 50MHz 的参考时钟源不需要额外提供 PHY 所需的 25MHz 晶振外围网络。此外它还内置了 1.2V 稳压器一颗 3.3V 供电就能跑功耗也低非常适合对 BOM 成本敏感或 PCB 面积受限的嵌入式产品。当然你如果在做车载以太网或者工业级高可靠性产品考虑温度范围更为宽裕的 DP83848 或者带完善诊断功能的 KSZ8081 可能更合适。但做好消费级、工业级大部分场景LAN8720A 完全够用。下面我要讲的接口设计均以 RMII 为例这也是 STM32F4 LAN8720A 最常用的搭配方式。2. RMII接口才是硬件设计的核心RMII 接口的诞生本质上是为嵌入式系统优化过的“减肥版”MII。标准 MII 需要 16 根数据/控制线对于 MCU 这种引脚资源紧张的器件来说太奢侈了。RMII 把数据线从 8 位降到 2 位同时将时钟频率从 25MHz 提高到 50MHz用 DDR双沿采样方式在 50MHz 时钟下完成 100Mbps 数据传输。2.1 信号线逐一拆解STM32F4 的 RMII 接口总共只需要 7 根信号线我在这里按功能分类给你过一遍TXD[1:0]发送数据线2 位并行数据。当 TX_EN 拉高时PHY 在 REF_CLK 的上升沿采样这两根线上的数据。10M 模式下这 2 位数据是重复采样传输的100M 模式下才是真正的 2 位并行。TX_EN发送使能信号。MAC 在要发送数据时拉高数据线开始有效空闲时拉低PHY 知道线上没有有效数据。RXD[1:0]接收数据线。PHY 在 REF_CLK 上升沿驱动这两根线MAC 在上升沿采样。CRS_DV该信号是载波侦听和数据有效指示的混合信号。当 PHY 检测到链路上有活动时拉高代表有数据正在接收在接收到有效数据时保持高电平在帧间隙或空闲时拉低。MDC 与 MDIO管理接口信号用于配置 PHY 寄存器、读取链路状态。MDC 是管理时钟MDIO 是双向数据线速度较低但非常重要——你后面读 PHY ID、检查 link 状态都要靠这两根线。注意RMII 模式下的 REF_CLK 是由外部统一提供的 50MHz 时钟而不是 PHY 或 MAC 单独产生的。也就是说MAC、PHY 必须共享同一个 50MHz 参考时钟才能保证同步采样。这是最容易出错的地方之一我后面会详细说。2.2 50MHz参考时钟到底该谁出关于 50MHz 参考时钟的来源实际上是整个 RMII 接口设计里最容易迷糊的点。我见过不少人在这里翻车。总共有三种主流做法由外部有源晶振直接产生 50MHz同时给 STM32F4 的 ETH_CLK 引脚和 LAN8720A 的 XI/CLKIN 引脚提供时钟。由 STM32F4 的 MCO 引脚PA8输出 50MHz 时钟分配给 LAN8720A。由 LAN8720A 内部的 50MHz 振荡器方案产生需要 50MHz 晶振挂在 PHY 的 XI、XO 上然后 PHY 把 REF_CLK 反馈给 STM32F4。理论上前两种做法都可以但这里有工程细节要注意。LAN8720A 的 REF_CLK 输入位置在 XI/CLKIN 引脚第 14 脚。如果你用外部有源晶振方案需要确认晶振的输出电平标准是否满足 PHY 的时钟输入要求如果你用 MCO 输出方案一定要注意 STM32F4 的 MCO 引脚本身不是高速专用时钟引脚它在 50MHz 下的输出边沿质量可能不太行建议加个 33 欧姆的串阻来改善信号质量。我建议项目初期采用方案一外部有源晶振因为它把所有时钟解耦开来调试时少一个变量。但要注意外部晶振的输出要走尽量短、阻抗可控的走线避免引入噪声。而 LAN8720A 的时钟输入对占空比有一定要求通常 40%~60%用示波器量一下比较保险。2.3 一个容易被忽略的细节MAC的时钟输入选择STM32F4 的 RMII 模式下MAC 的时钟源必须配置为外部 50MHz而不是内部的 AHB 时钟。这一点在库函数和 HAL 库的初始化代码里都会体现RCC_ETHClockConfig(RCC_ETHCLK_External)或者直接调用HAL_RCC_ETHClockConfig()。也就是说你在画原理图时就要决定好STM32 的 ETH_CLK 引脚PA1必须接入 50MHz 信号。这个信号可以来自外部晶振也可以来自 LAN8720A 的 REF_CLK 输出。如果接错了MAC 侧完全没有时钟哪怕 PHY 芯片本身工作正常你也是死活 ping 不通的。这部分是软件配置的重点后面第 4 章会展开。3. 参考电路与外围器件设计有了接口信号的宏观认识后接下来我们把原理图层面的事情说清楚。网上很多参考电路其实都是直接抄官方评估板的但官方评估板往往隐藏了很多“必须”的细节而这恰恰是项目量产的坑。3.1 LAN8720A电源与复位电路LAN8720A 是 3.3V 单电源供电但其内部集成了一颗 1.2V 的 LDO 稳压器为内核数字逻辑供电。这个 1.2V 电源是通过 VDDCR第 6 脚即数字内核稳压器输出引出的必须外接一个旁路电容到地。这里有个关键点LAN8720A 内部 LDO 需要一个“电荷泵”来产生 1.2V 的驱动能力所以芯片的 12 脚VDDCR和 13 脚VDD之间要接一个 1uF 的电容同时需要接一个 10k 电阻到地作为负载官方叫法是“外部负载电阻”。很多人画板时图省事直接把这个电阻省了结果芯片工作不稳定频繁死机、ping 不通查了很久才发现是这里的问题。我自己的经验是这个电阻一定要加而且尽量靠近 VDDCR 引脚放置。复位电路方面LAN8720A 的 nRST第 14 脚是低电平有效复位输入。官方要求复位脉冲宽度至少 1ms且 PHY 的时钟必须稳定后才能释放复位。实际项目里我通常用 MCU 的普通 GPIO 控制复位引脚这样软件可以按需复位 PHY灵活性最高。如果直接用 RC 复位电路要计算好时间常数确保上电后时钟稳定了再释放复位。3.2 网络变压器与RJ45连接PHY 芯片的差分信号不能直接接到 RJ45中间必须经过网络变压器俗称“隔离变压器”。变压器的作用是隔离共模干扰、提供电气隔离和阻抗变换通常是 1:1同时对浪涌和静电起到一定防护作用。如果你的 PCB 空间紧张可以直接选用带网络变压器的一体化 RJ45 座比如 HR911105A 这类带隔离变压器的连接器这样省去独立变压器占用的面积也是目前最主流的做法。选择独立变压器时要注意中心抽头的接法LAN8720A 的 TX 差分对中心抽头需要接 3.3V 并串联一个 1k 欧姆电阻类似 Bob Smith 端接RX 差分对中心抽头通过 0.1uF 电容接地。这部分不按规格书画后续 EMC 测试会很难看。3.3 LAN8720A 的LED指示灯电路LAN8720A 提供了两个 LED 驱动引脚nLED1、nLED2分别用于指示链路状态和活动。设计时可以直接通过 330 欧姆电阻连接 LED 到 3.3V但要注意PHY 的 LED 引脚是“灌电流”驱动方式即 LED 点亮时电流是从 VDD 流入 PHY 内部。如果你用推挽方式去驱动 LED反而会导致 GPIO 配置错误或 LED 状态异常。我还遇到过一种情况LED 引脚同时被复用来做其他功能比如低功耗模式唤醒引脚如果没有做跳线隔离可能会互相干扰。建议在量产板设计时将 LED 引脚做成可选焊盘或串接 0 欧姆电阻方便调试时断开。4. 软件配置从寄存器到网络栈硬件搞定了接下来就是软件。STM32F4 以太网这块的软件配置分为两层一是 PHY 寄存器配置通过 MDIO 访问二是 STM32 的 MAC/DMA 配置通过库函数或 HAL 库。很多人卡在“硬件都检查过了为什么还是连不上”的问题上根源往往是 PHY 的初始化没有做对。4.1 先用MDIO把PHY读通再谈其他PHY 芯片上电后默认是工作在自动协商模式下的但你要确认它是否正常工作第一件事就是通过 MDIO 总线读取 PHY 的基本寄存器。LAN8720A 的 PHY 地址通常是 0x00由 RXER/PHYAD0 引脚决定MDIO 操作由 STM32 的 MAC 管理接口控制。我推荐的初始化顺序是配置 STM32 的 ETH 引脚RMII 模式确保 MDC/MDIO、TXD、RXD 等引脚模式正确。使能 ETH 外设时钟并配置为 RMII 模式。通过 HAL_ETH_Init 完成 MAC 层初始化该函数内部已经包含了对 PHY 的复位操作。调用 HAL_ETH_ReadPHYRegister 读取 PHY ID 寄存器寄存器 2 和 3验证 MDIO 通信是否正常。读取 BMSR 寄存器寄存器 1检查链路状态位bit 2是否为 1。如果第 4 步读数不对说明你的 MDIO 时序或引脚配置有误。如果第 5 步链路状态为 0说明 PHY 与对端设备没有协商成功可能是网线没插好或者对端设备本身没开机。上面说的是裸机/RTOS 移植 LwIP 的场景。本质上只要 STM32 的 ETH 驱动代码很多工程直接用 CubeMX 生成的和 LAN8720A 的复位配置正确剩下的就是 LwIP 的事了。这里有个小技巧很多网上的驱动模板里PHY 芯片的型号是 DP83848如果你直接拿过来跑 LAN8720A会因为 PHY 地址不同DP83848 通常为 0x01、LAN8720A 为 0x00而导致读取链路状态失败。改起来很简单——把 PHY 地址宏改成 0x00 即可。4.2 STM32CubeMX 下的快速配置如果你用的是 STM32CubeMX 生成初始化代码配置以太网外设时会让你选择 PHY 芯片型号。很遗憾默认列表里可能没有 LAN8720A但你可以选择“Custom PHY”或直接指定 PHY 地址为 0。关键参数如下RMII 模式50MHz 时钟源外部提供。发送/接收 Buffer 描述符数量根据你内存空间来一般每个方向 4 个够用。PHY 地址 0x00。自动协商使能速率设为 100M/10M 自适应。生成代码后还要额外检查一下HAL_ETH_Init中的 PHY 配置结构体是否正确。因为 CubeMX 不会自动生成 LAN8720A 的特定寄存器初始化序列比如把自动协商的广告值寄存器写对。好在 LAN8720A 通常默认自动协商就开了你可以先跑起来再慢慢调。4.3 关于“Class B 时钟自检”和非 Linux 设备树配置热词里提到了“stm32f4安全诊断class b时钟自检”这里也顺带提一句。在功能安全相关的项目比如医疗或工控产品中系统会要求对以太网外设时钟、甚至 MCU 内部时钟进行周期性自检确保时钟偏移不会影响通信可靠性。这种场景下不要单纯依赖 PHY 的自动协商还应当在应用层做时钟偏差校验或者利用 MAC 的状态计数器监测 CRC 错误帧数量。至于“PHY 设备树配置”那是 Linux/嵌入式 Linux 的场景。如果你把 STM32F4 跑起来的是 Linux比如经过 MMU 的 Cortex-A 处理器设备树里需要定义mdio总线节点并在以太网节点中引用 PHY 的设备树节点。此时 LAN8720A 对应的 compatible 字段一般为ethernet-phy-id0007.c0f1reg 属性设为 0x00对应 PHY 地址。设备的 max-speed 可以设为 100。这一块不展开太多但调试时如果遇到 “PHY 没有发现”多半就是设备树中的 phy 地址和实际硬件引脚不一致。5. 实际项目中踩过的坑与排查清单这章是我最想写的部分。因为所有参考电路和初始化代码都能在网上找到但真正的项目价值其实是在你踩坑之后总结出的经验。5.1 典型的“死活不通”场景场景一上电后 PHY 的 50MHz REF_CLK 没有输出。检查到外部晶振和 LAN8720A 引脚接触良好但测量 XI/CLKIN 引脚始终没有波形。后来反应过来LAN8720A 的 XI/CLKIN 输入必须满足一定电平阈值当时用的是 3.3V 有源晶振输出但输出端电容过大导致边沿太缓PHY 内部时钟电路无法启动。处理办法减小晶振输出负载电容或改由 MCU 的 MCO 引脚提供时钟并加 33Ω 匹配电阻。场景二MDIO 读到的 PHY ID 是 0xFFFF。这通常说明 MDIO 总线上的数据根本没被 PHY 正确应答。排查思路先量 MDC 是否有时钟再看 MDIO 数据线上的上下拉电阻是否匹配。LAN8720A 的 MDIO 引脚内部有一个弱上拉/弱下拉如果你外部又并联了很大的上下拉电阻会拖垮总线电平。建议 MDIO 加 1.5k 欧姆上拉MDC 不需要上拉。场景三能 ping 通但大包传输总是丢包。这种怪问题往往不是 PHY 或 MAC 逻辑的问题而是 STM32F4 的 RX DMA 描述符、以太网缓冲区在内存中的地址对齐不对或缓存一致性没有处理好。在带 Cache 的 MCU 上比如 F7 系列这个问题尤其突出。F4 虽然没有 D-Cache但 DMA 描述符必须在 4 字节对齐且以太网 Buffer 最好放在专门的 SRAM 区域如 ETH DMA 描述符放在 AHB SRAM。如果通信一繁忙就丢包优先检查这里。5.2 硬件排查速查表下面这个表格是我在实际调试过程中总结出来的基本覆盖了“网口不通”的大部分排查路径你可以直接拿去用。现象检查点工具/手段网口灯完全不亮1. 网络变压器及 RJ45 焊接2. LAN8720A 供电3.3V 和 1.2V3. 50MHz 时钟是否存在万用表、示波器灯亮但 ping 不通1. MDIO 是否能读到 PHY ID2. RMII 信号线连接重点查 CRS_DV3. STM32 ETH 时钟选择是否外部示波器量 RMII 信号协商速率不对全是 10M1. PHY 自动协商相关寄存器配置2. 对端设备端口协商能力3. 网络变压器参数是否匹配 100M读 PHY 寄存器值大包丢包、CRC 错误1. STM32 ETH DMA 描述符内存对齐2. PCB 差分走线阻抗控制3. 网线质量抓包工具、修改缓冲区5.3 关于热词里“ESP32 连接 LAN8720 的 3 个问题”热词里有人提到“esp32连接lan8720以太网模块常遇到的3个问题”这和 STM32F4 的调试思路在原理上是一致的我也顺带说几个跨平台通用的法则不管是什么 MCU接 LAN8720A 时最普遍的问题是“复位时序不对”。PHY 上电后需要等待时钟稳定再释放复位如果 MCU 在初始化 GPIO 时就把复位引脚拉高PHY 内部可能还未完全稳定导致后续寄存器读写失败。处理方式将 LAN8720A 的复位引脚接到 MCU 的一个普通 GPIO上电后延时 10ms 再拉高复位再延时 1ms 后执行 MAC/PHY 初始化。第二个高发问题是“时钟抖动”。很多情况下 PCB 布局紧凑50MHz 时钟走线过长或参考地不完整导致边沿质量差。排查时可以用示波器看 REF_CLK 的上升沿是否存在振铃。如果有加个小电容或调整匹配电阻。第三个高发问题是“RMII 接口 CRS_DV 信号接线错误”。CRS_DV 是接收路径的关键信号它融合载波侦听和数据有效两个功能如果接错到别的 GPIO接收路径不会有数据。很多移植驱动的朋友都在这里栽过跟头。你可以把这三个问题默认当作“必须先排除”的清单。它们在我调试 STM32F4 时也都遇到过并不是 ESP32 独有。6. 定时器与位宽问题对以太网工程的影响热词里有个“stm32f4 定时器位数”看起来和以太网无关但我实际项目里确实因为定时器溢出问题影响了以太网链路诊断功能的实现。这里稍微花点篇幅说一下背后的逻辑。在以太网项目中特别是做 TCP 连接超时管理或 DHCP 租约刷新你往往需要一个“秒级”的时基。多数人会选择 TIM2 或 TIM5 这类 32 位定时器它们的好处是最长溢出时间可达 100 秒以上1MHz 计数频率下 32 位大约 4295 秒约 71.5 分钟不需要频繁处理溢出中断。而如果你用了 16 位定时器TIM3、TIM4 等在 1MHz 计数频率下每 65.5ms 就会溢出一次处理中断和软件计数器的代码如果不够严谨容易发生计数偏差最终导致链路断线检测不准。我个人建议以太网状态机相关的时基统一挂到一个 32 位定时器上比如 TIM2用 1ms tick 作为基准然后做分频。这样不仅超时判断容易做而且后期如果在协议栈里加入 SNTP、TCP 重传超时等逻辑也能复用同一套时基。定时器位数这个“小概念”在关键时刻很能帮你省事。另外顺带说一个安全诊断话题——热词里提到 class B 时钟自检。在做功能安全诊断时不光要对 CPU 内核时钟做自检往往还需要验证外设时钟是否超出允许漂移范围。以太网的 50MHz REF_CLK 如果来自外部有源晶振和 MCU 系统时钟是异步的做安全分析时需要将其纳入系统时钟故障模式考量。如果没有硬件计数器监测 50MHz 频率可以考虑软件层面周期性地通过 MDIO 读取 PHY 的链路状态并对长时间无收发活动的链路进行重新初始化算是一种软性缓解。7. 一些工具与测试手段的补充建议最后补充一些工具层面的建议帮大家提高调试效率。示波器是硬性要求。至少需要双通道、100MHz 带宽以上的示波器。测量 RMII 信号时探头地线要尽可能短避免地噪声干扰导致假波形。网口测试时可以准备一个“已知好”的交换机或路由器。这样能排除对端设备的问题。另外测试时用短网线1米内避免过长链路引入额外干扰。如果在 PC 端用 Wireshark 抓包注意在 PC 上关闭防火墙否则会看到大量 ARP 请求被拦截的假象。实际测试网络通断最简单的方法是持续 ping 网关观察时延和丢包率。还有一个小工具建议如果条件允许可以用一个带 PoE 供电的调试网口这样在调试低功耗设备时既能通信又能减少一把电源线的干扰。不过 PoE 涉及到变压器中心抽头取电和普通隔离变压器设计不同这一点在初版原理图阶段就要决定好不然后期改板成本高。8. 设计与调试中最重要的三个常识做以太网硬件和软件交叉调试最重要的是要有一个“分层排错”的思维。第一层是硬件物理层PHY 供电对不对、时钟有没有、复位时序对不对。这一层不出问题后面都是空谈。第二层是链路层MDIO 能不能读到 PHY ID、PHY 能不能协商出 100M 全双工。这一层通了才有必要去折腾 IP、MAC 地址以及 LwIP 协议栈。第三层是网络层IP 配好了没有、网关通不通、ARP 能不能解析。很多人一上来就去查 LwIP 代码反而走了弯路。这三个常识是我经历了好几个项目才真正内化的。以前遇到网口不通我第一反应是查驱动代码觉得是软件 bug后来发现 80% 的问题其实出在硬件设计或者 PHY 的初始化时序上。所以后来我每次设计以太网板卡画完原理图都会先对照着 LAN8720A 数据手册的参考电路一项一项过一遍确认无误后再投板这会大大缩短调试周期。这个项目后续如果你要继续推进比如加 PoE 供电、或者改成多网口设计类似的调试思路依然可以复用。不同 PHY 芯片的寄存器定义会有差异但排查路径和接口信号基本大同小异。先把 RMII 和 PHY 调通整个系统的网络部分就等于打通了任督二脉后面的 TCP/IP 协议栈反而都是比较成熟的东西了。
