• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 36 subscribers
  • Views 2489 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.

Linux/DP83867IR: No continuous pulses on TX_CTRL line executing PING from target board

Abhijit Naik3
Intellectual 400 points
Part Number: DP83867IR
Other Parts Discussed in Thread: DP83867E, DP83867CR

Tool/software: Linux

Hi Everyone,

We have ZYNC-ZC702 based custom board where we have connected, two DP83867E phys to two macs. For now, we have disabled one MAC instance effectively using only one. The active mac is reading Phy ID of both the phys properly. We have configured the phy in RGMII mode.

I/O voltages that we are using is 2.7V and following are strap register values

We are getting both Tx and Rx clocks. 

Following are registers for strap, in format of <Strap pin, Rhi, Rlo>

==================================================================

Strap pins in Mode 2:
G1LED_0, 6.2K,1.6K
G1LED_1, 6.2K,1.6K
G1LED_2, 6.2K,1.6K
G1ETH_RXD0, 6.2K,1.6K
G1ETH_GPIO1, 6.2K,1.6K

G2LED_0, 6.2K, 1.6K
G2LED_1, 6.2K, 1.6K
G2LED_2, 6.2K, 1.6K
G2ETH_GPIO1, 6.2K, 1.6K

Strap pins in Mode 1:
G1ETH_RXD2, Open, 1.6K
G1ETH_GPIO0, Open, 1.6K

G2ETH_RXD2, Open, 1.6K
G2ETH_GPIO0, Open, 1.6K

Strap pins in Mode 4:
G1ETH_RXCTRL, 960, 1.6K
G2ETH_RXCTRL, 960, 1.6K
G2ETH_RXD0, 960, 1.6K

============================================

TX data lines are connected through series resistor of 22Ohms. We have verified both Tx and Rx clocks are continuous.

We have host machine and custom board connected through switch and we are running ping from target to host and Linux is running on both systems

When pinging from target to host, we are not getting continuous TX_CTRL pulse as expected and also transmit interrupt is occurring only once when pinging from target to host.

Please let me know whether our setup is ideal for debugging and the reason for TX_CTRL not being continuous pulse. We are seeing any packets on Wireshark too...

