DP83867IS: Autonegotiation not working with 100MBit-Cable

Hi Walter,

Is this cable the only cable that shows issues with linking up, or do all 100Mbit cables have the same effect?

If you use two boards with DP83867 can a link be established? I want to be sure the link partner is not preventing link up.

If you set 0x0014[9] to enable speed optimization, do you get a link up? This feature should allow the PHY to shift down to 100M speed when it cannot bring the link up at 1G.

Best,

Shane

Dear Shane,

I am from the customer who reported the issue to Mr. Ahrend.

We tried multiple cables and also checked the wires and pins of the cables. 

"If you use two boards with DP83867 can a link be established?"
=> We can try this, but:

We also used different link partners, e. g. a LAN port of a laptop or USB-to-LAN adapter.
The problem came up when a device was in a test laborytory for a fieldbus conformance certification. The test engineer there also tried different link partners and used a cable (100 MBit/s, 2 Pairs) that is certified for the fieldbus.

So we are quite sure that the effect does not depend on the cable or the link partner.

We already tried to activate the speed optimization because our engineer found this forum threat: 
Linux/DP83867IR: DP83867IR phy Auto-Negotiation problem - Interface forum - Interface - TI E2E support forums
But the speed optimization did not solve our problem.

After pluging in the RH45 jack it takes approx. 20 seconds until the link LED turns on and starts to blink. But no there is no link.
In constrast to this: If we connect to another 100 Mbit/s switch (which does not support 1 Gbit/s) the link is established very fast (<< 3s)

Is it mabe possible that other settings of the PHY interfere with the linking or the speed optimization?

Best regards,
Dirk

Hi Dirk,

Thanks for the context. It would help to see the results of these experiments:

1. Use two boards with DP83867 and the 2 Pair cable between them. Do they link up?

2. Keep auto negotiation enabled on DP83867, but disable gigabit advertisement as a supported mode. This is done in register 0x0009[9:8]

3. Can you provide a register dump of the PHY when connected via the 2 pair cable in the failing condition? I'm primarily interested in registers 0x0 through 0x1F.

In the meantime let me see if I can order a 2-pair cable to test on our EVMs here. Do you have a part number for the cable you're testing with? This would help keep our setups more 1:1

SW Dev said:

Is it mabe possible that other settings of the PHY interfere with the linking or the speed optimization?

Its possible that some configuration on the PHY is interfering with the link, however I'd want to test with two DP83867's first (ideally on EVMs). The EVM serves as a baseline that removes possible hardware or software interference from the test. The fact that there are no issues when forcing 100M is a good sign that your PCB layout is ok.

Best,

Shane

Hello Shane,

it took a while to set up the PYH dump and test some scenarios. Now we can provide the following information:

Regarding the cable. I am sorry that I can not provide a specific order number. We tested with two cables:
- Two combined adapter cables with M12 X-coded via M12 D-coded via M12 D-coded back to M12 X-coded.
- A manually modfied normal 4-pair patch cable. (Pair 2 and 3 still connected. Pair 1 and 4 cut though)

Both cables work fine in other contexts.

1.)
We took two of our devices with the DP83867 and connected them via a 2-pair cable mentioned above. Unfortunately we do no longer have the EVMs. Both devices are set to auto negotiation. It takes approx. 20 seconds until the link LEDs turn on at both devices and start to blink. But there is no link. This is the PHY dump after the link LEDs start to blink:

Offset          Values
------          ------

0x0000:         0a de 00 01 00 01 01 29 4f 04 00 00 ff 05 00 00

0x0010:         81 00 01 00 00 00 00 02 00 00 00 00 00 00 00 91

0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 33 00 77 7e

0x0030:         77 0e 00 00 00 00 00 80 03 00 00 00 00 00 00 00

The command to create the PHY dump was always: ethtool -d eth0p9

We also took a PHY dump before both devices were connected via the cable:

Offset          Values
------          ------

0x0000:         0a 10 00 01 00 01 01 29 4c 04 00 00 ff 05 00 00

