• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 310 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.

TMS570LC4357: EMAC gets stuck when fed with small frames at maximum speed

Georg Hermann
Prodigy 10 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

During a test implementation of EMAC on the Hercules Development Kit, some errors occured when the RX data rate was near to the maximum speed.

Especially frames with minimum size at maximum speed bring the µC to stop frame reception completely. After some measurments, I figured out, that this behaviour is caused by the RX ISR which takes longer than there is time until the next frame arrives. For this reason, the µC is running out of buffer and setting the RX Header Descriptor Pointer to zero. As mentioned in the reference manual, the EOQ bit should indicate this. However, in my case, it seems, that sometimes the HDP gets zero without setting the EOQ bit. This results in the ISR not being executed anymore. Why don't we see the EOQ bit?

We partially solved the problem by testing whether the HDP is zero in the EMACReceive function. If the HDP is zero, we set it to the free_head pointer. Thus, the µC can recover after such an overload.

After doing this, a slightly different error occured: We reveice new frames and they trigger the ISR as expected. But for some reason, the OWNER bit is still set in the active_head frame.

My aim is not, to prevent package loss completely as this is impossible, but that the µC can recover from such overloads in every case.

With kind regards

Georg Hermann

  • 0
    TI__Guru 73361 points

    Hi Georg Hermann,

    Thanks for pointing this out.

    Is it possible to share the code along with the test procedure, because i want to reproduce this issue at my end.

    So, i want to know the tools you used and procedure you followed. If possible, share your code as well.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 10 points

    Hi Jagadish,

    Thanks for your quick response.

    You will find my C-code in the source.zip file. The packets were generated with the included Python-script.

    Additionally, I found two potential bugs in HL_emac from HalCoGen.

    1. In the HL_hw_emac_ctrl.h file, the define for EMAC_CTRL_CnRXTHRESHEN(n) should have the value 0x10u instead of 0x20u.
    2. During initialization of the EMAC in HL_emac.c, the EMAC_FREEBUFFER is first set to zero. After that the GMII bit is enabled. A bit later, the EMACNumFreeBufSet function is called to set the number buffer which really are allocated. Unfortunately, because of the GMII bit, the FREEBUFFER register is write-to-increment thus resulting in FREEBUFFER = 0xFF + MAX_RX_PBUF_ALLOC.

    Thanks for your support in advance.

    With kind regards,

    Georg

  • 0
    Prodigy 10 points

    Here a short update of today's situation:

    The first error still persists. So in a million 64B frames that are sent with maximum speed, roughly 3500 times the EOQ flag is not set where it should be set. The workaroud is to directly check the Header Descripto Pointer instead of the EOQ flag.

    The second error was, that sometimes the active_head frame has OWNER bit set and therefore waiting for frame completion. For some reason, the OWNER bit did not get cleared because the EMAC was writing the next frames to the active_head->next pointer. This issue was solved by enabling cache and setting the CPPI region to STRONGLYORDERED_SHARABLE

    A third error occured. Due to OWNER flag was not set in the freed packed buffer descriptor, the host error was triggered. In a million 64B frames with maximum speed, this error occurs roughly 1500 times. The workaround was to check the OWNER flag near the end of the ISR and set it again if not present. Interestingly, the error only occurs in connection with the first error.

    All in all, it looks like there is something wrong with the CPPI RAM.

    Thanks and kind regards

    Georg Hermann