DP83822HF: Timing Requirements

Hi Danilo,

1. DP83822 needs 200ms after power-up to stabilize before accessing registers. This is from the rise of the power rails, not from the rise of Reset.

2. Accessing registers 60ms after reset rising is ok so long as the reset rises at least 140ms after your power rails.

3. Reset needs to rise after the clock has stabilized. Its difficult to tell from the screenshot, but is the clock stable here? It looks like the clock is in a high state

Otherwise, the reset pulse width looks ok.

Best,

Shane

Hi,

Thank you for your answer.

I have a few follow-up questions:

The reset is asserted when the power rails come up, before the clock (XI) stabilizes. Therefore, according to Figure 7-2. Power-Up With Unstable XI Input, we toggle the reset again.

1. Does our sequence make sense considering the clock is unstable at power-up?
2. You mentioned that a minimum of 200 ms is required before accessing the registers (e.g., MDC) after power-up, but the datasheet defines 200 ms as the maximum. Could you please clarify this point (Section 7.6, Timing Requirements, Power-Up Timing T2)?
3. After each reset toggle, is the minimum delay before accessing the registers 2 ms (following the initial 200 ms for power-up)?
4. In some cases we see after the power-up that the devices fails to get IP from the server, it stays on default. Any thoughts on that? could be related to timing?

Thanks,
Ido

Hi Ido,

Thank you for the clarification. I did not realize the top image is zooming in on the marker in the bottom image, but now I understand the power sequence.

1. Yes your sequence looks ok. This would meet the power up timings with an unstable clock.

2. T2 is defined as the 'post powerup stabilization time [before register access]'. 200ms max means it will take up to 200ms for the PHY to stabilize before you should access registers. This does not mean you need to access registers within 200ms of startup.

3. Yes this is correct. Wait at least 2ms after reset before accessing registers.

4. This is interesting but is not necessarily a physical layer issue. I have a couple of questions to be sure:

• Is the fail condition dependent on power cycling the PHY? If not, does the fail seem dependent on anything?
• In the fail condition, does the PHY stay linked up? Do you notice any errors in register 0x0015?

Best,

Shane

Thank you Shane!

Regarding 4,

• We are running loops of power up/power down and verifying the IP. In some cases after power up there is no IP so I would say that it probably related to the power cycle.
• It seems that in the fail condition eth0 link is down. We will also check if we get errors in register 0x0015 with the SW guys..
  
  BR,
  Ido

Hi, We've just noticed another behavior.

On the fails that the link is down, the clock reference (RX_D3) seems to be 140Mhz instead of the expected 50Mhz, which explains why eth0 can't get up. Do you have any thoughts about that? XI is steady at 25Mhz.

Thanks