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.

DP83867IR: MDIO being pulled low

Part Number: DP83867IR
Other Parts Discussed in Thread: MIO, MSP430F5529

Using DP83867IRRGZ on a custom board with Xilinx XC7Z045FBG676 FPGA.

The MDIO line seems to be getting pulled low by the PHY. I have a 2.2k pull-up to VDDIO, which is 2.5V. When PHY RESETN is low, MDIO is pulled high to 2.5V, as expected. Once PHY is taken out of reset, MDIO is being pulled low by something. When FPGA talks, Vhigh is only about 1.75V. When the PHY responds, Vhigh is only about 0.85V. When neither the FPGA nor the PHY are communicating, MDIO is pulled back low.

If I put PHY in reset and send out read requests from the FPGA, then the levels are correct.

What could be pulling MDIO low?

Here is an attempted read of PHY register 0x03:

Thanks,

Will

  • Hi Will,

    Can you share a schematic with us? I am curious to see if you have any components on the IO or ground. This is very strange behavior for an open drain pin.

    Do you have multiple PHYs on this board? Multiple MDIO pull-ups in parallel could also create a very strong pull-up equivalent that can hamper MDIO communication.

    Best Regards,
  • Rob,

    Here are the related parts of the schematic. There are no other PHYs on the board and there is only one pull-up on MDIO.

    Will

    1385.ethphy.pdf

  • Will,

    Looking at your schematic, I got curious about the PS_MIO_VREF_501 pin and I found this thread from Xilinx support forum: forums.xilinx.com/.../691706

    Can you verify your IO Standard is set to LVCMOS25?

    A second debug step would be isolating the FPGA from the MDIO bus and placing an external MDIO master to talk to the DP83867. You could use the MSP430 based tool we offer. You can find it at: www.ti.com/.../usb-2-mdio You will need an MSP430F5529 launchpad.

    Regards,
  • Rob,

    Yes, the IO standard is set to LVCMOS25. I have supplied reference voltage to PS_MIO_VREF_501 as suggested on page 56 of Xilinx UG933:

    Removing the FPGA from the situation would be quite difficult, as they are on the same board and are powered by the same supplies. I have already seen that the MDIO levels from the FPGA are correct when the PHY is placed in reset.

    Will

  • Will,

    I found this as well on Xilinx's forum saying UG933 is incomplete.  For LVCMOS standards you do not need VREF.  

    https://www.xilinx.com/support/answers/62833.html

    Have you tried floating VREF?  I'd also like to see the MDC line to make sure the FPGA is giving the DP83867 32 clock cycles.

    Have you also posted this question to the Xilinx forum?

    Best Regards,

  • Rob,

    It really looks like the problem does not concern VREF. I've attached two scope shots. The first one shows MDC and MDIO for attempted read of register 0x03 when the PHY reset is asserted low. Notice that the levels of MDC and MDIO are 2.5V, as they should be. The second image shows an attempted read of reg 0x03 when phy reset is high. Here, MDC levels are still correct, but MDIO is not pulled up to 2.5V. If MIO_VREF (or anything on the fpga side) were the issue, I would expect for the problem to persist even when phy is in reset.

    There is another copy of this board, but I do not have it. I'm going to see if I can get someone to do the same tests on that board to make sure that it's not just the chip on this particular board.

    Read of register 0x03 when phy in reset

    Read of register 0x03 when phy not in reset

    Thanks,

    Will

  • Will,

    I was able to reproduce your error, I believe, by strapping the GPIO_0 pin to mode 4, which is a restricted strap mode.

    Your schematic does not show a pull-up on GPIO_0 but your FPGA may have an internal pull-up.

    Please place a significantly strong pull-down on the GPIO_0 pin to pull the voltage down to the threshold stated in the datasheet.

    Best Regards,
  • The GPIO_0 strap was indeed the problem. I had internal pull-ups on both GPIO lines. After removing those, I can now talk to the phy. Still can't send/receive packets, but I assume that's related to the bad strap mode I have on RX_CTRL.

    Thanks a lot Rob,

    Will

  • Will,

    Yes, make sure RX_CTRL is strapped to mode 3 and also ensure that your RGMII delays are set correctly. Once those are squared away you should get packet traffic.

    Regards,