企业官网建设流程全解析

1. 板子上的以太网“偶尔通、偶尔断”，先别急着怀疑PHY坏了

做嵌入式网络设备的人，大概率都遇到过这种场景：板子画完、贴片回来，上电初始化STM32H563的ETH外设，MDIO能读到ADIN1200的寄存器，Link也能起来，但一跑业务就露馅——PING大包偶发超时，TCP重传率高得离谱，甚至某个温度下完全不通。代码翻来覆去查不出逻辑问题，换一颗PHY还是老样子，最后只能把锅甩给“信号质量不行”。

我之前在一个工业网关项目里就栽过这个跟头。主控是STM32H563，PHY选的是ADI的ADIN1200，接口自然是RMII。当时第一版PCB为了赶交期，RMII信号组的等长约束做得比较随意，REF_CLK和数据线各走各的，长度差了个好几厘米。结果就是前面说的那一幕：常温短距离测试勉强能过，放到产线做持续吞吐测试就原形毕露。

这个问题的本质，不是“不通”，而是RMII接口的时序裕量不足。它不会直接让系统死掉，但会在硬件环境略微恶化时（温度升高、线缆变长、板卡批次差异），让数据采样刚好落在建立时间或保持时间边缘，造成偶发错误。这种问题最坑人，因为它不是必现，且很难用软件手段抓到直接证据。

所以这篇就围绕STM32H563和ADIN1200这对组合，把RMII时序裕量这件事从原理、排查到修复完整梳理一遍。文章不会只给结论，会把我实际踩坑的过程、测量的方法和最后落地的改动都摊开讲。如果你正在做H5系列+ADIN1200的方案，或者遇到RMII接口诡异问题的，这篇应该能帮你省几周时间。

2. 先算清楚RMII的时序账，才知道裕量到底被谁吃掉了

2.1 RMII比MII省了引脚，但代价是时序预算更紧

RMII（Reduced Media Independent Interface）是MII的精简版，数据线从4位砍到2位，所以需要50MHz的REF_CLK才能撑起100Mbps吞吐。接口信号从MII的16根左右降到7根：TXD[1:0]、TX_EN、RXD[1:0]、CRS_DV、REF_CLK，再加上管理接口MDC/MDIO。

引脚少了是好事，但代价是所有数据都以REF_CLK为唯一参考时钟，而且只有20ns的周期。所有信号要在REF_CLK的上升沿附近完成采样，留给建立时间和保持时间的预算非常紧张。相比之下，旧MII接口的25MHz时钟下有40ns周期，时序容错明显更好。

因此在RMII设计中，REF_CLK的走线长度、时钟极性和数据线的等长匹配，从原理上就决定了系统能不能稳定跑。这不是玄学，是可以用公式算出来的硬约束。

2.2 建立时间、保持时间与REF_CLK的三角关系

时钟沿采样数据要满足两个条件：数据在时钟沿之前稳定（建立时间t_su），在时钟沿之后继续保持一小段时间（保持时间t_hold）。RMII里的REF_CLK通常是由PHY提供的（ADIN1200可以作为时钟源输出50MHz），MAC根据这个时钟来驱动TXD/TX_EN，同时PHY也用它来采样RXD/CRS_DV。

以PHY输出REF_CLK给STM32H563为例，整个链路的时序关系大概是：

• PHY内部通过REF_CLK沿把TXD/TX_EN锁存到输出引脚；
• TXD信号经过PHY内部延迟和PCB走线后到达STM32的ETH_TX引脚；
• STM32内部对TXD的采样也是以REF_CLK（来自PHY）为基准的。

看上去很简单，但这里的延迟路径有：PHY内部的输出延迟（Tco）、PCB走线延迟、STM32引脚输入延迟、以及REF_CLK本身从PHY输出到STM32引脚的走线延迟。如果REF_CLK和TXD的走线长度相差太大，等于给建立/保持时间塞进了一个额外的偏差项。

实际体会是，在30MHz以下低速接口上，几厘米的走线差基本不用管；但RMII的50MHz参考时钟下，数据有效窗口本身就是个位数纳秒，这个偏差就变得很致命了。

