DP83867IR: Device unstable linkup

Hi David,

Please provide additional information about the failure cases such as:

1. How many boards do you have and how many are experiencing the failure signatures?
2. What percent of the time does occasionally and rarely mean?
3. How are you measuring link up?

LED_0 by default is link status. For scenario 2, are you saying there is link up after the reset signal is removed? All of these scenarios sound like reset pin is being accidentally triggered. Please probe the reset pin and ensure that the CPU is not pulling it low.

Thanks,

David

Hi David

Appreciate the response! I will confirm with the customer about percentage of time and qty of device they are experiencing this issue.

In the meanwhile, adding some waveform of the reset pin, it seems like the pin stayed H during the event, and for your comments below

David Creger said:

For scenario 2, are you saying there is link up after the reset signal is removed?

Yes, according to the customer normally they expect LED to stay off after the reset signal removal but for some reason the LED was on.

David Creger said:

How are you measuring link up?

I think they do it by checking the MDIO read, but I will re-confirm this

Scenario 2:

Scenario 4:

Regards

Hi David,

Is LED_0 configured as link status? If so, if LED_0 is on, then link is up. 

Holding the reset pin low will cause the device to be in reset mode and not link up. When the reset pin is released and goes high, the device will enter normal operation and link up automatically if it is strapped into autonomous mode and the appropriate link partner is connected. 

Therefore, the LED is expected to turn on when you remove the reset signal. Can you help me understand why "the customer normally expect LED to stay off after the reset signal removal"?

Thanks,

David

Hi David

Yes, LED_0 was configured as link status. The customer used LED_0 as indicator of the link status as well as using PC to check the end equipment link status with DP83867 in the application. 

David Creger said:

Therefore, the LED is expected to turn on when you remove the reset signal. Can you help me understand why "the customer normally expect LED to stay off after the reset signal removal"?

The customer first checked the end equipment on PC and found that the link was not performed, therefore they expected the LED to stay off since normally LED would indicate the status of the link, but instead the LED was on despite the device failed to link.

David Creger said:

• How many boards do you have and how many are experiencing the failure signatures?
• What percent of the time does occasionally and rarely mean?

As for your question, the customer mentioned that they've found this issue in 2 out of 10 boards. The customer didn't record the accurate percentage of when this issue was observed, but according to the customer, the issue only happened a few times out of many tests and it was hard to replicate the issue. The customer thought the device might have malfunctioned in the failure cases.

Regards

Hi David,

How is the customer checking link status on the PC? Please have them read register 0x1 bit[2] for link status. 

To me, it sounds like there is no issue here. The device will not function when the reset pin is held low, and will link up when the reset is removed. It will be very difficult to solve the problem here if is has only happened a seldom number of times and is not reproducible. Can you please help to precisely define the issue and find the exact conditions in which it occurs? It will help to probe the reset line during success and fail case, please provide scope shots under each scenario for comparison. 

Thanks,

David 

Hi David

Adding some updates from the customer:

David Creger said:

Please have them read register 0x1 bit[2] for link status. 

During the event when LED_0 is H and the device did not linkup,  DP83867 did not response to the attempts of reading 0x1 bit[2].

0x1 bit[2] was found to be 1 during normal linkup and 0 when the LAN cable was removed.

【Log during the linkup failure event】

　　root@xilinx-k26-som-2021_2:~# phytool read eth0/0x01/0x0001

　　error: phy_read (-22)         //DP83867 no response

【Log during normal linkups】

　　root@xilinx-k26-som-2021_2:~# phytool read eth0/0x01/0x0001                                             

　　0x796d                              //When LAN cable is connected                    

　　root@xilinx-k26-som-2021_2:~# phytool read eth0/0x01/0x0001                                             

　　0x7949                              //When LAN cable is removed           

When the device was in this linkup failure state, there's no response when sending SW_RESET（0X001F bit[15]=1) to DP83867

　　root@xilinx-k26-som-2021_2:~# phytool write eth0/0x01/0x001f 0x8000

　　error: phy_write (-22)        //DP83867 no response

Also, changing the high/low of RESET_N did not change anything on DP83867.

Attempts to access DP83867 registers all ended up no response.

As mentioned previously, this issue rarely happened and was hard to replicate.

However, it did occurred sometimes when powering up the device.

Base on these, the customer concluded that DP83867 malfunctioned somehow.

