STM32+SR8201F通用驱动包：百兆以太网PHY移植与调试指南

简介：针对SR8201F物联网芯片在STM32平台上的通用驱动代码，面向嵌入式开发与物联网终端设计工程师，解决SR8201F以太网控制器在STM32平台上的底层适配与快速移植问题。压缩包内共2个文件，采用1个头文件加1个源文件的精简结构：头文件提供寄存器映射、接口声明及关键宏配置，源文件实现ETH_Start、DMA收发等核心函数，覆盖MAC初始化、DMA启动、数据包发送与接收完整流程，可嵌入裸机或RTOS工程使用。整体仅32KB，代码轻量紧凑、依赖单一，方便阅读与二次修改。当前已有740人学习下载，适合需要快速验证SR8201F通信链路或为其STM32项目增加以太网能力的开发者。驱动聚焦底层寄存器操作，结构清晰，能帮助使用者省去逐条查阅芯片手册的繁琐，快速完成平台适配与网络收发调试。

1. SR8201F 的 STM32 通用驱动包：国产百兆 PHY 芯片的落地底座

做物联网终端只要涉及有线以太网，STM32 和 PHY 芯片之间的驱动适配就是最先卡住进度的环节。SR8201F 是国产百兆以太网 PHY 芯片，常被拿来和 STM32 组队做联网设备，而这个 zip 的核心价值就落在 stm32_eth.h 和 stm32_eth.c 这两份通用驱动上——它把 MAC 初始化、DMA 描述符管理、收发状态机这些容易被底层细节拖住的逻辑，提前理好了一条可复用的路径。适合正在做联网采集器、网关、电力终端这类产品的嵌入式开发人员，尤其是刚拿到 SR8201F 样片、想省掉自己从零折腾 PHY 适配的人。下面我按拆包顺序讲：文件结构、移植步骤、收发链路逻辑，再挑几个调试中实际踩过的坑展开，最后给一套上板验证方法。

2. stm32_eth 驱动结构解剖：从文件布局到函数调用链

2.1 PHY/MAC/DMA 三层职责划分与驱动边界

以太网硬件栈分成三层：PHY、MAC 和 DMA。PHY 负责物理层信号转换，把网线上的差分模拟信号转成 MAC 能识别的数字电平；MAC 负责以太网帧封装、CRC 校验和流量控制；DMA 负责把内存里的数据搬进搬出，不占 CPU 做逐字节搬运。SR8201F 属于 PHY 层，它通过 RMII/MII 接口与 STM32 内置的 MAC 连接，而 stm32_eth.c 里写的内容正好落在另外两层——MAC 寄存器配置和 DMA 收发通道管理，外加一条 MDIO 总线用来读写 PHY 内部寄存器。

这套分层思路决定了驱动边界：换不同厂商的 PHY 时，MAC/DMA 部分几乎不用动，只需要改 PHY 地址宏、复位引脚定义和少量 PHY 寄存器操作函数。我拆这份驱动时最先确认的点就是分层是否干净。如果一份驱动把 PHY 初始化、MAC 初始化、DMA 配置全部揉进一个大函数，后续换 PHY 型号就要整个重写，那这份资源的复用价值就大打折扣。stm32_eth.c 的做法相对标准：ETH_Init 负责 MAC 和 DMA 整体配置，ETH_Start 负责使能收发状态机，PHY 的相关操作独立成子函数，由上层按业务需要调用。

这里要理解一个容易混淆的点：PHY 芯片本身不跑协议栈，它只处理物理信号、自动协商、链路状态检测这些事。像 ping 通、TCP 连接这些功能由上层协议栈完成，而驱动只保证一件事——把上层给的数据包原样从网线发出去，把网线上收到的包完整交到内存缓冲区。所以评估这份驱动代码时不用看它带不带 TCP/IP 栈，重点看 MAC 初始化是否正确、DMA 描述符环管理是否可靠、收发中断/轮询流程是否闭环。

