[参考译文] DP83822IF：错误载波事件、接收错误与放大器；链路质量中断

您好 Julian、

您能否分享以下内容：

原理图。

2.信号流和所用电缆长度/类型的方框图。

3.上电后是否配置了 PHY 寄存器？

4.您是在 XI 引脚上使用晶体还是板载振荡器？  

如果您看到数据包错误和链路质量中断、我们可以查看电缆侧连接+解码+参考时钟质量的原理图。

您好 Vikram、

感谢您的快速响应！

表示1。 和2. 我将以 pdf 文件的形式随附原理图以及在故障排除过程中测试的不同版本的电缆设置。 电缆管理/信号流的每个版本似乎都会导致相同的 PHY 行为。

e2e.ti.com/.../ethernet-schematics.pdf

更改为3：
正如您在原理图中看到的、我们将通过引导至 RMII 模式使能、25MHz 输入 CLK 来配置 PHY。 除此之外、我还将在如下所示的初始化例程中配置 PHY：
上电后的 PHY 寄存器：
- BMCR (0x0)：写入0x8000 (复位 PHY)  
   =>等待(BMCR & Bit15)
-读取 PHYIDR1 (0x2)：
   =>如果寄存器！= 0x2000：等待(等待 phy 被初始化)
-设置 PHYSCR (0x11)：Bit0 (中断输出)、Bit1 (中断使能)、[寄存器中的所有其他位未被改变]
-置位 CR3 (0xB)：位6 (极性交换)[寄存器中的所有其他位未改变]
-设置 PHYCR (0x19)：位15 (自动 MDI/x)[寄存器中的所有其他位未被改变]
- RCSR (0x17)：将0x60写入寄存器
- IOCTRL1 (0x462)：擦除(0x7 |(0x7 << 0x8)|(0x7 << 0xC))、置位(0x3 << 0x8)(根据位[14：12]的时钟参考)、置位(4<12)(RMII 主模式参考时钟：50-MHz)、置位 Bit0 [所有其他未触摸的位]寄存器中的位
- LEDCFG1 (0x460)：擦除(15 << 8)、设置 Bit8 [寄存器中的所有其他位均未被触摸]
- MISR1 (0x12)：设置位3、位4、位5、位6、位7 [寄存器中的所有其他位未被改变]
- MISR2 (0x13)：设置位0、位1、位3、位4、位7 [寄存器中的所有其他位未被改变]
-在此初始化方案之后
   => BMCR (0x0)：将 Bit9置位以开始自动协商
   =>等待 BMSR (0x1)位5未置位

更改为4.：
如原理图所示、我们在引脚 XI 和 XO 上使用外部晶体(TSX-3225 25.0000MF10Z-AC3)。

此致、
Julian

我正在查看原理图/寄存器、并将返回给您。

--

此致、

Vikram

您好 Vikram、

您是否对我有任何有关审核的状态更新？

此致、

Julian

您好 Julian、

我在原理图或寄存器设置方面没有发现任何问题。 我正在等待团队的进一步反馈(主要是关于软件设置)。 同时，您将能够在使用以下附加选项进行编程后看到该行为：

选项1：写入寄存器位0x04D1[0]= 0。 强制写入以禁用 EEE、即使您的自举用于禁用 EEE。

选项2：读取寄存器0x0009并共享该值。 写入寄存器位0x0009[5]= 1。

--

此致、

Vikram

您好 Vikram、

感谢您的回复！

‘ll 周一，我会回到办公室，测试您提到的选项。 ‘ll 观察到结果后，我立即回复。

此致、

Julian

您好 Vikram、
我测试了您提到的选项：

• 选项1对 PHY 的行为没有任何影响、我仍然观察到我的描述中的错误。
• 选项2：
  启动后、CR1寄存器读出以下内容：
  CR1 (0x9)：0x0
  在 PHY 初始化期间、我如您所述设置了稳健耐用的自动 MDIX、因此寄存器的读数为：
  0x0009：0x00000020
  此选项似乎也不能解决问题、因为我仍然看到越来越多的错误载波事件、接收错误和链路质量中断。

您还有其他测试选项吗？
我将在 PHY 初始化后附加寄存器映射、以防您需要有关当前 PHY 状态的更多信息：

