• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 33 subscribers
  • Views 341 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.

DP83869HM: PHY works with some switches, but not others.

Dimitar Dyakov
Prodigy 10 points
Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869

Tool/software:

Hello, I have trouble with DP83869 PHY

The phy is on a custom Linux board. The goal is to have RGMII to copper 100Mbit/s connection.

I have two switches 8 port on and 4 port different brand. When I connect my device to the 8 port one everything works as expected using the ethtool I can see that they phy is set to 100Mbit/s Half duplex connection. Also If I connect the board through USB to ETH adaptor to a PC and it also works.

When I connect to the 4 port switch (or directly to a PCs) I can see slow blinking light on the switch port and there is no connection. Here is the output of ethtool:

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
1000baseX/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
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Link detected: no

I can use this command 'ethtool -s eth0 speed 10 duplex half autoneg off' and we can see that we have established 10Mbit/s connection. I have ping and everything.

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Link detected: yes

I would like to have the phy work reliably accross the board. I cannot post schematics, but I can double check on request. However I don't think I the problem is HW since I am able to have 100Mbit/s connections established.

I am able accessing the phy register using phytool. Here are some register that might be of interest. The extended register are being accessed using the method described in AP DP83869 Troubleshooting Guide - 4.2.1 Read (No Post Increment) Operation

BMCR
phytool eth0/0x00/0x00
ieee-phy: reg:BMCR(0x00) val:0x1140

BMSR
phytool eth0/0x00/0x01
ieee-phy: reg:BMSR(0x01) val:0x7949

ANAR
phytool eth0/0x00/0x04
ieee-phy: reg:0x04 val:0x01e1

ALNPAR
phytool eth0/0x00/0x05
ieee-phy: reg:0x05 val:0xc5e1

ANER
phytool eth0/0x00/0x06
ieee-phy: reg:0x06 val:0x006f

ANNPTR
phytool eth0/0x00/0x07
ieee-phy: reg:0x07 val:0x2001

ANLNPTR
phytool eth0/0x00/0x08
ieee-phy: reg:0x08 val:0x4806

GEN_CFG1
phytool eth0/0x00/0x09
ieee-phy: reg:0x09 val:0000

GEN_STATUS1
phytool eth0/0x00/0x0A
ieee-phy: reg:0x0a val:0x0800

PHY_CONTROL
phytool eth0/0x00/0x10
ieee-phy: reg:0x10 val:0x5048

PHY_STATUS
phytool eth0/0x00/0x11
ieee-phy: reg:0x11 val:0x1302

GEN_CFG2
phytool eth0/0x00/0x14
ieee-phy: reg:0x14 val:0x

GEN_STATUS2
phytool eth0/0x00/0x17
ieee-phy: reg:0x17 val:0x0040

GEN_CFG4
phytool eth0/0x00/0x1E
ieee-phy: reg:0x1e val:0x0012

GEN_CFG3
phytool eth0/0x00/0x31
ieee-phy: reg:0x31 val:0x7302

RGMII_CTRL
phytool eth0/0x00/0x32
ieee-phy: reg:0x32 val:0000

RGMII_CTRL2
phytool eth0/0x00/0x33
ieee-phy: reg:0x33 val:0x9c42

STRAP_STS - read as extended
phytool write eth0/0x00/0x0d 0x1f
phytool write eth0/0x00/0x0e 0x6e
phytool write eth0/0x00/0x0d 0x401f
phytool eth0/0x00/0x0e
ieee-phy: reg:0x0e val:0000

OP_MODE_DECODE - read as extended
phytool write eth0/0x00/0x0d 0x1f
phytool write eth0/0x00/0x0e 0x1df
phytool write eth0/0x00/0x0d 0x401f
phytool eth0/0x00/0x0e
ieee-phy: reg:0x0e val:0x0040

This is the driver used:
github.com/.../dp83869.c

It would be great to have a configuration that I can manually test (using phytool) if the phy works across the devices before continuing to fix drivers etc.

I also tried this without success:

• Write 0x0040 to register 1DFh // Set Operation Mode to RGMII to Copper
• Write 0x1140 to register 0h // Reset BMCR
• Write 0x01E1 to register 4h // Advertise 100Base-TX and 10Base-T ability
• Write 0x0300 to register 9h // Reset GEN_CFG1
• Write 0x5048 to register 10h // Reset PHY_CONTROL
• Write 0x4000 to register 1Fh // Software Reset

