DP83869HM: 1G Communication fail with KSZ9031RNXCC

Hi Nam,

Can you try both the DP83869 and KSZ9031 with another link partner? This can help narrow down which side may be causing the issue.

I will look through the register dump.

Thanks,

David

Hello David, 

Thank you for your attention. 

There is no issue between DP83869 and another link partner but There is also no issue between KSZ9031 and another link partner. 

This issue only occurs between DP83869 and KSZ9031. Please review it again and let me know your opinion. 

Below register value is for normal status (no fail status) 

0x00 0x1140

0x01 0x796d

0x02 0x2000

0x03 0xa0f1

0x04 0x09e1

0x05 0xc5e1

0x06 0x006d or 0x006f

0x07 0x2001

0x08 0x6801

0x09 0x0a00

0x0a 0x3c00 or 0x7c00

0x0b 0000

0x0c 0000

0x0d 0x401f

0x0e 0x10b0

0x0f 0xf000

0x10 0x5048

0x11 0xbf02

0x12 0000

0x13 0x5c44 or 0xdde4

0x14 0x2bc7

0x15 0000

0x16 0000

0x17 0x0040

0x18 0x6150

0x19 0x4444

0x1a 0x0002

0x1b 0000

0x1c 0000

0x1d 0000

0x1e 0x0012

Thank you. 

Hi Nam,

What is this no fail status register dump? Does the DP83869 and KSZ9031 only fail some of the time? Additionally, what cable type and length is being used. Can you try a different cable?

Thanks,

David

Hi David, 

David Creger said:

What is this no fail status register dump? Does the DP83869 and KSZ9031 only fail some of the time?

Yes, this issue is not always fail. 2 or 3 fail per 10 tests. No fail status register dump is the value when communication is successful with KSZ9031. 

David Creger said:

what cable type and length is being used. Can you try a different cable?

Cable type is CAT-5E , cable length is 1m ~ 5m cable. This issue also occur when the customer are using other type cable supported 1Gbps and are using variable cable length. 

I can't find root cause yet. Pleas help me to find cause or debugging point. Can you find something strange in register value? 

I think schematic and layout are not problem because there is no issue when DP83869 didn't have a problem when communicating with other partners. 

But I attached customer schematic and layout for reference. Please review it let me know your opinion.

DP83869 issue schematic and layout_230713.pptx

Thank you. 

Hi Nam,

It's possible the DP83869 or KSZ9031 design have some marginalities that only become apparent when they are connected together. 

Can you share the datasheet of the magnetics that the customer is using? Please also share the schematic in pdf format to review.

Thanks,

David

Hi David, 

Thank you for your support. 

David Creger said:

It's possible the DP83869 or KSZ9031 design have some marginalities that only become apparent when they are connected together.

If some marginalities are problem, Can you specify which specification is causing the problem?

Is there anything unusual about the register value? 

Main difference between fail and normal status are 0x08, 0x0A, 0x11 

- 0x08 bit13 : when fail , 0h = Received page is an unformatted page but 1h = Received page is a message page when communication is successful, 

- 0x0A bit12,13 : when fail ,  0 = Local receiver is not OK,  0 = Remote receiver is not OK but 1 = Local receiver is OK, 1 = Remote receiver is OK when communication is successful.

- 0x11 bit 15,14 bit9,8 : when fail, 01 = 100Mbps, 0 = MDI but 10 = 1000Mbps, 1 = MDI-X when communication is successful.

Would you please explain the role of 0x08, 0x0a, 0x11 register? And please let me know your opinion regarding difference register value. 

David Creger said:

Can you share the datasheet of the magnetics that the customer is using? Please also share the schematic in pdf format to review.

Please refer to the below schematic and datasheet. 

1. DP83869HM schematic 

DP83869HM Ethernet schematic_230718.pdf

2. power for DP83869HM

DP83869 Power_230718.pdf

3. LPJG4801DNL datasheet 

LPJG4801DNL datasheet.pdf

Thank you. 

Hi Nam,

Please give me some time to review the data. I will get back to you next week.

Thanks,

David

Hello David, 

I am sorry to push you but when can I get your feedback regarding this issue? 

Thank you. 

Hi Nam,

I see in register 0x13 that auto-Negotiation error has occurred.  

Please see the following Errata app note from Microchip: https://ww1.microchip.com/downloads/en/DeviceDoc/80000692D.pdf. It discusses a "Auto-Negotiation link-up failure". This may be the cause. Please contact Microchip to support this debug.

Thanks,

David

Hello David, 

Above issue is cleared but the root cause is not Errata of KSZ9031. 

Currently, the value of GEN_CFG2 register (14h) is 2BC7.(this value is set from Linux driver code dp83869.c ) so, SPEED_OPT_EN(9 bit)  is enable. 

When this bit is reset to 0h( Disable Speed Optimization) , Above issue is cleared. Please let me know your opinion why this bit status is affecting this issue. 

