TMS570LC4357: Support Required for Handling RXSOFOVERRUNS and RXDMAOVERRUNS on TMS570LC43x

Part Number: TMS570LC4357

Tool/software:

I am experiencing issues with Ethernet packet transfers on the TMS570LC43x 16/32 RISC Flash Microcontroller. Specifically, during packet transmission, the flow intermittently halts. Upon investigation, I observed the following:

  • The RXSOFOVERRUNS (Receive DMA start of frame overruns register) and RXDMAOVERRUNS (Receive DMA start of frame and middle of frame overruns register) are incrementing during these halts.
  • Further inspection revealed that the head buffer is overflowing, causing these issues.

Request for Support:

  1. Reinitiating Packet Transfers:

    • Is there a recommended procedure to reinitiate the packet transfer once an overrun is detected?
  2. Clearing SOP/EOP Packets:

    • What is the best practice for clearing Start of Packet (SOP) and End of Packet (EOP) once the buffer overflow condition is resolved?
    • Can you provide specific instructions on controlling the relevant registers to manage these overruns?

I have attached the screenshots of registers data . please find them

  • Hi Avesh,

    Apologies for the delayed response.

     The incrementing RXSOFOVERRUNS and RXDMAOVERRUNS registers, along with the head buffer overflowing, seems like indicate that the EMAC (Ethernet Media Access Controller) is running out of available receive buffers to store incoming frames.

    The core problem might be our application is not providing empty receive buffers to the EMAC fast enough, or you receive buffer pool is too small for the incoming traffic rate.

    To "reinitiate" successful packet transfers, you need to address the root cause: ensure a continuous supply of empty receive buffers to the EMAC.

    1. Provide More Empty Buffers: The EMAC uses a linked list of buffer descriptors for reception (as hinted in "32.2.6.1 Packet Buffer Descriptors").
    2. Process Received Packets Quickly: When the EMAC receives a packet and places it into one of your buffers, it marks the corresponding BD as "full" or "received." 

    Best Practice:

    1. Check the Buffer Descriptor Status: When your application's receive handler processes a completed buffer descriptor, it must check the status flags within that descriptor. The documentation indicates an OVERRUN flag will be set in the SOP (Start of Packet) buffer descriptor if an overrun occurred for that frame.
    2. Discard Overrun Packets: If the OVERRUN flag (or any other error flag indicating a corrupted frame) is set, the data in that buffer is invalid. Your application should discard this packet. Do not pass it up the network stack.
    3. Return the Buffer: After discarding the invalid packet, the most important step is to return the buffer (and its descriptor) to the EMAC's free receive descriptor list. This makes the buffer available for a new incoming packet, effectively "clearing" the problematic packet from the system's active memory.

    The "halt" is a symptom of the EMAC running out of buffers. To resolve and prevent this:

    1. Increase your receive buffer pool size if necessary.
    2. Optimize your receive packet processing to quickly return buffers to the EMAC's free list.
    3. Configure RXCEFEN (likely to 0) to have the EMAC automatically filter overrun frames.
    4. Implement robust error checking in your receive handler to check for OVERRUN flags in buffer descriptors (if RXCEFEN is 1) and discard corrupted packets, always returning the buffer.
    5. Monitor RXSOFOVERRUNS and RXDMAOVERRUNS to confirm your changes are effective and clear them periodically for fresh measurements (refer to the full TRM for clearing instructions).

    --
    Thanks & regards,
    Jagadish.

  • Hi,

    As per the suggestion, we have implemented the code; however, we are still encountering issues during packet transmission. A similar ticket has been raised for this issue.

     TMS570LC4357: Ethernet controller (EMAC) and new undocumented race condition on receive 

    Could you please provide a permanent solution to resolve this race condition?

  • Hi Anvesh,

    Apologies for the delayed response, i was off for few days due to personal work.

    We have several tested ethernet examples here in below FAQ:

    I am suggesting you refer them once.

    Is it possible to share your code for testing at my end?

    --
    Thanks & regards,
    Jagadish.