[参考译文] DP83826E：复位后、当 CDCR 寄存器中的 cfg_rescal_en 设置为 true 时、链路从未建立

Eric、您好！

我不熟悉清除该位的效果。

您能否尝试以下两次寄存器写入来尝试和解决链接：

1) 0x1F = 0x4000 (软重启)

2) 0x0[9]='0'(重启自动协商)

谢谢！

Evan

Evan、您好！

很抱歉耽误你的时间太长。 本周我们进行了一些测试：

• 写入软重启或自动协商未解决问题。 恢复(没有 cfg_rescal_en 位)的唯一方法是执行物理复位或通过 BMCR 进行复位。
• 在上电后增加已置为有效的延迟或在释放物理复位后取消置为有效的延迟不会解决该问题。
• 我们使用 PWRDN 引脚阻止链路、直到准备就绪。 此问题仅按以下顺序(随机)发生：
  1. 在 RESET 引脚激活且 PWRDN 激活的情况下上电；
  2. 释放 RESET 引脚并使 PWRDN 保持活动状态；
  3. 等待几秒钟、让系统准备就绪并释放 PWRDN 引脚、以便建立链路；
  4. 链路永远不会建立、并且 cfg_rescan_en 位始终为 true。
• 在 RESET 引脚处于同一时刻释放 PWRDN 可解决该问题。 ***确认问题消失了、但在我们的情况下、启动 PHY (无需链路即可访问)非常重要、直到系统准备好进行通信。

Eric、您好！

感谢您的跟进。

重要的是引导 PHY 时无需链路即可访问、直到系统准备好进行通信为止。

您能解释一下这一要求吗？ 如果在系统准备好进行通信之前建立 PHY 链路、有什么问题？

请尝试写入0x0[11]='1'以启用断电、而不是使用 PWRDN 引脚、并在系统准备好通信后写入"0"以进行正常操作。 此情况下问题是否仍然出现？

谢谢！

Evan

您好 Evan

在器件准备就绪之前进行隔离的要求是因为可以在 TCP/IP 或 EtherCAT 中使用同一个 PHY。 EtherCAT 需要在器件准备好通信之前保持链路断开。 这是我们选择该 Phy 的一个原因、因为我们可以在异步上电中使用 PWND 引脚。

如果使用第11位而不是 PWND 引脚、则可能引入一个较小的机会窗口、释放复位后链路可以出现。 一些 EtherCAT 主站是非常明智的、发生这种情况时可能会生成错误。

你知道我怎么能得到更多关于 cfg_rescan_en 位的信息吗? 它真的与电缆测试有关吗？ 该位在复位后为真、当一切运行良好时变为假、我想这不仅是读/写、而且是硬件使用它？

同时、我们正在分析启动时的所有信号、以至少仔细检查 PHY 是否符合电气要求。

谢谢你

您好！

Evan 今天太棒了,明天还会再来的。  

此致、

Gerome.

Eric、您好！

非常感谢您澄清 EtherCAT 要求。

CFG_rescal_en 与电缆测试无关、该位处理内部 PHY 电阻器校准。 我们不希望将此位配置为初始化、但我们正在进行内部讨论以确认这一点。

我还有两个测试需要确认：

1) 1)写入0x1F = 0x8000是否可以解决链路问题？ 如果是、这是否是可以接受的权变措施(轮询链路状态并定期写入0x1F = 0x8000、直到链路)？

2) 2)每次下电上电的链路故障率是多少？

谢谢！

Evan

Eric、您好！

感谢您确认链路故障率。 请允许我花一些时间来确认这方面的建议、目前正在就同一问题进行内部讨论。

谢谢！

Evan

Eric、您好！

很抱歉耽误你的时间。

写入0x1F = 0x8000是我们的设计团队建议的权变措施。

我了解 在驱动程序初始化后复位 PHY 寄存器的问题-您是否能够在没有驱动程序配置的情况下建立链路？

如果是、我们可以实现以下逻辑：

1) 1)为 PHY 供电、等待链路

2) 2)如果链路出现、请继续进行驱动程序初始化

3) 3)如果链路失败、则应用0x1F = 0x8000。 如果驱动程序初始化解决了链接问题、则继续执行此操作

谢谢！

Evan

尊敬的 Evan：

另一个埃里克在这里只是为了混你!