2.3 时序裕量到底怎么算

时序裕量的物理意义是：在当前设计下，留给建立时间和保持时间的剩余空间。以PHY输出REF_CLK为例，MAC端接收方向的数据时序校验，可以简化成下面这个思路：

建立时间裕量 = REF_CLK到达时刻 - 数据变化沿到达时刻 - 接收端要求的建立时间

保持时间裕量 = 数据下次变化沿到达时刻 - REF_CLK到达时刻 - 接收端要求的保持时间

在FR4板材上，普通微带线的信号传播速度大约是每厘米67~70ps，走线每差1cm，延迟就差大约70ps。单独看1cm似乎可忽略，但如果PCB上REF_CLK比数据线短了5cm，就产生了约350ps的偏差；再叠加PHY内部输出延迟（通常1~5ns）和STM32引脚的输入延迟，就真的可能把只有几ns的建立时间吃光。

ADIN1200的数据手册里会给出MAC侧接口的建立时间、保持时间要求，H563的ETH外设也会给出RMII接口的时序参数。两者同时满足才是裕量为正。我实际测试时发现，真正能把问题定位下来，靠的就是把测量到的实际延迟代入公式算一遍，而不是靠感觉去“调一下试试”。

3. 实测记录：一个偶发丢包问题的完整排查链路

3.1 现象确认：是“必现”还是“偶发”，决定了排查方向

当时我在板子上跑的是一个简单的TCP回环测试：STM32H563接收网口数据，原样回传，电脑端用吞吐工具持续发。正常情况下100Mbps小包能跑到90Mbps以上且零丢包，但这块板子跑几分钟后就会出现重传，重传率在0.1%~1%之间波动，看起来不高，但是对工业控制场景是不可接受的。

先做了一套常规检查：MDIO读写都正常，PHY的链路状态寄存器显示Link up，协商结果是100Mbps全双工，MAC侧的中断也没有报错。然后怀疑是软件问题，把DMA描述符优先级、缓存一致性都查了一遍，没有发现异常。换了一块板子跑，丢包率更低，但也没完全消失——这个“时好时坏”的特征，让我开始怀疑硬件时序。

3.2 示波器抓时序窗口：真相在REF_CLK的上升沿附近

我用的是一台带宽500MHz的示波器，如果手头只有100MHz的，抓50MHz时钟没问题，但看上升沿细节会吃力，测出来误差反而误导判断。探头用短地簧，直接点在RMII信号上。

测量点选在STM32引脚端（也就是接收端），同时抓REF_CLK、TXD0、TXD1、TX_EN四根线。之所以选发送方向，是因为我们板子的REF_CLK是ADIN1200输出的，PHY作为时钟源，时序从PHY端到MAC端，测出来最直接。

波形结果显示，数据线的翻转沿离REF_CLK上升沿非常近，数据稳定窗口大概只有2~3ns。而ADIN1200要求接收端数据相对于时钟达到一定的建立时间，如果数据刚稳定1ns时钟沿就来了，采样结果自然不稳定。再测另一块丢包率更低的板子，发现它的数据稳定窗口明显更宽（4~5ns），这就基本坐实了：丢包率差异和时序裕量差异是相关的。

这里要注意，示波器波形看到的现象是“数据沿贴着时钟沿”，但究竟是哪一段路径吃掉了时序预算，需要结合布局布线来倒推。我随后跑到PCB设计文件里量了长度，发现TXD[1:0]走线平均比REF_CLK长了约3cm，有些过孔还额外加了延迟。3cm按70ps/cm计算大约是210ps，这个量级看起来不大，但加上芯片内部延迟和信号上升沿的大概1~2ns，就把整个窗口压到了边缘。

3.3 锁定根因：REF_CLK的数据返回路径被忽略了

根因比预想的还要多一层：这个板子的REF_CLK走线是从ADIN1200的CLKOUT引脚直接拉到STM32H563，中间没有串阻，也没有在靠近PHY端加滤波电容。表面上看没问题，但RMII的REF_CLK既作为时钟，又隐含了“数据回送参考”的作用——当PHY作为时钟源时，它自己的TXD输出路径是和REF_CLK输出路径在内部关联的，外部走线如果再不对称，等于给这个关联又加了一个变量。

