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.

DP83867CS: DP83867CS - no error-free ping with 1000 Mbps in SGMII mode possible

Part Number: DP83867CS
Other Parts Discussed in Thread: DP83867IR

Dear support team,

we have a module with ethernet phy DP83867CS, configured in SGMII mode.

After start both link partner show 'Link detected: yes'. But we get no ping reply via 1000 Mbps.

The link data on module-with-DP83867 side are as follows:

Settings for eth0:
        Supported ports: [ ]
        Supported link modes:   10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: ubgs
        Wake-on: d
        SecureOn password: 00:00:00:00:00:00
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: yes

The register values on DP83867CS are:

0x0 0x1140
0x1 0x796d
0x2 0x2000
0x3 0xa231
0x4 0xd41
0x5 0xcde1
0x6 0x6f
0x7 0x2001
0x8 0x4806
0x9 0x200
0xa 0x4c00
0xb 0x0
0xc 0x0
0xd 0x401f
0xe 0x1000
0xf 0x3000
0x10 0x5848
0x11 0xac02
0x12 0xec10
0x13 0x4
0x14 0x2bc7
0x15 0x0
0x16 0x0
0x17 0x40
0x18 0x6150
0x19 0x4444
0x1a 0x2
0x1b 0x0
0x1c 0x0
0x1d 0x0
0x1e 0x282
0x1f 0x0

The link data of ethernet partner (a simple Ethernet card in PCI Slot of an computer) are as follows:

Settings for ens4:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Full
                                             100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: slave
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: d
        Link detected: yes

Sometimes single ping requests get an reply...

64 bytes from 192.168.225.1: icmp_seq=7 ttl=64 time=2.28 ms
64 bytes from 192.168.225.1: icmp_seq=11 ttl=64 time=2.17 ms
64 bytes from 192.168.225.1: icmp_seq=15 ttl=64 time=2.17 ms
64 bytes from 192.168.225.1: icmp_seq=20 ttl=64 time=2.18 ms

...but the most of packets are lost (e.g. '64.8% packet loss').

Even if we reset the PHY to the default values (hard reset), no error-free ping handling is possible.

Even if we use the Phy register values of the troubleshooting document - no error-free pings ...

What is our problem, what can change for an error-free ping handling?

Thanks for your help,

regards

Joerg

  • Hi Joerg,

    Thank you for sharing the information. If possible, could you share the following information:

    • A block diagram of the setup?
    • Schematic on SGMII communication.

    --

    Regards,

    Hillman Lin

  • Hi Hillman Lin,
    attached is the block diagram of the setup.

    The scematic will follow shortly.

    Regards

    Joerg

  • ...and the scematic of the PHY:

    ...and the power supply:

    Regards,

    Joerg

  • Hi Joerg,

    One more thing I would like to check is register 0x0037. Is SGMII auto negotiation complete?

    I take a look on your schematic, I only see AC coupling on transmitting pins. Did you also have AC coupling resistor on receiving pin as well?

    I also see that you are using both RGMII and SGMII in your schematic. If possible, could you remove the 0 ohms resistor that is used for RGMII communication and see if that help with your setup?

    --

    Regards,

    Hillman Lin

  • Hi Hillman Lin,

    1.Boths bits are enabled in register 37, SGMII page has been received and SGMII autonegotiation was completed.

    2.Yes we have AC coupling capacitors also on the receiving lines. These capacitors are located close to the source (MAC) on a further adapter-PCB (therefore not visible on the given schematic excerpt).

    3.We have done it already, all 0 ohm resistors removed to cut the RGMII lines but we couldn't observe any impact.

  • Hi Jens,

    Is this E2E thread similar to the other one you post?

    https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1313217/dp83867ir-ethernet-link-instability-in-sgmii-mode

    If so, I will close this one and work on the other E2E.

    --

    Regards,

    Hillman Lin

  • Hi Hillman Lin,

    You are right, both cases are linked together. In both cases the same module is used, with same drivers and firmware, but the link partners are different and we have a different error behaviour. And therefore I would propose to handle both cases separately.

    Here again the differences between the two cases:

    Thread 1) 'DP83867IR: ethernet link instability in SGMII mode'
    * SGMII mode, 10 Mbps: Ping does not work (no answer, 100% packet loss)
    * 100/1000 Mbps: Ping works fine
    * Link partner (eth card): Broadcom BCM95722A2202G PCIe

    Thread 2) 'DP83867CS: DP83867CS - no error-free ping with 1000 Mbps in SGMII mode possible'
    * SGMII mode, 1000 Mbps: Ping works instable (not error-free, about 70% packet loss)
    * 10 Mbps: Ping works fine
    * Link partner (eth card): LogiLink PC0029A PCIe

    If you are of the opinion that both problems have a similar cause and solution, then close thread 1.

    Regards,
    Jörg

  • Hi Jorg,

    Thank you for explaining. This case it seems like the issues lies on MDI side instead of SGMII side. 

    • Could you let me know how did you change from 10mbps to 1000mbps?
    • If possible, could you share the RJ45 with transformer schematic information?
    • Could you also take a look on the layout checklist make sure your layout follow the layout checklist requirement?

    0245.IndustrialPHY_Layout Review Checklist.xlsx

    --

    Regards,

    Hillman Lin

  • Hi Hillman Lin,

    * By default we don't switch to 1000 Mbps, we assume that the autonegotiation negotiates the 1000 Mbps between our module and the link partner.
    Otherwise, if we switch the speed for tests, than we use the command for the link partner (here eth card 'LogiLink PC0029A'):
    'sudo ethtool -s ens4 speed 1000 duplex full'.

    * The used RJ45 is a RJMG201031110NR from Amphenol. Please see in the attached data sheet:

    rjmg20103xxx0xr.pdf

    * To work through the layout checklist we need a little more time...

    Regards,
    Jörg

  • Hi Jorg,

    Sorry, I don't think we can conclude the problem lies on MDI yet because SGMII auto-negotiation complete indicate that SGMII could communicate but it does not indicate how bad is the signal is.

    Like I mention in the previous E2E, could you enable packet generator on MAC or Soc. Then enable MII loopback on DP83867 and see if the SoC is able to receive back the packets. See if you are seeing any packets error in SoC?

    --

    Thank you,

    Hillman Lin