Below is the waveform acquired by the customer,

 according to the waveform, when VDD1P1 was around 500mV when RESET_N was internally pulled up.

Is it possible that for this reason the reset was removed before VDD1P1 reached 1.045V?

According to the DS, the device has POR and don't require reset after power on. Also since the customer was using 2 supplies mode therefore it should have no requirement on the power sequence.

Is there's anything you can think of that might have cause this issue?

Regards

Hi David,

Let me bring this up with the team and get back to you tomorrow.

Thanks,

David

Hi David,

It is possible that de-asserting the reset signal during power up is causing an issue. Please delay the reset signal to 1 second after all supplies are ramped. 

In the failure case, if you toggle the reset pin again, does it fix the issue?

Thanks,

David

Hi David,

Thanks for the response.

David Creger said:

It is possible that de-asserting the reset signal during power up is causing an issue. Please delay the reset signal to 1 second after all supplies are ramped. 

I will let the customer know about this.

David Creger said:

In the failure case, if you toggle the reset pin again, does it fix the issue?

No, in the failure case, device was not responding while toggling the reset pin. This does not change until the power supply reset.

Regards

Hello David,

20th Feb is US public holiday. I'll let David Creger respond as soon as he is back to office.

--
Regards,
Gokul.

Hi David,

This sounds like a power up timing issue, then. Please delay the reset pin de-assertion and let me know the results.

Thanks,

David

Hi David,

Below is the customer's application, the input of the RESET pin is controlled by FPGA GPIO which cannot pull low until the power is on.

For this reason they think it's highly unlikely that reset signal was pulled down before the power ramped up.

Is there any other reasons that might have caused this?

Also, do we have specification on how long should the customer wait until pulling the reset signal?(How long does it require for the device to start up)

Regards

Hi David,

The scope shot you shared shows reset pin being pulled low before power ramp to the PHY, and then going high midway during the power ramp. Is there something I am missing?

Please delay this signal by 1 second and let me know the results.

Thanks,

David

Hi David,

The customer reported no issue after delaying the reset time.

However, due to their system design, it would be hard to delay the reset for 1s. As a alternative, they decrease the power ramp up duration to make sure the power is up before the reset, by decreasing the ramp up duration to within 100ms they found no issue with 700 times test.

Adding a question from the customer:

When only using the internal reset of DP83867IR, is there a requirement for the power ramp up time?

Regards

Hi David,

Thanks for the answer.

I think the customer would like to figure out what's the shortest duration they will need to wait until they can safely remove the reset signal. In the case you mentioned, it would be 100ms, but is this the shortest time?

While using the internal reset there should be an delay duration and voltage threshold to reach before the reset is removed,

is there data available for these parameters? (something similar to the graph below)

Regards

Hi David,

200ms is the minimum time between the last power supply ramped and reset pin de-assertion. 

What do you mean by internal reset?

Thanks,

David 

Hi David,

Thanks for the response.

Internal reset is marked in datasheet as below as POR(power-on-reset) function.

I checked the datasheet again and found that the reset pin is latch-in for 200ms after the power ramp-up, this means that the de-assertion of the reset pin during the power ramp up shouldn't cause the issue as the device only gets internally reset upon power on, correct?

Regards

Hi David,

POR will be latched in for 200ms, yes. If there is a problem with the POR, the reset toggle afterwards will be effective and recover the PHY from an unknown state. This sounds like what is happening in this case, so please keep the reset pin de-assertion sometime more than 200ms after ramp completion. 

Thanks,

David

Hi David,

Sorry I got a bit confused by what you mentioned below, could you please elaborate a bit about this?

David Creger said:

If there is a problem with the POR, the reset toggle afterwards will be effective and recover the PHY from an unknown state. This sounds like what is happening in this case,

The customer mentioned when the issue happened, DP83867 was not responding despite reset toggle afterwards was performed.

Below is what customer mentioned:

After power ramped up, DP83867 failed to linkup, and there's no response from the device despite 8.5.5.1 Hardware Reset, 8.5.5.2 IEEE Software Reset and 8.5.5.3 Global Software Reset was performed.

Regards

Hi David,

Sorry I was mistaken, i forgot you mentioned the reset toggle afterwards did not fix the issue.

So it sounds like the reset during the middle of power ramp is causing the issue. I am not sure of the exact root cause of this problem as we have not tested such a case. Please delay the reset to 200ms post ramp and let us know if there are any issues in the future.

Thanks,

David