[参考译文] DP83867IS：通信问题

您好！  

1. 主机模式与从机模式的区别在于、在主机模式下、PHY 使用自己生成的时钟进行数据发送和接收、而在从机模式下、PHY 使用恢复的时钟进行数据发送和接收。 本质上、主器件决定了链路的时序、而从器件跟随它。
2. 主设备/从设备解析是 PHY 连接到链路伙伴时发生的自动协商过程的一部分。 有关这方面的更多信息、请参阅 数据表的第7.4.3.2节
3. 为了使通信正常工作、一个器件必须处于主模式、而另一个器件必须处于从模式。 这可能是导致该问题的原因。  

[quote userid="50131313" url="~/support/interface-group/interface/f/interface-forum/1447700/dp83867is-communication-problems 当我们检查寄存器0x000A 时、正常情况下是0x3800、通信问题下是0x78FF

只是为了澄清、  启动时寄存器0x0A 是否包含值0x3800、然后链接后是否变为0x78FF、或者即使链接后它是否继续保持值0x3800、直到您开始 ping 命令使其更改为0x78FF？

在这种情况下使用的是哪个链路伙伴？

此外、如果 PHY 处于主模式似乎是个问题、我们可以尝试使用寄存器0x09位[12：11]分别将其强制进入从模式。  

此致！

Vivaan

尊敬的 Vivaan-San：
感谢您的答复。

只是为了澄清、启动时寄存器0x0A 是否包含值0x3800、然后链接后是否变为0x78FF、或者即使链接后它是否继续保持值0x3800、直到您开始 ping 命令使其更改为0x78FF？

寄存器0x0A 在启动后为0x3800。 但是、链路伙伴需要每天重新启动一次、此时会出现通信问题。 每重新启动200次、通信问题的频率为1次。 发生通信问题后、ping 根本就不会通过。 当他们此时读取寄存器0x0A 时、值为0x78FF。

在这种情况下使用的是哪个链路伙伴？

连接方是另一制造商生产的 STB (机顶盒)。 该 STB 在市场上有许多产量。 我们无法识别 PHY 的器件型号。

此外、如果 PHY 处于主模式似乎是个问题、我们可以尝试使用寄存器0x09位[12：11]分别将其强制进入从模式。

我会向客户推荐。

此 E2E 帖子的目的是解决1/200通信问题。 如果您有任何建议、请告诉我。
其他寄存器的正常时间和有问题时间之间也存在差异。 我们正在并行调查这些问题。

尊敬的 Atsusi-san：

您注意到这两者之间还有哪些其他差异？ 您能否共享这两种情况的寄存器转储？

有关可能发生的情况的一种理论可能是器件会在链路伙伴重新启动后自动协商到错误的设置。 我们是否有关于链路伙伴的更多信息？ 它是否支持自动协商？

您还可以尝试在链路伙伴重新启动后复位 PHY、这应该会再次重新启动自动协商、如果这是一种边沿情况、在自动协商过程中 PHY 配置错误、可能表明观察到问题的次数为1/200、这将为 PHY 提供另一个正确配置自身的机会

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

我会通过私人按摩向您发送注册信息。

我们在获取有关链接合作伙伴的信息时遇到困难。

您指的是以下哪些复位？

-硬件重置

- IEEE 软件重置

-全局软件重置

尊敬的 Atsusi-san：

我是指将所有寄存器和器件本身复位的硬件复位。

我看到了您的消息、没有看到随附的寄存器转储。 您能否提供该信息用于调试

寄存器映射上没有常规和低功耗模式设置的原因是这些设置是保留的。 无论如何、当链路本身断开时、通常会执行该调试步骤。 根据我对您设置的理解、链路始终处于启动状态、但 ping 操作无法正常工作。

客户是否在 STB 重新启动后尝试过复位 PHY？  

在这种1/200情况下、您是否能够从 STB ping PHY？ 我注意到您说您正在尝试从 PHY ping STB。

我们可以采取的另一个步骤是探测 PHY 的 MDI 线路、以查看 ping 操作是否实际完成。 如果是、则可能是 STB 无法接收 ping 时出现问题。

此致！

Vivaan

尊敬的 Vivaan-San：

您说；
"此外、如果 PHY 处于主模式似乎是问题、我们可以尝试使用寄存器0x09位[12：11]分别将其强制进入从模式。"

我的客户在通信故障(链接已建立、但没有 ping 响应)期间尝试了该功能、但未重写该位。
是否可以在运行期间重写该位？
如果重写不成功有任何原因、请告诉我。

相反、当我的客户在从设备修复的情况下启动它时、未发生通信故障。
所以、我认为这个问题在于主/从解决方案。

那么,我有一个问题;
如果本地 PHY 和连接方都启用了自动协商功能、是否二者都能成为主机(或从机)？ 在什么情况下会发生这种情况？

尊敬的 Atsusi-san：

我还看了一下提供的寄存器。 我注意到有多个空闲错误、自动协商错误中断和极性更改错误中断。  

鉴于在固定从模式下不存在通信问题、我认为您是正确的、此处似乎是主/从解决方案的问题。  

由于我们没有太多有关 STB 的信息、并且该问题似乎发生在 STB 复位的1/200倍、因此 我们似乎偶然发现了一个边缘情况、其中器件之间的自动协商失败的次数为1/200。 该故障可能由几个不同的原因造成。 因此、PHY 默认为主模式、而 STB 也似乎处于主模式。 两个器件都需要通用时钟才能正常通信、因此它导致了 ping 失败问题、因为这两个器件都使用自己的未同步时钟来发送和接收数据。  

一个可能的原因可能是两个器件自动协商设置之间的时序不匹配。 如果任一 PHY 使用快速 An、而另一个 PHY 未使用、则可能导致此类意外行为。 对于 PHY、可以使用寄存器0x1E [14：12]对此进行检查。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的大力支持。

我检查过、Fast A 在客户系统上禁用。

并且使用 Realtek PHY 的链接伙伴不支持 Fast AN。

Fast 是 TI 独有的功能吗？

尊敬的 Atsusi-san：

FAST AN 未被 IEEE 标准描述并且不是通用的。 我认为链路伙伴 PHY 是未知的、因此我想确认是否存在潜在问题。 据我所知、Realtek 不提供 FAST AN。

从这些测试来看、在极少数情况下、自协商 会在出现错误时完成。 该错误似乎明确指向主/从解析、因为强制 PHY 进入从模式可解决该问题。 我们可以尝试切换电缆以查看这是否可能是导致该问题的原因、但也可能是链路伙伴端在下电上电时的行为。  

强制从模式对客户来说是否是可行的解决方案？ 它看起来可以解决罕见的1/200自动协商故障。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的支持。

针对强制受控模式、它并不解决方案、这是因为用户系统有可能也连接除了这个 STB 之外的系统。
客户系统需要灵活性、因此最好通过自动协商来确定主器件/从器件。

我们希望通过了解自动协商过程来解决该问题。

1) 1)在自协商过程中是如何决定主机模式还是从机模式的？
例如、这些角色由 FLP (快速链路脉冲)字段中的特定位解析、或者第一个接收 FLP 的位将解析为主模式。