2.2 stm32_eth.h 里必须关注的宏与结构体

打开头文件，先把进出口信息确认清楚。一个典型的 stm32_eth.h 会包含三类定义：PHY 相关参数、DMA 描述符结构体、缓冲区配置宏。下面这段代码是按这份驱动的通常形式还原出来的核心定义，实际使用时要对照你手上的头文件内容做调整。

/* PHY 地址与复位引脚 */ #define SR8201F_PHY_ADDR 0x01 #define SR8201F_RESET_PORT GPIOB #define SR8201F_RESET_PIN GPIO_PIN_12 #define SR8201F_RESET_CLK_EN() __HAL_RCC_GPIOB_CLK_ENABLE() /* DMA 描述符数量与缓冲区尺寸 */ #define ETH_TX_DESC_CNT 4 #define ETH_RX_DESC_CNT 4 #define ETH_RX_BUF_SIZE 1524 #define ETH_TX_BUF_SIZE 1524 /* 增强型 DMA 描述符结构体 */ typedef struct { uint32_t Status; /* 描述符状态字 */ uint32_t Control; /* 控制字：长度、缓冲大小、OWN 位 */ uint32_t BufferAddr; /* 数据缓冲区地址 */ uint32_t NextDescAddr; /* 指向下一个描述符 */ } ETH_DMADescTypeDef;

逻辑说明：PHY 地址宏决定 MDIO 总线访问哪个 PHY 器件，SR8201F 的 PHYAD 引脚电平组合会映射到这个地址，你板子上如果只有一个 PHY 芯片，通常就是 0 或 1。描述符数量决定 DMA 同时在飞的数据帧个数，4 个收发描述符对百兆网络够用，但如果你在上面跑 TCP 大吞吐，建议把接收描述符加到 8 个。缓冲尺寸 1524 是在标准以太网 MTU 1500 基础上加上 14 字节以太网头、可能的 VLAN 标签和 CRC，留了余量。

2.3 stm32_eth.c 函数执行顺序与状态转移分析

驱动代码的执行顺序可以画成一条清晰的链路：ETH_Init 先做时钟使能、MAC 软复位、DMA 描述符初始化，然后配 MAC 地址、帧过滤模式和 DMA 突发长度；ETH_Start 负责启动 MAC 和 DMA 的收发状态机；之后驱动进入工作态，收包、发包分别由 ETH_ReceiveFrame 和 ETH_TransmitFrame 完成。

ETH_Start 函数在项目摘要里有明确代码，它体现了一个重要的时序细节：先使能 MAC 的发送状态机，清空发送 FIFO，再使能 MAC 接收状态机，最后才启动 DMA 的发送和接收。这个顺序是有讲究的。DMA 是从 MAC 手里拿数据的，如果先启动 DMA 接收而 MAC 还没进入接收状态，描述符可能被 DMA 写异常；反过来先使能 MAC 而不开 DMA，收到的帧会堆积在 FIFO 里直到溢出丢包。驱动里特意在中间调用 FIFO flush，目的是清掉 MAC 软复位后残留的脏数据，避免 DMA 把预留在 FIFO 里的垃圾当成有效帧搬进内存。

这个状态机还有一个容易被忽略的点：ETH_Start 不会阻塞等待链路建立。PHY 的自动协商是异步完成的，Link 起来通常要几百毫秒到一秒，驱动必须容忍这个时间窗口。所以实际工程里应该在 ETH_Start 之后轮询 PHY 的 BMSR 寄存器（地址 0x01）里的 Link Status 位，或者使能 PHY 中断，等 Link 起来之后再让协议栈进入就绪状态，否则会出现"程序启动马上 ping 不通，过几秒自己又通了"的怪象。

3. 移植到 STM32F407：RMII 接线、时钟和 GPIO 配置

3.1 RMII 接口九根线与原理图逐根核对

