DP83867IR: auto-negotiation not complete on a special network switch

Hi Min,

Thank you for submitting this query, I will gladly assist in debugging this.

First I want to clarify a few items. We are using the DP83867 in 100Mbps, and it is working perfectly with multiple link partners (PC, switch, etc.) via a two pair cable. However we are having an issue specifically with the customer's custom switch. You mention that the customer's switch operates with Auto-negotiation OFF and 100Base-TX Full Duplex.

In the register log, I see that auto-negotiation is still enabled in our PHY. Can we try setting Reg 0x0 = 0x2100? This will force the PHY into 100Base-TX Full duplex.

Below is an FAQ that provides more information about Auto-negotiation and Forced Speed. Could we try forcing speed (100Base-TX, auto-negotiation OFF) on a PC (a known good link-partner) and see if the 867 can connect as well?

[FAQ] Forced Speed Vs Auto-negotiation

Regards,

Alvaro

Hi Alvaro, thanks for your reply

First, what you have clarified is right.

I have set the phy to be 100BaseTx full duplex autonegotiation off by ethtool ethtool –s eth0 speed 100 duplex full  autoneg off, but it never works. 

One thing that I have to mention is that  if customer configured the network switch to 10M baseT, then we could connect to the network switch.

by the way, can we use Time Domain Reflectometry (TDR) to detect the possible problems? I found it in dp83867 datasheet. 

Hi Min,

In the last register log, was this when connected to the customer's switch? When auto-negotiation is disabled on the DP83867, are we able to link up with the other known-good link partner's? 

Regards,

Alvaro

Hi Alvaro,

Yes, it is when connected to the customer's switch; And we can link up with other known-good link partners like PC or our device.

After communicating with customers, they configured the network switch to autonegotiation on too, but the problem still exists.

The strange thing is we found there is one of our devices that could connect to this network switch at normal temperature, but the link would down when the chip temperature goes higher and link would up when the chip temperature goes down. The circuit design is the same as that of our other devices.

the register below is tested on this cool-working-good device when our device is configured autonego on and the partner network switch is also configured autonego on

Register 0: 0x1140 Register 1: 0x796d Register 2: 0x2000 Register 3: 0xa231 Register 4: 0x05e1 Register 5: 0x0081 Register 6: 0x0064 Register 7: 0x2001 Register 8: 0000 Register 9: 0x0200 Register 10: 0000 Register 11: 0000 Register 12: 0000 Register 13: 0x401f Register 14: 0x0c4c Register 15: 0x3000 Register 16: 0x5048 Register 17: 0x4c02 Register 18: 0000 Register 19: 0000 Register 20: 0x2bc7 Register 21: 0000 Register 22: 0000 Register 23: 0x0040 Register 24: 0x6150 Register 25: 0x4444 Register 26: 0x0002 Register 27: 0000 Register 28: 0000 Register 29: 0000 Register 30: 0x0202 Register 31: 0000

when the temperature is high, the register becomes:

Register 0: 0x1140 Register 1: 0x7949 Register 2: 0x2000 Register 3: 0xa231 Register 4: 0x05e1 Register 5: 0000 Register 6: 0x0074 Register 7: 0x2001 Register 8: 0000 Register 9: 0x0280 Register 10: 0000 Register 11: 0000 Register 12: 0000 Register 13: 0x401f Register 14: 0x0c4c Register 15: 0x3000 Register 16: 0x5048 Register 17: 0x0302 Register 18: 0000 Register 19: 0x8c46 Register 20: 0x2bc7 Register 21: 0000 Register 22: 0000 Register 23: 0x0040 Register 24: 0x6150 Register 25: 0x4444 Register 26: 0x0002 Register 27: 0000 Register 28: 0000 Register 29: 0000 Register 30: 0x0206 Register 31: 0000

Do you have any suggestions about what we could do the next step? 

Hi Min,

min said:

Yes, it is when connected to the customer's switch; And we can link up with other known-good link partners like PC or our device.

So when the DP83867 is forced to 100Mbps, it is still unable to link up with the customer's switch, but it is still able to link up with the other known-good link partners.

You mention that one of your devices (could we give this device a name?) is able to connect to the custom switch, but will drop link when the temperature rises. In this scenario, which board is the one that is rising in temperature, your device or the custom switch? What ethernet PHY is on your device?

Is the register log you provided from our DP83867 PHY?

Regards,

Alvaro

yes, we try different ethtool settings(mdi/mdix, full/half duplex, autonegotiation on/off), they all fail with custom switch. But it is able to link up with other known-good link partners like PC.

The device that could connect to custom switch is our device and the same as our other devices, in this way, this device also use dp83867.  We cannot find any hardware difference between this cool-working-good-device and other devices. We try several boards, only one I mentioned above could connect. The custom switch also works well by connecting successfully with host PC and other custom network switches.

yes, the register log is provided from our dp83867 phy.

Hi Min, 

Understood, please allow me a day to consult with my team.

Regards,

Alvaro

Hi Min,

Could we read the registers (0x0-0x1F, 0x6E & 0x6F) again for:

1. non-working board connected to custom switch
2. cool-working board connected to custom switch
   1. With good link

This time keep auto-negotiation on for all boards, including the custom switch. 

min said:

Register 0: 0x1140 Register 1: 0x796d Register 2: 0x2000 Register 3: 0xa231 Register 4: 0x05e1 Register 5: 0x0081 Register 6: 0x0064 Register 7: 0x2001 Register 8: 0000 Register 9: 0x0200 Register 10: 0000 Register 11: 0000 Register 12: 0000 Register 13: 0x401f Register 14: 0x0c4c Register 15: 0x3000 Register 16: 0x5048 Register 17: 0x4c02 Register 18: 0000 Register 19: 0000 Register 20: 0x2bc7 Register 21: 0000 Register 22: 0000 Register 23: 0x0040 Register 24: 0x6150 Register 25: 0x4444 Register 26: 0x0002 Register 27: 0000 Register 28: 0000 Register 29: 0000 Register 30: 0x0202 Register 31: 0000

when the temperature is high, the register becomes:

Register 0: 0x1140 Register 1: 0x7949 Register 2: 0x2000 Register 3: 0xa231 Register 4: 0x05e1 Register 5: 0000 Register 6: 0x0074 Register 7: 0x2001 Register 8: 0000 Register 9: 0x0280 Register 10: 0000 Register 11: 0000 Register 12: 0000 Register 13: 0x401f Register 14: 0x0c4c Register 15: 0x3000 Register 16: 0x5048 Register 17: 0x0302 Register 18: 0000 Register 19: 0x8c46 Register 20: 0x2bc7 Register 21: 0000 Register 22: 0000 Register 23: 0x0040 Register 24: 0x6150 Register 25: 0x4444 Register 26: 0x0002 Register 27: 0000 Register 28: 0000 Register 29: 0000 Register 30: 0x0206 Register 31: 0000

In the register log you provided here, there are a few odd bits that are flipping but the one that grabs my immediate attention is Reg 0x16. This register enables PRBS data generator and the various loopback modes. Why is this enabled? Below is an excel file where I highlighted the different registers with a few remarks. Please let me know when you can get the new register dump.

DP83867IR auto-negotiation not complete on a special network switch.xlsx

Regards,

Alvaro

Hi Alvaro,

sorry for the late response. It is not easy to communicate and manage the test with our customer. I got the new register dump now but with the custom switch set 100M full duplex, negotiation off. We also test your sk-am62 develop kit (SK-AM62 Evaluation board | TI.com) which use the same phy as us, and it also fails to connect with the switch.

I answer your questions and put the resister dump in the excel file. The registers are dumped when cable connected with the switch

