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.

DP83867IR: DP83867IR: Reset Pulse duration

Part Number: DP83867IR

Tool/software:

Hi,

This question is continuation of following thread.
e2e.ti.com/.../dp83867ir-reset-pulse-duration

At that time, it looked that customer resolved MDIO read issue by changing duration from GPIO glitch to RESET_N driven low.
However, after their further investigation, they still rarely observe this phenomenon.

According to their investigation, they found that they used a little bit strong pull up resistor for MDIO line.
According to datasheet, you recommend to use 1.5kohm for MDIO line. But they used 1.1kohm(In fact, customer configured as shown below.) in this line.


So, they removed 2.2k PU resistor at DP83867 side, then it looks that this issue is fixed.
However, customer have following question.

* Even case of 1.1kohm PU resistor is used, they confirmed that MDIO signal is enough driven to low (they confirmed approx 200mV in case of "LOW" drive signal).
Actually, they used strong PU resistor than specification recommend, however they can meet VIL spec of MDIO of DP83867IR.
So, customer can not understand why they looked issue is fixed.
Do you have any idea why we can see such difference ?

Best Regards,

  • Hi Machida-san,

    How often does customer observe the issue with 2.2k PU?

    200mV is sufficiently below low threshold for the PHY (VIL = 0.7V for 3.3VDDIO), but I'm not clear on VIL/VIH thresholds on MAC side.
    When capturing MDIO waveform, does it meet VIL/VIH thresholds for both MAC and PHY spec? Are PHY/MAC both using same VDDIO domain?

    I would also like to confirm any possibility of setup/hold time violation with 2.2k PU:

    Thank you,
    Evan

  • Hello Evan-san,

    We have one update and describe feedback for your question.

    Update contents :
    After investigating customer side, customer observed MDIO read issue in case of PU resistor value 2.2kohm as well.
    When they changed this PU resister value to weaker value than 2.2kohm (they tried to use 3.3k, 4.7k, 10k and no PU resistor.), they said that they do not observe MDIO read issue.

    Feedback for your question :
    >How often does customer observe the issue with 2.2k PU?
    At first, they did issue with 1.1k PU (composite resistance of 2.2k). In this case, I heard that failure rate was less than 1%.

    >When capturing MDIO waveform, does it meet VIL/VIH thresholds for both MAC and PHY spec? Are PHY/MAC both using same VDDIO domain?
    MAC side is AM64xx TI sitara processor. And we believe that VIL/VIH is satisfied on MAC side as well.

    >I would also like to confirm any possibility of setup/hold time violation with 2.2k PU:
    Attached information include setup/hold time for "command" and "Read" data.
    It seems that setup/hold time of "PHY" side is satisfied datasheet specification, however I think that I need to check detail about MAC side because it seems that setup time is NOT satisfied.
    I'm checking this point with customer.

    Then, I have one additional question.

    Q. As I said above, customer will change PU resistor for MDIO line to weaker value than datasheet description.
    What do you think about this change ?
    (In the first place, It seems that MDIO line is push pull architecture, so I think that PU resistor is not mandatory.)

    Best Regards,

    DP83867_MDIO_ReadIssue.pptx

  • Hi Machida-san,

    Thank you for confirming and sharing the data.
    The setup and hold time for #1/#2 waveforms are compliant with PHY timing.

    Please let me know if timing on MAC-side is compliant.

    Q. As I said above, customer will change PU resistor for MDIO line to weaker value than datasheet description.
    What do you think about this change ?

    PU is mandatory to maintain default high state. Using a larger resistor value is acceptable, as long as VIL/VIH thresholds, and timing requirements are met. If customer sees no issue over many iterations with >3.3k PU, then this is acceptable.

    Thank you,
    Evan