SR8201F 与 STM32 的典型连接方式是 RMII 模式，因为它只需要 9 根信号线，引脚占用少，布线也容易。引脚清单大致如下：

移植时最容易翻车的就是 REF_CLK。RMII 只支持一种时钟频率：50MHz，而且要求 MCU 和 PHY 之间时钟同源。常见做法有两种：一是由有源晶振产生 50MHz 同时喂给 STM32 的 REF_CLK 引脚和 SR8201F 的 XI 引脚；二是用 STM32 的 MCO 引脚输出 50MHz 给 PHY。第二种方案少一颗晶振但要注意 MCO 的输出能力，驱动电阻和负载电容选不好会直接导致信号过冲或欠幅。原理图核对时不要只看线连没连，要确认时钟来源只有一个，两个芯片各自接独立 50MHz 晶振是跑不通的。

3.2 50MHz 参考时钟的两种来源与切换逻辑

如果采用 STM32 的 MCO 输出 50MHz，需要在系统初始化阶段把 MCO 配置正确。MCO1 从 PLL 分频出来，MCO2 可以直接选择 PLL 的第二个输出，具体哪个时钟源能整除出 50MHz 取决于你的系统主频。比如系统时钟 168MHz，倍频到 336MHz 再二分频就能出 168/2 的整数不可靠，通常用 PLLQ 单独分频，这部分要照着对应型号的参考手册仔细核算。

我在一个平台上踩过这样的坑：系统主频 168MHz，想通过 PLL 分频输出 50MHz，结果配置出来的实际频率是 50.4MHz，和标称值差了 0.8%。对 RMII 来说 50ppm 级别的偏差才允许，0.8% 会导致 PHY 偶尔能协商上百兆速度但数据采样出错，尤其在高低温环境下更明显。后来改成外接 50MHz 有源晶振直接给 PHY，MCU 侧用同一个晶振源，问题就消失了。所以如果板子空间允许，优先用外部 50MHz 晶振，省掉 MCO 分频的频谱纯度和驱动能力这两重不确定性，这也是多数模块方案的标准做法。

3.3 GPIO 复用配置与 MDIO 上拉要求

RMII 引脚必须映射到 STM32 以太网外设的专用复用功能上，配置时要调用 GPIO_PinAFConfig 把每个引脚切到 AF 模式。值得注意的是 MDIO 这条线，它是开漏双向信号，必须加上拉电阻，典型值 2.2kΩ 到 4.7kΩ，否则 MDIO 读操作在高电平区间会被寄生电容拉低，造成读到 0xFFFF 或者间歇性错误。很多板子把 MDIO 和 MDC 当成普通数字信号忽略上拉，这是 PHY 管理接口稳定性的第一杀手。

GPIO 速度等级也直接关系到信号质量。RMII 的 TXD、TX_EN、RXD 都工作在 50MHz 边沿附近，GPIO 速度至少要配到 High，不能默认 LOW。速度等级配低会拉长信号上升沿，在长走线上产生码间干扰；配过高又可能引入过冲和 EMI。量产板我会把 RMII 数据脚速率固定在 High，管理接口 MDC/MDIO 用 Medium 即可，MDC 本身频率一般也就 2.5MHz 左右，不需要 High 等级。

3.4 第一次上电：读 PHY ID 验证链路

驱动移植完第一步不是急着 ping 网关，而是先确认 MCU 能通过 MDIO 总线正常访问 SR8201F 内部寄存器。标准做法是读寄存器 0x02 和 0x03，这两个寄存器存放 PHY 厂商 ID 和器件型号。能读到预期值，说明 MDIO 物理层、PHY 地址、电源和复位都正常；读不到就直接定位到硬件或时钟问题，不用往下查协议栈。