0x0010:         81 00 01 00 00 00 00 02 00 00 00 00 00 00 00 91

0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 33 00 77 7e

0x0030:         77 0e 00 00 00 00 00 80 03 00 00 00 00 00 00 00

2.)
We turned off gigabit advertisement (turning off bit 8 and 9 of register 0x0009) for one of the devices. (For the other device gigabit advertisement was still turned on.) Again we conntected the devices via the 2-pair cable, waited for the link LEDs to blink and took the following PHY dump from the device with deactivated gigabit advertisement: 

Offset          Values
------          ------

0x0000:         0a 1d 00 01 00 01 01 29 4c 04 00 00 ff 05 00 00

0x0010:         81 00 01 00 00 00 00 02 00 00 00 00 00 00 00 91

0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 33 00 77 7e

0x0030:         77 0e 00 00 00 00 00 80 03 00 00 00 00 00 4a 00

But we still get no link.

Best regards,
Dirk

Hi Dirk,

I took a EIA 568B 4-pair cable and cut out two of the pairs to make a 2-pair cable. When testing this in our lab I can see DP83867 links up with 100M/10M PHYs, however it refuses to link up with other gigabit PHYs unless speed optimization is enabled. With speed optimization enabled I can get a link between gigabit PHYs after some time (around 10 seconds)

When I disable Gigabit speed advertisement through register 0x0009, the DP83867 can link up with other gigabit PHYs regardless of speed optimization. I used the following PHYs when testing:

DP83867 <--> DP83867

DP83867 <--> DP83869

I'm not sure on the format of your register dumps, as there seems to be discrepancies. For example in the first register dump:

SW Dev said:

0x0000:         0a 1d

This suggests register 0x0000 holds the value 0A1D which, if true, means auto-negotiation is disabled and the PHY is in power-down mode (0x0[12:11]). Is register access on the PHY working ok? Let me know if I am mis interpreting the register dump.

Best,

Shane 

Hello Shane,

Thank you very much for testing on your side. Maybe some other configuration in our PHY is the reason. We checked again the way we created the register dumps. Our suspicion is that the used command "ethtool -d eth0p9" did noth catch the registers of the DP83867 itself but somethin else. So we used another ways for access to the register and I hope that the results below fit better to the expected register content. So now again with the corrected register dumps:

1.)

We took two of our devices with the DP83867 and connected them via a 2-pair cable mentioned above. Both devices are set to auto negotiation. It takes approx. 20 seconds until the link LEDs turn on at both devices and start to blink. But there is no link.

This is the PHY dump after the link LEDs start to blink:

[TEST] ============================================

[TEST] BASELINE: Register dump WITH Gigabit enabled

[TEST] ============================================

[PHY STATUS] Port 9 Status:

  Autoneg enabled: YES

  Link status: UP

  Autoneg complete: YES

  Local advertised 10/100: 0x1e0

  Local advertised Gigabit: YES (0x200)

  Partner advertised 10/100: 0x1e0

  Partner advertised Gigabit: YES (0x800)

[PHY DUMP] ========================================

[PHY DUMP] Register dump for Port 9 (DP83867)

[PHY DUMP] ========================================

[PHY DUMP] Port 9 Reg 0x00: 0x1140

[PHY DUMP] Port 9 Reg 0x01: 0x796d

[PHY DUMP] Port 9 Reg 0x02: 0x2000

[PHY DUMP] Port 9 Reg 0x03: 0xa231

[PHY DUMP] Port 9 Reg 0x04: 0x05e1

[PHY DUMP] Port 9 Reg 0x05: 0x45e1

[PHY DUMP] Port 9 Reg 0x06: 0x0065

[PHY DUMP] Port 9 Reg 0x07: 0x2001

[PHY DUMP] Port 9 Reg 0x08: 0x4b6f

[PHY DUMP] Port 9 Reg 0x09: 0x0200

[PHY DUMP] Port 9 Reg 0x0a: 0x0800