我和 Eric B.合作对其进行调试、特别是使用示波器和打开的产品对其进行调试。

由于在 uboot 和 Linux 驱动程序中对其进行调试是漫长而困难的、我尝试使用闪存到 SPI 闪存中的裸机独立应用程序。 我首先仅在 RESET 和 POWERDOWN 信号被置位和释放时进行了尝试、但无法轻松地重现关闭电源并重新启动问题。 我最初认为它仅与加电问题有关。

然后、我们决定尝试在不降低功耗的情况下在环路中运行简单的 PHY 链路测试应用。 它重现了这个问题(从2对50尝试到10对50尝试)。 由于它与 uboot/Linux 不相关、而仅在2个硬件信号上、我想它可以解答您之前关于驱动程序问题的问题。 25us 的复位置位(上电后)加倍至50us、SMI (MDC/MDIO)上2ms 的"安静"周期加倍至4ms。 我们最终验证了 cfg_rescan_en 位的状态、并发现它是在链路断开时设置的。 向该位写入0总是使该链接出现。

然后、我们购买了裸片版本1 DP83826 (我们仍有许多裸片版本0器件)。 裸片版本1已焊接在电路板上。 我们看到配置发生了变化、因为现在 FLP 处于禁用状态(我们在每个 PHY 搭接引脚上没有上拉和下拉、而是通过内部上拉/下拉使用引脚的默认状态)。 SOR1和 SOR2自 PHY 裸片修订版本1的这种微小更改开始和结束时就已经过验证、一切都符合我们的意图。

 芯片版本1 PHY 上进行的测试具有相同的结果。

尝试了许多不同的序列(因为超过1周)。 循环数已增加、并且将 cfg_rescan_en 写入0是解决该问题的唯一方法。 PHY 已在周末复位超过40K 次、未出现任何问题。

我想强调 Eric B 对您的问题的回答。 将0x8000写入0x1F 不能解决该问题。

我们怀疑、当 PHY 处于断电状态时、有时无法通过外部 Rbias 电阻器完成其模拟校准。 什么影响的事实,有时它成功,有时不,我们不知道。 我们还在通过 SMI 访问 PHY 之前释放断电之后应用了延迟、就像存在一些类似的复位要求、但没有发生任何变化一样。

我看了 DP83826 EVM 的情况、发现引脚 PWDN 连接到分线板的接头。 如果未将其连接到低电平并控制在复位释放很长时间后释放、您将无法轻松重现自己。

我还查看了有关将 DP83826用于 EtherCAT (SNLA344C)的原理图。 本文档更新了我在论坛上看到的有关 Cext 值等的很多东西。 我不知道该原理图是否有真实的电路板、但断电引脚只有上拉电阻。 如果存在这样的板、那么肯定不使用。

由于 uboot/Linux 需要大量时间来引导(而不是运行 EtherCAT 从站控制器堆栈的小型微控制器)、因此我们必须能够保持链路断开、直到我们知道我们是将 DP83826用于"TCP/IP"协议或 EtherCAT 协议。 需要在链路断开时更改 PHY 配置、以避免在运行堆栈的软件不可用时断开 EtherCAT 环路。 这就是为什么我们选择该 PHY 时允许我们使用 POWERDOWN 引脚进行该操作的原因。

然后、我猜测在 PHY 规范中使用断电引脚可能不会频繁、这也是我们对该 PHY 遇到一些问题的原因。

我们最近改变了 uboot 和 Linux 处理复位和断电信号的方式、一次释放一个信号、而不是同时释放两个信号、以便能够根据我们在产品设计时使用的模式("TCP/IP"或 EtherCAT)通过 SMI 应用正确的 PHY 配置。 它揭示了问题。
到目前为止、当两个信号同时释放时、我们从未出现链路问题。

我希望它能澄清我们所看到的问题到底是什么。 我可以理解、对于一种未被广泛使用的特定模式、很难找到答案、您需要从自己的研发团队那里获取非常深入的详细信息。

如果您需要更多详细信息或有其他问题、请告诉我。

此致、

Eric Lewis

Evan、您好！

我还想补充埃里克·刘易斯的答复,它可以真正有用的理解背后的真正问题和这个位(cfg_rescal_en)是什么用。 不要误解我、但写入0x1F = 0x8000的解决方案有点像在发生错误时要求某人重新启动计算机。 我们使用此 Phy 销售产品、必须获取完整的信息、以确保能够解决所有问题、而无需使用另一个 Phy 进行重新设计。