uint16_t phy_id_high = 0; uint16_t phy_id_low = 0; /* 读 PHY 地址 0x01 的寄存器 0x02 与 0x03 */ phy_id_high = MDIO_ReadRegister(SR8201F_PHY_ADDR, 0x02); phy_id_low = MDIO_ReadRegister(SR8201F_PHY_ADDR, 0x03); if (phy_id_high == 0xFFFF || phy_id_low == 0xFFFF) { /* 总线不通，优先检查 MDIO 上拉和 PHY 复位引脚 */ } else { /* 读到 ID 说明 MDIO 链路已通 */ }

逻辑说明：MDIO_ReadRegister 需要自己实现或用驱动里现成的函数，本质是操作 MAC 的 MACMDIOAR 寄存器发起读事务，然后轮询 MACMDIOAR 的忙标志位直到读完成。参数 phy_id_high 和 phy_id_low 对应两个 16 位 ID 寄存器，具体数值以 SR8201F 数据手册为准。如果这里返回 0x0000 而不是 0xFFFF，多半是 MDIO 线上有应答但数据线短路到地；如果是 0xFFFF，基本可以判断 PHY 没有回应，检查方向应该是：PHY 供电是否齐全、复位脚有没有被外部器件拉死、PHYAD 地址是否和宏定义对得上。

读 ID 通过后，再做一次软复位请求验证：向 PHY 寄存器 0x00 写入 0x8000，等它自动清掉复位位。这一步能确认控制通路也正常，之后才进入真正的功能和速度验证。

4. 驱动收发链路实现：描述符环、状态机与 buffer 管理

4.1 DMA 描述符环的内存布局与初始化

STM32 以太网 DMA 使用描述符环（Descriptor Ring）管理数据缓冲区，每个描述符 16 字节，包含状态、控制、缓冲区地址和下一个描述符地址四个字段。收发各有一个独立的描述符环，环上每个描述符要么归软件拥有（SW），要么归 DMA 硬件拥有（HW），核心标志是控制字里的 OWN 位。DMA 收到数据后会找到 OWN=1 的接收描述符，把帧写入其关联缓冲区，清 OWN 位，然后更新 DMA 自己的尾指针；软件发现某个描述符 OWN=0，就知道这是新收到的帧。

初始化时要把所有接收描述符的 OWN 位置 1，缓冲区地址填成实际内存地址，并把环的最后一个描述符的 NextDescAddr 指回首地址，这样才能形成闭环。描述符和缓冲区都要做内存对齐，STM32 要求描述符按 4 字节对齐，缓冲区建议按 32 字节对齐，以免 DMA 突发传输跨过缓存行边界时出现问题。

for (uint8_t i = 0; i < ETH_RX_DESC_CNT; i++) { RxDesc[i].Status = 0; RxDesc[i].Control = ETH_DMA_RX_OWN | ETH_DMA_RX_BUFFER_SIZE(ETH_RX_BUF_SIZE); RxDesc[i].BufferAddr = (uint32_t)&RxBuf[i][0]; RxDesc[i].NextDescAddr = (uint32_t)&RxDesc[(i + 1) % ETH_RX_DESC_CNT]; }

逻辑说明：ETH_DMA_RX_OWN 是把描述符的控制位第 31 位置 1，表示描述符归硬件使用；ETH_DMA_RX_BUFFER_SIZE 宏把缓冲区长度写入控制字的低 15 位，告诉 DMA 这个描述符关联的缓冲区能装多少字节。NextDescAddr 用取模方式组成环，最后一个描述符指回首地址。这段代码在 ETH_Init 里执行一次，之后软件每次处理完一包，要把 OWN 位和缓冲区地址重新写回去，否则描述符被消费完以后 DMA 就停摆了。

4.2 ETH_Start 使能时序与收发状态机迁移

ETH_Start 这段代码虽然短，但它牵着一个完整的状态机迁移序列，值得逐句展开。第一句使能 MAC 发送状态机，意味着 MAC 开始接受上层递交的帧并通过 MII/RMII 接口向 PHY 发送；第二句 flush 发送 FIFO，把软复位或前一次异常残留的数据清掉，防止旧数据混在新链路里；第三句使能 MAC 接收状态机，MAC 开始把收到的帧写入接收 FIFO；最后两句分别启动 DMA 发送和接收，让 DMA 开始搬运。

