DP83867CR: Rx errors (RXDV_ER / reg 0x0015) only with particular Marvell PHY link partner

And of course the switch with the Marvell PHY passed our test when not connected to a DP83867CR.

Hi Francois,

I would like to ask couple questions to understand your setup and provide some debug suggestion:

Correct me if my miss understanding something on the setup:

• FPGA <--> Marvell PHY <--> DP83867 <--> FPGA
  • FPGA is the one that generate and received the packet
  • Marvell PHY<-->  DP83867PHY at 100mbps auto negotiation mode
  • What MAC interface are you using between DP83867 and FPGA?
• What is the length of cable and what type of cable are you using?
• Are you able to see a link up in your system?
• If possible, could you provide the register 0x0000 to 0x001F and 0x006E on DP83867?
• If possible, could you probe RX_CLK, TX_CLK, and CLKOUT?

--

Thank you,

Hillman Lin

Hi Hillman,

Thank you for you help.

The setup is a bit more complicated:
FPGA + DP83867 <-> Switch with Marvell PHY <-> FPGA + DP83867
Packets are generated and received by FPGAs.
All at 1000Mbps, autoneg or fixed 1000Mbps in the switch
The MAC interface is RGMII

Our application require short cables considering the integration, but for now I use 5m Cat6 cables.

The link is established without any problem.
Rx errors start to appear only with the Marvell based switch and when the rate increases.
If I replace the Marvell based switch by a cable or even by another switch, we don't have any Rx error with our test stream (100Mbps) + the stress stream (790Mbps)

Here is a register dump I made earlier today:

I didn't save Reg 0x006E, I can do that after.

So this shows the negotiation went well.
At this time, the Marvell switch was fixed at 1000Mbps.
The other switch has reversed polarity on D.
I don't see anything that is a concern, except reg 0x0015.

RX_CLK, TX_CLK, and CLKOUT was very ok last time I checked. But the RGMII interface is full validated now since we don't have any error on high bandwidth with anything but the Marvell switch.

In the mean time, I gave a closer look at this document:
https://www.ti.com/lit/ahttps://www.ti.com/lit/an/snla246b/snla246b.pdf?ts=1698646763397n/snla246b/snla246b.pdf
Section 3.8

At first, I replaced the short cables I was using before by 5m Cat6 ones.
It didn't change anything.

So I gave a try to the register settings described in the app note:

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

More tests have to be done but it seems to solve the Rx errors issue, but still with 5m Cat6 cables.

This is too much magic to accept it as a solution without a better understanding of what is happening.
Could you please (or someone closer to this specific short cable issue) give an explanation on what those settings are doing?
And why a solution for short cables (smaller than 1m) can fix an issue with 5m cables ?

Hi Francois,

Thank you for your response.

• If my understanding is correct, using the CAT 6 cable less than 5m still see an RX_Error after programming the short cable script?
• If possible, could you send me the schematic around the MDI traces or cable send to see if there is an variation in between?

Meanwhile, I will look at the register description and provide you feedback after review with the team.

--

Regards,

Hillman Lin

Hi Hillman,

I just started a test with a very small cable (0.25m) and with the script. It does work without Rx error for now. We need a longer test but there is a big improvement already.
So the result is the same than the 5m cable with the script.

What I can't understand now is:
- Why a 5m cable doesn't fix the issue with this particular partner PHY ?
- What is the meaning of those magic values in the script ?

Regards,

Francois

Hillman Lin said:

Meanwhile, I will look at the register description and provide you feedback after review with the team.

Thank you very much for that. I'm looking forward your feedback.

Hi Francois,

If possible, could you also share the register 0x006E information and schematic around RJ45 connector portion to double check on the connection.

I take a look on the register 0x0005, I see that for the Marvell PHY < -- > 867PHY condition. we are seeing link partner (867 PHY) no supporting 100mbps. This is an unusual behavior because you are able to see a link up but 867PHY is not supporting 100mbps speed so it shouldn't link up at 100mbps.

Based on the register 0x000A, I am seeing that the PHY is still link up in 1000mbps. May I ask how did you link up at 100mbps with 867PHY in your case? What would be the register dump when you are linking up at 100mbps and seeing the RX_ER?

Correct me if I misunderstand your concern,

• Link up between Marvell and 867PHY in 1000mbps you are not seeing RX_ER between the communication
• Link up between Marvell and 867PHY in 100mbps you are seeing RX_ER behavior

Is my conclusion correct?

--

Thank you,

Hillman Lin

Hi Hillman,

Hillman Lin said:

If possible, could you also share the register 0x006E information

Value is 0x0005 as expected (id is fixed to 5).

The schematic is drawn such a way that I can't show publicly that part because it would show other parts that we don't want to share.
We use Bourns SM51625EL transformers with 0.1uF from PHY's side center tap to ground, and the following center tap schematic at the connector side:

Hillman Lin said:

I take a look on the register 0x0005, I see that for the Marvell PHY < -- > 867PHY condition. we are seeing link partner (867 PHY) no supporting 100mbps. This is an unusual behavior because you are able to see a link up but 867PHY is not supporting 100mbps speed so it shouldn't link up at 100mbps.

As I said yesterday, we fixed the Marvell based switch to 1000M for application purpose. We want to be sure it can negotiate only at this speed.

Hillman Lin said:

• Link up between Marvell and 867PHY in 1000mbps you are not seeing RX_ER between the communication
• Link up between Marvell and 867PHY in 100mbps you are seeing RX_ER behavior

Still not.
We don't use 100M Ethernet at all. 100Mbps is the bandwidth of our test stream. And it is sent together with a 790Mbps bandwidth perturbation stream.
At the end 890Mbps can't fit in a 100M eth anyway.

Our problem is: we see RX_ER when we have a Marvell PHY as a link partner.

Regards,
Francois

Our problem is fixed when we apply the script documented in the www.ti.com/lit/an/snla246b/snla246b.pdf doc section 3.8.

What we need to know is:

1. What is the magic behind those undocumented registers?
2. This app note is for cables shorter than 1m. Is it safe to use it on longer cables?

Regards,
Francois

Hi Francois,

Glad that this script solve the problem.

There is no disadvantage with the script you wrote in the debug Appnote. This scripts should also work with the cable longer than 1m. 

--

Regards,

Hillman Lin

Hi Hillman,

Ok, but we can not take a magic solution for another problem as a solution for our problem without further information.

Moreover, we did have an RX_ER last night. It improves a lot, but it doesn't completely fix our problem.

Regards,
Francois

I confirm that the link partner PHY is a Marvell 88E1680-LKJ2.
We only have the RX_ER problem on the DP83867CR with this PHY as a link partner.

Regards,
Francois

Hi Francois,

Could we also discuss this issue in the email? We still want to confirm on the schematic everything is good on the MDI lines. I did a friend request on E2E Forum. I will send you the email privately after you accept the friend request.

Regarding to the short cable script, it is an errata on our DP83867PHY and we recommend customer to always write this script when they are using short cable application.

--

Regards,

Hillman Lin

Hi Hillman,

I rearranged our schematic to show only the PHY and MDI part. Here it is:

PHY_MDI.pdf

Regards,
Frnacois