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.

DP83867CR: DP83867CR connection falls/packet missing

Part Number: DP83867CR

Tool/software:

Hello,
we used DP83867CRRGZ but sometimes connection falls down, let's say in random terms. 
Firstly, we checked RGMII CLK and Data by oscilloscope and Z0 probes soldered at TX side wires near to the DP83867CRRGZ. Is it possible have good measuring results by this method?

CLK and Data signals are length matched on our PCB - pico seconds difference.
I guess the signal bellow is wrong and we need to properly set delays by 0x0086 register, but I'm not sure and I would be glad for another check to this issue.


The blue wave is CLK, and red Data signal. 


Thank you so much for any idea how to solve our problem.
Tomas

  • Hi, 

    Measuring in such way is a good method. If this is an issue with the MAC receiving the data, modifying the RGMII delay timing using 86h register will resolve the issue. Note that you will have to set the PHY in RGMII delay mode in register 32h to ensure that the setting in 86h works. Are you measuring the RX_CLK and RX data pins on the PHY (which are the data sent to the MAC from the PHY)?

    In addition, to better help with the issue, what is the test setup? And how often does this issue occur?

    Could you also send us the register information from 0x00 to 0x1F?

    Have you also had the chance to look at our troubleshooting guide on the product page and read the register information that stores link quality of each channel?

    Please let me know.

    Best,

    J

  • HI J,
    I'm working on the issue with my colleague Tomáš. We measured RX_CLK and RX_DATA near to our FPGA.

    It is a our idea then we have wrong setting of register 86h.
    We will provide more information once we carry out the fix. Thank you for confirming we're on the right way.
    BR
    Jan

  • Hi Jan, 

    Please keep me updated. Please note that 86h and 32h are extended registers so they can only be accessed in a certain way: 



    Also, if you could answer my questions above, that would be great. I would also like to rule out that this may not be an RGMII timing issue. 

    Best,
    J

  • We've changed the delay register 86h to 1.75ns for both lines and the connection seems to be still stable without losts.
    The value in link quality register (A,B,C,D channels) is around 60 for all.

    It's been solved, thank you so much!
    Tomas and Jan

  • Good to hear!

    Best,

    J