>0x0000：0x00003100
>0x0001：0x0000786D
>0x0002：0x00002000
>0x0003：0x0000A240
>0x0004：0x000001E1
>0x0005：0x0000CDE1
>0x0006：0x0000000D
>0x0007：0x00002001
>0x0008：0x00000000
0x0009：0x00000020
>0x000a：0x00000100
>0x000b：0x00001040
>0x000c：0x00000000
>0x000d：0x00004007
>0x000e：0x00000000
>0x000f：0x00000000
>0x0010：0x00002C15
>0x0011：0x0000010B
>0x0012：0x000002F8
>0x0013：0x0000009B
>0x0014：0x000000FF
>0x0015：0x00001259
>0x0016：0x00000100
0x0017：0x00000060
>0x0018：0x00000400
>0x0019：0x00008C21
>0x001a：0x00000000
>0x001b：0x0000007D
>0x001c：0x000005EE
>0x001d：0x00000000
>0x001e：0x00000102
>0x001f：0x00000000
>0x0025：0x00000000
>0x0027：0x00000000
>0x003e：0x00000000
>0x003F：0x0000B4FF
>0x0042：0x00000000
>0x0403：0x00009FCF
>0x0404：0x00000020
0x0428：0x00000000
0x0456：0x00000008
0x0460：0x00000151
0x0461：0x00000410
0x0462：0x00004301
0x0463：0x00000000
0x0467：0x00000FE3
0x0468：0x00000000
0x0469：0x00000440
>0x04a0：0x00001000
0x04a1：0x00000000
>0x04d0：0x00000302
>0x04d1：0x0000018A
>0x3000：0x00000400
>0x3001：0x00000040
>0x3014：0x00000002
>0x3016：0x00000000
>0x703c：0x00000000
>0x703d：0x00000000

此致、

Julian

您好 Julian、

这不是我们先前观察到的故障特征。 以下是我从团队收到的反馈、用于评估您的电路板是否存在电气故障：

1. 您是否有工具使用示波器(查看任何抖动)捕获 RJ45连接器侧的眼图？  

2.配置完成后，您能否尝试软复位：寄存器0x001F = x4000。

我正努力寻找任何能为我们提供链路质量指示的寄存器。 因为它不在数据表中、所以需要花一点时间在设计中找到它。 我将共享这些要读取的寄存器。

--

此致、

Vikram

Julian、

我刚刚收到了有关信号质量指示器的反馈、因为我键入了之前的消息。 当您看到链接已打开时、请务必共享寄存器 x218的值。 您可以多次轮询和报告该值、以查看该值如何随时间变化。

您好 Vikram、

再次感谢您的回复！

更改为1.：
我将尝试使用我的可用示波器在 RJ45连接器侧获取某种眼图。 它不支持任何眼图功能、但我会尝试临时设置。

更改为2.：
我应用了您的建议、因为我在 PHY 寄存器设置之后(就在自动协商开始之前)进行了数字复位。 我甚至在应用程序运行时多次手动触发数字复位、以查看它是否起作用、但似乎没有效果。 一般而言、这对错误载波事件、接收错误和链路质量中断的发生没有影响。

至您的最后一个问题：
在 PHY 链路状态为"运行"~ 5分钟后、我每隔100ms 捕获一次寄存器0x218。 我将在该答复中附加带有寄存器值的 Logfile。 (e2e.ti.com/.../DP83822-0x218-Test.log)

我期待您的下一个回复！

此致、
Julian

您好 Vikram、

由于我使用的是非常旧的示波器(Tektronix MSO 4032、频率为350MHz)、因此我无法提供正确的眼图。

如下图所示、我管理了在 RX (在电阻器 R1和 R2的原理图中)上捕获差分信号：

此外、我使用持续时间为1秒的捕获(以及电阻器 R1&R2上的捕获)捕获了某种"伪眼图"：

我恐怕无法用我的可用示波器获得更好的测量结果、我希望它能以任何方式帮助解决持续存在的问题。

此致、
Julian

您好 Vikram、

您是否对我上次调查结果有任何更新？
您能告诉我观察到的行为是否正确、您是否需要我的测试设置中的更多信息？

此致、

Julian

您好 Julian、

