• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 300 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.

DP83848-EP: Regarding the link down that does not return

?? ??
Prodigy 60 points
Part Number: DP83848-EP


Tool/software:

Hello
We are developing a product that uses the DP83848-EP.
We would like to know about the behaviour of this IC.
Please see the attached file.
This is a measurement of pins 1-2 (yellow) and 3-6 (blue) of the LAN cable connecting our product (which contains the relevant IC) and a PC, using a FET probe. Pins 3-6 are the signal (TX) output from the DP83848-EP.
(The signal waveform is displayed in overlay.)
This waveform shows a link down that occurred several times during communication, and then did not recover.
I have some questions about this.
1) Under what conditions do you think link downs like this occur that do not recover?
2) Why do the amplitudes of pins 3 and 6 increase at two points, ① and ②, after the seventh link down?
This kind of situation only occurs rarely.
We are also investigating problems with the PC side at the same time.
We would like to ask for advice from the IC manufacturer.
Best regards,
Tsuji

  • 0
    TI__Mastermind 25048 points

    Hi Tsuji-san,

    1) There are a few possible causes for this behavior, it's difficult to isolate without more information:

    • Auto-negotiation mismatch between link partners (near side enabled vs. far side disabled, or auto-neg advertisement mismatch)
    • Poor signal quality from noise in environment
    • PHY stuck due to ESD event

    Please share the register dump for both PHYs in the link failure case, this will help isolate.

    2) I suspect this is due to auto-negotiation disabled. Forced speed modes typically have higher swing.

    Thank you,
    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 60 points

    Hello, evan

    Thanks for your advice
    1) I understand that there is a possibility of this kind of problem occurring.
    I will check to see if I can get a register stamp.
    If I can get one, please give me some advice.
    2) I have not turned off auto-negotiation.
    I have forcibly turned off Auto-MDI/MDI-X.
    However, I don't think this is the cause of the problem.

    By forced speed mode, do you mean Forced Mode?
    This can be set either from the hardware AN_EN terminal or from the software register
    .
    The specifications state that it can only be set when the power is turned on or when the device is reset.
    Looking at the symptoms, I think the cause is the software, but is that correct?

    Best regards,
    tsuji

  • +1 in reply to ?? ??
    TI__Mastermind 25048 points

    Hi Tsuji,

    1) Sounds good, please share data when available and I will review

    2) Yes, I am referring to forced mode (auto-negotiation disabled, PHY set for fixed speed). This mode can be set through straps or registers. If this is not being changed through straps, I agree that possible cause is software script disabling auto-negotiation. These register dumps will help confirm this:

    Link up:
    PHY1 (848) 0x0 - 0x1F
    PHY2 (PC)  0x0 - 0x1F

    Link down (increased amplitude observed):
    PHY1 (848) 0x0 - 0x1F
    PHY2 (PC)  0x0 - 0x1F

    If PHY2 (link partner) is from Windows PC, please refer to Eth adapter settings to confirm the port has auto-negotiation enabled. If it is running on Linux, please do share register log.

    Thank you,
    Evan