DP83867IS: SGMII interface auto-negotiation failure with MAX24288

Hi Sukanya,

Is your RX_CTRL pin on the DP83867IS strapped to mode 3? Please see the datasheet about the required strapping mode, and possible SW workaround.

The majority of SGMII auto-negotiation issues are related to the RX_CTRL being strapped in an invalid mode.

Best Regards,

Hi Rob Rodrigues,

In the current hardware schematic we don't have strap option for RX_CTRL. But we found in datasheet that,
If the RX_CTRL pin cannot be strapped to
mode 3 or mode 4, bit[7] of Configuration Register 4 (address 0x0031) must be cleared to 0.
We have tried this option but no success. Could you please elaborate? or suggest any other possible options.

Regards,
Sukanya K

Hi Sukanya,

1. Kindly refer to section 8.4.1 to check status of SGMII is enabled on not.
2. You may want to check the SGMII Auto Negotiation status as well at both MAX24xx device and DP83867 (SGMII Auto-Negotiation Status (SGMII_ANEG_STS)), address 0x0037) to understand further.

Regards,
Geet

Hi Geet,

Thank you for the response.

I have done SGMII Enable by writing 

0x10 => 0x5848

and in extended address registers

0x31 => 0x1050.                               for clearing 7th bit as mentioned in datasheet. SGMII Auto-Negotiation Timer Duration = 800us.

0x00D3 => 0                                      for clearing 14th bit to select SGMII 4 wire mode.

one more observation here. 

If Phy is connected to LAN through ethernet cable then autonegotiation is passing in address (0x0001). but SGMII autonegotiation is not completing in both MAX and DP ICs.

But if LAN cable is removed then autonegotiation is passing in SGMII address (0x0037) and MAX IC. and autonegotiation for speed is not completing in DP83867.

Please suggest if anything is missing.

Regards,

Sukanya.K

Hi Sukanya,

When bit[7] of Configuration Register 4 (address 0x0031) is cleared to 0, auto-negotiation of the link should be restarted.

Please follow the clearing of bit[7] with restart of auto-negotiation in register 0x0. Write register 0x0 to 0x1200 to restart auto-negotiation.

Thanks,

Hi Rob Rodrigues,

I have followed the sequence that is after clearing bit[7] of Configuration Register 4(address 0x0031)  to 0. 

We tried autonegotiation enable and restart. by writing 0x1200 in one case and 0x1340 in another case

both lead to no success.

One more option we have tried is strapping RX_CTRL to Mode3

that is Rhi = 6.04kohm and Rlo = 2.49kohm.

and tried with writing 0x10D0 to reg 0x0031 (Config-Reg4).

lead to no success.

The Vmax (V) as mentioned in datasheet is 0.256*VDDIO i.e., in our case it is 0.256* 1.8 = 0.4608V

but observed voltage level here is 0.522V.

Regards,

Sukanya.K

Ensure the resitance are 1% accuracy.

can you check status of SGMII is enabled on not thru status register ?

 You may want to check the SGMII Auto Negotiation status as well at both MAX24xx device and DP83867 (SGMII Auto-Negotiation Status (SGMII_ANEG_STS)), address 0x0037) to understand further.

Regards,
Geet

Hi Geet,

The resistors used are with 1% accurate. 

the sgmii is enabled in 0x0010 register (bit 11) and read back the same.

sgmii autonegotiation is enabled in  0x0014 register (bit 7) and read back the same.

now shall I continue with the strap or I should remove it?

and please suggest any hardware/software changes if required.

Regards,

Sukanya.K

Did you check Auto Negotiation Status register at DP83867 and MAX. What they say ?

Regards,
Geet

Hi Geet,

The sgmii autonegotiation status register of DP83867(0x0037) readsSGMII page received in (bit 1) but SGMII autonegotiation won't complete.

but if I remove the LAN cable connecting PHY to LAN then SGMII autonegotiation complete (bit 0) and page received (bit 1) both will set.

similarly at max24288 autonegotiation complete status is read at BMSR register (0x0001) it reads remote fault indicating receive loss of lock.

but here also when LAN cable connecting PHY to LAN is removed then Autonegotiation completes.

Regards,

Sukanya.K

Hi,

