[参考译文] DP83867IR：AM64x EVM RX CRC、rxAlignCodeErrors RGMII

你好、Nam、

要确认这是 PHY 问题、是否可以尝试将 DP83867EVM 连接到 PC 并查看 PHY EVM 是否可以与 PC 通信？

我们能否尝试一些环回测试来检查错误发生在哪个接口上？

• 使用 PC 生成数据包、将 PHY 设置为反向回送、数据包将发送回 PC、检查错误以确定铜缆接口是否有故障。
• 使用 MAC 生成数据包、将 PHY 设置为数字回送、数据包将发送回 MAC、检查错误以确定 MAC 接口是否有故障。

谢谢、

Nikhil

此通信和任何相关通信中的所有信息均按“原样”和“不含任何瑕疵”提供，并受 TI 的重要声明(http://www.ti.com/corp/docs/legal/important-notice.shtml)约束。

你好、Nam、

要确认这是 PHY 问题、是否可以尝试将 DP83867EVM 连接到 PC 并查看 PHY EVM 是否可以与 PC 通信？

我们能否尝试一些环回测试来检查错误发生在哪个接口上？

• 使用 PC 生成数据包、将 PHY 设置为反向回送、数据包将发送回 PC、检查错误以确定铜缆接口是否有故障。
• 使用 MAC 生成数据包、将 PHY 设置为数字回送、数据包将发送回 MAC、检查错误以确定 MAC 接口是否有故障。

谢谢、

Nikhil

此通信和任何相关通信中的所有信息均按“原样”和“不含任何瑕疵”提供，并受 TI 的重要声明(http://www.ti.com/corp/docs/legal/important-notice.shtml)约束。

您好、 Nikhil、

感谢您的快速响应！

[引用 userid="423034" URL"~/support/interface-group/interface/f/interface-forum/1038081/dp83867ir-am64x-evm-rx-crc-rxaligncodeerrors-rgmii/3838998 #3838998"]使用 MAC 生成数据包，设置 PHY 进行数字回送，数据包将发送回 MAC，检查错误以确定 MAC 接口是否有故障。

我之前进行过此 TX 回送测试 、结果如下：

表1：未 修改  TX/rxDelayInPS 并启用近端环回

	txDelayInPs	rxDelayInPs	结果
PCS 环回	1500U	2000年 U	MAC： rxAlignCodeErrors 和 rxCrcErrors
数字环回	1500U	2000年 U	MAC： rxAlignCodeErrors 和 rxCrcErrors

表2：修改的 txDelayInps  和启用的近端环回

	txDelayInPs	rxDelayInPs	结果
PCS 环回	1250U	2000年 U	MAC：无错误
数字环回	1250U	2000年 U	MAC： rxAlignCodeError 和 rxCrcErrors

我认为问题可能出在   图10中的信号处理块。 方框图、  https://www.ti.com/lit/an/snla246a/snla246a.pdf?ts=1632270840270中的近端环回模式

此外、我使用了 Linux SD 卡映像并执行了相同的测试、 但未发现此类问题。 因此、我认为硬件或电缆不是问题。

请告诉我接下来可以检查的内容。

[引用 userid="423034" URL"~/support/interface-group/interface/f/interface-forum/1038081/dp83867ir-am64x-evm-rx-crc-rxaligncodeerrors-rgmii/3838998 #3838998"]使用 PC 生成数据包，设置 PHY 以进行反向回送，数据包将发送回 PC，检查错误以确定铜缆接口是否有故障。

您是否仍然需要此结果？

此致、

不结盟运动

尊敬的  Dominic：

非常感谢您的信息。  

我还通过与在 Linux 上运行 EVM 时的寄存器进行比较来找出原因。

我想存在一个错误、 idleCntThresh 始终设置为0。

添加 gEnetCpbBoard_dp83867PhyCfg.idleCntThresh     = 5U 将 解决此问题。

此致、

不结盟运动

尊敬的 Dominic 和 Nam：

感谢您的合作、我很高兴我们为您的两个案例提供了有效的解决方案。 在出现 idleCntThresh 错误的情况下、是否使用了 TI 驱动程序？

谢谢、

Nikhil

此通信和任何相关通信中的所有信息均按“原样”和“不含任何瑕疵”提供，并受 TI 的重要声明(http://www.ti.com/corp/docs/legal/important-notice.shtml)约束。

您好、Nikhil、

是的、我认为这是 TI 驱动程序中的一个错误。 请查看下面的补丁。
是否 还需要设置 txDelayInPs = 1250U？ 在 FreeRTOS 驱动程序代码中、它是1500U、而在 Linux 驱动程序中是2000U。  

您知道 Linux 为什么有不同的延迟吗？

diff --git a/source/networking/enet/utils/enet_board_am64x_am243x_evm.c b/source/networking/enet/utils/enet_board_am64x_am243x_evm.c
index f30ff1f..e33e09a 100644
--- a/source/networking/enet/utils/enet_board_am64x_am243x_evm.c
+++ b/source/networking/enet/utils/enet_board_am64x_am243x_evm.c
@@ -86,10 +86,11 @@ static const Dp83867_Cfg gEnetCpbBoard_dp83867PhyCfg =
 {
     .txClkShiftEn         = true,
     .rxClkShiftEn         = true,
-    .txDelayInPs          = 1500U,  /* 2.00 ns */
+    .txDelayInPs          = 1250U,  /* N.B. 1.25ns AM64x EVM work fine, otherwise TX CRC error */
     .rxDelayInPs          = 2000U,  /* 2.00 ns */
     .txFifoDepth          = 4U,
     .impedanceInMilliOhms = 35000,  /* 35 ohms */
+    .idleCntThresh        = 5U, /* N.B. Missing set this cause RX CRC error */
     .gpio0Mode            = DP83867_GPIO0_LED3,
     .gpio1Mode            = DP83867_GPIO1_COL, /* Unused */
     .ledMode              =

此致、

不结盟运动

你好、Nam、

我们将研究此问题、并将在最晚的星期一获得更多反馈。

谢谢、

Nikhil

此通信和任何相关通信中的所有信息均按“原样”和“不含任何瑕疵”提供，并受 TI 的重要声明(http://www.ti.com/corp/docs/legal/important-notice.shtml)约束。

你好、Nam、

对拖延表示歉意。 您能否确认您在哪里收到了此驱动程序？ 是否来自 AM64x 软件页面？ 您有链接吗？

谢谢、

Nikhil

此通信和任何相关通信中的所有信息均按“原样”和“不含任何瑕疵”提供，并受 TI 的重要声明(http://www.ti.com/corp/docs/legal/important-notice.shtml)约束。

您好、Nikhil、

我从以下链接下载了： https://www.ti.com/tool/PROCESSOR-SDK-AM64X

MCU-PLUS-SDK-AM64X — 适用于 AM64x 的 MCU+ SDK RTOS/NO-RTOS

此致、

不结盟运动

您好、Nikhil、

您对此问题是否有官方修复？

此致、

不结盟运动

BTW、 Domininc、

[引用 userid="387520" URL"~/support/interface-group/interface/f/interface-forum/1038081/dp83867ir-am64x-evm-rx-crc-rxaligncodeerrors-rgmii/3839664 #3839664"]

我们从 MCU+ SDK 中的驱动程序中删除了对 VTMCFG 和 DSPFFECFG 的两个写入操作、这为我们解决了 CRC 错误。

[/报价]

了解该寄存器未记录在 DP83869 DM 中、但我已确认它在 PHY 团队中的存在。

现在、删除这两个写入有助于您、因为在当前驱动程序中、我们写入的值0不正确。 因此、通过删除写入、您实际上可以保持0x5的默认值不变(写入有助于 Nam)。

无论如何、我将与 PHY 团队合作、更新 PHY 数据表、以包含缺失的寄存器详细信息。

此致、

Prasad

您好 Prasad、

是的、如果您能解决这个问题、那将会很棒。

我们已经计算出 DP83869具有相同的寄存器、感谢您的确认。

我们了解 VTMCFG 的问题、其中 MCU+代码仅遗漏了正确初始化稍后写入寄存器的值、结果是使用默认值5写入该寄存器/不写入该寄存器会导致 CRC 错误消失。

我对 DSPFFECFG 寄存器以及为什么 MCU+代码会无条件地以"短线缆"值写入该寄存器感到困惑。 数据表指出、写入此值将"不会影响长电缆性能"、但我很难接受存在根本没有缺点的非默认设置、只能改善一种情况。

此致、

Dominic

尊敬的 Dominic：

很抱歉、我在这里没有答案。 我们从 PHY 团队收到了这些设置、以修复连接短电缆(<1m)时的 CRC 错误。

他们会在下一个 DM 修订版中添加有关此内容的详细信息。

此致、

Prasad