Regards,

   Abhijit

  • 0
    TI__Mastermind 26985 points
    Hello Abhijit,

    Thank you for using the TI forum. Our product expert will get back to you by Tuesday.
  • 0
    TI__Mastermind 19780 points
    Hi Abhijit,

    Can you share a schematic? You did mention the straps in your post, but a schematic would be easier to read.

    1. VDDIO = 2.7V is not supported by DP83867E. Why are you using this voltage?

    2. RX_CTRL strapped to mode 4 disables auto-negotiation. Are you forcing the speed to 100M to communicate with the switch?

    3. Can you draw a diagram of the system including host and target to clarify how the traffic is expected to move?

    The TX_CTRL signal is sourced from the MAC, so the MAC is likely seeing something it doesn't like, or isn't configured properly.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Intellectual 400 points

    Hi Rob,

    Thank you very much for your reply. Please find my reply in line.

    Rob Rodrigues said:
    Hi Abhijit,

    Can you share a schematic? You did mention the straps in your post, but a schematic would be easier to read.

    I have attached the schematic in the postrpcoc-bb-ti-review.pdf

    1. VDDIO = 2.7V is not supported by DP83867E. Why are you using this voltage?

    VDDIO voltage is brought up due to I/O voltage requirements from ZYNC7000 processor. This was earlier 3.3V, but due to warning brought out by Zync that RGMII may not work at 3.3V, we have to change that to 2.7V. However we will take care of this in next spin of board but, can you please let me know how critical is this for continuing test?

    2. RX_CTRL strapped to mode 4 disables auto-negotiation. Are you forcing the speed to 100M to communicate with the switch?

    This we were planning to handle from S/W programming however we will fix in H/W and test

    3. Can you draw a diagram of the system including host and target to clarify how the traffic is expected to move?

    Please find our test setup below.

    The TX_CTRL signal is sourced from the MAC, so the MAC is likely seeing something it doesn't like, or isn't configured properly.

    I do agree with this but, we have not made any changes to software and were expecting TX_CTRL to be continuous

    One more point I missed in case of ping from PC side, RX_CTRL is pulsing continuously with some data being exchanged on RXD lines

    Best Regards,

  • 0 in reply to Abhijit Naik3
    TI__Mastermind 19780 points

    Hi Abhijit,

    I don't see an issue with the schematic you posted.  The straps were the only questions I had.

    1. VDDIO = 2.7V is not supported by DP83867E. Why are you using this voltage?

    VDDIO voltage is brought up due to I/O voltage requirements from ZYNC7000 processor. This was earlier 3.3V, but due to warning brought out by Zync that RGMII may not work at 3.3V, we have to change that to 2.7V. However we will take care of this in next spin of board but, can you please let me know how critical is this for continuing test?

    [Rob] For test purposes, I don't see an issue.

    2. RX_CTRL strapped to mode 4 disables auto-negotiation. Are you forcing the speed to 100M to communicate with the switch?

    This we were planning to handle from S/W programming however we will fix in H/W and test

    [Rob] Auto-negotiation cannot be restarted using S/W.  Please strap RX_CTRL into mode 3, or mode 1 and follow the note in the strap table for the S/W work around for RX_CTRL.

    3. Can you draw a diagram of the system including host and target to clarify how the traffic is expected to move?

    Please find our test setup below.

    [Rob] The image of your test setup did not come through.

    The TX_CTRL signal is sourced from the MAC, so the MAC is likely seeing something it doesn't like, or isn't configured properly.

    I do agree with this but, we have not made any changes to software and were expecting TX_CTRL to be continuous

    [Rob] TX_CTRL should pulse each time a packet is transmitted.

    One more point I missed in case of ping from PC side, RX_CTRL is pulsing continuously with some data being exchanged on RXD lines

    [Rob] This is a good indication, this means your PHY is working and receiving the pings and sending them to the Zync device.  Please ensure your Zync is configured properly.  When you said you haven't changed software, what do you mean?  Are you using a reference design or example code?

    Best Regards,

  • 0 in reply to Rob Rodrigues
    Intellectual 400 points

    Rob Rodrigues said:

    Hi Abhijit,

    I don't see an issue with the schematic you posted.  The straps were the only questions I had.

    1. VDDIO = 2.7V is not supported by DP83867E. Why are you using this voltage?

    VDDIO voltage is brought up due to I/O voltage requirements from ZYNC7000 processor. This was earlier 3.3V, but due to warning brought out by Zync that RGMII may not work at 3.3V, we have to change that to 2.7V. However we will take care of this in next spin of board but, can you please let me know how critical is this for continuing test?

    [Rob] For test purposes, I don't see an issue.

    2. RX_CTRL strapped to mode 4 disables auto-negotiation. Are you forcing the speed to 100M to communicate with the switch?

    This we were planning to handle from S/W programming however we will fix in H/W and test

    [Rob] Auto-negotiation cannot be restarted using S/W.  Please strap RX_CTRL into mode 3, or mode 1 and follow the note in the strap table for the S/W work around for RX_CTRL.

    [AKN] Thank you for pointing it, we will do necessary changes

    3. Can you draw a diagram of the system including host and target to clarify how the traffic is expected to move?

    Please find our test setup below.

    [Rob] The image of your test setup did not come through.

    [AKN] Sorry, Here is the images

    The TX_CTRL signal is sourced from the MAC, so the MAC is likely seeing something it doesn't like, or isn't configured properly.

    I do agree with this but, we have not made any changes to software and were expecting TX_CTRL to be continuous

    [Rob] TX_CTRL should pulse each time a packet is transmitted.

    One more point I missed in case of ping from PC side, RX_CTRL is pulsing continuously with some data being exchanged on RXD lines

    [Rob] This is a good indication, this means your PHY is working and receiving the pings and sending them to the Zync device.  Please ensure your Zync is configured properly.  When you said you haven't changed software, what do you mean?  Are you using a reference design or example code?

    [AKN] We are loading Linux driver itself. i.e driver for Cadence MAC IP which is known to work. The change I want to do is set the MAC in broadcast mode instead of promiscuous mode.

    Best Regards,

  • 0 in reply to Abhijit Naik3
    TI__Mastermind 19780 points
    Hi Abhijit,

    Also, the MDIO control by the MAC may appear to work fine, but not work with extended register access.

    The DP83867 utilizes indirect access of clause 45 registers by clause 22 MDIO.

    For the extended registers, register addresses 0x20 and higher, there are 4 register accesses required. Please look at DP83867E datasheet section "8.4.2.1 Extended Address Space Access" to ensure your MAC is accessing the extended registers properly.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Intellectual 400 points

    Hi Rob,

    Thank you very much for your help.

    We solved the issue of TX_CTRL. We added patch for handling multiple phys. After which both MACs are up.

    But out of two MACs only one MAC is running at 1000Mbps speed and other MAC is not working at 1000Mbps

    On second MAC,

    1.  This is working at 100Mbps only

    2. If I do ifconfig up eth1, it will configure itself in full dublex, 1000Mbps and auto-negotiation mode

    3. At 1000Mbps, this MAC doesn't get the IP through DHCP. I verified that no packets are being sent from this interface by running wireshark

    4. I have attached dump of phy register contents after completion of auto-negotiation for both working and non-working MAC instance

    Please note that in attached archive,

         post_auto_neg_eth0.log - Register dump for Phy registers post auto-neg for working MAC

         post_auto_neg_eth1.log - Regdump for Phy registers post auto-neg for non-working MAC
    From the diff of register dump of both phys, I interpret that,

    Register 0x08

    1 > Received page is a Message Page.

    Register 0x09

    1 > Advertise 1000Base-T Full Duplex ability.

    Register 0x0A

    1 > Manual Master/Slave Configuration fault detected.

    2 > Local receiver is not OK.

    3 > Remote receiver is not OK.

    4 > Link partner not capable of 1000Base-T Full Duplex.

    5 > Link partner not capable of 1000Base-T Half Duplex.
    Please note that both the phys are DP83867CR to be configured in RGMII interface.
    Thank you very much for all your helppost_auto_neg.zip
  • 0 in reply to Abhijit Naik3
    Intellectual 400 points

    Hi Rob,

    Since the MAC is working at 100Mbps mean that TX/RX lines that are used for only for 1000Mbps may be having issue?

    Thanks,

      Abhijit

  • 0 in reply to Rob Rodrigues
    Intellectual 400 points

    Hi All,

    I have marked the answer as resolved