This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83TC812R-Q1: Ethernet Switch Issues - Configuring for Open Alliance Specification

Part Number: DP83TC812R-Q1
Other Parts Discussed in Thread: AM2634,

Tool/software:

Context: Using 2x DP83TC812R-Q1 PHY's with a TI AM2634 Sitara chip configured for CPSW. While setting up master/slave configuration, we are following the `Application Note
DP83TC812, DP83TC813, and DP83TC814: Configuring for Open Alliance Specification Compliance (rev E)` document in order to improve interoperability.

Problem: After configuring for interoperability, exactly as the document outlines, we have a few units in our daisy chain that are not able to communicate with the master Ethernet switch (Marvell 88Q5192). If we remove the last few register configurations, the issue goes away. It is very reproducible. I have outlined our configuration flow below:

For slave (register_address, value):

// // Additional slave-specific configurations to meet Open Alliance Specification
0x0862, 0x0330
0x086E, 0x1868
0x0812, 0x00F4
0x0816, 0x0300
0x0873, 0x0021
0x0896, 0x22FF
0x089E, 0x0000
0x0411, 0x3F09

// Reduce slew rate of MAC interface IO drivers
0x456, 0x21

// // Improve RF immunity performance
0x85A, 0x3000
0x85B, 0x3000

// // Configure for TC10 interoperability
0x0189, 0x0018
0x018B, 0x144B

// Note(dharak): Below registers cause issues with Marvell switch while using CPSW
// 0x041C, 0x8802
// os_.delay(std::chrono::milliseconds(2));
// 0x041C, 0x0000
// os_.delay(std::chrono::milliseconds(2));
// 0x0514, 0x0640
// 0x0514, 0x0600
For master (register_address, value):
// // Additional master-specific configurations to meet Open Alliance Specification
0x081C, 0x0FE2
0x0873, 0x0021
0x089E, 0x0010
0x0874, 0x6866
0x0875, 0x6868
0x0812, 0x00F2
0x0816, 0x0300
0x0806, 0x293A
0x0807, 0x3348
0x0808, 0x3D56
0x083E, 0x045F
0x0834, 0x8000
0x0843, 0x4639
0x0862, 0x0330
0x0896, 0x32CB
0x003E, 0x0009
0x0830, 0x0143
0x0820, 0x03AA
0x0826, 0x1407
0x083D, 0x0047
0x080A, 0x0015
0x0831, 0x0703
0x0856, 0x0600
0x0857, 0x0500
0x0858, 0x0500
0x0859, 0x0500
0x0411, 0x3F09

// // Reduce slew rate of MAC interface IO drivers
0x456, 0x21

// // Improve RF immunity performance
0x85A, 0x3000
0x85B, 0x3000

// // Configure for TC10 interoperability
0x0189, 0x0018
0x018B, 0x144B

// Note(dharak): Below registers cause issues with Marvell switch while using CPSW
// 0x041C, 0x8802
// os_.delay(std::chrono::milliseconds(2));
// 0x041C, 0x0000
// os_.delay(std::chrono::milliseconds(2));
// 0x0514, 0x0640
// 0x0514, 0x0600
If this is a known issue or if there are any debugging steps you recommend, please let me know and I can test them for you. Thanks!
  • FYI if you could get someone from the relevant team to assist us with that, that would be much appreciated.

  • Additional information: On the Sitara, I am able to see that the PHY was correctly set to master/slave, the link up was successful, the SQI on both ports is 7, and the CPSW and LWIP stats indicate that messages are being sent/received.

  • Hi Dharak,

    Was there any issue with SNLA389 revision B? There is no problem using this configuration if not.

    It is interesting that link status is up and SQI is high. Are any interrupts being triggered (Register 0x12, 0x13, 0x18)? What is the link status according to Marvell 88Q5192?

    Does this issue occur on every single power cycle? Does a reset resolve the problem? 

    You mentioned messages are being sent and received according to Sitara. Where would the received messages be coming from, if communication with 88Q5192 is not possible? Is some loopback mode accidentally enabled (PHY register 0x16)? Is the Sitara/PHY showing packet errors?

    Can you also share your schematic with me? I would like to review.

    Thanks,

    David

  • Hi David,

    Could you please link me or send me the pdf for rev B? I am only able to source rev E on the TI website. 

    This issue does occur on every power cycle / sitara reset attempt. Resetting the Marvell switch also does not resolve the issue. I attempted to play with all applicable registers in the SNLA389 documentation and only the removal of the registers mentioned in my post seemed to resolve the issue. 

    I will check on the status of the interrupt registers this week and get back to you. Will also double check the link status on the Marvell switch.

    The received messages can be from the Marvell switch and from another Sitara that we have in the network. It is a closed network otherwise. When I pinged the Sitara through the Marvell switch, I was able to see the relevant LWIP stats increase on the Sitara side, even though the ICMP was never received on the Marvell side.

    What part of the schematic would you be interested in specifically? I can likely share it over email, but not in this public forum.

  • Hi Dharak,

    Please find attached SNLA389B. Please continue using this script if there are no issues.

    If you can share the schematic over email that would be great. I am interested to see which MAC interface you are using, the crystal/oscillator circuit, and MDI components, and will do a general check over of the schematic as well. I think you may have my email address already, if not I will share it over private message.

    Thanks,

    David

    snla389b.pdf