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

DP83822I: PHY receives packets but does not transmit; MII loopback fails

Fiorella UG
Prodigy 70 points
Part Number: DP83822I

Tool/software:

I'm testing the DP83822I on a modular custom board: microcontroller in one board, connected in shield-like style to the custom board were the phy is. On the MAC side, the microcontroller (STM32H723) and its code work as expected. It had already been tested with another phy (microchip LAN8742A).

On the PHY side, the straps are set to operate in RMII Master mode, XI = 25MHz, it correctly generates a 50MHz output. Only Straps to achieve that configuration are set (RX_DV and CRS_DV), the rest are keep on default.

The problem is that after correct link and autonegotiation (100mbps, full duplex), it only receives packets from link partner but does not transmit them correctly. Wireshark shows a packet transmitted with the correct frame length, but wrong data. Other way round it works fine as packets received on microcontroller are the same read by wireshark.

What I've verified:

  • Strap pin configuration is correct according to registers 0x467 and 0x468
  • Link is up and autonegotiation completes 100mbps, full duplex in normal operation
  • Reverse loopback test passes. The PHY correctly echoes the packets send by link partner
  • Analog, Digital, Input and Output loopback tests pass when using the packet generator. If I connect the cable to computer in digital test, the internally generated packets show on wireshark.
  • RMII signals remain the same along the whole trace from microcontroller to PHY in the second board
  • Signals measured on the oscilloscope are near PHY side, so I would say physical connection is not the problem

in MII loopback mode. I have verified the following

  • Autonegotiation is succesful at 100mbps, full duplex
  • The microcontroller sends data to the PHY, and I can see the transmitted signals on the TX0 and TX1 lines.
  • TX_EN works fine
  • TX0 and TX1 waveforms match the bytes send by the microcontroller, and are the same when tested with LAN8742A
  • The PHY apparently loops back the data, since I can see signals on RX0, RX1, and RX_DV using an oscilloscope.
  • However, the RX callback in my microcontroller is not triggered.
  • The same code works when receiving packets from a computer over Ethernet, so the MAC and callback mechanism seem to function correctly in normal operation.

Similarly, in the other near-end loopback modes with MAC generated packets:

  • Autonegotiation and AutoMDIX disabled and forced to 100Mbps full-duplex
  • TX_EN, TX0 and TX1 waveforms seen in oscilloscope
  • The PHY apparently loops back the data, signals on RX0, RX1, and RX_DV seen in oscilloscope.
  • Rx callback is not called, despite same code works with link partner packets.

I suspect the issue might be related to clock or MAC configuration or how it handles packets. What should I check to ensure the MAC correctly processes data on TX pins?

Any insights would be greatly appreciated.

Thanks!

  • 0
    TI__Mastermind 39785 points

    Hello,

    It appears that the PHY may be doing exactly what is expected of it, but the MAC may be having issues interpreting the data. An area of concern I would have would be ensuring that the MAC lines are length matched correctly and that the signals probed at the MAC pin on RX side is obeying the MAC's setup/hold times in conjunction with the VoD.

    Sincerely,

    Gerome

  • +1 in reply to Gerome Cacho
    Prodigy 70 points

    Hello Gerome, thanks for the quick reply.

    It was in fact, a timing issue in TX lines. After comparing them more carefully with the ref_clk signal turns out the setup time was almost nonexistent ... which is rare because somehow it works well with the other PHY which has even a higher setup requirement, that's why I didn't think much of it. Wrong data read by wireshark was consistent with the out of phase sampling.

    Solved the issue by changing drive strength of TX signals from MAC side as pointed out here: Solved: STM32H7 RMII timing - STMicroelectronics Community 

    I still have a related question though, and hope you can help me:

    Before trying from the MAC side, I found the RMII TX Clock shift feature of the PHY. I set bit 8 of register 0x17 and then extended register 0x42 to 0x11. But reading 0x42 again, it showed 0x1 which means the phase shift could not be enabled. I'm not sure if that is the correct way to use it or if that could've helped in this case, but I couldn't find much more information on the datasheet regarding those registers either. Is that feature aimed to work with RMII? if so, how does it work?

  • 0 in reply to Fiorella UG
    TI__Mastermind 39785 points

    Hello,

    It is my understanding that Reg 0x42 is more for MII than RMII. If you need to adjust RMII timings, Reg 0x17[8] would be the recommended way.

    Sincerely,
    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 70 points

    In that case, what should the shift be? What outcome should I expect after enabling it? For RGMII is specified to be 3.5ns, is the same for RMII? 
    I thought 0x42 looked more for MII too, but since I didn't see any changes on my transmission, I thought it could be related to 0x17[8] as well.

  • 0 in reply to Fiorella UG
    TI__Mastermind 39785 points

    Hello,

    Our expectation would be an internal shift of the TX pathway by 4ns. It will not be physically measurable, but the functional standpoint may be impacted.

    Sincerely,
    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 70 points

    Got it. Thank you for your help Gerome. Have a nice weekend!