This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867E: SGMII autonegotiation failure

Part Number: DP83867E

Hello,

We are trying to establish communication between Freescale QorIQ LS1021 ETSEC Ethernet Controller and DP83867 PHY. They are connected through 4 wire SGMII interface. Unfortunately we started our design with the older version of DP83867 datasheet (OCTOBER 2015). Initial design can be seen from the attached DP83867_schematic file.


Then we made the following modifications in the circuitry according to the revised version (March 2017) of DP83867:
- RX_CTRL is modified to Mode3 to enable autonegotiation.
- LED_0 Rhi resistor value is changed from 11K to 10K to set strap configuration to Mode2.

In our tests we observed that in far end (reverse) loopback mode, we successfully received transmitted packages. Hovewer neither in MII loopback mode, nor in Digital loopback mode, we could not receive none of the transmitted messages. We have checked SGMII lines and observed 1.25GHz signals at transmit and receive lanes.

We have also set bit7 of register 0x31 to 0 and restarted autonegotiation by writing 0x1200 to register 0. But we did not observe any improvement.

Dumped DP83867 register values are given below.

Do you have any suggestions to solve SGMII autonegotiation problem?

Kind Regards,

Asil YILDIRIM

RX_D0 and RX_D2 are at Mode1, so PHY address is 0.

register 0x31 kept unchanged:

phy add 0

reg add: 0x00000000, val: 0x00001000
reg add: 0x00000001, val: 0x0000796d
reg add: 0x00000002, val: 0x00002000
reg add: 0x00000003, val: 0x0000a231
reg add: 0x00000004, val: 0x000001e1
reg add: 0x00000005, val: 0x0000c1e1
reg add: 0x00000006, val: 0x0000006d
reg add: 0x00000007, val: 0x00002001
reg add: 0x00000008, val: 0x00004806
reg add: 0x00000009, val: 0x00000300
reg add: 0x0000000a, val: 0x00003800
reg add: 0x0000000b, val: 0x00000000
reg add: 0x0000000c, val: 0x00000000
reg add: 0x0000000d, val: 0x0000401f
reg add: 0x0000000e, val: 0x00000095
reg add: 0x0000000f, val: 0x00003000
reg add: 0x00000010, val: 0x00005848
reg add: 0x00000011, val: 0x0000ae02
reg add: 0x00000012, val: 0x00000000
reg add: 0x00000013, val: 0x00000000
reg add: 0x00000014, val: 0x000029c7
reg add: 0x00000015, val: 0x00000000
reg add: 0x00000016, val: 0x00000000
reg add: 0x00000017, val: 0x00000040
reg add: 0x00000018, val: 0x00006150
reg add: 0x00000019, val: 0x00004444
reg add: 0x0000001a, val: 0x00000002
reg add: 0x0000001b, val: 0x00000000
reg add: 0x0000001c, val: 0x00000000
reg add: 0x0000001d, val: 0x00000000
reg add: 0x0000001e, val: 0x00000002
reg add: 0x0000001f, val: 0x00000000
phy add 0
reg add: 0x00000025, val: 0x00000400
reg add: 0x00000031, val: 0x000010b0
reg add: 0x00000032, val: 0x000000d3
reg add: 0x00000033, val: 0x00000000
reg add: 0x00000037, val: 0x00000001
reg add: 0x00000038, val: 0x00000000
reg add: 0x0000006e, val: 0x00000800
reg add: 0x0000006f, val: 0x00000100
reg add: 0x00000071, val: 0x00000000
reg add: 0x00000072, val: 0x00000000
reg add: 0x000000d3, val: 0x00000000
reg add: 0x000000dc, val: 0x00003800
reg add: 0x000000fe, val: 0x0000e721
reg add: 0x00000135, val: 0x00000000
reg add: 0x0000016f, val: 0x00000095


