DP83867IR: AM64x EVM RX CRC, rxAlignCodeErrors RGMII

Hi Nam,

To confirm this is a PHY issue, is it possible to try connecting a DP83867EVM to the PC and see if the PHY EVM can communicate with the PC?

Can we try some loopback tests to check to see on which interface the errors occur?

• Use PC to generate packets, set PHY for reverse loopback, packets will be sent back to PC, check for errors to determine if Copper interface is faulty.
• Use MAC to generate packets, set PHY for digital loopback, packets will be sent back to MAC, check for errors to determine if MAC interface is faulty.

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nam,

To confirm this is a PHY issue, is it possible to try connecting a DP83867EVM to the PC and see if the PHY EVM can communicate with the PC?

Can we try some loopback tests to check to see on which interface the errors occur?

• Use PC to generate packets, set PHY for reverse loopback, packets will be sent back to PC, check for errors to determine if Copper interface is faulty.
• Use MAC to generate packets, set PHY for digital loopback, packets will be sent back to MAC, check for errors to determine if MAC interface is faulty.

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nikhil,

I appreciate your quick response!

Nikhil Menon said:

Use MAC to generate packets, set PHY for digital loopback, packets will be sent back to MAC, check for errors to determine if MAC interface is faulty.

I did this TX loopback test before and here was result:

Table 1: Did not modify tx/rxDelayInPs and enabled Near-End Loopback

Table 2: Modified txDelayInPs and enabled Near-End Loopback

I think the problem could be at Signal Process block that is at Figure 10. Block Diagram, Near-End Loopback Mode in: https://www.ti.com/lit/an/snla246a/snla246a.pdf?ts=1632270840270

Moreover, I used the Linux SD card image and did the same test and did not see such issue. So I think HW or cable is not a problem.

Please advise me what I can check next.

Nikhil Menon said:

Use PC to generate packets, set PHY for reverse loopback, packets will be sent back to PC, check for errors to determine if Copper interface is faulty.

Do you still need this result?

Best regards,

Nam

Hi Dominic,

Thank you very much for your information. 

I also just found out the cause of this by comparing with the register when running EVM on Linux.

I think there is a bug, the idleCntThresh is always set to 0.

Adding gEnetCpbBoard_dp83867PhyCfg.idleCntThresh        = 5U will fix the issue.

Best regards,

Nam

Hi Dominic and Nam,

Thanks for your collaboration and I'm glad that we have come to a working solution for both of your cases. For this case with the idleCntThresh error, was a TI driver used?

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nikhil,

Yes, I think it is a bug in TI driver. Please look at my patch below.
Also setting txDelayInPs = 1250U is expected? In the FreeRTOS driver code, it is 1500U but in Linux driver is 2000U. 

Do you know why Linux has different delay?

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              =

Best regards,

Nam

Hi Nam,

We are looking into this issue and will have additional feedback by Monday latest.

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nam,

Apologies for the delay. Could you kindly confirm where you received this driver? Was it from the AM64x software page? Do you have the link?

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nikhil,

I downloaded from this link: https://www.ti.com/tool/PROCESSOR-SDK-AM64X

MCU-PLUS-SDK-AM64X — MCU+ SDK RTOS/NO-RTOS for AM64x

Best regards,

Nam

Hi Nikhil,

Do you have official fixes on this issue?

Best regards,

Nam

Btw, Domininc,

Dominic Rath said:

We removed both writes, to VTMCFG and DSPFFECFG from the driver in the MCU+ SDK, and that solved the CRC errors for us.

Understand this register is not documented in DP83869 DM but I have confirmed it's presence with PHY team.

Now, removing these two writes helped you because in current driver we are writing value 0 which is incorrect. So by removing the writes you actually kept the default value of 0x5 intact (writing which helped Nam).

Anyway, I will work with PHY team to get PHY data sheet updated to include missing register details.

Regards,

Prasad

Hello Prasad,

yeah, it would be great if you could get this sorted out.

We already figured that the DP83869 had the same registers, thanks for your confirmation.

We understand the issue about VTMCFG, where the MCU+ code merely missed to properly initialize a value that is later written to the register, and it turned out that writing this register with the default of 5 / not writing it made our CRC errors go away.

I'm more puzzled about the DSPFFECFG register, and why the MCU+ code unconditionally writes it with the "short cable" value. The datasheets says that writing this value will "not effect Long Cable performance", but I'm having trouble accepting that there's a non-default setting that has no drawbacks at all, and just improves one condition.

Regards,

Dominic

Hi Dominic,

Sorry but I don't have answer here. We had received these settings from PHY team to fix CRC errors when short cable (<1m) is connected.

They would would add details about this in their next DM revision.

Regards,

Prasad