• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 182 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:

DP83825I: Clock Availability at Power Ramp

DP83825I: RX_ER/DV glitch after RESET deassertion (bootstrap pin)

Hamza Atifi
Prodigy 50 points
Part Number: DP83825I
Other Parts Discussed in Thread: DP83825EVM

Tool/software:

Hello TI team,

This is a follow-up to my earlier question regarding the DP83825I REF_CLK during power ramp-up: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1486923/dp83825i-clock-availability-at-power-ramp/5715771#5715771

We have updated our design based on your recommendation and now assert RESET after REF_CLK is stable. However, after this change, we noticed the following behavior:

  • We observe a single spike/glitch on the RX_ER/DV pin after RESET is deasserted (see attached oscilloscope screenshot).
  • RX_ER/DV is used as a bootstrap pin, with a 2.49 kΩ pulldown as recommended in the datasheet.
  • After the glitch, RX_ER remains low, and the PHY seems to boot correctly.
  • RESET and REF_CLK ramp-up seem correct, and the spike appears only once.

glitch appears just after RESET rises.

My questions:

  1. Is this a known problem with RX_ER showing a glitch after RESET deassertion?
  2. Can this glitch affect the bootstrap sampling, or is it safe as long as RX_ER is low at the moment RESET rises?

Thanks in advance for your support!

Best regards,
Hamza

  • 0
    TI__Genius 12281 points

    Hi Hamza, 

    I have just tested on the DP83825EVM and I could not observe RX_ER spiking when the reset deasserts. 
    However, this should be safe as long as RX_ER is low around VIH of the reset which is 1.7V.
    Has this been a recurring issue, and has strapping been misconfigured?

    Best,
    J

  • 0 in reply to J
    Prodigy 50 points

    Hi J,

    Thank you for your response.

    You mentioned that "this should be safe as long as RX_ER is low around VIH of the reset (1.7 V)."
    Could you please clarify what time window 'around VIH' refers to? Is it something like 10 ns, 100 ns, or longer?

    Is the strap sampling done as a one-time snapshot after reset deassertion, or is it observed over a longer period?

    So far, we haven't seen any sign of misconfigured strap pins on our side, but we’d like to ensure our setup is stable during the critical sampling window.

    Best regards,
    Hamza

  • 0 in reply to Hamza Atifi
    TI__Genius 12281 points

    Hi Hamza,

    The datasheet specifies that strapping configuration is set 50ms after the power-up before SMI is active.

    Strap sampling is done once.

    Best,

    J

  • 0 in reply to J
    Prodigy 50 points

    Hi J,

    Thanks for your reply.

    I went through the datasheet again, but I couldn’t find a section that clearly states that the strapping configuration is sampled after 50 ms.

    If you're referring to T4: "POR release time / Power-up to SMI ready: Post power-up stabilization time prior to MDC preamble for register access" (max 50 ms) — I understand this as the time before SMI/MDC access is allowed, but not necessarily as the point where strap sampling happens.

    Could you please point me to the exact part of the datasheet that confirms when strap sampling occurs?

    Best regards,
    Hamza

  • 0 in reply to Hamza Atifi
    TI__Genius 12281 points

    Hi Hamza, 

    I am referring to the T4. Strapping is meant to happen before SMI/MDC access is allowed. 
    I also checked the validation data on the device and strapping is to occur within 50ms. 

    Best,
    J