1563.DP83867IR auto-negotiation not complete on a special network switch.xlsx

Hi Min!

I almost forgot about this query. Please allow me until the end of week to review.

Regards,

Alvaro

Hi Alvaro,

please help review it soon and see if any other tests we could do with the switch, because the switch and the lab is available this week. and would wait after this week.

Thanks very much

Min

Hi Min,

Understood, I will try to have a response ready tomorrow.

Regards,

Alvaro

Hi Alvaro, 

Do you have some ideas already?

Hi Alvaro,

Update :we tried loopback mode to see if the internal path is okay with the cable connected with the switch, and the 100M analog loopback works well.

May this will help find root clause.

Hi Min,

Thank you for all of the register data. I am not sure what the issue is here and need to consult further with my team. 

Regarding your loopback test, I'm glad that this works but it does not help debug the current issue. Analog loopback takes data received from the processor and send it back to the processor. This confirms that the MAC Interface connection is functioning. 

The current problem we have no is in the MDI interface, where we are unable to link up to the custom switch.

Processor <-MAC Interface-> DP83867 <-MDI Interface-> RJ-45 Connector <-Ethernet Cable-> Link Partner

Questions:

1. Does the customer have different cables that they can test with? Would like to see if a different length cable would affect this issue (100m cable is the longest supported).

2. Between the good-cool temp board and non-working board, are we sure that there is nothing different about the schematic & layout? Do they use the same transformer?

Regards,

Alvaro

Hi  Alvaro, 

Thanks for your reply.

1,yes, we have tried different cables, from 2-meter to 10-meter's long,  but they all behave the same. So I think the cable may not be an issue.

2,they use the same transformer and the schemetic is the same, For the layout, maybe I have to discuss with our colleagues to see if there is any difference

3, when could I get further feedback from your team?

Hi Min,

Please allow me another day to respond.

Regards,

Alvaro

Hi Min,

Sincerest apologies for my delay. This seems to be a strange corner case where the DP83867 cannot link up with the customer switch's PHY. We have not seen many interoperability issues with the DP83867.

The SK-AM62 Evaluation board | TI.com and your current board cannot connect, but past boards that also have the DP83867 are able to link up to the switch. Please review the layout for your boards, particularly the MDI traces, magnetics, and RJ-45 connection.

As a complete shot in the dark, attached below is a script meant to improve performance when using short cables. I am unsure if this will help your case.

begin
// Hard Reset
001F 8000
// Threshold for consecutive amount of Idle symbols for Viterbi Idle detector to assert Idle Mode
set to 5
0053 2054
// CAGC DC Compensation Disable
00EF 3840
// Master Training Timers - increasing time in different training states
0102 7477
// Master Training Timers - increasing time in different training states
0103 7777
// Master Training Timers - increasing time in different training states
0104 4577
// Timing Loop Bandwidth
010C 7777
// Timing Loop Bandwidth
01C2 7FDE
// Slave Timers - increasing time in different training states
0115 5555
// Slave Timers - increasing time in different training states
0118 0771
// Timing Loop Bandwidth
011D 6DB2
// Timing Loop Bandwidth
011E 3FFB
// Timing Loop Bandwidth
01C3 FFC6
// Timing Loop Bandwidth
01C4 0FC2
// Timing Loop Bandwidth
01C5 0FF0
// FFE Fix
012C 0E81
// Soft Reset
001F 4000
end

Regards,

Alvaro

Hi Alvaro, 

I have tried the script above, and it does not help.

In addition to the comparison method between the working and non-working board, any other ways to investigate this problem directly? One more update:For another type of 100M network switch from the same vendor, all our dp38367 boards fail to link up. 

Hi Min,

Would it be possible to share your schematic?

Regards,

Alvaro

Hi Avrao,

Let me share eth related schematic

Thanks,

Min

Hi Min,

