• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1255 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.

RM57 EMAC loses RX frames

Christian Herget
Expert 6985 points


Hi,

A customer reported issues with the EMAC module on RM57. They like to upgrade their current system from RM48 to RM57 for this they simply produced new boards with RM57 on them instead. Now they started to see that they lose some packets, they reported a packet loss of 5-50% depending on the board with identical SW. The Ethernet driver is the same between RM48 and RM57.

The packet statistics showed that the amount of lost packets equals the amount of CRC errors:

So the questions are:

  • Are there any differences between RM48 and RM57 that could cause this issue?
  • When does the EMAC performs the CRC check before, or after the frame was copied into the RAM?
  • How is the EMAC clocked for receiving frames is the 50MHz clock generated by the MCU or the PHY (DP83848, RMII)?

Any other ideas what could go wrong in this setup?

Thanks,
Christian

  • 0
    TI__Guru 68930 points
    Christian,

    The EMAC is exactly the same between the two devices I don't see how this would relate to the MCU itself.

    Is the PHY & Board the same? Are they seeing this packet loss using our kits? If they are comparing say an HDK vs. a LaunchPad the phy is different and the PCB is different so could be something related to that.

    I'm not sure where the CRC is checked so need to look this up. But the clocking really depends on the board.
    And it can be sourced either by the MCU or by the PHY just depends.. If you look at the TI phy's there's a bit to set whether the RMII clock is master or slave...
  • 0 in reply to Anthony F. Seely
    TI__Expert 6985 points
    Anthony,

    They are using their own boards with the DP83848 on it, the boards are the same between RM48 and RM57.
    However, you might be right that there is something wrong with the clocking of the PHY or EMAC, we wil double check that.

    Thanks,
    Christian
  • 0 in reply to Christian Herget
    TI__Guru 68930 points
    Christian,

    Like your new photo!

    So I think we should check the phy as well. Could be a layout issue. Hard to tell.
    But if it's CRC errors causing the packet loss then it seems like the problem would be upstream from the MCU.. like either
    on the RMII interface (clocking or timing problem) or somewhere in the phy...

    -Anthony
  • 0 in reply to Anthony F. Seely
    TI__Guru 68930 points
    This thread e2e.ti.com/.../1936370 reminded me of something.

    The phy has some (large) amount of time it requires between coming out of powerup or reset and the first time you start accessing it through the MDIO interface.

    This timing might be perturbed with a different board (as the phy might be relased from reset differently) so something you might also want to check...
  • 0 in reply to Anthony F. Seely
    TI__Expert 6985 points

    Hi Anthony,

    They did some more tests including enabling the RXCEFEN (Receive copy error frames enable bit) mode, where the EMAC also copies corrupted frames (CRC mismatch) into the RAM buffer. From this they saw that several bits in different bytes in the corrupted frames are flipped. Any idea what could be the reason for this? As said the setup is the same between RM48 and RM57, the RM57 boards are even the same as for RM48 just with the devices swapped. Can this be a timing issue in the sense that RM57 is more sensitive than RM48?

    Thanks,
    Christian

  • 0 in reply to Christian Herget
    TI__Guru 68930 points
    No idea what this might be. Doubt it is any sort of timing problem.

    Is this a setup you can ship up and send here?
  • 0 in reply to Anthony F. Seely
    TI__Guru 68930 points
    Christian,

    Any inputs as to whether this issue can be isolated to the Mac or Phy?

    I think it's bad to presume the issue is in the MAC just because the MCU is the component that changed.

    For example the move to a higher frequency MCU could be coupling back to the phy analog through the power supply or other path on the board, unrelated to the MAC and causing a signal reception problem. Doesn't mean there is some digital issue inside the MAC.

    I would suggest trying :
    a) create a trigger when the corrupted packet occurs, as close to detection of this problem as possible in time (like toggle a GIO)
    b) use this GIO to trigger a logic analyzer capture of the MII interface pins.
    c) inspect the packet on the MII interface as it is passed from the Phy to the MAC

    If (c) shows that the packet is actually coming in w. a corrupt CRC already on the MII wires then there's not much point in worrying about the MAC.. it's time to look upstream.

    Make sense?