• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 137 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

[FAQ] DP83867IR: Packet Loss and CRC Errors with DP83867 using Short Cables

DP83867IR: packet loss with dp83867 on very short cable

Joris COLLOMB
Prodigy 10 points

Part Number: DP83867IR

Hello,

We are encountering errors at the physical layer. We are seeing the following type of syslog message from the DPAA driver (linux kernel 5.10.186):

fsl_dpaa_mac 1ae8000.ethernet int0: Err FD status = 0x00080000

We are using a very short cable setup (a few centimeters). We followed the recommendations for register values provided for this type of situation.

However, when we dump the register values, we observe two discrepancies:

address : value from dump -> recommended value
0x0115 : 0xb8bb -> 0x5555
0x0118 : 0x8bf9 -> 0x0771

Is this expected? These registers (like many others mentioned in the recommendations) are not documented in the datasheet, which makes it difficult to understand whether this behavior is correct. Did you have a more exhaustive datasheet, where this fix is described ? 

Do you have any recommendations to help us better understand or debug this issue?

 

thanks a lot,

JCO

  • 0
    TI__Mastermind 36915 points

    Hi JCO,

    1. A few centimeters of cable is very short, may I ask what the end use of this is that requires such a short cable?

    2. Does the short cable script you've linked have any affect on the packet loss?

    3. When you switch to a longer cable does the issue go away? What cable length do you start to see this problem with?

    4. Are both link partners DP83867s on identical boards?

    Joris COLLOMB said:
    However, when we dump the register values, we observe two discrepancies:

    I believe these registers should hold the recommended values. Does writing to these registers ever populate the correct value?

    We are planning to add these registers to our datasheet in the next revision, but as they are more internal-facing DSP registers they have previously been left out. This script  is also mentioned in our DP83867 troubleshooting guide:

    Best,

    Shane

  • 0 in reply to Shane Hauser
    Prodigy 10 points

    thanks,

    1. Boards are mounted in a rack and connected through a backplane. The boards on which we observe the issue are located right next to each other. This is not systematic: the issue does not appear on all boards, nor on all racks.

    2. We will run some tests without the script to evaluate the impact. This will not be done today; I will provide an update later.

    3. It is not very convenient for us to test this, as we do not see the issue on our lab racks, only on the client side. However, I can say that when we move the faulty board to a position farther away in the rack, the issue disappears.

    4. Yes, both partners are identical boards, both equipped with DP83867s.

    Note: This is not an issue related to a single board; it has been observed on several boards.


    Regarding the dump:


    The values of registers 0x115 and 0x118 are set to the requested value plus 0x8888. Is it expected that the most significant bit of each 4-bit nibble is set? Do you know what this means?

    Regards,
    JCO

  • 0 in reply to Joris COLLOMB
    TI__Mastermind 36915 points

    Hi JCO,

    I will await your update on #2, as for your question:

    Joris COLLOMB said:
    Is it expected that the most significant bit of each 4-bit nibble is set? Do you know what this means?

    On further investigation, yes this is expected. The most significant bit in each of these registers is read-only and will be set by the PHY. I tested this in our lab and saw similar behavior.

    Best,

    Shane

  • 0 in reply to Shane Hauser
    Prodigy 10 points

    Hi Shane,

    I have a response for the point 2, we run some test without the script, and I can confirm that the issue is more frequent without it.

    The issue is not present at each run. If the issue is present at the beginning of a run, we will observe it regularly till a reboot. If it is not present, it does not seam to appear if we let the product running.

    without the script, the rate is around 1 over 2 or 3 boot. With the script, 1 over 10 to 20ish.

  • 0 in reply to Joris COLLOMB
    TI__Mastermind 36915 points

    Hi JCO,

    When packet errors are observed, do you see the value in register 0x0015 incrementing on the receiving PHY? This would be the RX_ERROR_COUNTER, and should track symbol errors coming form the link partner of the PHY. 

    Best,

    Shane