DP83867IR: 1Gbps link fails with specific cables

Hi Mirko, 

It looks like the link is disabled in the register dump. But, you are seeing that the link is up and is 100Mbps, right?
Also, what are the cable length?

Best,
J

Hi J,

I apologise; I attached the register dump that was performed during the TDR, so the connection was down. For completeness, here is the one with the link up at 100Mbps with the cable C.

The cables are in range of 1-10 m, the cable C is 10 m.

I'd also like to mention that I tried the improvements suggested in Section 3 of the SNLA246C: '3.2 Improving Link Margins across Different Channels' and '3.4 Unstable Link Up Debug in 1 Gbps Communication'. However, these make small improvements, sometimes the PHY links at 1Gbps sometimes at 100Mbps with cable C.

---

Moreover, I read MSE registers as suggested in SNLA246C.

This is a case in which the PHY links at 1Gbps with cable C. 

MSE_A 0x0225: 0x0091

MSE_B 0x0265: 0x01C5

MSE_C 0x02A5: 0x003B

MSE_D 0x02E5: 0x0041

---

Sometimes happens the following situation:

when connecting the ethernet cable the MSE registers has these values for just one read (every 1 second):

MSE_A 0x0225: 0x014F

MSE_B 0x0265: 0x034E

MSE_C 0x02A5: 0x0064

MSE_D 0x02E5: 0x006B

And then, these registers has the followings values:

MSE_A 0x0225: 0x0076

MSE_B 0x0265: 0x7FFF

MSE_C 0x02A5: 0x7FFF

MSE_D 0x02E5: 0x7FFF

Thus, the PHY links at 100Mbps.

Hope this could help.

---

Regards,

Mirko

Hi Mirko, 

Interesting, it seems like this cable has a particularly bad link quality on line B before the link drops to 100M. 
Could you also try the script on 3.1 of SNLA246C?

I looked at your TDR results, but we would need more information to analyze the TDR results. 
If you can, could you run another TDR because we need the results from the following registers besides 1A5 and 1A6:


This is from this application note if you are interested to do the analysis yourself, but please share the results so I can also do the analysis myself and we can see what could be wrong with this particular cable, or if there are any issues on the PHY. 

Also, what is the length of cable C? And, does this cable work fine if it is used for other links?

Best,
J

Hi J,

I tried the script on 3.1 of SNLA246C but it does not make any difference.

Here it is the complete TDR registers:
0x0190: 0x000F
0x0191: 0x0000
0x0192: 0x1000
0x019A: 0x002B
0x019B: 0x0000
0x019C: 0x2400
0x01A5: 0x0021
0x01A6: 0x0061

---

Cable C is 10 metres long. It works fine for other links, even at 10 Gbps.

I also tried a 100 m cable, but it wouldn't connect at all, even at 100 Mbps.

Regards,

Mirko

Hi J,

I accidentaly hit the "This resolved my issue" button.

By the way, I already tried writing 0xF508 to register 1D5h, and this is one of the changes that let the PHY link at 1Gbps even with cable C sometimes. But it does not resolve the issue completely.

Cable A is 0.5 m CAT5E, cable B is 5 m CAT6, cable C is 10 m CAT6.

Until now more or less 5 units have been affected over thousands.

The link partners I tested are various, Intel, Realtek, 1G and 10G. Do you need more details on this?

I'll collect the schematics/layout and send them to you via private message, thank you!

Regards,

Mirko

Hi Mirko, 

I see. You can get additional increase of VoD swing using registers 0xA0 and 0xA1. However, the increase depends on the trim of the PHY. 
Since it is 5 out of 1000s of boards, could we try doing a ABA swap on the problematic PHY? This will isolate if this is the PHY or the board issue. 
Once you send me the design files, I can look at them to see if there's anything that is out of our recommendation also. 

Please let me know. 

Best,
J

Hi J,

I have already tried increasing the VoD via registers 0xA0 and 0xA1, but it made no difference.

I'm sending you the schematics and layout of the PHY parts.

In the meantime, we tried an ABA swap, and found that the issue followed the PHY. The board with the new PHY can now link at 1 Gbps with all cables, whereas a different board with the suspected PHY can only link at 100 Mbps.

Regards,

Mirko

Hi Mirko, 

Since the issue follows the PHY during ABA swap, we are suspecting this could be a quality issue. I will check your design and get back to you if there are any design flaws that could be causing this, but in the meantime, could you submit a return request through the FAE for failure analysis?

Best,
J

Hi Mirko, 

I noticed a few things on the schematic: 

1. MDC line doesn't require 2.2k pullup. 
2, I noticed that mirror mode is meant to be enabled but it seems like LED0 is not strapped to mode 3. Could you confirm?

Best,
J

Hi J,

1. We interpreted the MDIO as an I2C-like communication protocol, so the MDC line is pulled up. Could this lead to errors?

2. LED_0 (pin 47) is unconnected to disable Mirror Mode. There is a note in the schematic explaining the function of each pin, as well as the actual configuration.

Regards,

Mirko

Hi Mirko, 

MDIO is similar to I2C, but the specification does not require a pull-up on MDC. I've seen previous customer designs with pull-ups on MDC and it works fine. In your case also, most PHYs are working properly so I do not expect this will lead to errors, but I've given the feedback more as FYI. 

I apologize for the confusion on mirror mode. I misread the strap configuration as you meant to enable mirror mode. That makes sense as it matches the pinout on the PHY. The transformer was inverted that I misunderstood. 

Were you able to submit a return request?

Best,
J

Hi J,

We got the PHY from Arrow. But they're not supporting TI anymore.

Do you know how I should go about making a return request?

Thanks!

Regards,

Mirko

Hi Mirko,

Please use this link to reach out to Customer Support. 
You will have to make TI account and feel free to refer to this E2E thread that the team asked you to submit for return. 

Best,
J

Hi J,

we will proceed with a return request.

Thank you for your time!

Regards,

Mirko