DP83867IS: RX link error

Hi JH,

We are looking into your question and will have additional feedback by Thursday of this week latest.

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi JH,

I have the following questions:

• What is the nature of the connection failure? No data observed on the line, data observed but Zynq can't receive, etc.?
• What is the interface between the PHY and Zynq?
• What are the values of the registers 0x0, 0x1, 0x10, 0x11, 0x6E, 0x6F?

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml).

Hi Nikhil,

Here is the customer's answthers.

1. It is a situation where they cannot see the request message in Zynq.

By activating the sniffer mode of the L2 Switch, the data received from the external node was checked. However, they could not check the PHY line or the RGMII line.

2. RGMII

3. Do you need the register values when the symptom occurs? Checking the registers with the symptom is difficult because the symptom occurs randomly in the field.

Below are the registers read values in normal status.

Regards,

JH

Hi JH,

Thanks for the requested information. If symptom is difficult to reproduce, a register dump during normal operation will still help me understand the PHY functional behavior. 

Based on register 0x10 value, it looks like the link is being forced as good. Is this intentional? 

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml). 

Hi Nikhil,

The read value of regiater 0x10 is 0x4040. Therefore, only bit6 and bit14 are set.

FORCE_LINK_GOOD of bit 10 is 0, which is Normal operation setting.

Could you please explain what 'it looks like the link is being forced as good' means?

Thank you.

JH

Hi JH,

Apologies, I had misread the register value and information. You are correct, only bits 14 and 6 are set. If "force link good" is enabled, we may be forcing the PHY to think an MDI link has formed when there is none, hence the loss of packets. However, this does not seem to be the case as you have pointed out.

The expected default value for register 0x10 = 0x5048. There is a reserved bit 3 that is not the default value. Has there been any intentional changes made to the PHY Control register? Can we try re-writing to the default value?

You also mentioned that customer cannot check the PHY line or RGMII line. Am I correct in understanding this means customer cannot probe either the MDI pairs or the RX_D[3:0] pins?

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml). 

Hi Nikhil,

1. The customer did not control the register 0x10 in the initial configuration. So, they don't know why the register was changed.

     They are going to investigate the change in the initial value of the register.

2. The customer can only  use the scope to check if there is a signal. But, they have not yet been able to confirm it because it is the symptom that occurs randomly in the field.

    Is there any recommended way to check the PHY line or RGMII line?

Thank you.

JH

Hi JH,

If there are any headers or series components in line with the PHY MDI lines or RGMII lines, they could be used to check the waveforms. Else, some external fixture may be needed (for example, a small daughter board with an RJ45 and headers for each MDI pair. Connect the PHY  board to this daughter via cable, and observe MDI via headers). 

Please let me know if this is at all possible, observing the waveforms will be extremely helpful to this debug. Else, we must look for other solutions.

One test we can run: PHY PRBS + digital loopback

• Enable the PRBS generator of the PHY and digital loopback to generate packets sent across RGMII to the Zynq. 
  • Write register 0x16 = 0xF004
• Observe packets sent to Zynq

If Zynq is still not seeing packets, it will become necessary to probe the RGMII lines to ensure the PRBS generator and loopback are working to send packets across RGMII.

Thank you,

Nikhil

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and it is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml). 

Hi Nikhil,

The customer is not finding out what caused the value to change for the register 0x10.

In particular, although bit3 of the register 0x10 is Read-Only, the value they read is always 0 unlike the datasheet.

Could you please confirm the default value of the register 0x10 via EVM?

Thank you.

JH

Hi JH,

I am on the same team as Nikhil, and will be supporting this thread from now on. On the evm, register 0x10 read 0x5048.

Sincerely,

Gerome

Hello, Gerome

The customer has additional questions.

1. How to check the PRBS in the Zync after writing the register 0x16 to 0xF004?

2. After power on or H/W reset, does DP83867IS work normally without register control as default setting?

JH

Hi JH,

Regarding your questions:

1) You would need to check with the company behind Zync to ensure that the packets are being read. 

2) Yes, DP83867IS would work normally assuming it is strapped into the settings you would like them to be at. Keep in mind that in default, TX and RX delays are enabled.

Sincerely,

Gerome

Hi Gerome,

The customer requests a more detailed explaination of the PRBS test method for the DP83867IS.

If you have any documentation on how to test PRBS for the phy chip, please provide it.

There are PRBS_BYTE_CNT and PRBS_ERR_CNT in the DP83867IS's register(Address 0x71, 0x72).

When should the registers be checked?

When the customer enable the PHY PRBS+digital loopback as below, how to check if there is an error?

Thank you.

JH

Hi JH,

For more detailed explanation on how PRBS+Digital loopback interface looks like from a signal chain standpoint, please check out Figure 7-5 located on DP83TG720S datasheet. I would like to note that PRBS checking will not check data coming from MAC side. I would like to refocus this conversation towards the initial issue that customer is seeing. Can you remention what the symptom they are saying points them to an issue in the RGMII side?

A common troubleshoot for RGMII is to ensure that the necessary shifts/skews are properly programmed for TX and RX of RGMII, located on section 8.4.1.2.2 and available on registers 0x32, as well as on Table 8 and 9 of DP83867 datasheet. Please ask customer if they have accounted for this yet.

Sincerely,

Gerome