This issue is still pending
Please Respond.

Regards,
Sukanya.K

Hi Sukanya,

Adjust the SGMII auto-negotiation timer to 1.6ms using register 0x31. bit[6:5] = 0b00

From that point, you should consider attempting to remove the CML to LVDS device you have between the MAX24288 and the DP83867 as a debug step.

Ensure that you are using the extended register access method for these registers, if you do not, then you may be inadvertently changing the values of incorrect registers.

Best Regards,

Hi Rob Rodrigues,

We have used extended register access as specified in datasheet using REGCR(0x000Dh) and ADDAR (0x000Eh)registers.

We have tried all the possible autonegotiation speeds but no success.

Is it Ok to remove the conversion from CML to LVDS between MAX and DP?

Even we are doubting the interface between MAX and DP since the MAX is detecting remote fault and it is also indicating CDR loss of signal and loss of lock. I have shared the interface diagram here.

all the capacitors are 0.1uF and resistors are 100ohm.

Please do have a look at it. and suggest what can be the reasons for the Receive CDR Loss-of-Signal.

Regards,

Sukanya.K

Hi Sukanya,

You do not need the CML to LVDS converter.  We implement the SGMII link as LVCMOS and ensure the AC parameters match the LVDS spec.  Then we suggest AC coupling the LVDS to our LVCMOS.  It looks like the MAX is doing the same scheme.

I'd recommend changing your circuit like the following.  Please note the DP83867 has an internal SGMII termination, so the 100ohm diff term is not necessary.

Best Regards,

Hi Rob Rodrigues,

Thanks for the suggestion.

We have tried the circuit changes as specified, with different autonegotiation timer durations at register 0x0031.

Also we have tried the force speed at PC side to 100Mbps half duplex as suggested in the link,e2e.ti.com/.../490569

but no success.

Here I have two issues,

1. Why remote fault is occuring at MAX side, saying CDR loss of signal and loss of lock?

2. Why Autonegotiation in DP at register 0x0037(SGMII_ANEG_STS) and MAX are completing when LAN cable is removed?

Regards,

Sukanya.K

Hi Rob,

I have dumped the register values from DP for your reference. (This is after AN completed at BMSR(0x0001) and before SGMII AN at SGMII_ANEG_STS(0x0037))

0 => 0x1000
1 => 0x796D
4=> 0x0DE1
5 => 0xCDE1
6 => 0x006F
7 => 0x2001
8 => 0x4006
9 => 0x0300
0xA => 0x3800
0xF => 0x3000
0x10 => 0x5848
0x11 => 0xAC02
0x12 => 0x0000
0x13 => 0x1C40
0x14 => 0x29C7
0x15 => 0x0000
0x16 => 0x0000
0x17 => 0x0040
0x18 => 0x6150
0x19 => 0x4444
0x1A => 0x0002
0x1E => 0x0002
0x1F => 0x0000
0x6E => 0x0009
0x135 => 0x0000
0x31 => tried various things, 0x0090, 0x00B0, 0x00D0, 0x00F0
Please suggest if something is wrong and what is expected.

Regards,
Sukanya.K

Hi Rob,

we are seeing the AN_RX register in MAX24288, it is receiving the changes in speed and duplex forced in the PC. This can happen only through SGMII Auto negotiation indicating the receive path to be working proper, then what is the significance of CDR loss of signal and does it confirm the hardware is OK?

When we force the link status in MAX24288 AN_ADV to 0 then auto negotiation is passing in MAX24288 and DP83867 for SGMII. But the link is not working - (PING is not happening). Can you help us understand auto negotiation process better?

Regards,

Sukanya.K

Hi Sukanya,

I think this will require some deeper debug. I have passed you my contact information. Please reach out to me to continue this discussion.

Best Regards,

SCH-ETH-DP8386_MAX24288.pdfHi Rob,

The issue was in RGMII link with MAX24288. In MAX24288 RX and TX clock delay programming was not possible and this was supposed to be handled through hardware. After adding long cables (~75cm) in TX and RX clock paths the link is now working for 10Mbps. but still we are facing issue in 100Mbps and 1Gbps we have updated the schematic for next version. we need your help in reviewing it.

Thanks in advance.

Regards,

Sukanya.K