1. If SPEED_OPT_EN and SPEED_OPT_ENHANCE D_EN are set to enable at the same time, will this cause problem?

2. If SPEED_OPT_EN(9 bit)  is disable, Is there any side effect? please let me know your opinion. 

There are other issues . 

<Issue status> 

- Auto-negotiation => link up => after 1 second => link down => retry => repeat link up/down => after long time complete link up. 

this issue is similar phenomenon mentioned Errata of KSZ9031, but Despite the change in SW according to errata, there is still issue. 

I asked the customer that this issue should be done with microchip and debugging.

but the customer want to check also DP83869HM side. Because there was similar history before between DP83867 and Broadcomm PHY. 

I knew that this issue cleared changing hidden register(control timing)value of DP83867. 

Please review this issue and let me know your opinion regarding cause ,debugging points and other similar issue history. 

Thank you. 

Hi Nam,

If I am understanding correctly, disabling the speed optimization fixes the issue of the link coming up in 100Mbps. However, it creates a new issue of link status becoming unstable. This is expected as speed optimization will drop to lower speed if the link is unstable.

This may point to a signal integrity issue. Can you try with a longer cable (10m)? Occasionally we have seen a benefit vs short cable.

Can you also share the datasheet of the magnetics used? I could not find it online.  

Please recommend the customer again to contact Microchip to debug.

Thanks,

David

Hello David, 

Thank you for your strong support.but there is still a problem. Please refer to the below comment and review it again 

David Creger said:

However, it creates a new issue of link status becoming unstable

No, second issue(repeat link up down) is not related the speed optimization. the speed optimization is related only for 1st issue.( link up but no communication). 

Please let me know your opinion again regarding below 2 questions. 

1. If SPEED_OPT_EN and SPEED_OPT_ENHANCE D_EN are set to enable at the same time, will this cause problem(1st issue)?

=> two option seem to be similar,If the customer set to enable at the same time, will this cause problem? 

2. If SPEED_OPT_EN(9 bit)  is disable, Is there any side effect? please let me know your opinion. 

=> If the customer is set to enable SPEED_OPT_ENHANCE D_EN, isn't it a problem if the SPEED_OPT_EN(9 bit)  is disable? 

David Creger said:

Can you also share the datasheet of the magnetics used? I could not find it online.  

I already attached the datasheet of the magnetic at above article 2 weeks ago. please refer the below. 

8738.LPJG4801DNL datasheet.pdf

David Creger said:

Can you try with a longer cable (10m)?

We checked already variable cable. Cable type is CAT-5E , cable length is 1m ~ 5m cable, After using 10m cable, let you know the result. 

David Creger said:

Please recommend the customer again to contact Microchip to debug.

For Microchip device, the customer are working with them also. 

Thank you. 

Hello David 

I am sorry to push you but please review above question again and let me know your opinion regarding the speed optimization register value. 

< Issue 1 : link up but fail communication>

1. If SPEED_OPT_EN and SPEED_OPT_ENHANCE D_EN are set to enable at the same time, will this cause problem(1st issue)?

=> two option seem to be similar,If the customer set to enable at the same time, will this cause problem? 

2. If SPEED_OPT_EN(9 bit)  is disable, Is there any side effect? please let me know your opinion. 

=> If the customer is set to enable SPEED_OPT_ENHANCE D_EN, isn't it a problem if the SPEED_OPT_EN(9 bit)  is disable? 

<Issue 2 : repeat link up/down> 

David Creger said:

Can you try with a longer cable (10m)?

We test again using 3/5/10m cable, but the result is same. there is still problem. 

Thank you. 

Hi Nam,

If SPEED_OPT_EN and SPEED_OPT_ENHANCE D_EN are set to enable at the same time, there is no issue. The link is falling back to 100Mbps after 4 failed attempts to establish at 1Gbps.

If SPEED_OPT_EN(9 bit)  is disable, there is no side effect. 

Has there been any update from Microchip side?

Thanks,

David

Hello David, 

Thank you for your comment. 

Regarding Microchip side, they are checking again errata fix is applied correctly or not. Let you know test result soon. 

But please review Link up/down issue again, let me know your opinion regarding debugging points. 

The application with KSZ9031(HMI application) is already released to market few years ago and no return field issue , but our application with DP83869HM should be out to market soon.

Thank you.  

Hello David, 

The customer checked again errata fix is applied correctly but the test result is same. 

I will contact again by e-mail.

Thank you. 

This thread is being handled offline.

Thanks,

David

Hi,

I am facing the same issue (#2) with DP83869HM connected to a Microchip KSZ9893R switch. Link comes up and goes down again after 1s in 1000MBit/s mode. After many retries link comes up.
Was there a solution for this issue which I could try?

Thanks

   Tom

Hi Tom,

There was found to be a cable dependency. Can you try with different cable length/type? Additionally, please see the Microchip Errata document as several of these items may be having an affect.

Please make a new thread and we can assist you further with your debug.

Thanks,

David