此致

Eric、Eric、大家好、

感谢您对问题历史记录和测试用例的详细说明。 我和您一样、对  cfg_rescal_en 缺乏上下文感到沮丧、仍在研究与 r&D 解决此问题

同时、我将探讨不依赖于 PWDN 引脚的权变措施。

使用 bit 11 (而非 PWND 引脚)可引入小窗口释放复位后可提供链接。 某些 EtherCAT 主站非常明智、在发生这种情况时可能会生成错误。

当使用0x0[11]而不是 PWDN 引脚置为断电时、我们是否可以确认灵敏度？ 如果我们可以利用此时序通过寄存器置位断电、则应该可以在建立链路之前短暂访问寄存器。

谢谢！

Evan

尊敬的 Evan：

我们在复位释放后所需的2ms 之后执行了测试、写入 BMCR 的位11。 在关闭电源并重新启动或仅在置位 PHY 复位后重新启动新循环迭代后、就完成了数千个循环。 这两种方法都没有出现问题、PHY 每次都能建立链路。

使用这种方法的问题是 uboot 和 Linux 驱动程序从许多函数(特定和通用函数)访问 BMCR。 必须修改驱动程序(特定的板级配置文件和 PHY 的通用文件)以拦截设置了 IEEE 断电位的事实、并作为一个示例、避免使用 BMCR 的位15进行标准复位。 对 uboot 或 Linux 新版本的任何更改都需要 将代码与 更改进行比较、并再次将修复程序应用到此新版本。 使用 POWERDOWN 引脚不需要对驱动器进行太多修改。 它可以是由第一级引导加载程序或 FPGA 置位的单个 I/O 状态、在驱动程序完成常规操作后发布。

我们想知道我们何时会收到有关此问题的信息？  您的支持团队是否会尝试通过在掉电/中断引脚上使用下拉电阻并在复位之后释放该引脚来重现该问题？ 从我们这边看、它似乎很容易重现。 甚至不需要切断使用的电路板的电源。

否则、其他人也将认为断电引脚可被使用、并且将在我们遇到的同样问题中运行。

请向我们说明您为什么要探索不依赖于 PWDN 引脚的权变措施。

此致、

Eric Lewis

Eric、您好！

在 PWRDN 引脚被驱动为低电平时供电、这似乎是 PHY 电源序列的边缘情况行为。 正如您已确认通过寄存器访问设置断电模式不会导致问题、因此该引脚可能还有另一种权变措施。

我们使用 PWRDN 引脚阻止链路直至就绪。 此问题仅按以下顺序(随机)发生：

1. 在 RESET 引脚激活且 PWRDN 激活的情况下上电；
2. 释放 RESET 引脚并使 PWRDN 保持活动状态；
3. 等待几秒钟、让系统准备就绪并释放 PWRDN 引脚、以便建立链路；
4. 链路永远不会建立、并且 cfg_rescan_en 位始终为 true。

[报价]

对于此序列、请仅在 PHY 上电后(复位仍有效)更改 PWRDN 引脚驱动为低电平的步骤(1)进行测试。

将 PWRDN 驱动为低电平的时序可以调整为 PHY 通电和 PHY 链路之间的相同短时窗口。

您是否看到本例中出现了此问题、以及它是否满足系统要求？

谢谢！

Evan

尊敬的 Evan：

感谢您的回答。

我相信这不仅仅与 PHY 的上电有关、因为我们最近的测试表明、即使 PHY 电源保持开启且仅完成了硬件复位(POWERDOWN 引脚同时置位)、也会出现问题。 循环测试中的此复位显示了问题。

实际上、这些在循环中复位 PHY 的测试要快得多。 在释放复位然后断电(后者通过引脚或 BMCR)后、两次3秒后读取 BMSR、以查看链路是否存在、然后读取 CDCR 寄存器、如果设置了 cfg_rescal_en 位、则将其清除。 三秒后、再次读取了 BMSR、并再次读取了 CDCR。 每次在等待初始3秒(确认没有链路)后为循环设置 cfg_rescan_en 时、清除它始终显示3秒后链路已启动。 每个循环迭代都可以在5秒内完成、而不会出现此问题。 与在 uboot 中修改代码相比、使用独立测试应用程序执行错误数的结果要快得多。 在示波器上捕获信号、以确保它们符合预期的顺序。