这个顺序的隐含条件是：DMA 和 MAC 之间是流水关系，MAC 是生产者/消费者，DMA 是搬运工。生产链先转起来，搬运工再启动，才不会出现空转或丢数据。反过来先启动 DMA，DMA 会立即去扫描描述符环，但此时 MAC 接收未使能，环上的 OWN 位状态还没准备好，DMA 可能在错误时机把环尾指针推进，导致后续收包错位。

还有一个细节值得注意：ETH_Start 通常只执行一次，但实际工程中链路 down 之后重新 up，不需要重新跑完整的 ETH_Init，只需要重新调用 ETH_Start 并把接收描述符重新挂上环。很多开发者在断线重连时把整个 MAC 和 DMA 全部软复位重来一遍，反而引入了不必要的时序窗口。我在项目里只用 PHY 的协商状态和 DMA 状态机做联动，链路 down 时暂定 DMA 收包，up 后再恢复，效率高很多。

4.3 轮询与中断收包两种模型的实现差异

驱动提供的收包方式通常有两种：轮询和中断。轮询模型在主循环里不断调用接收处理函数，检查当前接收描述符的 OWN 位是否被 DMA 清掉，如果清了就说明新包已到位。这种模型的好处是代码简单、无并发问题，坏处是网络空闲时 CPU 一直空转，中断延迟高，不适合大流量场景。

uint8_t ETH_ReceiveFrame(void) { if ((RxDesc[RxIndex].Status & ETH_DMA_RX_OWN) != 0) { return 0; /* DMA 还没写完，说明无新包 */ } /* 处理当前描述符里的帧 */ ProcessFrame(&RxBuf[RxIndex][0], RxDesc[RxIndex].Status & ETH_DMA_RX_LENGTH_MASK); /* 重新挂回描述符给 DMA */ RxDesc[RxIndex].Status = 0; RxDesc[RxIndex].Control = ETH_DMA_RX_OWN | ETH_DMA_RX_BUFFER_SIZE(ETH_RX_BUF_SIZE); RxIndex = (RxIndex + 1) % ETH_RX_DESC_CNT; return 1; }

逻辑说明：RxIndex 是软件维护的当前处理下标，每次从环上取一个描述符。Status 里的 OWN 位由 DMA 在写完后清零，长度字段记录实际接收字节数。处理完帧之后必须把 OWN 位重新置回 1，否则 DMA 认为该描述符不可用，会在环上等待。参数里最需要留意的是 ETH_DMA_RX_LENGTH_MASK，它从状态字里取出实际帧长度，错用成固定 1524 会把没填满的缓冲区内容一起交给上层，造成字节错位。

中断模型则是在 DMA 接收完成时触发 EXTI 或以太网中断，在中断服务函数里标记事件，主循环再处理。中断模型的关键有两点：一是中断服务函数里只做描述符摘取和事件标记，帧处理放主循环，避免在中断里执行协议栈回调造成嵌套过深；二是接收描述符环的处理速度必须快于 DMA 写环的速度，如果软件处理一帧需要的时间超过网线上来一帧的时间间隔，环形缓冲会被冲掉。百兆网络满速时每帧间隔大约 96 纳秒起步，实际受块长影响，所以接收描述符数量要留够，4 个只是下限，跑 TCP 大包场景我一般配 8 到 12 个。

4.4 缓存一致性、对齐与内存屏障处理

在 STM32F4 这类不带 Cache 的内核上，以太网 DMA 和 CPU 共享内存，只要对齐正确，基本不存在缓存一致性问题。但如果换用带 Cache 的 STM32H7 平台，DMA 搬运的数据会经过 Cache，CPU 读缓冲区时可能读到旧数据。这个问题在拆这份驱动时就要预先留好处理口：要么把以太网缓冲区所在的 RAM 区域配置成不缓存属性，要么在收包前执行 Clean/Invalidate 操作。