我们查看了您共享的 SNR 寄存器日志。 看起来信号质量一直都很好、但您突然会得到一个链路中断。 有了现有的数据，假设可能的根本原因有点困难。 团队正在研究可能的方案，但您知道吗：

1.如果发生某些特定系统级事件时发生链路中断？

2.即使您没有传输任何数据，也会发生链路中断吗？

3.链路断开频率是否随 IPG 的不同而增加/减少？

--

此致、

Vikram

您好 Vikram、

通过链路中断、您指的是链路质量中断、对吧？ 因为(如初始帖子中所述)除了在 CR3寄存器中启用"快速下行链路事件"之外、我没有观察到硬下行链路事件。

更改为1.：
我将我的应用程序降至最低、在显式测试中、我甚至排除了处理以太网通信的以太网/网络处理程序。 应用程序会初始化 phy、然后定期检查 phy 寄存器中的中断事件。 正在处理的其他模块包括看门狗复位以及我的 UART-Console。 因此、一般来说、我会声称绝对没有任何系统级事件会影响链路质量。

更改为2.：
如第1部分所述、我还测试了一个应用、其中甚至以太网/网络处理程序都没有使用、因此从 MCU 侧看、没有任何通信刺激。 对于此特定测试、我甚至将 PCB 直接连接到了计算机、以避免来自交换机的任何网络流量。 计算机本身也不会激励与 MCU 的任何通信。 链路质量中断仍然会发生、并且不断增加错误载波事件和接收错误。

更改为3.：
我尝试通过激励不同的通信(ping、定期发现...)来改变 IPG 但在我看来、无论是否有任何沟通都无关紧要。 错误行为及其周期对我来说是相同的。

如果您有任何建议、请告诉我、这里正在发生什么情况、或者我是否可以从我的设置中为您提供更多信息/测试结果。

此致、
Julian

您好 Julian、

很抱歉、我读错了、感觉您在正常配置中也看到了下行链路。 但在重新读取该线程时、我了解到链路断开事件仅在快速下行设置期间发生、而在正常应用期间、只有 Rx_er/false-carrier/link quality 中断才会频繁发生。

此外、还感谢具有和不具有数据包的实验结果。 它有助于知道错误与 IPG 无关。 从目前的签名来看、它更像是电气问题、而不是配置问题：

您能否围绕"Rbias "布线共享电路板布局快照

通过编程寄存器0x0462[14：12]='001b、您能否测量晶体时钟的频率(以查看与预期25MHz 是否存在较大的 ppm 差异)

我可能错过了这个问题、但您是否在使用822的多个电路板上看到了这个问题？

--

此致、

Vikram

您好 Vikram、

感谢您的回复！

明天、我将看到我是否可以获取有关 PHY 的布局的快照、并将其附加到该线程中。
无论如何、我会按照您的建议为 RX_D3配置 IOCTRL1寄存器、并在 phy RX_D3引脚处测量信号：

频率为25MHz、对我来说很好。

对于您的最后一个问题、我可以确认我测试了3个独立的设计板、并观察到每个板上的问题。

此致、
Julian

您好 Julian、

团队提出了另一种配置、以便在您的系统中尝试。 您能否尝试以下设置(在默认情况下您已进行编程的基础上)并检查这两个设置中的任何一个是否解决了接收器错误的问题：

您好 Vikram、

我在 PCB 上的 phy 周围获得了布局：
e2e.ti.com/.../Layout-around-PHY.pdf

• 在第1页、您可以看到 PCB 的顶部。 我为 RBIAS 插入了一个标记/注释。
• 在第2页、您可以看到 L2
• 在第3页、您可以看到 L3
• 在第4页、您可以看到 PCB 的底部
• 在第5页、您可以看到 PCB 的镜像底部

您能否告诉我、将电阻器放置在 PCB 不同层的 RBIAS 上是否合理(正如我们所做的那样)、 还是必须将电阻器放置在布局的同一层(在我们的案例中为顶部)、以避免过孔到达 PCB 的底部？

如果您需要有关布局的更多信息、请告诉我。

稍后、我将附上您上次请求中有关两个附加 phy 配置的结果。

此致、

Julian

您好 Vikram、

除了我之前的帖子外、我还将为您附加4个有关您请求的 phy 配置的日志文件。