Please find the schematic review attached. I didn't see anything obviously wrong with the schematic that would contribute to this issue. Regarding the magnetics, would you be able to provide the data sheet for the XMH-9771-8812-S0LHTL-P-LFG Magjack component ?

DP83867_Schematic_Checklist_PHYTEC.xlsx

Regards,

Alvaro

Hi Alvaro,

Thanks for your effort a lot!I sent you the datasheet in private message. But since the ethernet on your am62 board also does not work, this magjack may not matter. 

Min

Hi Min,

Thank you for sending the Magjack data sheet, the specs look good and is likely not the cause. You have the AM62EVM which also has our DP83867 and it also shows the same problem. Just to re-confirm, both the customer board and the AM62 only have this issue with the custom switch? They are able to link up with any other link-partner? Does this problem happen with both a 2-pair and 4-pair cable? 

Regards,

Alvaro

Hi Alvaro,

yes, they only have issue with the custom switch and are able to link up with other patner like the PC hosts. The custom switch has his own special cable which is 2-pair wtisted wire with the kind of interface like the picture below  as one end. These are the interfaces on the custom switch.

Min

Hi Min,

Thanks for the picture, please allow me to review again with my team.

Regards,

Alvaro

Hi Min,

I want to double check the short cable script. Most of the registers in the script are extended registers, please see how to properly read/write them here:

[FAQ] Extended Register Space access for Ethernet PHYs

Also, previously you mentioned using a 2-10m cable, what kind of cable is it (shielded, unshielded, CAT 5, 6)?

[EDIT]:

When you were testing at low temperature (when link was successful), was the entire board cold or only the PHY? Were both the customer board and the custom switch at a cold temperature?

Regards,

Alvaro

Hi Alvaro,

we only use the cables showed with the picture before to connect with the network switch, the cables are provided by our customer, the have different length(2-10m) of cables of this type. The end near the network switch is shielded but the end near our device is unshielded. Our customer has a coverter cable to connect the shielded and unshielded side.

The phy and soc are very close to each other, so they both get cold and hot, we can not identify. But all the temperature falls in the normal working temperature range of our system on module.  And update: we test another network switch from the same vendor, all the boards including the cool working board fail to connect.

Min

Hi Min,

Could we try forcing the MDI/X resolution? In the beginning I believe you already tried this via the terminal command, but to be sure can we enable it via the PHYs register?

Reg 0x10:

• = 5048
  • Auto-MDIX enabled
  • This has already been attempted, no need to recreate
• = 5008
  • Forced MDI
• = 5028
  • Forced MDI-X

Could you also provide a register dump 0x0-0x1F for each of these cases?

Regards,

Alvaro

Hi Alvaro,

yes, both our client and me absolutely have tried set force mdix and mdi, but the all did not work. And it truely took effect because there would not be continuous mid/mdix interrupt on interrupt register. And we have measured the waveform that our device would send negotiation signal on one pair twisted-wire after mdi/mdix set.

And most important, currently,  due to the project's timeline, our client refused to do test again and tried other ways to connect to the speial network switch. I am afraid this issue may never be fixed. What do you think about this problem?

Min

Hi Min,

Alvaro is out of office, please expect a delay in feedback until next week.

Thank you,

Evan

Hi Min,

Thank you for your patience. I understand that this has taken a while and the project timeline is closing in.

From the register logs we can see Auto-neg is not completing and in Register 0x6[0] we see that the link partner does not support auto-negotiation. Reg 0x6[0] is expected to be high on good link, which is not the case even on your cool working board. 

Speed optimization is also currently enabled, could you try disabling this (Register 0x14 = 0x2887 will disable speed optimization).

Regards,

Alvaro

Hi Alvaro,

the link partner does not support auto negotiation by default. It requires our customer to set the network switch's configuration. So we tested with link partner auto-nego off, 100 Mbps, I think I have noted that before.

But No more new test is allowed now.

Thanks 

Min

Hi Min,

Understood, will close this thread.

Regards,

Alvaro