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.

RTOS/TMS570LS3137: EMAC does not work when ethernet packets are received at high rate

Part Number: TMS570LS3137
Other Parts Discussed in Thread: TMS570LC4357

Tool/software: TI-RTOS

Hello,

I am working on TMS570LS3137. I am currently trying to integrate FreeRTOS v9.0.0 and lwIP v2.1.0.

I can successfully send UDP (SNMP) packets from my PC to TMS570 and get answers at 1.3 mbps. Above this speed, response rate gradually decreases as I increase the sending rate. When I send packets at above 12 mbps, there is no answer at all. The problem is, even after I stop sending SNMP packets, I cannot ping the device anymore. The device functions properly, but does not get into EMACRxIntISR().

I use lwIP contrib 2.1.0 freeRTOS port. Here is how I process the packets:

  • I use notification in EMACRxIntISR() to wake my ethernet task.
  • In ethernet task, I send the packets to message box of lwIP (a queue).
  • Packets are processed in tcpip_thread() task of lwIP. 

Here is my deductions:

  • Nothing to do with SNMP. Custom UDP Packets also fails the device.
  • If I don't use hdkif_input() function in EMACReceive() during the high speed transfer, there is no problem. After stopping sending at high bit rate, I reenable hdkif_input() and can succesfully send ping.

What could be the problem at very high speeds? Any help?

Regards

Marry Jane

  • Hi Ercan,

    Did you test it without freeRTOS? I tested LWIP 1.4.1 TCP/IP at 10mbps and 50mbps before, it works fine.
  • Hi Wang,

    Yes, I tested it without FreeRTOS. It still get interrupts but after I stop sending packets, it gets stuck in TX Interrupt.

    By the way, I found out that the problem occurs in low_level_input(). This function simply allocates a pbuf with padding (due to memory alignment issue) and fills its payload. I call that function in the ethernet input task because memory allocation has something to do with semaphores I guess. I don't remember the exact reason but as far as I remember, pbuf_alloc() should not be used in an ISR when used with tcpip_thread().

    Regards
    Marry Jane

  • Hi QJ,

    After lots of hours, I finally managed to solve the problem using the patch in:

    e2e.ti.com/.../678879

    I hope TI solves this problem as fast as possible.

    Regards,
    Mary Jane
  • Don't hope, that solution from TI will be fast. I am waiting for confirmation of this problem from TI side two years! 
    It looks like synchronization problem between EMAC and CPU access. Problem is that MCU can read EOQ=0 when EMAC read NULL from next pointer already. Definitely. 
    Referenced patch works (I am author of this) but we are not able to close this problem without errata from TI side (reason, conditions, workaround etc.)

    I'am notice few customers with same problem on different TI cores (TMS570LS3137, TMS570LC4357, and some others) and there isn't any reaction from TI side.

  • Hi Jiri,

    I don't know how to thank you for the solution patch. That was really helpful for us.

    You are right, the problem is not actually resolved until TI does necessary changes.

    Thanks again,
    Mary Jane
  • Hi Mary Jane,

    Apologies for the bug in the EMAC driver. We will push our SW team to fix the problem. Thanks.