内存屏障问题往往被忽略。DMA 写描述符是硬件行为，CPU 读描述符时如果没有做编译屏障，编译器可能把读操作重排到其他位置，导致 CPU 拿到的 OWN 位是过期的。裸机代码里我一般用 volatile 修饰描述符结构体字段，或者加 __DSB() 指令做隔离。RTOS 环境下更要注意：收包任务和 DMA 中断不是同一个上下文，描述符的读写最好通过临界区保护，避免任务切走时描述符被 DMA 更新的竞争窗口拉长。

5. 避坑手册：SR8201F 驱动移植中的 5 个典型翻车现场

5.1 现象：读 PHY ID 全 0xFFFF

上电后执行读寄存器操作，返回的 phy_id_high 和 phy_id_low 都是 0xFFFF，MDIO 总线上完全看不到 PHY 应答。排查时先查电源：SR8201F 的模拟和数字电源是不是都已经稳定，很多板子共用一路 LDO，上电瞬间电压爬坡时间太长，PHY 内部复位逻辑没有完成初始化。其次量复位脚的波形，复位脚必须在电源稳定后拉低至少 10 毫秒再释放，不少复位电路用简单的 RC 复位，时间常数算得不够，PHY 还没完成复位时序就被强行访问。解决方法是把复位脚直接用 GPIO 控制，上电延时 50 到 100 毫秒后拉高，并在读 ID 前做一次 PHY 软复位，给足初始化窗口。

5.2 现象：Link 状态正常但收不到任何包

PHY 的状态寄存器显示链路已经是 up，网线也插着，但协议栈抓不到任何数据帧。这种问题八成出在 RMII 时钟源上。我排查过一个具体案例：板子上 MCU 和 PHY 各接了一颗独立 50MHz 晶振，频率都标称 50MHz，但两颗晶振的实际频率差超出 RMII 允许范围，MCU 侧 MAC 采不到 PHY 发送数据的稳定相位，导致接收端完全静默。解决方法是改成单一时钟源，由 MCU 的 MCO 输出 50MHz 同时喂给 PHY，或者由 PHY 的 REF_CLK 输出反向给 MCU，确保发送接收两侧的采样参考完全同源。检查时用示波器量 REF_CLK 频率，两台晶振各自的频率偏差通常都在量程外，但加起来的累积偏差就超过了 MAC 的容限。

5.3 现象：发送偶发失败，重传之后自己恢复

跑一段时间后偶尔出现某个包发送超时，但过一会儿又自动好，看起来像是链路间歇断了一下。对照描述符状态字查具体错误位，发现 TX 描述符里出现了 TX Underflow 或 Late Collision 标志。前者是 DMA 发送时 FIFO 数据没跟上，常见原因是你配置的 DMA 突发长度超过了总线带宽，或者发送描述符环里数据还没准备完就被 DMA 抢走；后者是发送过程中检测到碰撞，多半是链路对端或线缆问题，和驱动关系不大。解决做法是把 DMA 发送突发长度从 32 字节降到 16 字节，同时确保发送描述符的 OWN 位只在缓冲区内容完全准备好之后才置位。我在 RTOS 环境里还见过另一个坑：发送任务优先级低，OWN 位置位后任务被抢占，DMA 在总线带宽空闲时提前把未填完的缓冲区发出去，所以发送描述符的填充和置位要放在同一临界区内完成。

5.4 现象：高负载下错包率明显上升

