[参考译文] DP83867IR：器件链路不稳定

尊敬的 David：

请提供有关故障情况的其他信息、例如：

1. 您拥有多少块主板、有多少块主板遇到了故障特征？
2. 偶尔会有什么影响、很少会有影响？
3. 如何测量链路建立情况？

默认情况下、LED_0是链路状态。 对于场景2、您是否说在移除复位信号后链路已建立？ 所有这些情况听起来像是 RESET 引脚被意外触发。 请探测复位引脚、并确保 CPU 没有将其拉低。

谢谢。

大卫

你(们)好

感谢您的回复！ 我将与客户确认 遇到此问题的时间百分比和设备数量。

同时、通过添加 RESET 引脚的一些波形、似乎该引脚在事件发生期间保持了 H、请您在下面进行注释

Unknown 说：

对于场景2，您是否说在删除复位信号后链路已接通？

是的、根据客户的正常情况、他们希望在移除重置信号后 LED 保持熄灭、但由于某种原因、LED 亮起。

Unknown 说：

您如何测量链路？

我想他们是通过检查 MDIO 读取来实现的、但我会再次确认这一点

场景2：

场景4：

此致

尊敬的 David：

LED_0是否配置为链路状态？ 如果是、如果 LED_0开启、则表明链路已建立。  

将 RESET 引脚保持在低电平将导致器件处于复位模式而无法建立链路。 当 RESET 引脚释放并变为高电平时、如果器件捆绑到自主模式并且连接了适当的链路伙伴、则器件将进入正常工作状态并自动建立链路。  

因此、当您删除复位信号时、LED 预计会亮起。 您能否帮助我理解为什么"客户通常期望在移除复位信号后 LED 保持熄灭"？

谢谢。

大卫

你(们)好

是、LED_0配置为链路状态。 客户使用 LED_0作为链路状态的指示器、 并在应用中使用 PC 通过 DP83867检查终端设备链路状态。  

Unknown 说：

因此，LED 指示灯应在您删除复位信号时亮起。 您能否帮助我理解为什么"客户通常希望在删除重置信号后 LED 指示灯保持关闭状态"？

客户首先检查了 PC 上的终端设备、发现未执行链路、因此他们认为 LED 应保持熄灭、因为通常情况下、LED 将指示 链路状态、但 LED 却亮起、尽管器件无法链路。

Unknown 说：

• 您拥有多少块主板、有多少块主板遇到了故障特征？
• 偶尔会有什么影响、很少会有影响？

[/报价]

关于您的问题、客户提到他们在10个板中的2个板中发现了此问题。 客户没有记录到这个问题的准确比例、 但是 据客户了解、这个问题在很多次测试中只出现了几次、很难重现。  客户认为设备在出现故障时可能出现故障。

此致

尊敬的 David：

客户如何在 PC 上检查链路状态？ 请让它们读取寄存器0x1 bit [2]以了解链路状态。  

对我来说、这里似乎没有问题。 当 RESET 引脚保持低电平时、器件将不工作、并在移除复位后建立链路。 如果是只发生很少几次并且不可重现、则很难解决此处的问题。 您能否帮助您准确定义问题并找到问题发生的确切条件？ 它将有助于在成功和失败案例期间探测复位线路、请在每个场景下提供示波器截图以进行比较。  

谢谢。

大卫  

你(们)好

从客户处添加一些更新：

Unknown 说：

请让他们读取寄存器0x1 bit[2]以了解链路状态。  [/报价]

在 LED_0为 H 且器件未建立链路的事件期间、  DP83867没有响应读取 0x1位[2]的尝试。

在正常链路期间、发现0x1 bit[2]为1；在移除 LAN 电缆时，发现0x1为0。

 

【在链路故障事件期间记录】

Root@Xilinx-K26-SOM-2021_2：~# phytool read eth0/0x01/0x0001

错误：PHY_READ (-22)      //DP83867无响应

 

【正常链路期间记录】

Root@Xilinx-K26-SOM-2021_2：~# phytool read eth0/0x01/0x0001                                             

0x796d                // 连接 LAN 电缆时            

Root@Xilinx-K26-SOM-2021_2：~# phytool read eth0/0x01/0x0001                                             

0x7949                //拔下 LAN 电缆时       

 

当器件处于此链路故障状态时、 向  DP83867发送 SW_RESET（0X001F 位[15]=1)时没有响应

 

root@Xilinx-k26-som-2021_2：~# phytool write eth0/0x01/0x001f 0x8000

错误：PHY_WRITE (-22)     //DP83867无响应

 

 

此外、更改 RESET_N 的高/低电平不会改变  DP83867上的任何内容。

对 DP83867寄存器的访问尝试全部结束、无响应。

如前所述，这个问题很少发生，很难重现。