Register 0x31 bit7 is set to 0:
phy add 0
reg add: 0x00000000, val: 0x00001000
reg add: 0x00000001, val: 0x0000796d
reg add: 0x00000002, val: 0x00002000
reg add: 0x00000003, val: 0x0000a231
reg add: 0x00000004, val: 0x000001e1
reg add: 0x00000005, val: 0x0000c1e1
reg add: 0x00000006, val: 0x0000006d
reg add: 0x00000007, val: 0x00002001
reg add: 0x00000008, val: 0x00004806
reg add: 0x00000009, val: 0x00000300
reg add: 0x0000000a, val: 0x00003800
reg add: 0x0000000b, val: 0x00000000
reg add: 0x0000000c, val: 0x00000000
reg add: 0x0000000d, val: 0x0000401f
reg add: 0x0000000e, val: 0x00000095
reg add: 0x0000000f, val: 0x00003000
reg add: 0x00000010, val: 0x00005848
reg add: 0x00000011, val: 0x0000ae02
reg add: 0x00000012, val: 0x00000000
reg add: 0x00000013, val: 0x00000000
reg add: 0x00000014, val: 0x000029c7
reg add: 0x00000015, val: 0x00000000
reg add: 0x00000016, val: 0x00000000
reg add: 0x00000017, val: 0x00000040
reg add: 0x00000018, val: 0x00006150
reg add: 0x00000019, val: 0x00004444
reg add: 0x0000001a, val: 0x00000002
reg add: 0x0000001b, val: 0x00000000
reg add: 0x0000001c, val: 0x00000000
reg add: 0x0000001d, val: 0x00000000
reg add: 0x0000001e, val: 0x00000002
reg add: 0x0000001f, val: 0x00000000
phy add 0
reg add: 0x00000025, val: 0x00000400
reg add: 0x00000031, val: 0x00001030
reg add: 0x00000032, val: 0x000000d3
reg add: 0x00000033, val: 0x00000000
reg add: 0x00000037, val: 0x00000001
reg add: 0x00000038, val: 0x00000000
reg add: 0x0000006e, val: 0x00000800
reg add: 0x0000006f, val: 0x00000100
reg add: 0x00000071, val: 0x00000000
reg add: 0x00000072, val: 0x00000000
reg add: 0x000000d3, val: 0x00000000
reg add: 0x000000dc, val: 0x00003800
reg add: 0x000000fe, val: 0x0000e721
reg add: 0x00000135, val: 0x00000000
reg add: 0x0000016f, val: 0x00000095

  • Hi Asil,

    From your schematic, I do not see a large problem. One thing to note is that the cap divider formed by C2216 and C2217 should be connected as shown in the datasheet Clock In (XI) Recommendation section.

    I am not sure what your problem is yet because you mentioned SGMII is not working, yet your SGMII auto-negotiation complete bit in register 0x37 is set to 1. This means the PHY has already transferred the status and information of the link to the MAC, and the MAC has acknowledged the data.

    In your post you said "In our tests we observed that in far end (reverse) loopback mode, we successfully received transmitted packages." Do you mean the packets you sent in from the cable were put on the SGMII interface? Or do you mean that you transmitted packets from the link partner, and then received them back at the link partner?

    When you enable the MII loopback or the digital loopback, where are you sending packets from? The MAC or the link partner?

    What link partner are you using? Is the link partner capable of EEE? If so, please disable EEE.

    Best Regards,
  • Hi Rob,

    Thanks for your response.

    In reverse loopback mode test, transmitted packages are successfully received back at the link partner. In MII or digital loopback mode test, we are sending packets from the MAC (Freescale LS1021 MOTETSEC). We checked SGMII transmit and receive lanes and observed 1.25 GHz signal in normal mode. Unfortunately we don't have an analyzer, so we don't know the content of the data.

    As link partner, we tried Allied Telesis AT-FS708LE (10/100M), 3Com OfficeConnect gigabit switches. These basic switches do not have any configuration interface and they are connected to Cisco Catalyst 3560-CX series managed switch. Host computer is also connected to Catalyst 3560-CX switch.

    In reverse loopback mode, host computer can receive transmitted packets. Does it enough to validate the path between DP83867 and host computer?

    Kind Regards,
    Asil YILDIRIM
  • Hi Asil,

    Can you confirm that the capacitor divider in your schematic was replaced with the correct configuration described in the datasheet?
    A reverse loopback is good to verify the MDI side (cable side) and MII loopback to verify the xMII interface (PHY - MAC connection).
    Full device tests are even better though with no internal loopbacks used since it will be what you end system is like. Do you have the capability to enable a loopback within your MAC to allow a full test?

    Best regards,
    Ross
  • Hi Ross,

    We have updated capacitor divider circuit as described in the datasheet but still we could not communicate through PHY. MAC does not have a reverse loopback capability. In loopback mode, it only "loops back the MAC transmit outputs to the MAC receive inputs".

    In a healthy SGMII connection between MAC and PHY, what shoud be the value of DP83867 SGMII Auto-Negotiation Status register (register 0x37)? In general, my first read attempts to read register 0x37 results in 0x3 but next reads return 0x1 value after some point. I don't know if this temporary case has a correlation between MDI autonegotiation completion. Can link partner affect the SGMII link between MAC and PHY?

    Do I have to set bit[7] of register 0x31 to 0? Can it have a side effect? Register 0x37 bit[0] becomes 1 independent of register 0x31 bit[7] value. So, SGMII autonegotiation can be completed without updating register 0x31 bit[7] in our case.

    Kind Regards,
    Asil YILDIRIM