用大包连续压测时，抓包工具发现问题帧比例升高，CRC 错误和 Alignment 错误都有。这类问题通常集中在物理层：GPIO 速度等级配置太低导致上升沿恶化，或者 PCB 走线过长。另外值得核查的是 RMII 的 CRS_DV 信号，这个信号在 RMII 模式下由 PHY 驱动，如果在接收期间抖动，MAC 会把帧当成错误帧丢掉。我在一个项目里遇到 GHZ 级别的串扰导致 CRS_DV 误触发，后来在信号线上串联了 22Ω 电阻，并把 GPIO 速度调到 High，错包率从千分之几降到十万分之一以下。调试时用示波器分别量 TXD 和 RXD 的边沿，看有没有明显的振铃或触发电平抖动，一步定位是驱动配置问题还是硬件布线问题。

5.5 现象：中断模式收包丢首包

中断收发模式下，程序启动后第一包往往收不到，后面的通信却正常。这个现象通常是使能顺序造成的：ETH_Start 使能 DMA 接收后，接收描述符环上所有 OWN 位都是 1，DMA 收到帧会把 OWN 清零并置起中断标志。但如果中断在 DMA 初始化完成前就已经处于使能状态，或者中断标志在 ETH_Start 之前被意外置位，中断服务函数会在描述符还没挂好时被触发，一次性把环上所有描述符误判成已接收帧。解决方法是严格按顺序操作：先初始化描述符环，再启用 DMA 中断，最后调用 ETH_Start，并在启用中断之前主动清一次中断挂起标志。不要小看这个顺序，我在三个不同平台上都因为这段先后关系复现过同样的问题，改成固定顺序后再没出现过。

6. 上板验收与进阶调试：回环自测、吞吐压测与多平台移植

驱动跑通之后，建议按由浅入深的三层顺序做验收，避免"能 ping 通就万事大吉"的错觉。

第一层是 PHY 内部回环。向 PHY 寄存器 0x00 写入回环模式位，数据从 MAC 发出后不经网线，直接由 PHY 内部返回给 MAC。在协议栈没跑起来之前，这个测试可以验证 MAC/DMA/PHY 的完整数据通道是否畅通。操作方法是配置回环位后，直接构造一个帧调用发送函数，看同一描述符环上是否在短时间内收到长度相同的数据。收得到说明链路数据通路正常，收不到就回到 MAC 配置层面查问题。

第二层是外部回环。用网线把两块开发板直连，一块主动发，一块被动收。这里有一个快速判断物理层是否正常的技巧：观察 PHY 状态寄存器里的 Link 位是否在插线后变成 1，同时看对端是否也报告 Link up。只有两边都 up，才说明网线、变压器、PHY 的物理链路没问题。外部回环测试要用不同帧长的包分别跑，64 字节小包测突发处理能力，1518 字节大包测缓冲区管理和 CRC 校验路径，两种包都能长时间互发不丢，驱动基本可以认为稳定。

第三层是吞吐量压测。没有现成带宽工具时，用一个简单的计数发包程序：发送端连续发送 10000 个大包，接收端统计收到的帧数和字节数，计算实际吞吐。我在百兆环境下的经验值：裸机驱动跑满 90Mbps 以上才算调通，如果只能跑二三十兆，优先怀疑描述符环数量不足或中断处理太慢，而不是怀疑 PHY 能力。

最后一层是多平台移植。这份驱动代码的移植规律是：F1/F4 系列主要管 GPIO 复用号和 RCC 时钟使能，H7 系列额外要处理 Cache 和 RAM 属性配置，L4 系列则要注意低功耗模式下以太网时钟是否被切断。我习惯在移植前先把目标型号的参考手册以太网章节通读一遍，重点标注 DMA 描述符和 MAC 寄存器的地址偏移差异，再对照驱动里的宏定义逐一修正。移植完不要直接跑到业务代码里，先在空工程里跑回环和外环测试，确认和原平台行为一致，再往上层挂协议栈。

从那以后，我每次拿到一份新 PHY 驱动，都会强制自己先走一遍这套验证流程：读 ID、回环、外部直连、大包压测，全部通过才允许合入业务代码。这个习惯帮我挡掉了好几次"上板能起来但压力测试就翻车"的返工。希望帮到你。

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