[PHY DUMP] Port 9 Reg 0x0b: 0x0000

[PHY DUMP] Port 9 Reg 0x0c: 0x0000

[PHY DUMP] Port 9 Reg 0x0d: 0x401f

[PHY DUMP] Port 9 Reg 0x0e: 0x0000

[PHY DUMP] Port 9 Reg 0x0f: 0x3000

[PHY DUMP] Port 9 Reg 0x10: 0x5848

[PHY DUMP] Port 9 Reg 0x11: 0x6f02

[PHY DUMP] Port 9 Reg 0x12: 0x0000

[PHY DUMP] Port 9 Reg 0x13: 0x0000

[PHY DUMP] Port 9 Reg 0x14: 0x2bc7

[PHY DUMP] Port 9 Reg 0x15: READ FAILED

[PHY DUMP] Port 9 Reg 0x16: 0x0000

[PHY DUMP] Port 9 Reg 0x17: 0x0040

[PHY DUMP] Port 9 Reg 0x18: 0x0079

[PHY DUMP] Port 9 Reg 0x19: 0x4444

[PHY DUMP] Port 9 Reg 0x1a: 0x0002

[PHY DUMP] Port 9 Reg 0x1b: 0x0000

[PHY DUMP] Port 9 Reg 0x1c: 0x0000

[PHY DUMP] Port 9 Reg 0x1d: 0x0000

[PHY DUMP] Port 9 Reg 0x1e: 0x0202

[PHY DUMP] Port 9 Reg 0x1f: 0x0000

[PHY DUMP] ========================================

[TEST] ============================================

[TEST] BASELINE dump complete (Gigabit ENABLED)

[TEST] ============================================

2.)

We turned off gigabit advertisement (turning off bit 8 and 9 of register 0x0009) for one of the devices. (For the other device gigabit advertisement was still turned on.) Again we conntected the devices via the 2-pair cable, waited for the link LEDs to blink and took the following PHY dump from the device with deactivated gigabit advertisement: 

[TEST] ============================================

[TEST] TEST MODE: Disabling Gigabit advertisement

[TEST] ============================================

[TEST] Disabling Gigabit advertisement on port 9

[DEBUG] Port 9 Register 0x09 (before): 0x0200

[DEBUG] Port 9 Register 0x09 (after): 0x0000

[TEST] Gigabit advertisement disabled and autoneg restarted on port 9

[TEST] Waiting 10 seconds for autoneg to complete...

[TEST] ============================================

[TEST] TEST: Register dump WITHOUT Gigabit

[TEST] ============================================

[PHY STATUS] Port 9 Status:

  Autoneg enabled: YES

  Link status: UP

  Autoneg complete: YES

  Local advertised 10/100: 0x1e0

  Local advertised Gigabit: NO (0x0)

  Partner advertised 10/100: 0x1e0

  Partner advertised Gigabit: NO (0x0)

[PHY DUMP] ========================================

[PHY DUMP] Register dump for Port 9 (DP83867)

[PHY DUMP] ========================================

[PHY DUMP] Port 9 Reg 0x00: 0x1140

[PHY DUMP] Port 9 Reg 0x01: 0x796d

[PHY DUMP] Port 9 Reg 0x02: 0x2000

[PHY DUMP] Port 9 Reg 0x03: 0xa231

[PHY DUMP] Port 9 Reg 0x04: 0x05e1

[PHY DUMP] Port 9 Reg 0x05: 0xc1e1

[PHY DUMP] Port 9 Reg 0x06: 0x006f

[PHY DUMP] Port 9 Reg 0x07: 0x2001

[PHY DUMP] Port 9 Reg 0x08: 0x0000

[PHY DUMP] Port 9 Reg 0x09: 0x0000

[PHY DUMP] Port 9 Reg 0x0a: 0x0000

[PHY DUMP] Port 9 Reg 0x0b: 0x0000

[PHY DUMP] Port 9 Reg 0x0c: 0x0000

