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.

DP83849IV Link unstability

Basically, my DP83849IV based Ethernent PCB works well. (I made 4 engineering samples.)

It means that I can ping successfully from my PC to these 4 engineering samples with each specific IP/Mac address via  multi-port ethernet switch. 

After checking functionality, I am now closely monitoring link quality by ping them continuously(100ms interval, 512 byte buffer size)

But, sometimes(not always) after some times has passed, one of them lost link suddenly , and after that, this link is not recovered. Link LED turns on and off repeatedly.

Basically, I believe that my register accesses have nothing to do with Link stability of PHY chip, itself.

( I just check the link status, Link speed, Link duplex, etc, every 1 sec, I do not access auto-negotiation related registers except during initialization)

If I reset system during this unstability, all things are recovered correctly.

Is there  any possible root cause to show this link unstability?

Best Regards

Hak-Jin Jeong

  • Hak-Jin,

    Does the issue occur equally for all four boards or are there differences in the behavior of the four boards?

    What are the link partners on the other end of the cable for these tests?

    Patrick

  • Answer for your question

    -Link Partner Model: AT-FSW708 (Allied Telesyn)

    -Up to now, two of them show this behavior.

     

    Below images are the register value dump results when it shows abnormal behavior.

    (I captured them every time I met this abnormal behavior)

    Two things are interesting to me.

    First, Sometimes, AUTO negotiation completed but link is not established (in BMSR). Is it possible? Normal case?

        (Of course SD and DESCRAMBLER LOCK in PHYSTS has “0” value when it happens)

    Second, I found that RX FIFO overflow bit has been set. What happen if RX FIFO overflows? Can DP83849IV recover automatically? Or do I need to do something?

    I always found this RX FIFO overflow has been detected when it happens.

    So, I guess this might be the root cause of abnormal behavior, what shall I do in this case?

    Or , do you have any other insight on this issue? Please let me know your opinion

     

  • These register results are unusual.  It appears that your intended configuration is:

    • RMII
    • Cable extender mode
    • Auto-negotiation and Auto-MDIX enabled

    Could you confirm this is correct?

    The behavior you are seeing could be caused by a problem with the clocking and/or the configuration straps.  Could you provide the same register information again with the inclusion of both DP83849 ports?  Could you provide a schematic for review?

    Patrick