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

DP83867CS: ZYNQ ultracale + PS integration problem

ELIMELECH KELLER
Prodigy 50 points
Part Number: DP83867CS


Tool/software:

Hi TI team.

I have a custom board with ZYNQ ultrascale +.

It is connected to two DP83867CS by an SGMII PS port.

I am working with petalinux OS.

on the eth1 port, everything is OK,it obtains IP automatically.

However, on eth0, it doesn't automatically get an IP, and even when I set a static IP, no message is sent or received.

Can you help me resolve it ?

More details for troubleshooting :

Here is what I get for ifconfig :

eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0a:35:16:c7:dd txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 45

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.26.119 netmask 255.255.255.0 broadcast 172.16.26.255
inet6 fe80::2c1:beff:fe33:1 prefixlen 64 scopeid 0x20<link>
ether 00:c1:be:33:00:01 txqueuelen 1000 (Ethernet)
RX packets 28758 bytes 1791349 (1.7 MiB)
RX errors 0 dropped 10599 overruns 0 frame 0
TX packets 2929 bytes 634923 (620.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 46

When  I read DP83867CS registers of each , I get the following data :

eth0 (not working well) : 

Register 0x00 = 0x1140

Register 0x01 = 0x7949

Register 0x02 = 0x2000

Register 0x03 = 0xa231

Register 0x04 = 0x09e1

Register 0x05 = 0000

Register 0x06 = 0x0064

Register 0x07 = 0x2001

Register 0x08 = 0000

Register 0x09 = 0x0300

Register 0x0A = 0000

Register 0x0B = 0000

Register 0x0C = 0000

Register 0x0D = 0x401f

Register 0x0E = 0000

Register 0x0F = 0x3000

Register 0x10 = 0x5848

Register 0x11 = 0x0002

Register 0x12 = 0000

Register 0x13 = 0x0040

Register 0x14 = 0x2bc7

Register 0x15 = 0000

Register 0x16 = 0000

Register 0x17 = 0x0040

Register 0x18 = 0x6150

Register 0x19 = 0x4444

Register 0x1A = 0x0002

Register 0x1B = 0000

Register 0x1C = 0000

Register 0x1D = 0000

Register 0x1E = 0x0202

Register 0x1F = 0000

eth1 (working well)

Register 0x00 = 0x1140

Register 0x01 = 0x796d

Register 0x02 = 0x2000

Register 0x03 = 0xa231

Register 0x04 = 0x09e1

Register 0x05 = 0xc5e1

Register 0x06 = 0x006f

Register 0x07 = 0x2001

Register 0x08 = 0x5806

Register 0x09 = 0x0300

Register 0x0A = 0x3800

Register 0x0B = 0000

Register 0x0C = 0000

Register 0x0D = 0x401f

Register 0x0E = 0000

Register 0x0F = 0x3000

Register 0x10 = 0x5840

Register 0x11 = 0xac02

Register 0x12 = 0000

Register 0x13 = 0x1c40

Register 0x14 = 0x2bc7

Register 0x15 = 0000

Register 0x16 = 0000

Register 0x17 = 0x0040

Register 0x18 = 0x6150

Register 0x19 = 0x4444

Register 0x1A = 0x0002

Register 0x1B = 0000

Register 0x1C = 0000

Register 0x1D = 0000

Register 0x1E = 0x0202

Register 0x1F = 0000

  • 0
    TI__Mastermind 19621 points

    Hi Elimelich,

    Is this issue seen on multiple boards? Are we sure that the schematics for both PHYs are the same? In the register log you provided, I noticed that eth0 is linked down (Reg 0x1 = 0x7949) and eth1 is linked up (Reg 0x1 = 0x794D). Was this intentional? Does eth0 have any link issues?

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 50 points

    Hi Alvaro,

    Thank you for your response.

    I checked again, and the schematics for both PHYs are identical, besides the I2C address resistor.

    This is how it is :

    This issue is on three boards.

    I read register 0x006E and got 0x882C; that means that DP83867 doesn't recognize the right strap voltage level for LED0.

    When I read register 0x0031, I got 0x1091 (which indicates mirroring that I didn't ask it)

    I tried writing to register the 0x0031 value of 0x1090 (without mirroring), and it began to work well.

    I tried measuring the voltage on startup on LED0 for both channels; it is 350mV, as expected.

    So it is not these resistors issue.

    Do you have any idea why the initial value on 0x0031 is 0x1091 ?

    How to make it work well without sending a command manually?

     

  • +1 in reply to ELIMELECH KELLER
    TI__Mastermind 19621 points

    Hi Elimelech,

    Reading Register 0x6E is an excellent debug step.

    1. Do the values of 0x6E change between the working and non-working port?
    2. Straps are sampled during PHY bootup, could you try measuring the voltage again during the bootup phase?
      1. It could be that something is driving the LED line, causing an incorrect strap voltage during bootup
    3. Just to confirm, disabling port mirroring completely fixes the issue. 
      1. Now we want to avoid this being enabled in the first place

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 50 points

    I measure the strap voltage while the PHY is on hardware reset.

    on both PHYs, I got 300mV, which is as expected(for mode 2).

    This wire is connected to gate of mosfet(TI's CSD13381F4T) that drives a led.

    I assume the current to the Mosfet get is negligible.

    as you wrote on line 3 , disabling port mirroring completely fixes the issue. 

    Now we want to avoid this being enabled in the first place

    what do you think ?

  • 0 in reply to ELIMELECH KELLER
    TI__Mastermind 19621 points

    Hi Elimelech,

    Thank you for confirming the 300mV strap voltage, could you also confirm the following:

    Alvaro (Al-vuh-roe) Reyes said:
    Do the values of 0x6E change between the working and non-working port?

    Right now you have eth1 working as expected and eth0 that is getting strapped into mirror mode. Could you read registers 0x6E & 0x6F on both of them?

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 50 points

    on eth0(not working well on startup) :

    0x6E = 0x882c

    0x6F = 0x0140

    on eth1(working well on startup):

    0x6E = 0x0804

    0x6F = 0x0100

  • 0 in reply to ELIMELECH KELLER
    TI__Mastermind 19621 points

    Hi Elimelech,

    I believe this is the issue. Something is causing the PHY to get strapped into an unintended mode. This FAQ goes over the steps we already took, and you would have to investigate your system to find the root cause of the strapping issue.

    Regards,

    Alvaro