[PHY DUMP] Port 9 Reg 0x0d: 0x401f

[PHY DUMP] Port 9 Reg 0x0e: 0x0000

[PHY DUMP] Port 9 Reg 0x0f: 0x3000

[PHY DUMP] Port 9 Reg 0x10: 0x5848

[PHY DUMP] Port 9 Reg 0x11: 0x7c02

[PHY DUMP] Port 9 Reg 0x12: 0x0000

[PHY DUMP] Port 9 Reg 0x13: 0x9ce4

[PHY DUMP] Port 9 Reg 0x14: 0x2bc7

[PHY DUMP] Port 9 Reg 0x15: 0x7217

[PHY DUMP] Port 9 Reg 0x16: 0x0000

[PHY DUMP] Port 9 Reg 0x17: 0x0040

[PHY DUMP] Port 9 Reg 0x18: 0x0079

[PHY DUMP] Port 9 Reg 0x19: 0x4444

[PHY DUMP] Port 9 Reg 0x1a: 0x0002

[PHY DUMP] Port 9 Reg 0x1b: 0x0000

[PHY DUMP] Port 9 Reg 0x1c: 0x0000

[PHY DUMP] Port 9 Reg 0x1d: 0x0000

[PHY DUMP] Port 9 Reg 0x1e: 0x0202

[PHY DUMP] Port 9 Reg 0x1f: 0x0000

[PHY DUMP] ========================================

[TEST] ============================================

[TEST] TEST dump complete (Gigabit DISABLED)

[TEST] ============================================

But we still get no link.

But now I am not sure if our understanding of "having no link" is correct:

As described above we observe the link LEDs at the ethernet ports starting to blink. But we are not able to send a ping to a device via the cable and also not to load a webpage from the webserver of the embedded device (where the DP83867 is built in). That is why our conclusion was that we get no link. But is this conclusion correct?

Best regards,

Dirk

Thank you for the details Dirk,

From the register dumps it seems like you're actually getting a link up. Register 0x0001[2] and 0x0011[10] are high in both cases, indicating link is up on the MDI side between the PHY and link partner. Getting a successful ping requires a good quality link on the MDI and MII sides of both PHYs.

In the register dumps you've provided I see register 0x0015 is either failing to read or is populated with a high value. This indicates there are receive errors coming from the link partner into the DP83867 over the 2-pair ethernet cable:

With this in mind I have the following questions:

• When one PHY is forced to 100M speeds, does the ping test work? You mentioned the link works when one PHY forces the speed.
• Can you share the schematic for the PHY implementation and connection to the RJ-45 port? Alternatively I'd recommend checking your design with our DP83867 schematic checklist.
• How long is the 4-wire cable?
• Does ping work with a 1Gbps link?
• What value do you see in register 0x225 after the link is established? This register is described in section 2.5 of the DP83867 troubleshooting guide:

Best,

Shane

 Hello Shane,

I am sorry for the late reply and that I can just provide answers just for a part of your questions. The rest will follow at the beginning of next week.

When one PHY is forced to 100M speeds, does the ping test work? You mentioned the link works when one PHY forces the speed.

• Yes, if one of the PHYs (regardless if the DP83867 or the link partner) is set to 100 Mbit/s (regardless if half-duplex or full-duplex) then can ping and load the internal website of the device where the DP83867 is built in.

Can you share the schematic for the PHY implementation and connection to the RJ-45 port? Alternatively I'd recommend checking your design with our DP83867 schematic checklist.

• It is possible to share the schematics with you directly?

 How long is the 4-wire cable?

• Approx. 5 meters. But is makes no difference if we use the other cable (described above) which is approx. 1 meter.

Does ping work with a 1Gbps link?

• Yes, if we use a cable with 8 wires resp. 4 pairs then we get a 1 Gbit/s link, can ping and load the webpage.

What value do you see in register 0x225 after the link is established?

• We will be able to provide the register content at the beginning of next week. Sorry.
  
  

