DP83867IS: could not ping with external PC issue

Hi Tess,

Since you are having issues with RX_CLK, it is possible that the PHY is getting strapped into the incorrect modes or the power-up timing is incorrect. Can you try the following:

1. Can you read registers 0x006E and 0x006F and check if the read values match your strap settings?
2. Can you check that your power-up timing matches that shown in section 7, figure 1 of the datasheet?
3. Is the clock going into the PHY from a crystal, oscillator, or the SOC? The clock needs to present before power-up.

Regards,

Adrian Kam

Hi Adrian,

Thanks for the prompt feedback.  Below is the addition information to help with issue:

• There are about 10pcs same prototype boards with Xilinx ZYNQ core chip . Every boards have 3pcs DP83867IS. Two DP83867IS have been mentioned in the post above for ETH0 and ETH1.  And the other DP83867IS is for SGMII interface.  
• The issue is not applied for all boards and PHYs. There are certain possibility PHY( both ETH0 and  SGMII ports) on some boards have the ping issue. And some replacements directly new DP83867IS chip on board sometimes could eliminate the issue. So we also consider the failures on hardware. But we could not understand the chip could work by doing global software reset.Waves if ping is OK.rar

 Please find the test result related to your last post on EH0 below. 

       1.Can you read registers 0x006E and 0x006F and check if the read values match your strap settings?

Registers 0x006E and 0x006F have values of 0021,0100 after power up and register read after drive initialization is complete, ping is not possible. However, after the global software reset, the values for this read register 0x006E and 0x006F are still 0021,0100. Ping is now possible.

       2.  Can you check that your power-up timing matches that shown in section 7, figure 1 of the datasheet?

The power-up timing wave can meet the needs of datasheet, as specified in the attachment.

Power up wave.rar

3. Is the clock going into the PHY from a crystal, oscillator, or the SOC? The clock needs to present before power-up.

The clock uses a 25MHz ±30ppm Crystal, which will not vibrating until it is powered up. See above power wave.

Test result for SGMII port PHY :

• The Reset timing measurement also found no problems (Follow Figure 2 in datasheet)
• The MII loopback register configuration code is as follows:

Phytool write eth2/0xf/0x001F 0x8000

Phytool write eth2/0xf/0x0000 0x0140

Phytool write eth2/0xf/0x0016 0x0040

Phytool write eth2/0xf/0x001F 0x4000

• Some boards can work with near-end lookback, but others could not.
• SGMII good board, mdio reads 0 and 0xf addresses both respond, and value is correct. SGMII bad  board, mdio read 0 address does not respond and value is ffff; read 0xf address responds and value is correct
• The attachment here is the SGMII interface timing test waveform, which contains the 1. power timing,  2.hardware reset timing, 3. good PHY differential port wave  and 4. bad PHY differential port wave.

SGMII PHY TEST WAVE.rar

Questions:

• How can I determine that the PHY local clock is locked with the CDR recovery clock?

• Please provide configuration instructions for loopback :

  A) RGMII MII Loopback/PCS Loopback/Digital Loopback/Analogue Loopback

  B) SGMII MII loopback/PCS Loopback/Digital Loopback/Analogue Loopback

• Any other suggestion to improve to clarify the issue? 

Thank you so much. 

Best Regards,

Tess Chen

Hi Tess,

1. Can you elaborate on this question? Why do you need to determine if the PHY local clock is locked with the CDR recovery clock?
2. To enable MII loopback, set bit[14] of register 0x0000 to 1. For all the other loopback modes, configure bits[5:2] in register 0x0016 to whichever loopback mode you want. Keep in mind that not all loopback modes are available for all MAC interfaces and for all speeds. Table 4 in section 8.4.4 of the datasheet provides an overview of which loopback modes are available for which MAC interfaces and speeds.
3. I noticed in your power-up scope shots that the clock is not oscillating until after all three supplies are powered on. The clock has to be oscillating before the PHY is turned on. Can you try externally powering the clock, power up the clock first, and then go through the power up sequence of the PHY?

Regards,

Adrian Kam

Hi Adrian,

Does we have any doc to guide customer for DP83867IS soldering process?  Thanks.

Hi Tess,

We do not have any documents to guide customers on the soldering process of the DP83867 specifically. However, since the package is used for other TI parts as well, there may be some documents on what you are looking for on the TI website.

Has your overall issue been solved since my previous reply?

Regards,

Adrian Kam

Hi Adrian,

We have tried the software configuration suggestions, but it didn't help.  Then we soldered another two boards and they are still not work but  different phenomena.

PHY connection: On the PS side of the ZYNQ7000, two DP83867 are connected to Xilinx hard core, which share a set of MDC, MDIO. After the full board power-up boot, enter UBOOT and boot the Linux system through QSPI. The DP83867 chip is configured as Mode0 except for the RX_CTRL pin configured as Mode3.

There are two main issues：

1.The waveform of RX_CLK first shows a 125-MHz clock after powering up the board, then becomes a 2.5-MHz clock. Then becomes a 125-MHz clock when the linux system starts up. It then goes to a 2.5-MHz clock, and finally goes to a long-high level with a low-level pulse signal of different pulse widths. As shown in the following figure:

RX_CLK：125MHz

RX_CLK: 2.5MHz

Rx_CLK different low-level pulse-width abnormal signal

2. In the configuration, the 0x6E register is read as 8881, and  the Autoneg Disable read by the register should be 0, but the status read from the register is 1. After the Global software reset, The RX_CLK waveform changes to 2.5 MHz and  the 0x6E register is still 8881.

Question:

- As mentioned above, the two PHYs share one MDC, MDIO-specific pin for the Xilinx PS interface, does this have any issue here?

- Any further suggestion to find the cause?

Thank you so much for the support.

Best Regards,

Tess

Hi Tess,

1. How long does the abnormal signal last? Is it permanent until you reset? If the RX_CLK looks strange, it possibly means that the PHY is stuck in a reset state or in an unknown state. When the Linux system starts up, does it trigger a reset somewhere during the start up process? Also, can you check to make sure that when the Linux system is starting up, the software does not configure some registers incorrectly, potentially putting the PHY into some unknown state?
2. Can you check the voltage values on the strap pins during power-up and reset? If the voltages are not within spec of the configuration you want (see table 5 of section 8.5.1 of the datasheet), then the PHY will be configured to a different mode or an unknown mode. If it is configured to an unknown mode, this could cause RX_CLK to look strange, and the reason why the values in register 0x6E do not align with what you expect.

Regards,

Adrian Kam

Hi Tess,

In addition, two PHYs sharing one MDC/MDIO line is fine as long as the two PHYs have different addresses.

Regards,

Adrian Kam