我另外还注意到，H563的ETH外设RMII支持时钟极性的配置，可以在寄存器里翻转采样沿。这意味着：如果REF_CLK和数据线的延迟差让默认的上升沿采样落在数据变化的边沿附近，那么把采样沿翻转到下降沿，反而可能拿到更宽的稳定窗口。这也是后面修复时最先尝试的软件手段。

4. 三种常见根因：从硬件设计到软件配置逐个排雷

4.1 根因一：时钟源方向和电路设计不匹配

RMII的REF_CLK有两种工作模式：PHY提供时钟（PHY as clock source），或者MAC提供时钟（MAC as clock source）。H563和ADIN1200两端都得配置一致，否则即使链路能通，时序基础就是错的。

H563的ETH外设可以配置RMII时钟是从外部引脚输入，还是由内部生成后输出。ADIN1200的REF_CLK引脚也可以配置为输入或输出。很多人在做原型时，硬件上REF_CLK是PHY输出的，但代码里初始化时MAC侧没有正确配置对应的时钟方向，导致MAC内部对REF_CLK边沿的处理和实际电路不一致，时序裕量自然很差。

我的建议是，拿到一块新板子，第一步先核对硬件原理图上REF_CLK的实际连接方向，再去查驱动初始化代码里ETH的时钟配置，确保两者一致。不要只看默认例程，不同开发板的REF_CLK方向经常是反的。

4.2 根因二：PCB走线延迟失衡，REF_CLK与数据线长度差过大

这是最常见的物理层根因。RMII的信号组里，REF_CLK是时钟，TXD[1:0]、TX_EN、RXD[1:0]、CRS_DV都是数据，设计中应该把REF_CLK和所有数据线做等长约束。

很多PCB工程师习惯按普通信号去走RMII，觉得“不过就是几十兆的信号”，这就埋了雷。我之前这块板子就是吃了这个亏。建议在Layout阶段把REF_CLK设为约束管理器中的时钟Target，数据线以它为基准做等长，组内偏差控制在±2mm以内，REF_CLK和整组数据线的长度差尽量控制在±5mm内。如果结构限制确实做不到，优先保证REF_CLK不短于数据线，因为“时钟比数据晚到”一般是可以通过软件采样沿调整来弥补的。

4.3 根因三：GPIO速度等级和上下拉配置拖了后腿

这个坑特别容易误判，因为它藏在MCU的引脚配置里。STM32H563的ETH_TX、ETH_TX_EN等引脚需要配置为复用功能，同时还要选择合适的GPIO输出速度等级。

输出速度等级太低，上升沿变缓，数据的稳定窗口会被压缩；输出速度等级太高，又会引入过冲和振铃，对信号完整性同样不利。实测中，100M RMII的TXD信号建议把GPIO速度配到High（不同系列叫法不同，H563上对应的是High speed档），不要用Very High，也不要用Medium。具体可以量一下波形上升时间做取舍。

至于MDC/MDIO的上拉问题——这是网上被问得很多的一个点。MDC是管理时钟，由MAC驱动PHY，方向固定，一般不需要外部上拉；MDIO是双向数据线，需要接上拉电阻（常见4.7kΩ到10kΩ）保证空闲状态为高。如果你用了ADI评估板的参考设计，也可以直接照搬其取值。需要特别提醒的是：千万别给RMII的数据线或REF_CLK随意加上拉/下拉电阻，这会直接影响信号边沿质量和时序，百害无一利。

5. 修复与验证：先软件后硬件，一步步把裕量找回来

5.1 第一步：调整RMII时钟极性，用软件试探裕量方向

即使布局布线已经定型，软件仍然有优化的余地。STM32H563的ETH外设RMII支持时钟极性选择，可以在不推翻硬件的前提下改变采样时刻，从而避开数据不稳定区域。

我用一轮对比试验来确认效果：