Beside the suspicious content of register 0x0015: Did you see any other settings in the registers that might lead to the effect we observe?

Thank you very much for your support.

Best regards,
Dirk

Hi Dirk,

SW Dev said:

It is possible to share the schematics with you directly?

Yes this is possible through E2E's direct message function. I've sent you a friend request via E2E. 

If you can accept this request it will allow us to create a private message space under the direct messages icon in the top right hand side of E2E:

SW Dev said:

Beside the suspicious content of register 0x0015: Did you see any other settings in the registers that might lead to the effect we observe?

So far it seems ok aside from that register. For instance I can see:

• The link is up at 100Mbps (0x11[15:14] = 01) 
• The link partner's abilities are detected to support 100Base-TX: (0x5 = C1E1)
• Autonegotiation is completing: (0x1[5] = 1)

If we can look at the MSE register it may give us a clue as to the quality of the link itself. So far all indicators show the link comes up ok, however the quality of the link may contribute to the errors in register 0x15.

Best,

Shane

Hi Shane,

I'm a developer working on this project and I dumped all PHY registers.
Here is the register dump:

[PHY STATUS] Port 9 Status:
Autoneg enabled: YES
Link status: UP
Autoneg complete: YES
Local advertised 10/100: 0x1e0
Local advertised Gigabit: YES (0x200)
Partner advertised 10/100: 0x1e0
Partner advertised Gigabit: YES (0x800)
PHY Extended Reg 0x225: 0x45e1

[PHY REG 0x225 DECODE] Port 9 - Extended Register 0x225 Analysis:
Raw value: 0x45e1 (binary: 0100_0101_1110_0001)
Bit [15:8]: 0x45 (69)
Bit [7:0]: 0xe1 (225)
Bit 15: 0
Bit 14: 1
Bit 13: 0
Bit 12: 0
Bit 11: 0
Bit 10: 1
Bit 9: 0
Bit 8: 1
Bit 7: 1
Bit 6: 1
Bit 5: 1
Bit 4: 0
Bit 3: 0
Bit 2: 0
Bit 1: 0
Bit 0: 1

[PHY EXTENDED] Port 9 Ext Reg 0x0010: 0x5b48 (PHYSCR (PHY Specific Config))
[PHY EXTENDED] Port 9 Ext Reg 0x0031: 0x6c02 (PHYSTS (PHY Status)) [WILL BE DECODED BELOW]
[PHY EXTENDED] Port 9 Ext Reg 0x0032: 0x0000 (PHYCR (PHY Control)) [WILL BE DECODED BELOW]
[PHY EXTENDED] Port 9 Ext Reg 0x0086: 0x0065 (RXERCNT (RX Error Counter))
[PHY EXTENDED] Port 9 Ext Reg 0x0170: 0x5b48 (SGMIICTL1 (SGMII Control 1))
[PHY EXTENDED] Port 9 Ext Reg 0x016f: 0x3000 (STRAP_STS1 (Strap Status 1))
[PHY EXTENDED] Port 9 Ext Reg 0x006e: 0x00d3 (STRAP_STS2 (Strap Status 2))
[PHY EXTENDED] Port 9 Ext Reg 0x00d3: 0x0c04 (DSP_FFE_CFG (DSP/FFE Config))
[PHY EXTENDED] Port 9 Ext Reg 0x0134: 0x29c7 (RGMIICTL (RGMII Control))
[PHY EXTENDED] Port 9 Ext Reg 0x0086: 0x0065 (100M_CTRL (100BASE-TX Control))
[PHY EXTENDED REGISTERS] ======================================

Port 9 - PHYSCR (0x0010) = 0x5b48
Downshift Enable: ENABLED
Downshift after 5 failed Gigabit attempts

