• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 691 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: lwip stack causes watchdog timeout/stack clarification

ms120
Prodigy 240 points

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN,

This for TMS570LS3137 using HALCoGen generated code and lwip 1.4.1 example code.

I've had an issue when using the lwip stack in the provided example code. Everything works as intended 99% of the time. When receiving multiple packets in quick succession (on the order of 10-20 within a few mS), it will cause the stack to get stuck. It sounds like this issue. The buffer descriptor points in the linked list in the rx interrupt handler gets corrupt showing a nonsensical packet length. I tried to increase my buffers to a large number, 30. This seems to resolve the interrupt being stuck/corrupted link list, however I have a system watchdog which times out. The amount of time spent processing all of those packets is too much. I have some questions towards finding a resolution:

1. The provided lwip documentation mentions that the stack uses DMA in the CPPI RAM for the buffer descriptors. I don't see where this actually occurs in the code. There is no init for the DMA called anywhere. In addition, there a bunch of functions in emac.c which relate to init, and rx/tx interrupts but none of them are used. It seems a parallel set of functions was created in hdkif, and I'm not sure why... It seems like these functions may be more comprehensive then the ones provide in the hdkif file. The emac.c function also does an init call for the DMA. Is the hdkif provided in the example code actually using DMA? Why are the functions in emac.c not used? should they be?

2. I tried to enable RX pacing to help with the watchdog timeout. I was hoping it would stagger the interrupts a bit more to allow the watchdog to be kicked. When trying to enable this via INTCONTROL and the C0RXPACEEN, I ended up making the rx/tx break in lwip. Is there a specific way to enable that?

3. I have considered having the RX poll, which was mentioned here. I have tried that in the past and it did not work correctly. Is all that is required is to disable the RX interrupt and poll as mentioned? 

I have modified the watchdog to trigger the ESM and I've checked the stack when that is triggered and it's either in the rx handler or one of my lwip callbacks. Is there something else I might be missing? Is there a more methodical way to debug why the hdkif rx linked list gets corrupt? I've noticed that I can reproduce it if I send 10 packets, wait a second, and then send another 10 packets. The second 10 packets is always what causes the watchdog timeout, not the first 10.   

  • 0
    TI__Guru**** 199216 points

    Hi MS120,

    I am not sure if the issue is related to the so-called "race condition" mentioned in 29.2.6.2 of 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."

    Our lwip example code doesn't implement this workaround.