DP83867IS: RX Err on 1 GiBit (AM6548)

Intellectual 270 points

Replies: 11

Views: 104

Part Number: DP83867IS

Hello,

we have a customised board featuring the AM6548 and have in total seven DP83867 PHYs on this board. One for the MCU CPSW and two for each PRUSS instance. The connection and strapping for the PHYs is roughly equal - differences are in PHY address and the MCU CPSW has a 25 MHz quartz on XI/XO, while the PRUSS PHYs get a 25 MHz oscillator input on XI.

The MCU CPSW interface works perfectly in our Linux 5.4 using delays only on RX (phy-mode = "rgmii-rxid").

The PRUSS Ethernet interfaces don't work (same delay settings):

* Connected to a Gigabit Switch (TP-Link TL-SG1005D): Link LED goes on and off, no Link up reported to Linux. Workaround: Force Gigabit Master mode via register CFG1 bits 12,11.

* Any incoming data is recorded as RXerr bytes in the PHY.

Are there any debugging registers or any ideas why the PHY rejects received packets?

Best regards,

Michael

11 Replies

  • Hi Michael,

    As you have mentioned slight strapping differences, you may check registers 0x6E and 0x6F of both the working and non-working setups to ensure both are strapped as expected. I would expect these values to be the same, as the only change you have mentioned was PHY address. 

    Additionally, can you provide a register dump for both the working and non-working PHY's for registers 0x0 - 0x1F, and 0x32.

    Thank you,

    Nikhil

  • In reply to Nikhil Menon:

    Nikhil,

    the registers 0x6E and 0x6F were indeed equal.

    Please find attached the requested register dumps.

    I took one non-working PHY as an example against the one working.

    I already marked the differences in the dump for better readability.

    Interestingly the non-working phy on eth5 reports that it did not receive even the Link Code Word (register 0x06).

    Because of the difference in register 0x11 suggesting different MDI/X settings, I already tried to force Manual MDI and MDI-X via register 0x10 bits 6:5 on eth5, but it not change the result.

    Best regards,

    Michael

    e2e_regdump_eth5_eth0.txt

  • In reply to Michael Krummsdorf:

    Hi Michael,

    A couple follow up questions:

    1. What is the desired MAC interface?

    2. What is the cable length used in both the working and non-working case?

    3. On the connected pins between the PHY and processor, particularly the strap pins, are there differences in the internal pull values of the MCU CPSW versus the  PRUSS module?

    4. In the non-working case, Register 0x9 = 0x1A00, which is not the default value. Have any write statements been done to set this value? Does returning this register to value 0x0300 return the PHY to an operational state?

    Thank you,

    Nikhil

  • In reply to Nikhil Menon:

    hi Nikhil,

    1) All PHYs are connected as RGMII.

    2) I use the same cable - 1m length - when testing the working/non-working PHYs.

    3) The pull settings are the same across all ethernet pins.

    4) Yes, I needed to write that register to 0x1A00 on every PRU PHY in order to establish a link at all (CFG1, bit12,11 - see first post).

    It should be mentioned, that we are using a AM6548 SR2.0 and these firmware files from 07.02.00.001:

    https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware&id=31e626d84a3f8a5dc7175b79440972ce90a23de0

    I wanted to compare against the TI starterkit TMDX654GPEVM with the same DP83867 PHY and an AM6548 SR1.0 and using these firmware files:

    https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware&id=534ba03becfa9b39ccbd42b97e091abd94a207e7

    PRG2 ethernet works on that board.

    Best regards,
    Michael

  • In reply to Michael Krummsdorf:

    Hi Michael,

    Some follow ups to the specific line items:

    2. Is the issue also seen at other cable lengths, such as 10m or 20m?

    4. Thanks for the clarification, I understand this operation now. 

    Thank you,

    Nikhil

  • In reply to Nikhil Menon:

    Hi Nikhil

    I only have a 10m cable available. Auto-negotiation does take a bit longer with it but in the end it's the same: Got Link up, but packets dropped.

    Best regards

    Michael

  • In reply to Michael Krummsdorf:

    Hi Michael,

    Can we try both a near-end and far-end loopback test to help determine the source of the error? Please review section 8.4.4 in the datasheet for information on loopback modes. Let's try both an analog loopback and reverse loopback. Please let me know if errors are observed with either loopback experiment. Please let me know if you require additional information for setting up loopback modes.

    Thank you,

    Nikhil

  • In reply to Nikhil Menon:

    Hi NIkhil

    I guess I need a little help in setting up and testing the two loopback modes.

    Reverse Loopback test: 

    1. Set register 0x16 (BISCR) to 0x0020 (set bit 5)

    Now I my PC I use wireshark to monitor packets on the Ethernet interface and send a ping to the device's IP address. But wireshark does only show the ARPs to ask who has that IP address.

    Is that how you test this loopback mode?

    Analog Loopback test: 

    1. Disable auto-negotiation: Set register 0x00 (BMCR) to 0x0140 (clear bit 12).

    2. Disable Auto MDI/X, force manual MDI: Set register 0x10 (PHYCR) to 0x5008 (bits 6:5 to 0x00)

    3. Set register 0x00FE (LOOPCR) to 0xE720.

    4. Issue a sw restart: Set register 0x1F (CTRL), bit 14.

    How do I test this loopback mode?

    Then I assign an IP address to the ethernet interface and try to ping my host PC.

    I have tcpdump on the target but I don't how to use it

    Thanks,

    Michael

  • In reply to Michael Krummsdorf:

    Hi Michael,

    Some additional notes for each test:

    1. Reverse loopback: Writing 0x0016 = 0x0020 is the correct register setting. This should be all that is needed for this test. Do you have access to the MII pins of the PHY? If so, can you confirm you can observe MII data on these pins before setting the loopback mode? Have the link partner send the PHY data during normal operation and observe the RX_Data pins. 

    2. Analog loopback: You have the correct steps 1-3. Step 4 should be set analog loopback (register 0x16 = 0x0008). Then step 5 would be issue a soft reset (0x1F = 0x4000). For this test the PHY must be connected to a MAC, and the MAC should be set to generate packets, the PHY will loop the packets back to the MAC and the MAC should count the packets and display that there are no errors. The MDI pairs (cable side) should be terminated with a 100 ohm differential impedance. If the termination is not available, digital loopback can be used instead (set register 0x16 = 0x0004). However, analog loopback engages all analog blocks of the PHY and will be useful in fully confirming the functionality of the MDI side of the PHY.  

    Please let me know if this has helped clarify the setup for near-end loopback.

    Thank you,

    Nikhil

  • In reply to Nikhil Menon:

    Hi Nikhil,

    I will connect a scope to the RGMII pins and try to observe RX Data as you described.
    Will get back to you next week!

    Regards,

    Michael