[PHY PHYSTS 0x31 DECODE] Port 9 - PHY Status Register Analysis:
Raw value: 0x6c02
MDI/MDIX: MDIX
Receive Error Latch: ERROR DETECTED
Polarity: NORMAL
False Carrier Sense: DETECTED
Signal Detect: YES
Descrambler Lock: NOT LOCKED
Page Received: NO
MII Interrupt: INACTIVE
Remote Fault: OK
Jabber Detect: OK
Autoneg Complete: NO
Loopback: DISABLED
Duplex: Half-Duplex
Link Status: DOWN
Speed: 100 Mbps

[PHY STRAP STATUS DECODE] Port 9 - Bootstrap Configuration:
STRAP_STS1 (0x016F): 0x3000
STRAP_STS2 (0x006E): 0xd3

STRAP_STS1 Analysis:
SGMII Clock Config: 0x0 (125 MHz output)
Mode[3]: 1
Interface Mode: 0x2 (Fiber)

STRAP_STS2 Analysis:
MII Mode: 0
LED Config: 0x0
PHY Address: 0x1a (26)

[PHY DUMP] ========================================
[PHY DUMP] Register dump for Port 9 (DP83867)
[PHY DUMP] ========================================
[PHY DUMP] Port 9 Reg 0x00: 0x1140
[PHY DUMP] Port 9 Reg 0x01: 0x796d
[PHY DUMP] Port 9 Reg 0x02: 0x2000
[PHY DUMP] Port 9 Reg 0x03: 0xa231
[PHY DUMP] Port 9 Reg 0x04: 0x05e1
[PHY DUMP] Port 9 Reg 0x05: 0x45e1
[PHY DUMP] Port 9 Reg 0x06: 0x0065
[PHY DUMP] Port 9 Reg 0x07: 0x2001
[PHY DUMP] Port 9 Reg 0x08: 0x4953
[PHY DUMP] Port 9 Reg 0x09: 0x0200
[PHY DUMP] Port 9 Reg 0x0a: 0x0800
[PHY DUMP] Port 9 Reg 0x0b: 0x0000
[PHY DUMP] Port 9 Reg 0x0c: 0x0000
[PHY DUMP] Port 9 Reg 0x0d: 0x401f
[PHY DUMP] Port 9 Reg 0x0e: 0x00d3
[PHY DUMP] Port 9 Reg 0x0f: 0x3000
[PHY DUMP] Port 9 Reg 0x10: 0x5b48
[PHY DUMP] Port 9 Reg 0x11: 0x6c02
[PHY DUMP] Port 9 Reg 0x12: 0x0000
[PHY DUMP] Port 9 Reg 0x13: 0x0000
[PHY DUMP] Port 9 Reg 0x14: 0x29c7
[PHY DUMP] Port 9 Reg 0x15: 0x0323
[PHY DUMP] Port 9 Reg 0x16: 0x0000
[PHY DUMP] Port 9 Reg 0x17: 0x0040
[PHY DUMP] Port 9 Reg 0x18: 0x0079
[PHY DUMP] Port 9 Reg 0x19: 0x4444
[PHY DUMP] Port 9 Reg 0x1a: 0x0002
[PHY DUMP] Port 9 Reg 0x1b: 0x0000
[PHY DUMP] Port 9 Reg 0x1c: 0x0000
[PHY DUMP] Port 9 Reg 0x1d: 0x0000
[PHY DUMP] Port 9 Reg 0x1e: 0x0202
[PHY DUMP] Port 9 Reg 0x1f: 0x0000

I hope this information helps.

Hi David,

The reading from 0x225 suggests a high mean-square error on the link. The link is up, but it seems to be poor in quality.

Let me see if I get a similar result on my EVM boards in our lab when using a 2-pair cable. 

Best,

Shane

Hi David,

When I test on my EVMs with the same modified cable I used last time, I do not see the behavior you describe. The value in register 0x225 fluctuates between 0x3F and 0x28. The value in 0x0015 did not increment over the duration of my test (around 1 minute). Here are the details on the test I performed:

• DP83867ERGZ-R-EVM (LP) --> Modified 2 pair cable --> DP83867ERGZ-S-EVM (DUT)
• I wrote 0x0016 = 0xF000 on the LP to transmit PRBS data from the LP to the DUT. Additionally I enabled speed optimization on both PHYs through 0x0014[9]. I can see the link is up and there is activity when connecting the modified cable to both EVMs.
• Next I read registers 0x0225 and 0x0015 every 10 seconds to monitor the link quality and error counter. I did not see poor link quality and did not see the error counter incrementing.

This leads me to believe there is something board or cable specific in your setup attributing to this. I have a few questions to get a better idea:

1. Are you using a standard RJ-45 cable with two pairs cut?
   1. If so, can you test this cable with two DP83867 EVMs to rule out a cable dependency?
   2. If not, can you elaborate on what type of cable and connectors are used?
2. Can you run a similar test to what I have done with two boards using DP83867 as the PHY? Do you see a similar result?
3. What is the length of the cable you're using? I used a 3M cable in my test, so I'm wondering if perhaps the length of the cable could be causing this discrepancy in our results.

Best,

Shane

Hi Shane,

we did some investigation and found that the issue might be related to the SGMII connection to the Marvell chip, which handles the other ports.

The negotiated speed reported by the DP83867 registers is 100 Mbit/s, while the Marvell chip reports a 1 Gbit/s link.

Could this indicate a misconfiguration of the SGMII interface?

Best regards,
David

Hi David,

The SGMII link should follow the link on the MDI, so its odd that you see a 1G SGMII link when the PHY is linked up at 100Mbps. We do have an SGMII troubleshooting guide that may help here if you suspect an issue with the SGMII. 

I would still consider the tests described in my last reply, as I would not expect an SGMII issue alone to cause a bad MSE value (though it may cause 0x0015 to increment on the link partner if you are transmitting errors).

Best,

Shane

Hello Shane,

thank you for your tests and the description of them.

In the meantime we do not think that the cable is the reason but I still want to answer your questions:

1.

Yes, we used a no-name standard cable with RJ-45 plugs and cut the two pair that belong to gigabit speed.  

In detail we have the following chain because the device is for industrial use:

M12 X-coded jack (of the device) => M12 X-coded plug => short industrial-grade ethernet cable => RJ-45 plug => double-jack adapter => RJ-45 plug of the modified (only 2 pairs for 100 Mbit/s) standard cable => standard cable => ... (same way back to another of our devices with the DP83867)

For the most recent tests we used another cable setup:

M12 X-coded jack (of the device) => M12 X-coded plug => short industrial-grade ethernet cable => M12 D-coded jack => M12 D-coded plug => ... (same way back to another of our devices with the DP83867)

1a.) Unfortunately we do no longer have the EVMs because the development of the device is some years ago.

1b.) I do not have the exact types order numbers of the cables mentioned above. But we have the problem also with other cables. Even a test engineer in a external test laboratory has the effect with the cables and equipment that is approved for the certification tests.

2.) Yes, using two devices of the same type, both using the DP83867, leads to the same problem.

3.) In both setups mentioned above the cable length was max. 3 meters.

As described in older posts: If we turn of auto-negotiation at one device and fix it to 100 Mbit/s (regardless if half- or full-duplex) then we get a link quickly and can communicate via the 2-pair cable (sending pings or open the website of an embedded webserver of the device) If the signal quality across the cable was too poor then we should not be able to do this.

This is one reason why we are now looking also at the interplay between the PHY and the MAC as my colleague David wrote.
Thank you for the link to the SGMII troubleshooting guide.


We will post again as soon as we have hopefully new information.

Best regards and thanks for your effort,
Dirk 

Hello Shane,

in the meantime, the manufacturer of the MAC gave us some special register settings. And indeed, those settings solved our problem.

On the side of the DP83867 the only step was to activate the „speed optimization“. The rest of the problem seemed to be on the MAC side with the SGMII interface when shifting down to 100 Mbit/s.

So our issue is solved. Thank you very much for your help and patience.

Best Regards,
Dirk