Best regards.
M

  • 0
    TI__Mastermind 40275 points

    Hi M,

    This is very interesting. 10Mbps to 100Mbps shouldn't be too big of a difference MDI-wise. I do see on Reg 0x5 that DUT is getting the LP advertisements for 100M, but it is unclear why Auto-Negotiation is not converging on either side. I would like to propose we check the following:

    - Schematic review. Please fill out this document to rule out any HW-related health checks

    - Cable Type/Length. Does this behavior depend on the type and length?

    - On problematic switches, do other devices connect to the switch?

    - What happens if DUT is forced 100M speed?

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    - This will take a minute 
    - Tried with different types / length. Failure is consistent 
    - Problematic switches work with other devices. Tried multiple configurations. 
    - Forcing the 100M speed does nothing.

    However, enabling the speed optimization:

    phytool write eth0/0x00/0x14 0x2BC7
    phytool write eth0/0x00/0x1F 0x4000

    gets me here:

    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    1000baseT/Half 1000baseT/Full
    1000baseX/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
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    1000baseT/Full
    Link partner advertised pause frame use: Symmetric
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Link detected: yes

    But still no ping to the device. 

  • 0 in reply to Dimitar Dyakov
    TI__Mastermind 40275 points

    Hi M,

    It is encouraging that speed optimization is allowing PHY to linkup at 100Mbps. In this case, I would want to check MDI and MII signal integrity via loopback in this speed to make sure everything is okay. While 10Mbps is working, the higher speeds on the same HW could pose an issue if layout is marginal. 

    Could you check as a few experiments:

    - Reverse Loopback (Reg 0x16) on DUT. This will redirect traffic from MDI receive back out to link partner. Link partner MAC can then determine if there are packet errors.

    - MII Loopback (Reg 0x0), while setting PHY in 100Mbps mode and DUT MAC sending packets to DUT. This will do a similar loopback except on the MII portion in this speed.

    - Check for RX Errors. Reg 0x15 will be able to help determine if packets are getting corrupted coming into the DUT to help isolate MDI.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    There was a lot to unpack from your post. Its multistep process. I have propolsal to create a similar excel document on the loop back topic as the one you provided for HW check.

    I followed the instruction in this section "7.3.5 BIST Configuration" in the datasheet.

    - power up -
    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0xfe
    phytool write eth0/0x00/0x0d 0x401f
    phytool write eth0/0x00/0x0e 0xe720
    phytool write eth0/0x00/0x00 0x2100
    phytool write eth0/0x00/0x10 0x5028
    phytool write eth0/0x00/0x16 0x4

    - link up -
    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    1000baseT/Half 1000baseT/Full
    1000baseX/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
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    Link detected: yes

    phytool write eth0/0x00/0x16 0xF004

    - 11 bit in this reg goes high -
    phytool eth0/0x00/0x17
    ieee-phy: reg:0x17 val:0x0a40

    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0x72
    phytool write eth0/0x00/0x0d 0x401f
    phytool write eth0/0x00/0x0e 0x201

    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0x71
    phytool write eth0/0x00/0x0d 0x401f
    phytool eth0/0x00/0x0e
    ieee-phy: reg:0x0e val:0x8426

    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0x72
    phytool write eth0/0x00/0x0d 0x401f
    phytool eth0/0x00/0x0e
    ieee-phy: reg:0x0e val:0x0200

    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0x1A8
    phytool write eth0/0x00/0x0d 0x401f
    phytool eth0/0x00/0x0e
    ieee-phy: reg:0x0e val:0xb0e6

    phytool write eth0/0x00/0x0d 0x1f
    phytool write eth0/0x00/0x0e 0x1A9
    phytool write eth0/0x00/0x0d 0x401f
    phytool eth0/0x00/0x0e
    ieee-phy: reg:0x0e val:0x0003

    Is this the correct test?

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    One more test.

    I power up the DUT

    The link is not up at this point.

    I ping the PC connected to DUT and there are no packets send or received on both systems. I ping the DUT from the PC and as expected no packets received or transmitted on both systems.

    I enable the speed optimization

    phytool write eth0/0x00/0x14 0x2BC7
    phytool write eth0/0x00/0x1F 0x4000

    The link is up at 100Mbit/s auto-neg on full diplex.

    If I ping the PC from the DUT I can see on the DUT that packets are being sent. Nothing is received at the PC.
    If I ping the DUT from the PC I can see on the PC that packets are being sent. This time packets are being received at the DUT.

    Seems like one way communication.

    Now I enable Reverse Loopback.

    phytool write eth0/0x00/0x16 0x20

    If I ping the DUT from the PC I can see on the PC that packets are being sent and received (through the loopback i suppose).

    Also, the question stands how come with some devices 100Mbit/s is possible and with some not?

  • 0 in reply to Dimitar Dyakov
    TI__Mastermind 40275 points

    Hello,

    I don't believe these are the correct tests.

    The idea is that for MII loopback, the MAC sends traffic to the PHY. The PHY in MII loopback (via Reg 0x0) needs to just receive and redirect the traffic out. Only Reg 0x0 is needed.

    For Reverse loopback, the PHY will be redirecting MDI traffic in similar manner, so the link partner's MAC will need to send data out and report the integrity once returned.

    While in reverse loopback, the PHY's RX Error register will also be able to help determine if the packets are corrupted coming into the DUT.

    Regarding your test, it stands to reason that there is an issue on the MAC interface. I would recommend checking the setup/hold time on the MAC side, specifically the TX lines as you are reporting issues when the DUT tries to ping the PC, nothing is showing up.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    Hello,

    I would like little more detail. 

    For MII loopback just set 14 bit high in reg 0x00. Do I need to set auto-neg on or diplex or anything else? How do I send/res MAC data i.e. what tool do I need to install and how do I used it.

    For the reverse loopback same question as MII loopback. Do I need link up before I run the test and what tools should be used?


  • 0 in reply to Dimitar Dyakov
    TI__Mastermind 40275 points

    Hello,

    For MII loopback, you should disable the auto-negotiation and set the speed as the MAC interface will need this to properly send data at the correct datarate.

    For sending MAC data, you will need to contact the vendor for this information. I would recommend seeing if there is anything inbuild to automatically send traffic out regardless of link, or a customer function may need to be made.

    For reverse loopback, auto-negotiation is advised as PHY will be linked up (with Speed Optimization enabled).

    Sincerely,

    Gerome