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.

DP83640: Link and Activity LED Status in case of Software is not running yet

Part Number: DP83640


Hello,

I am using DP83640TVV/NOPB PHY on my custom design board in the MII mode which is connected to a Xilinx FPGA. It might be a pretty simple question, but I wanted to ask it to make clear: 

After board power up, in case the FPGA is not programmed and any software has not started to run yet, when I plug the LAN cable, for example, from the PC to the my board, I see that the LINK and ACTIVITY LEDs of the DP83640 start to light up. Is this behavior is expected and normal? Since the FPGA is not programmed and the software is not running, we think that these LEDs should not be lit even if I plug a LAN cable to my board.

If this is a fault condition, what can I do to prevent this?

Best Regards,

  • Hi Doner,

    I am not sure if I understand your question completely, you are seeing an LED link up when you plug in ethernet cable to the PC before programing anything on FPGA right?

    If my understanding is correct, this situation is expected. LED link up indication are mainly displaying ethernet cable side instead of the MAC side or (MII communication). The PHY should link up automatically without any programing requirement

    --

    Regards,

    Hillman Lin

  • Hi ,

    Thank you for your reply. 

    I am not sure if I understand your question completely, you are seeing an LED link up when you plug in ethernet cable to the PC before programing anything on FPGA right?

    Yes. Situation was exactly this. 

    After that, we just realized that PHY was not in Reset state when power-up, due to RESET_N input pulled up on the board. After changing RESET_N input with a pull-down on the board, We have kept the PHY in the reset state at power up. Now is Link & Activity LEDs are not light up when we plugged to cable in case of FPGA is not programmed yet, as expected.  

    But now, after we programmed FPGA and just only released (means drive High) the RESET_IN input of PHY by software, again Link & Activity light up (cable plugged of course). We haven't accessed and configured the PHY from the MDIO interface yet, or any software still doesn't work. We just drive the RESET_IN input high. 

    In order to understand the reason for this traffic when the software is not running yet, we captured the MII interface between PHY and FPGA by adding ILA debug core. Shortly after RESET_IN released (nearly 400 us later), we saw that PHY started driving RX_DV ( receive data valid) high and sending random size of frames to the FPGA. Activity was due to this random size frames. We dont interpret this situation why PHY sending this random data to FPGA on the MII interface, just after releasing the RESET_IN, even if PHY is not configured from MDIO interface yet and any application software is not running yet. Who might be generating this random data? Is it the PHY itself or the other node in the LAN?

    Best Regards,

  • Hi Doner,

    May I ask what application are you trying to perform? A block diagram would help.

    • RX_DV driven high is most likely cost by strapping which is in the datasheet section 5.5.
    • There will be activity between MII communication every time you power up and reset.

    --

    Regards,

    Hillman Lin

  • Hi,

    It is an EtherCAT application. I use DP83640 PHY for EtherCAT Master on my board. We try to communicate with an EtherCAT Slave. Just we add ILA core on the MII interface between PHY & FPGA. And we observed below cases: 

    Please note that, we did not configure the PHY via MDIO. PHY is working as its default power-up configurations. 

    • Master side cable unplugged. After we released RESET_IN input of PHY, we did not see any random data on the RX_Data lines of the MII. 
    • Master side cable plugged, but slave side unplugged. After we released RESET_IN input of PHY, we did not see any random data. 
    • Master side cable plugged and slave side plugged. Master and Slave is connected to each other now. After we released RESET_IN input of PHY (we did not configure the PHY through MDIO, we use PHY as its default power-up settings), we saw some random data on the RX_Data lines of the MII. All data is started with mostly 0x55 (sometimes started with 0x5555) and ended with 0x55 ( and sometimes with not x55). Size is not standard. There are various frames with different sizes. RX_DV is driven high and sometimes later driven low. Not everytime High. 

    What can be the reason of the these random data ? Actually these random data is broken the our EtherCAT line. 

    Best Regards,

  • Hi Doner,

    If possible, could you draw a block diagram for more clarification?

    If my understanding is correct, it seems like there is some signal coming from the slave side of the EtherCAT that DP83640 is picking up the signal. May I ask what is the PHY you are using for the slave side?

    Are you using one master and one slave or daisy chain for your EtherCAT application?

    --

    Thank you,

    Hillman Lin

  • Hi ,

    Please find attached a diagram of setup. 

    I dont know what PHY is used inside the slaves. We have one Master and below Slaves. But note that, we have not started to Master functionality yet. Before it, in order to be sure EtherCAT bus is stable and have a valid physical connection, at first, we send some frames periodically and expect to receive them back the same frames. At the beginning of the test, just after releasing Reset of the PHY, before we send these periodic frames, we just quickly received those random bytes. RX_Data valid line became high before TX_EN. So, we immediately received something after Link established. They are such a random bytes, not even standard Ethernet frames. They have various sizes around sometimes 18 bytes sometimes 200 bytes. 

    Connector is not RJ-45 on the board. It is a board-to-board connector. 

     

    Best Regards

  • Hello,

    I work alongside Hillman. He will be able to continue this discussion starting next week as TI is on Good Friday/Easter Holiday.

    Sincerely,

    Gerome

  • Hello

    We just found the root cause of the problem. It sourced from not terminating the CAT-5 cable shield to board chassis because we dont use a standard RJ-45 connector. So, the problem is resolved after properly terminating the CAT-5 cable shield to board chassis. 

    Thank you

    Best Regards,