DP83TG720S-Q1: Once abnormal state after power on

Hi Daniel,

Master/Slave setting can be configured by bootstrap or register write. Are the bootstraps configuring master or slave? Are you writing registers to configure master or slave?

Thanks,

David

Hi Daniel,

Is the customer intending to use Master or Slave mode?  Slave mode is enabled by default by bootstrapping of the LED_0 pin.  Do you have schematics you can share?  Which connected PHY is Master (Both PHYs cannot be configured as Master)?

Regards,

Undrea

hello David, current design is configured Master by bootstrap and after power ON set the 0x1834 as Master by software,  but  happened in customer side, there is An extremely low probability to found the register 0x1834 is in Slave Mode.

hello Undrea,

1. Use Master Mode 2. yes, enabled by bootstrap.   3.no, Our product is already in mass production, and the probability of this issue occurring is extremely low, close to one in 100,000.

Hi Daniel,

In the fail case, can you read register 45Dh which tells what the bootstrap pin values are, we would like to see if the bootstrap has changed from Master to Slave.

Regards,

Undrea

hello Undrea

         yes, understand your meaning, current state is not easy to change the software to do the analyze.  so is there other Possibility to cause this issue.

Hi Daniel,

Given the difficulty to repeat the issue, it's difficult to speculate as to what the root cause may be.  It may be some very marginal timing at bootup with the strap pins or programming.

In the fail case is other PHY functionality ok? Can you read/write to device when this issue occurs?
Also, after issue is observed, if you only write to register 0x1834 to set as Master, does that recover the link?

Regards,

Undrea

hello undrea,

1)  Fortunately, we reproduced the issue once, but this time the situation is different from the last time. In this case, the 720s PHY is the master, but it is link down with the peer device. Below are the register values read when the issue occurred.

• register 0x0  ->     Value is 0x0140
• register 0x1  ->     Value is 0x0141
• register 0x2  ->     Value is 0x2000
• register 0x3  ->     Value is 0xA284
• register 0x1E  ->   Value is 0x0000
• register 0x10  ->   Value is 0x84
• register 0x12  ->   Value is 0xE400
• register 0x639  -> Value is 0x0028
• register 0x63A  -> Value is 0x0000
• register 0x45D  -> Value is 0x2024
• register 0x63E  -> Value is 0x0000
• register 0x63D->       Value is 0x0000
• register 0x60D  ->     Value is 0x000F
• register 0x60A  ->     Value is 0x936
• register 0x547  ->     Value is 0x1401
• register 0x545  ->     Value is 0x0038
• register 0x543  ->     Value is 0x0023
• register 0x608  ->     Value is 0x027A

         What surprised me is that 0x60D is 0xF, and 0x547 is 0x1401

2) After a power cycle, the PHY is in normal status, but I found that the value read from 0x60D is 0x6.

Hi Guofang,

SGMII FIFO full/empty indication is expected when link drop occurs but MAC is still sending data.

Who is the peer device? 

What length of cable are you using? Can you try using a different length of cable?

Thanks,

David