1. 配置#1、在执行自动协商后应用
   e2e.ti.com/.../01-TestConfig1_5F00_afterAN.log
2. 配置#1、在执行自动协商之前应用
   e2e.ti.com/.../02-TestConfig1_5F00_beforeAN.log
3. 配置#2、在执行自动协商后应用
   e2e.ti.com/.../03-TestConfig2_5F00_afterAN.log
4. 配置#2、在执行自动协商之前应用
   e2e.ti.com/.../04-TestConfig2_5F00_beforeAN.log

我在日志文件中捕获了整个 PHY 初始化过程、因此您可以控制我执行的每个写入访问。
此外、我执行了几次读取来显示虚假载波事件计数器以及接收错误计数器(也显示 RX FIFO 下溢/上溢)。

您可以看到、错误仍然存在、并且由于激活的快速下行链路事件、链路从向上跳到向下跳转、反之亦然。

在这个测试设置中、我将 PCB 直接连接到我的 PC、并且我再次从我的应用中排除了以太网和网络处理程序、这样就不会发生通信。

再次感谢您的支持！

此致、

Julian

您好 Julian、

是哪个信号：

这是开关信号吗？

Rbias 是一个敏感节点、其上的干扰可能会在 PHY 的接收和发送路径中引入噪声。 我们是否可以尝试在电阻器上放置一个小电容(~10pF 但不超过40pF)？

此外、我们还可以尝试 通过编程0x0460[11：8]= x0001或0x101使 LED_1的动态性更低、从而减少转储到接地的噪声(而不是您当前的 TX/Rx 活动配置)

--

此致、

Vikram

您好 Vikram、

您的标记信号是我们的"全局复位"、可复位 μ µC 和 PHY。 它由开关手动控制。

至 RBIAS：
我将请求在 rbias 处放置一个与电阻器并联的电容器、并在我测试其行为后立即给出响应。
由于 rbias 如您所述一样敏感、您是否看到过我们通过过孔在 rbias 放置电阻器时出现任何问题、或者是否不会产生任何影响？

我还将0x0460[11：8]处的 LED 配置从0x0001 (与我的默认配置一样)切换到0x101。 这对所述错误的发生没有影响。

此致、
Julian

您好 Julian、

我们看不到任何通过过孔连接 Rbias 电阻器的明显问题。 我们主要关注 Rbias 周围的串扰问题。 这一个(电源？)是哪个过孔：

是、让我们看看您是否看到电阻器上的电容有任何改进。 我正在与团队一起再次查看结果、但只是为了确保 您在两个配置之前共享时仍会看到错误(未激活快速链路丢弃)。 对吧？

--

此致、

Vikram

您好 Vikram、

为了进一步研究、我们对 RBIAS 电阻器进行了一些更改。
在两个独立的电路板上、我们设置了一个与4K87电阻器并联的10pF 电容。

除此之外、我们还更换了第三块电路板上的4K87电阻器、如下所示：

• 我们在 RBIAS 处钻过过过孔(以移除 Rbias 与 bootom 层的连接)
• 我们按照布局/原理图中的说明、从该位置小心地移除了电阻器。
• 我们已将 PCB 顶层的4K87电阻器从过孔的持久性位置重新连接到相邻的接地线迹：
  

我重复了我们之前讨论过的几个测试用例(在每个电路板上)、包括您建议的测试配置1和2。 我研究了这两种配置在启用和不启用快速链路中断时的行为。

除了我之前的测试之外、我还排除了我在 MCU 中的整个以太网初始化：

• 不包括所有以太网信号(RX0、RX1)的端口复用。 CLK、RXER、CRS_DV、TXEN、TX0、 TX1、TX2、TX3)、以便每条线都处于三态。
• 不包括整个以太网初始化(以太网 MAC 设置以及后续 TCP 和网络初始化)

剩余的唯一初始化是设置以太网 SMI 接口以及前面提到的 phy init 例程。

遗憾的是、我的每一项进一步调查都对虚假载波事件、接收错误和链路质量中断的发生没有影响。 鉴于我要声明的附加配置#1和#2、配置#2引起的接收错误比配置#1多一些、但总的来说、这些错误在提到的每个配置中都存在。