因此、如果没有误码、则已完成请求的测试更改步骤(1)、因为 PHY 上的电源已生效、在这些"重新启动"测试期间从未移除。

如果您希望我检查其他内容、请告诉我。

此致、

Eric Lewis

Eric、您好！

对于此测试、PWRDN 引脚是否在 PHY 初始上电期间被驱动为低电平？

谢谢！

Evan

尊敬的 Evan：

没有 POWERDOWN 引脚在初始期间未被驱动为低电平、并且仅在上电期间被驱动为低电平。

POWERDOWN/中断引脚上有一个上拉电阻器、因为我们已将其用作通过中断来检测链路变化(如果有需要)的配置。 在 RESET 引脚上有一个下拉电阻器。

在我通过一个独立应用进行的测试期间、用于向 PHY 驱动信号的 FPGA 未在上电和复位时使 POWERDOWN 引脚生效。

由于我们的平台使用 SoC、因此第一级引导加载程序必须首先加载位流、以便 FPGA 引脚可以由处理器驱动。 在加载 FPGA 位流之前、复位和断电引脚都不由 FPGA 驱动(复位和断电引脚都处于 tri 状态、直到处理器启用这些引脚)。 RESET 通过下拉电阻保持有效。

一旦在 PHY 上提供1V8和3V3、外部25MHz 振荡器就会发送基准时钟(振荡器由与 PHY 相同的1V8电源轨供电)。

从非易失性存储器加载之后、独立测试应用只是将引脚置于正确状态(复位 PHY 并将断电置为有效)、然后用适当的时序否定它们、通过 SMI 执行所需的序列、记录结果并执行新的测试循环将复位和断电重新置为有效。

我们尝试了大量序列、其中一些序列涉及在释放掉电后等待 SMI 访问、因为没有根据这个外部信号定义时序要求。 即使在执行 SMI 访问之前等待数秒也会显示、有时链路未建立、并且读取 CDCR 会在设置 cfg_rescan_en 位的情况下确认停止的模拟校准。

正如我告诉过您的、重现这个过程相当简单。 您应该能够在50个环路内重现此问题。 当我们清除 cfg_rescan_en 位作为权变措施时、我在周末运行了测试、循环次数超过40K、但没有出现问题。

此致、

Eric Lewis

Eric、您好！

我们重现了此问题、并确认它是设计中的已知错误。

可能的替代方法是使用寄存器命令将 PWRDN 置为有效、或在发生故障的情况下对 PHY 进行软复位。

对于此处的挑战、我们深表歉意。

谢谢！

Evan

尊敬的 Evan：

感谢您确认我们到目前为止看到的情况、感谢您通过这些调查提供的慷慨支持。

我可以问您一些问题吗？

1) 1)您是否可以申请更新下一个数据表版本、以描述断电引脚的问题并提供您向我们建议的替代方案？ 其他人将从中受益。
2) 2)您是否可以请求更新下一个数据表版本、以便定义 cfg_rescal_en 位的正确类型？ 如果客户不需要使用此位、则可能应将其标记为保留(必须为0)而不是 R/W
3) 3)我从您的论坛上读出的很多内容、我是否很好地理解如果我们决定仍然希望按预期使用 POWERDOWN 引脚、并在 cfg_rescan_en 引脚卡在高电平时将其清除、那么这可能会略微降低以太网信号的合规性？ 我知道这是一个艰难的,但我问它无论如何。
4) 4)支持 EtherCAT 并具有断电引脚的其他 PHY 是否存在同样的问题？ 如果愿意、您可以私下回答我。

此致、

Eric Lewis

Evan、您好！

在最终应用程序中测试权变措施之前、我一直在等待单击"解决"按钮。 我可以确认权变措施、在进行复位周期(使用引脚或者使用硬件复位位)时、保持断电引脚不被置为有效、在复位后等待2ms 并将断电置为有效、工作正常。

对我来说、保留此引脚的实用程序是最佳折衷方案、此外、减少 u-boot 和内核中的工作、以防止 BMCR 复位在引导时打破隔离。

祝你度过美好的一天