此致、

尊敬的 Atsusi-san：

主机和从机配置是 自协商过程中完成的一个相当复杂的过程。 标准 IEEE 802.3 (特别是2012版的第55.6.2节)详细概述了该流程。

从我们到目前为止完成的测试来看、自协商过程中从链路伙伴接收的位好像已损坏、这会导致 PHY 无意中搭接至错误的主设备配置。 为了使用自动协商来解决这种行为、我们需要确保链路伙伴为自动协商发送正确的值。  

我们可以尝试使用不同的 PHY 重现此问题、以确认作为完整性检查、但根据我们进行的测试、我相信此行为可能是由 STB 链路伙伴引起的

此致！

Vivaan

您好、Vivaan-San。

我真的很感谢您的礼貌回应。

您说；
为了使用自动协商来解决这种行为、我们需要确保链路伙伴为自动协商发送正确的值。

我该如何具体检查？
有些方法可能会比较困难、因为我们可以从链接伙伴处获取的信息有限。

如果主从配置是一个复杂的过程、我认为这会特别困难。

此致、

尊敬的 Atsusi-san：

我认为这不是可行的选择。 这需要跟踪正在交换的自动协商数据包并手动对其进行解码。

鉴于我们对链路伙伴的了解不多、您是否可以使用867测试不同的链路伙伴？ 我们甚至可以尝试使用另一个867作为链路伙伴。 将链路伙伴保持为固定主设备、我们可以尝试运行测试、并查看我们是否观察到与 STB 相同的行为。 如果我们看不到相同的行为且 PHY 的性能不符合预期、我们可以将这种行为的原因范围缩小到 STB 链路伙伴。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

我们将尝试检查与固定为主器件的链路伙伴的通信。

您在上一篇文章中说过如下。

您能详细说明一下吗？

您的意思是通用时钟表示由 MDI 线路上的4D-PAM5编码生成的波形吗？

"由于两个器件都需要通用时钟才能正常通信、因此它导致了 ping 失败问题、因为这两个器件都使用自己的未同步时钟来发送和接收数据。"