关于布局的最后一个问题：
你绝对是对的。 您标记的过孔会路由到 PHY 的 VIDDIO 引脚。

此致、

Julian

您好 Julian、

不幸的是，我们迄今未能通过实验远程解决改进问题。 我正在与团队了解后续步骤。 您是否有 TI 的现场团队联系人为您提供支持？  

--

此致、

Vikram

您好 Vikram、

到目前为止、我们没有任何联系。
您是否能够组织一个？

我最近的调查似乎显示了 µC μ s 速度与 发生误差的频率/强度之间的某种相关性、因为误差率似乎随着 µC μ s 时钟速率的降低而降低。 到目前为止、我不知道它是 μ µC 系统时钟本身还是任何其他影响 PHY 错误行为的衍生时钟。 目前、我实际上不知道 μ µC 时钟如何影响 phy、因为 μ µC 本身不会为 phy 计时、并且持续存在的错误位于接收侧。

因此、我需要进一步调查、以提供有关此方法的更多信息。

此致、

Julian

Julian、

这可能是一个很好的线索。 您是否知道 UC 时钟是否会影响 MDC 时钟频率(时钟进入 PHY)？ UC 是否与 PHY 共享电源？

--

此致、

Vikram

您好 Vikram、

在我的上一篇文章中、我跳过了 MDIO/MDC 接口、因为它"仅"是用于 μ µC 寄存器通信的双线接口。 我错过了 MDC 随时计时、而不仅仅是在访问 phy-registers 时计时。 因此、μ µC 确实为 phy 提供了一个恒定的时钟。

μ µC 在任何系统时钟上为 MDC 提供~2.5MHz 的频率(它有内部偏差、始终提供 MDC <= 2.5MHz)。 因此、在我测试的任何情况下、MDC 应该几乎相同、我也会通过测试引脚 TP4上的示波器(如原理图中所述)从我的观察中确认。 当 μ µC 系统时钟发生变化时、MDC 上的噪声似乎没有变化。 不过、当改变 μ µC 系统时钟及其衍生产品(例如总线时钟)时、我会看到错误发生频率发生变化。 目前、我不确定实际相关性、因为时钟差异并不真正指向明确定义的行为模式。 我将继续进行一些其他测试。

μ µC 和 phy 确实共享相同的3.3V 电源和 GND。

此致、
Julian

您好 Julian、

由于这些额外的数据包错误、您是否选择了低于最大可能吞吐量？ 从到目前为止的观察结果来看、这看起来像是一个电气抗扰性问题、并且可能是由于电路板上的噪声。 如果是电源噪声问题、我们可能会尝试在 uC 周围建立衰减网络、或在 uC 电源之间放置铁氧体磁珠(如果有占位器)或通过提供用于调试目的的外部电源来隔离 uC 电源。 它可能需要进一步的调试和迭代。 如果吞吐量足以满足您的应用需求、则您可以继续使用当前的实现方式、而不启用快速下行链路模式。 这样、您就不会有链路故障、吞吐量也会持续。

--

此致、

Vikram  

您好 Vikram、

经过进一步调查、我在 PCB 上找到了本案例的分压源。
µC 器是一个 Δ Σ- CLOCKOUT 引脚、可驱动30-60MHz 范围内的时钟、并在 PHY 迹线 MDIO、MDC 和 RX_ER 旁边持续存在。 启用和禁用此引脚可引发并抑制在 PHY 上观察到的错误以及后续以太网通信干扰。 因此、作为一个结论、当在上述频率范围内驱动时钟时、此引脚会引起 PHY 布线的串扰。
我没有弄清楚串扰在哪个物理层布线上会产生问题影响、您可能会看到所描述的时钟输出噪声源与物理层的敏感部分之间存在关联？

一般而言、我会假设这种情况已关闭、因为我能够控制干扰源。 随着 PCB 的重新设计、一旦我的桌面上有新硬件进行最终验证测试(这将在大约3到4个月内进行)、我就可以回到这种情况。

非常感谢你们的热情和出色的支持！

此致、
Julian

您好 Julian、

您取得的巨大突破！ 除了共享电源/接地之外、一些易受 XTALK 影响的敏感信号：XI、XO、Rbias。  

--

此致、

Vikram