• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 470 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.

TMS570LS3137: emac.c tx interrupt got stuck

Karl Tsai
Prodigy 220 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Hi there,

I am building my network interface code around the HalCoGen generated emac driver and have found the TX interrupt may get stuck with txchptr.next_bd_to_process pointing to an empty entry and interrupt kept going non-stop.

This usually happens in the first transmit with larger packet size. From my experience if it get passed the first 10 it won't happen.

Has this problem been addressed with new HalCoGen code or?

Karl Tsai

  • 0
    TI__Guru**** 197186 points
    Hi Karl,

    What packet size can cause the problem? What is your recommendation for the workaround to the EMAC driver generated through the HALCoGen? Thanks Karl for pointing this out, and appreciate your suggestion.
  • 0 in reply to QJ Wang
    Prodigy 220 points
    Hi QJ Wang,
    I've seen 10 pings at 1s interval with 1400B packet size does it and I'm not sure what causes it.

    Karl Tsai
  • 0 in reply to Karl Tsai
    Prodigy 220 points

    Hi,

    Just found out my test run failed after sending 800 1400B packets and for the exact same reason.

    There goes my theory.

    Karl Tsai

  • 0 in reply to Karl Tsai
    TI__Guru**** 197186 points
    Hello Karl,

    Do you see the issue with smaller packet size (<1400B)? The protocol supports packet larger than 1400B. I am not sure if this issue is related to the "potential race condition" issue listed in TRM.

    "There is a potential race condition where the EMAC may read the “next” pointer of a descriptor as NULL in the instant before an application appends additional descriptors to the list by patching the pointer. This case is handled by the software application always examining the buffer descriptor flags of all EOP packets, looking for a special flag called end of queue (EOQ). The EOQ flag is set by the EMAC on the last descriptor of a packet when the descriptor’s “next” pointer is NULL. This is the way the EMAC indicates to the software application that it believes it has reached the end of the list. When the software application sees the EOQ flag set, the application may at that time submit the new list, or the portion of the appended list that was missed by writing the new list pointer to the same HDP that started the process."
  • 0 in reply to QJ Wang
    Prodigy 220 points

    Hi QJ Wang,

    I don't believe it is the case. The generated emac driver is endowed with lots of TX descriptors and most failures I've seen happens less than 20 frames into transmission. I.e.: the end of queue is far away.

    One thing I've learned is that the LWIP implementation doesn't rely on the generated emac driver and is acknowledging both EMAC_INT_CORE0_TX and EMAC_INT_CORE0_RX in either TX or RX ISR. Kind of interesting approach and I'm not sure if that could solve it.

    Thanks,

    Karl Tsai

    0675.hdkif.c

  • 0 in reply to Karl Tsai
    TI__Guru**** 197186 points
    Thanks Karl

    I will ask SW team to investigate.