• 配置1：上升沿采样，默认配置。实测丢包率0.5%左右；
• 配置2：下降沿采样。实测丢包率降到0.01%左右，几乎观察不到重传；
• 配置3：恢复默认配置，同时把PHY侧CLKOUT的驱动强度调小一档，丢包率介于两者之间。

出现这个结果，说明该板卡的REF_CLK与数据线延迟差方向，恰好让下降沿采样拿到了更宽的稳定窗口。这不代表所有板子都应该用下降沿，但至少验证了软件调整的可行性。

具体寄存器操作上，H563的ETH外设里有一个控制RMII采样沿的位，不同HAL版本名称可能不同，你在初始化ETH时留意一下结构体里“Polarity”或“ClockDivision”相关字段即可。

5.2 第二步：调整GPIO速度等级和PHY驱动强度

软件极性问题解决后，我继续把发送引脚的GPIO速度从“Very High”降到“High”，同时在ADIN1200寄存器里调整了RMII输出驱动强度。这一步的目的不是救时序，而是降低EMI和过冲，让信号更干净。过冲大的信号虽然不会立刻导致误采样，但在高温或长走线下，反射叠加会把裕量进一步吃掉。

调整后重新抓波形，TXD信号的上升沿从大约1.2ns变为1.8ns，过冲从约15%降到5%以内，数据稳定窗口又增加了大约0.5ns。量不大，但对本来只有2~3ns的窗口而言，相当于多了20%的余量。

5.3 第三步：硬件整改，从走线层面根治

软件调整是“找回”裕量，但真正要在量产中稳定，还得靠硬件把根因消除。

我当时的改板动作主要有三个：

1. REF_CLK与数据线等长：把REF_CLK走线单独绕线，让REF_CLK与TXD[1:0]、TX_EN、RXD[1:0]、CRS_DV的长度差控制在5mm以内。绕线时用45度折角，不走直角，减少阻抗突变。
2. REF_CLK远离其他高速信号：确保REF_CLK两侧有足够的地铜皮包裹，减小串扰。尤其不要让它和以太网变压器的差分走线平行长距离走线。
3. 靠近PHY的REF_CLK引脚增加串联端接：在ADIN1200的REF_CLK输出靠近源端位置放一个22Ω电阻，可以有效抑制过冲，实测效果明显。

改完板子再跑之前那个TCP回环测试，持续12小时，丢包率从0.5%降到0，重传数为0。再测不同温度（用温箱跑了-20℃到70℃），在默认上升沿采样配置下也全部通过，说明裕量已经真正恢复到了正常水平。

5.4 补充：软件上还可以做哪些防御性措施

硬件修好之后，我还在固件里加了两个防御性设计，适合量产项目：

• 上电后统计PHY的链路错误寄存器，如果连续几次出现接收错误，就主动做一次软复位重新初始化，避免偶发错误累积。
• 周期性读ADIN1200的温度和寄存器状态，提前发现信号质量劣化趋势。这套逻辑不复杂，但对工业现场远程维护很有帮助。

6. 把时序裕量做成可量化的指标，比“感觉稳定”靠谱得多

调试完这块板子之后，我最大的感受是：RMII能不能稳定，不是玄学，而是每一段路径延迟加起来能不能满足数据手册上的建立/保持时间要求。

后续我在设计阶段就定了一套检查清单，现在分享出来：

另外在测量方法上有几个经验：

• 示波器带宽至少要300MHz以上，带宽不足看到的上升沿是失真的，测出来的裕量会偏小或偏大，都会误导判断。
• 探头要用最短的地线夹，不要用长地线，否则探头本身就会在波形里引入几个ns的振铃。
• 测波形要测在接收端引脚，不是测在PHY输出端，因为看的就是接收端实际的采样条件。
• 如果板子已经量产不能大改，优先尝试软件时钟极性调整，往往能救回一大半，再考虑用PHY寄存器调整驱动强度或均衡，最后才是改PCB。

最后说一句，ADIN1200本身是一颗不错的工业以太网PHY，低温、长距离这些场景表现都靠谱。大多数时候问题出在我们自己这一侧，尤其是RMII的时序设计上。按照上面的思路做一遍量化验证，再把裕量余量留足，这套H563+ADIN1200的方案还是很稳的。