但是、有时在为器件上电时也会发生这种情况。

基于这些、客户得出结论认为 DP83867存在某种故障。

下面是客户采集的波形、

 根据波形、当 内部上拉 RESET_N 时、VDD1P1约为500mV。

因此、是否有可能在 VDD1P1达到1.045V 之前移除了复位？

根据 DS、器件具有 POR 功能、上电后无需复位。 另外、由于客户使用2电源模式、因此它应该对电源序列没有要求。

您能想到什么可能导致此问题的原因吗？

此致

尊敬的 David：

让我向团队提出这个问题、并在明天与您联系。

谢谢。

大卫

尊敬的 David：

上电期间将 RESET 信号取消置位可能会引起问题。 在所有电源都斜升后、请将 RESET 信号延迟至1秒。  

在出现故障的情况下、如果您再次切换复位引脚、它是否可以解决该问题？

谢谢。

大卫

尊敬的 David：

感谢您的答复。

Unknown 说：

加电期间取消置位复位信号可能会导致问题。 在所有电源都斜升后、请将 RESET 信号延迟至1秒。  [/报价]

我会告诉客户这方面的情况。

Unknown 说：

在故障情况下，如果您再次切换重置引脚，它是否能解决此问题？

否、在故障情况下、在切换 RESET 引脚时器件无响应。 这在电源复位之前不会发生变化。

此致

[/quote]

David、您好！

2月20日是美国公共假日。 我会让大卫·克雷格一回到办公室就回复。

--
此致、
Gokul.

尊敬的 David：

在下面是客户的应用、RESET 引脚的输入由 FPGA GPIO 控制、FPGA GPIO 在上电前不能拉低。

因此、他们认为在电源斜升之前下拉复位信号的可能性很大。

是否还有其他原因可能导致这种情况？

此外、我们是否有关于客户应等待多长时间直至拉取 RESET 信号的规格？(器件需要多长时间才能启动)

此致

尊敬的 David：

您共享的示波器屏幕截图显示、RESET 引脚在电源斜升至 PHY 之前被拉至低电平、然后在功率斜升期间变为中间高电平。 我缺少什么吗？

请将该信号延迟1秒、让我知道结果。

谢谢。

大卫

尊敬的 David：

客户报告延迟复位时间后没有出现问题。

但是、由于其系统设计、很难将复位延迟1秒。 作为替代方案、它们降低了功率斜升持续时间、以确保在复位之前通电；通过将斜升持续时间减小到100ms 以内、它们发现700次测试没有问题。

添加客户的问题：

当仅使用 DP83867IR 的内部复位时、是否需要电源斜升时间？

此致

尊敬的 David：

感谢您的回答。

我认为客户想要弄清楚在可以安全地移除复位信号之前他们需要等待的最短持续时间是多少。 在您提到的情况下、它将为100ms、但这是最短的时间吗？

使用内部复位时、在消除复位之前应该有一个延迟持续时间和电压阈值。

是否有适用于这些参数的数据？ ( 与 下图类似)

此致

尊敬的 David：

  最后一次电源斜升和复位引脚失效之间的最短时间为200ms。  

内部复位是什么意思？

谢谢。

大卫  

尊敬的 David：

感谢您的答复。

内部复位在数据表中标记为 POR (上电复位)功能、如下所示。

我再次查看数据表发现、RESET 引脚在电源斜升后200ms 内处于闩锁 状态、这意味着  在 电源斜升期间 RESET 引脚取消置位不应导致问题、因为器件仅在上电后才获得内部复位、对吗？

此致

尊敬的 David：

POR 将锁存200ms、是的。 如果 POR 有问题、之后的复位切换将生效、并将 PHY 从未知状态恢复。 这听上去像是本例中正在发生的情况、因此请在斜升完成后的200ms 内让 RESET 引脚取消置位。  

谢谢。

大卫

尊敬的 David：

很抱歉、您下面提到的内容让我有点困惑、您能详细说明一下吗？

Unknown 说：

如果 POR 出现问题，则之后的复位切换将生效，并将 PHY 从未知状态恢复。 这听起来就像在这种情况下所发生的事情，

客户提到发生此问题时、 尽管 之后执行了重置切换、但 DP83867仍无响应。

以下是客户提到的内容：

上电后、DP83867无法建立链路、尽管 执行了8.5.5.1硬件复位、8.5.5.2 IEEE 软件复位和8.5.5.3全局软件复位、但器件没有响应。

此致

尊敬的 David：

对不起、我弄错了、我忘记了您提到之后的重置切换未解决问题。

似乎在功率提升过程中进行了复位、从而导致了该问题。 我不确定问题的确切根本原因、因为我们尚未测试此类案例。 请将重置延迟至斜升后的200ms、如果将来出现任何问题、敬请告知。

谢谢。

大卫