一 个在 STM32F746 上通过 RMII 接口连接 KSZ8863RLL 三端口交换芯片的项目，卡了整整三天，现象简单得有点“气人”：Port 1、Port 2 都能正常 Link，唯独 Host 口（Port 3）在 PHY 寄存器里的 Link Status 始终是 0，自动协商也一直不完成。这个组合在工业双网口设备里非常常见——STM32F746 带内置 MAC，外接 KSZ8863RLL 做二口交换，CPU 通过 Port 3 接入交换机，实现“一芯双网口”甚至“三网口”的形态。如果你也正在调 RMII，尤其是“MDC 需要上拉电阻吗”“RMII 时钟从哪边给”这类问题还没理清，那这篇文章值得你花十分钟看完。我会按实际调试顺序，把硬件排查、寄存器初始化、时钟配置和常见坑全部拆开讲，每一步都给到可以直接抄的结论和代码。
1. 项目背景：STM32F746 + KSZ8863RLL 的典型架构与 Port 3 定位
1.1 为什么要用交换芯片而不是两个 PHY
很多人在设计双网口设备时，会下意识地选“一颗带双 MAC 的 MCU + 两颗 PHY”的方案。但 STM32F746 这类芯片只有一个以太网 MAC，若需要两个独立网口，常见做法就是外接 KSZ8863RLL 这种“二口交换 + 一个 Host 接口”的芯片。
KSZ8863RLL 的内部结构可以粗略理解为：Port 1 和 Port 2 是两个带 PHY 的物理网口，直接接 RJ45；Port 3 是 Host 端口，专门用来接 CPU 的 MAC 侧接口。CPU 通过 RMII/MII 连到 Port 3，再加上交换芯片的硬件转发能力，就能实现两个物理网口之间的二层交换，同时 CPU 也能访问这两个口。
这个架构最大的好处是：MCU 的以太网 MAC 只需要管理“一条链路”，即 MCU 到 Port 3 的链路；Port 1 和 Port 2 之间的转发由交换芯片自己完成。对于需要做“网桥”、“工业网关”、“串口服务器”这类产品来说，这是个非常经典的硬件拓扑。
1.2 问题现象与初步判断
我这边具体的故障表现是：
- Port 1、Port 2 接网线后，RJ45 的 Link LED 正常亮起。
- MDIO 总线能正常访问，PHY ID 能读出来，说明 MCU 与 KSZ8863RLL 之间的 MDIO 通路是通的。
- 但读 Port 3 对应的 PHY 状态寄存器，Link Status 一直为 0；即使把网线插到 Port 3 对应的外部 PHY 口（注意，这里的“Port 3 外部口”其实在部分型号里是 Host 口，不直接对应 RJ45），状态也不变。
- 用示波器看 RMII 的 TX、RX 信号，TXD 有数据在跳，但 RXD 没有任何反应。
这个现象说明问题不在 MDIO 读写层面，而更可能在 RMII 接口的物理信号、时钟方向、芯片工作模式，或者交换芯片内部对 Host Port 的使能配置上。下面我按调试顺序，从硬件讲到寄存器，把每一步的“为什么”也一并说清楚。
2. RMII 接口硬件排查：MDC 上拉、REF_CLK 与信号完整性问题
2.1 MDC 到底要不要上拉：答案和你想的不一样
先从热搜词里最高频的一个问题说起：MDC/MDIO 需不需要接上拉电阻。很多新手在画原理图的时候，看到 PHY 芯片参考设计里 MDIO 上拉、MDC 没上拉，就开始纠结“是不是漏了”。这里直接给结论：
- MDC 是时钟线，由 MAC 侧（STM32F746）推挽输出，不需要上拉电阻。
- MDIO 是双向数据线，Open Drain 结构，必须要有上拉电阻。通常选 2.2kΩ 到 10kΩ，3.3V 电平下单端 4.7kΩ 是通用选择。
为什么 MDIO 必须上拉？因为 MDIO 总线是半双工三态总线，物理层靠“线与”逻辑实现双向通信。如果不上拉，当驱动端释放总线时，MDIO 会悬空，读出来的数据不是 0 就是随机值，表现为 PHY 寄存器偶尔能读对、偶尔全 0 或全 1。KSZ8863RLL 的 MDIO 引脚内部没有默认上拉，外置上拉是必须的。
之前在实际板子上就遇到过：原理图里 MDIO 上拉电阻位被预留了，但物料贴片时漏贴了 4.7kΩ，结果 MDIO 能读但 10 次里有 4 次读回来是 0xFFFF。后来补上电阻后，读寄存器 100 次全部稳定。
补充一点：MDC 虽然不需要上拉，但如果 MDC 走线过长，建议在源端（STM32 引脚附近）串一个 22Ω 或 33Ω 的电阻，用来减小振铃。MDC 频率不能超过 2.5MHz，这是 802.3 Clause 22 的规定，STM32 HAL 里可以通过时钟分频配置 MDC 频率，后面会讲。
2.2 RMII 的 50MHz REF_CLK：方向决定成败
RMII 接口相比 MII，最大的特点就是复用信号、降低引脚数，代价是所有信号必须严格以 50MHz REF_CLK 为参考时钟。这颗 50MHz 时钟从哪里来，是整个 RMII 调试里最容易出问题、也最容易被忽略的地方。
REF_CLK 有三类提供方式：
- MAC 提供：STM32F746 通过 MCO 引脚输出 50MHz 给交换芯片。
- PHY/交换芯片提供：KSZ8863RLL 自己产生 50MHz 后输出给 STM32 的 ETH_RMII_REF_CLK。
- 独立外部时钟源：用一颗 50MHz 有源晶振同时供给 MAC 和 PHY。
不管选哪种，核心原则只有一个：MAC 和 PHY 必须使用同一个 50MHz 参考时钟源，频率误差通常要求 ±50ppm。
在 KSZ8863RLL 的 RMII 场景下，我建议优先确认“交换芯片是否能作为时钟源输出 50MHz REF_CLK”。如果 KSZ8863RLL 的 X1/X2 引脚被配置为外部时钟输入模式，而外部又没有接 50MHz 时钟，那 Port 3 是永远不可能 Link 起来的。这点和常见的 LAN8720A 不一样——LAN8720A 用 25MHz 晶振内部倍频出 50MHz REF_CLK 输出给 MCU，但 KSZ8863RLL 的 RMII Host 接口对 REF_CLK 的要求需要单独看数据手册确认，不能想当然。
实测遇到过一种“看似正常但实际错误”的情况：做了个外部 50MHz 有源晶振，输出同时接到 STM32 的 ETH_RMII_REF_CLK 和 KSZ8863 的 X1，看起来没问题，但因为选的是 3.3V 有源晶振，而 KSZ8863 某些引脚的 IO 电平域是 2.5V，导致 X1 引脚输入高电平不够，时钟幅度被钳位到 1.8V 左右，交换芯片内部 PLL 锁不住，最终同样的故障现象：Link 不起来。
调试时用示波器量 REF_CLK 引脚，多数情况下只能看到“有没有波形”，但一定要确认幅值是否达到芯片手册要求的 VIH 最低值。RMII 信号线上，50MHz REF_CLK 的边沿质量和幅度，直接决定 RXD 能不能被正确采样。
2.3 容易被忽略的硬件配置：RBIAS 和复位时序
除了 MDC/MDIO 和 REF_CLK，还有几个硬件点会在“Link 不上”时被反复怀疑，但真正出问题时又容易被忽略。
第一是 RBIAS 电阻。KSZ8863RLL 这类交换芯片，通常有一个 RBIAS 引脚，需要外接一个 12.4kΩ（1%）电阻到地，用来设置内部 PHY 的偏置电流。如果这个电阻没焊、虚焊或者阻值差太多，PHY 的 RX/TX 驱动能力会异常，甚至读 PHY ID 都出问题。我排查时第一件事就是用万用表量 RBIAS 对地电阻。
第二是复位时序。有的板上直接把 KSZ8863RLL 的复位引脚和 STM32 的复位接到一起，问题不大；但如果是 MCU GPIO 控制复位，必须在初始化时保证复位释放后等待足够时间，再开始访问 MDIO。通常要求至少等 10ms 左右，保守一点 50ms。如果复位之后立刻读寄存器，交换芯片内部还没完成自检，读出来的状态会误导排查。
第三是 X1/X2 引脚的接法。如果数据手册要求外部输入时钟，那 X1 接时钟源、X2 悬空或按要求处理；如果用无源晶振，则要按晶振负载电容计算匹配电容。这个细节看起来很小，但选错接法会直接导致芯片没有参考时钟源，Port 3 自然 Link 不上。
3. 核心寄存器与初始化配置
3.1 KSZ8863RLL 的寄存器体系：从哪里看链路状态
我习惯把 KSZ8863RLL 的寄存器分成三层看：
- 全局寄存器（Global Registers）：控制芯片整体工作模式、RMII/MII 模式选择。
- Port 寄存器（Port Registers）：控制每个端口的工作模式、速率、双工、流控等。
- PHY 寄存器（PHY Registers）：通过 MDIO 访问，链路状态、自动协商、PHY ID 都在这一层。
在 MDIO 通路能正常访问的前提下，最直接的链路状态查看方法是读 PHY 寄存器 0x01（BMSR，Basic Mode Status Register），其中 bit 2 就是 Link Status。该位是锁存位，读取后会自动清零或需要重新读才会更新，所以排查时不要只看第一次读的结果。
如果你用 STM32 HAL 库，读 PHY 寄存器的代码很简单：
uint32_t phy_addr = 0x16; /* 这个地址取决于你的硬件配置，KSZ8863RLL由ID引脚决定，下面会讲 */ uint32_t reg_val = 0; /* 读 PHY ID 寄存器，验证 MDIO 通路 */ HAL_ETH_ReadPHYRegister(&heth, phy_addr, 0x02, ®_val); printf("PHY ID1: 0x%04X\n", reg_val); HAL_ETH_ReadPHYRegister(&heth, phy_addr, 0x03, ®_val); printf("PHY ID2: 0x%04X\n", reg_val); /* 读 BMSR，看 Link Status */ HAL_ETH_ReadPHYRegister(&heth, phy_addr, 0x01, ®_val); printf("BMSR: 0x%04X\n", reg_val);如果读出来的 PHY ID 不是 0x0000 也不是 0xFFFF，基本可以判断 MDIO 通路没问题，接下来就去查模式配置和时钟。
有一个细节要特别提醒：KSZ8863RLL 的 MDIO 设备地址，是由芯片的 ID0~ID3 引脚（或者叫做 SMI 地址配置引脚）决定的，不同板卡可能不同。我这张板上实际是 0x16，但有的参考设计会用 0x10、0x18，甚至需要把地址左移一位才能读到正确数据。如果你读 PHY ID 一直失败，建议把手册里关于 SMI 地址的那一页找出来，对着原理图确认一次，而不是反复去怀疑硬件接触不良。
3.2 必须使能 RMII 模式的几个关键配置
KSZ8863RLL 的 Host Port（Port 3）可以工作在 MII 或 RMII 模式，这个模式的选择不一定只靠外部引脚 Strap，很可能还需要写全局寄存器。
举个例子，我手上这个板子，芯片上电默认从某个 Strap 引脚读取 Host 接口模式，但实际配置寄存器里还有一个全局使能位，控制 Host 口是“RMII MAC 接口模式”还是“RMII PHY 接口模式”。如果这个位置错误，就算你的 REF_CLK 正常，STM32 发出来的 TXD 信号在交换芯片看来也是“完全不可理喻的”，Link 自然起不来。
所以初始化流程里，至少要做三件事：
- 通过 MDIO 写全局寄存器，把 Host 口配置为 RMII 模式。
- 通过 MII/PHY 寄存器把 Port 3 的自动协商使能打开，速率 100M、双工 Full。
- 如果有需要，再去配置 Port 1、Port 2 的转发域，让 Host 口能和其他端口互通。
其中第三点非常容易被忽略：KSZ8863 内部是一个带管理功能的交换芯片，Port 3 即使物理链路 Link Up，但如果端口没有被加入转发数据库，或者端口处于隔离状态，STM32 依然 ping 不通任何网口。这个问题在现象上很像“RMII 没调通”，但本质上已经是“交换机配置”的问题，我们后面专门用一节来说。
3.3 STM32F746 侧的 RMII 初始化
STM32F746 的以太网 MAC 要工作在 RMII 模式，CubeMX 里需要做两件事：
- 在 ETH 配置里，把 Media Interface 选为 RMII。
- 正确初始化 RMII 对应的 GPIO 引脚，并启用外部 PHY 或外部时钟路径。
RMII 模式下，STM32F746 的以太网引脚是固定的，我这边用的对应关系如下：
| 信号 | STM32F746 引脚 | 说明 |
|---|---|---|
| ETH_RMII_REF_CLK | PA1 | 50MHz 参考时钟输入 |
| ETH_RMII_CRS_DV | PA7 | 载波侦听/数据有效 |
| ETH_RMII_RXD0 | PC4 | 接收数据位 0 |
| ETH_RMII_RXD1 | PC5 | 接收数据位 1 |
| ETH_RMII_TX_EN | PG11 | 发送使能 |
| ETH_RMII_TXD0 | PG13 | 发送数据位 0 |
| ETH_RMII_TXD1 | PG14 | 发送数据位 1 |
| ETH_MDC | PC1 | MDIO 时钟 |
| ETH_MDIO | PA2 | MDIO 数据 |
这些引脚的复用功能基本都是 AF11，CubeMX 里只要勾选 ETH 外设并选择 RMII，它会自动帮你把 GPIO 的 AF 初始化好。但要注意：GPIO 模式里，ETH_MDIO 通常应配置为 Output Open Drain + Pull Up，而不是推挽输出。这一项如果不小心设成推挽，MDIO 总线会与交换芯片的驱动产生冲突，轻则读数据不稳定，重则长时间拉低总线。
时钟方面有一个常见误区：STM32F746 内部并没有专门的 50MHz RMII 时钟源，它必须从外部输入 ETH_RMII_REF_CLK。如果你采用“STM32 通过 MCO 输出 50MHz 给 KSZ8863”的方案，要特别注意系统时钟分频是否能精确得到 50MHz。举个例子，HSE 25MHz、系统主频 216MHz 时，PLLCLK 是 216MHz，MCO 输出分频系数只有整数，216/4=54MHz，216/5=43.2MHz，怎么都凑不出 50MHz。这种情况下如果你还强行用 MCO，REF_CLK 频率就是错的，Link 永远不可能成功。这也是我后来决定改用“外部 50MHz 有源晶振 + 同时供给两端”方案的原因。
4. 调试实录：从 Link Status 不变到稳定 up
4.1 先用 MDIO 把“看到”的东西量化
拿到故障板之后，我习惯先写一段最原始但信息量最大的调试代码：上电初始化 ETH，然后直接读 PHY ID、BMSR、BMCR，打印出来。这个动作能帮我把“软件配置问题”和“芯片工作状态问题”快速分开。
我第一次运行时打印如下：
PHY ID1: 0x0022 PHY ID2: 0x1460 BMSR: 0x0000 BMCR: 0x0000PHY ID 能读出来，说明 MDIO 没问题。但 BMSR 是 0，说明 PHY 的自动协商能力位、Link 状态位全是 0，问题不是“没 Link”，而是“PHY 根本没开始工作”。
这时候我去读全局寄存器，确认 Host 口模式，发现 RMII 模式位压根没被使能。原因是我们的电路板把 Host 接口的 Strap 引脚默认接到了“MII 模式”的电平，而初始化代码里又没有去覆盖这个配置。这就解释了为什么 Port 1、Port 2 都能 Link，唯独 Port 3 起不来——因为 Port 3 的物理接口还在按 MII 模式工作，而 STM32 这边已经按 RMII 发送信号了，两边根本对不上。
遇到这种情况，不要心存侥幸，直接把正确的 RMII 模式值写进全局寄存器，再复位一下 Port 3，然后重新读 BMSR。印象很深，写完寄存器后再读：
BMSR: 0x794D BMCR: 0x1000BMSR 的 bit 2（Link Status）变成了 1，自动协商完成。这时候 Port 3 根目录通的物理链路终于起来了。
4.2 时钟问题的定位过程
链路起来后，我以为可以收工了，结果发现另一个问题：STM32 能收到 RXD 信号，但 TX 发出去的数据，对端网口收不到任何字节。排查到最后，问题还是回到 50MHz REF_CLK 上。
我用示波器同时测量 STM32 ETH_RMII_REF_CLK 引脚和 KSZ8863 X1 引脚，发现两个引脚上的时钟波形虽然都是 50MHz，但相位差已经接近 10ns。RMII 的建立/保持时间一般在納秒级，10ns 的偏差虽然看起来不大，但对于高速采样就是致命的。
这个相位偏移来源有两个：一个是 KSZ8863 内部的时钟缓冲路径引入的延迟，另一个是 PCB 走线太长，又没有做等长处理。解决办法是把 RMII 相关信号线尽量缩短、等长；REF_CLK 信号单独走线并包地，不要和其他高速信号并行走。
如果你在手头还没有改板的条件下调试，可以考虑用“交换芯片输出 REF_CLK 给 MCU”的方式，让 STM32 完全跟随 KSZ8863 的时钟域，这样天然保证同源同相。但前提是 KSZ8863RLL 的型号和配置支持这种时钟输出，这一点一定要看数据手册确认，不同批次/型号可能有差异。
4.3 端口使能和交换域的坑
链路 Link Up 之后，还有一个容易卡住的大坑：Port 3 虽然 Link 了，但 STM32 访问不到 Port 1、Port 2 后面的设备，也就是“通了但 ping 不通”。
这个问题的本质是交换芯片内部的端口转发配置。KSZ8863RLL 内部有端口 VLAN 表、静态 MAC 地址表等。非网管模式下，芯片默认行为可能是把 Port 3 排除在转发域之外，或者需要你在初始化时把 Port 3 设置为“接受所有帧”、“泛洪到所有端口”。
调试这类问题，建议先做一个小实验：把 Port 1 和 Port 2 互相 ping，看是否通——如果不通，说明两个物理口之间的转发本来就有问题；如果通，再拔掉 Port 1/2，把 PC 接到 Port 1，让 STM32 通过 Port 3 去 ping PC，这时抓包观察 KSZ8863 是否把 Port 3 收到的帧转发到 Port 1。
我在这个环节踩的坑是：某个寄存器里 Port 3 被配置成了“Host Port 特殊模式”，只接收特定地址的帧，其他普通报文全部丢弃。所以终端上看到的现象是：Link 正常、寄存器正常、但业务不通。最终把寄存器改为普通“二端口交换 + Host 接入”模式，才彻底解决。
5. 常见问题与避坑清单
5.1 RMII/MDC 常见问题速查表
把这次调试遇到的和朋友交流时提到的典型问题整理成一张表，方便你排查时对照：
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| MDIO 读 PHY ID 为 0xFFFF | MDIO 上拉电阻没贴、设备地址不对、MDC 频率过高 | 检查 MDIO 上拉，核对 KSZ8863 SMI 地址，降低 MDC 频率到 2.5MHz 以下 |
| MDIO 读 PHY ID 为 0x0000 | 芯片复位未释放、供电异常、RBIAS 异常 | 测量电源、复位时序，确认 RBIAS 阻值 |
| PHY ID 读正常，Link Status 始终为 0 | RMII 模式未使能、REF_CLK 没有或频率不对 | 写全局寄存器使能 RMII，示波器确认 50MHz 时钟和幅值 |
| Link Status 为 1，但 ping 不通 | Port 3 未加入转发域、VLAN 配置错误 | 检查端口转发寄存器，确保 Port 3 与 Port 1/2 在同一个交换域 |
| 偶发启动后 Link 不稳定 | MDC/MDIO 走线噪声、REF_CLK 相位偏移 | 串阻、等长走线、REF_CLK 单独走线，检查上拉电平 |
| RMII 的 RXD 完全无数据 | REF_CLK 方向/相位问题、CRS_DV 信号异常 | 确认时钟同源，测量 CRS_DV 是否正常拉高 |
5.2 我踩过的三个坑
第一个坑：RBIAS 电阻漏贴。改版后的第一批样板贴出来，结果 5 块板子全部读不到 PHY ID，排查了很久，最后发现是 BOM 里把 RBIAS 电阻漏掉了。这里想说的是，KSZ8863RLL 这类芯片的“静默失败”很多，不会给你报错，只会表现为“Link 不上”或“MDIO 异常”。所以画原理图时，一定要把 RBIAS 器件标得显眼一点，评审时专门核对。
第二个坑：MDIO 的 GPIO 模式。STM32 的 HAL 库在 CubeMX 里生成代码时，ETH_MDIO 引脚如果没有手工配置为 Open Drain 模式，默认可能是推挽输出。这在读寄存器时偶尔能成功，但非常容易在总线上产生冲突。我后来在代码排查时加了一句检查：确认 GPIOA PIN2 的模式寄存器有没有配置为 OTYPER 开漏。很多网上案例说“MDIO 需要上拉”，根源就在这里。
第三个坑：SMI 设备地址对不上。KSZ8863 系列的 MDIO 地址，硬件上往往有一个“地址偏移”的设计，有些板子上的地址是 0x16，但如果你按 0x16 去读，始终返回 0xFFFF，而左移一位变成 0x2C 后反而能读通。这类地址映射问题和芯片的数据手册描述方式有关。建议直接去翻手册“SMI Interface”章节，不要用“某个现成代码里的地址”硬套。
5.3 给还没有画板的人的建议
如果你现在还处于原理图设计阶段，下面几条建议可以帮你省掉不少调试时间：
- MDIO 上拉电阻位一定要预留，4.7kΩ 起步。
- REF_CLK 方案优先选择“交换芯片或 PHY 输出 50MHz 给 MCU”，减少 MCU 侧 MCO 频率凑不整的风险。
- RMII 信号线务必等长，REF_CLK 走线尽量单独敷地包起来。
- 在 KSZ8863 的 RESET、MDIO、MDC、RBIAS 附近预留测试点，方便示波器勾波形。
- 在初始化代码里，把“读 PHY ID”作为第一条自检日志，串口打印出来，能省掉大量的“盲猜”时间。
6. 调试过程中的经验补充
这次的问题，最终总共改了三个地方：补 MDIO 上拉、正确配置 KSZ8863 的 RMII 模式寄存器、以及重新处理了 REF_CLK 的走线。三者叠加，才让 Port 3 真正稳定 Link。
说句实在话，这类问题的难点不在某个寄存器多难理解，而在于“硬件和软件夹在一起，现象又很单一”。我个人的习惯是，先把问题按协议分层拆开：时钟和电气层、MDIO 管理通道层、MAC 配置层、交换芯片转发层，逐层验证，每一层都要有明确的观测数据，比如波形、寄存器值、打印日志。不要因为看到了一个“Link Status 为 0”就一头扎进寄存器配置里反复改，先花十分钟搞清楚时钟到底有没有，MDIO 到底稳不稳定。
最后分享一个小技巧，算是我调网络接口多年的习惯：在系统上电初始化的最开始，用串口打印出 PHY ID、BMSR、BMCR 三个值，作为“网口硬件健康自检”的第一条日志。每次改板、换料、更新驱动之后，先看这条日志，异常一眼就能看出来。这个习惯让我避免了很多“明明硬件有问题却在调软件”的无效加班，你也可以试试。
