• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 33 subscribers
  • Views 861 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83867IS: DP83867

Yannis PLANUS
Prodigy 50 points
Part Number: DP83867IS

Hello,

Our board have two 100Mb and two Gigabits interfaces. All interfaces are connected to the same PC (Centos 7 OS).

After a while (several minute or few hours), one of the 100Mb interfaces goes down without any reason (no link detected on our board). Problem appears with a Linux 4.1.35 and a FreeBSD 11.2 OS on our board.

The problem has been reproduce with other PC (Windows/Linux)

We made a dump of the PHY register before and after the problem:

Before :

BMCR: 0x1140
BMSR: 0x796d
PHY_IDR1: 0x2000
PHY_IDR2: 0xa231
ANAR: 0x01e1
ANLPAR: 0xc5e1
ANER: 0x006d
ANNPTR: 0x2001
ANNPRR: 0x7801
CFG1: 0x0300
STS1: 0x0800
REGCR: 0x401f
ADDAR: 0x0481
1KSCR: 0x3000
DP_PHYCTR: 0x5848
DP_PHYSTS: 0x6c02
DP_MICR: 0x0008
DP_ISR: 0x0000
DP_CFG2: 0x29c7
DP_RECR: 0x0000
DP_BISCR: 0x0000
DP_STS2: 0x0040
DP_LEDCR1: 0x6150
DP_LEDCR2: 0x4444
DP_LEDCR3: 0x0002
DP_CFG3: 0x0082
DP_CTRL: 0x0000
DP_TMCH_CTRL: 0xc5e1
DP_FLD_CFG: 0x401f
DP_CFG4: 0x6c02
DP_RGMIICTL: 0x0008
DP_RGMIICTL2: 0x0000
DP_100CR: 0xa231
DP_STRP_STS1: 0x0481
DP_STRP_STS2: 0x3000
DP_RGMIIDCTL: 0x006d
DP_IO_MUX_CFG: 0x5848
DP_GPIO_MUX_CTRL1: 0x6c02
DP_GPIO_MUX_CTRL2: 0x0008

After:

BMCR: 0x1140
BMSR: 0x1140
PHY_IDR1: 0x1140
PHY_IDR2: 0x1140
ANAR: 0x1140
ANLPAR: 0x1140
ANER: 0x1140
ANNPTR: 0x1140
ANNPRR: 0x1140
CFG1: 0x1140
STS1: 0x1140
REGCR: 0x401f
ADDAR: 0x1140
1KSCR: 0x1140
DP_PHYCTR: 0x1140
DP_PHYSTS: 0x1140
DP_MICR: 0x1140
DP_ISR: 0x1140
DP_CFG2: 0x1140
DP_RECR: 0x1140
DP_BISCR: 0x1140
DP_STS2: 0x1140
DP_LEDCR1: 0x1140
DP_LEDCR2: 0x1140
DP_LEDCR3: 0x1140
DP_CFG3: 0x1140
DP_CTRL: 0x1140
DP_TMCH_CTRL: 0x1140
DP_FLD_CFG: 0x401f
DP_CFG4: 0x1140
DP_RGMIICTL: 0x1140
DP_RGMIICTL2: 0x1140
DP_100CR: 0x1140
DP_STRP_STS1: 0x1140
DP_STRP_STS2: 0x1140
DP_RGMIIDCTL: 0x1140
DP_IO_MUX_CFG: 0x1140
DP_GPIO_MUX_CTRL1: 0x1140
DP_GPIO_MUX_CTRL2: 0x1140

This problem does not seem to appear when connected to a switch. Moreover, we have not observed it on a Gigabit link.

For information, our board is not Half Duplex capable. But on the Centos PC, ethtool returns:

        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  100baseT/Half
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: No
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 4
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Do you have an idea of where this problem could come from?

Thank you for you help and do not hesitate if you need more information.
  • 0
    TI__Genius 9920 points

    Hi Yannis,

    In the 'After' photo, is this still when there is a link when you record the register dump? Is your design strapped to half duplex? 

    Best,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Prodigy 50 points

    Hi Cecilia,

    Yes, the link is still connected and the PC continue to work as if nothing happend, I mean there is no new auto-negociation and the link is UP as 100Mb Full duplex.

    However, the ethtool PC picture has been taken after an unplug/plug manipulation. Our Ethernet Tester also confirmed the 100Mb Half duplex.

    Our design is strapped to Half-Duplex. We modify the registers to not advertise half-duplex by software

    Regards,

    Yannis

  • 0 in reply to Yannis PLANUS
    TI__Genius 9920 points

    If your design is strapped to half duplex it may be restarting to advertise half duplex. Is the modification to the registers by software done after the unplug/plug manipulation?

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Prodigy 50 points

    Hello Cecilia,

    The modification to the registers is done after each PHY reset.

    The problem here is not that Half duplex is advertised. It looks like advertising is deactivated. 100BaseTX Half-duplex is deducted by the PC but the link is down for our board.

    This problem never occured on Gigabit link.

    Thank you

    Yannis

  • 0 in reply to Yannis PLANUS
    TI__Genius 9920 points

    Hi Yannis,

    Is the link partner in a forced mode or is auto-negotiation enabled? Perhaps there could be mismatch between auto-negotiation and duplex select. 

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Prodigy 50 points

    Hi Cecilia,

    Both devices (our board and our Linux PC) have auto-negociation enabled. We also used an Ethernet Tester (FLUKE) and the results were similar to the Linux PC values.

    As you can see in my first post, our board is configured to only advertise 10Mb Full duplex and 100Mb Full duplex. It seems that either the PHY goes into an error mode, or the communication (MDIO) between PHY and our driver is down.

    Is there a reason why the PHY can go into error mode with the configuration we have set? How can we detect that PHY is in error mode? Which straps can create this kind of problem if not correctly set?

    Thanks,

    Yannis

  • 0 in reply to Yannis PLANUS
    TI__Genius 9920 points

    Hi Yannis,

    I think your suspicion may be correct that the communication from the MDIO to the PHY may not be reading properly. Do you have your schematic for how you are connecting your data lines?

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Prodigy 50 points

    Hi Cecilia,

    By looking at our schematic, we found that RX_CTRL/RX_DV strap are not configure in MODE3 (they are not used at all).

    The solution is to set the INT_TST_MODE_1 (7) bit to 0 into the Configuration Register 4 (0x31).

    Thanks for your help

    Yannis