• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 851 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: Is this a bug in F2838x CM ethernet driver?

Nicholas Langrind
Prodigy 240 points
Part Number: TMS320F28388D

HI,

I am using LWIP on the CM of f28388.

In f2838xif.c:f2838xif_transmit() the transmit descriptors are chained if the input pbuf is a chain.  Descriptors are chained using the nextPacketDesc member.

The nextPacketDesc member is also used to put descriptors on a wait queue in the ethernet driver in ethernet.c:Ethernet_performPushOnPacketQueue().

The TX completion call in f2838xif.c:f2838xif_process_transmit() follows the chain of nextPacketDesc, calling mem_free() for each descriptor.

This causes a problem because when a descriptor is removed from the wait queue and given to the EMAC to send, it could have a non-null nextPacketDesc, which means that when the completion routine is invoked, it will free all the descriptors that were on the wait queue, regardless of whether they were part of the original pbuf chain or not.

Note that this is an issue even if pbufs are never chained. The problem can happen anytime more than one packet is on the TX wait queue.

Can someone please confirm that I have understood this correctly, and that this is indeed a bug?

I think that the issue would be fixed if the routine ethernet.c:Ethernet_removePacketsFromTxQueue() were to arrange to clear the nextPacketDesc member of the last descriptor in the chain as it is enqueing them to the device.

  • 0
    TI__Expert 5240 points

    Hi,

    I see a limitation with the code since it frees up all descriptors till it is null.but did you face any issue with it? What is the kind of application you are using to run?

    As I told in another thread, we did not face this issue with the reference application for HTTP Server. 

    Thanks for the feedback. 

    Regards,

    Sudharsanan

  • 0 in reply to Sudharsanan
    Prodigy 240 points

    Hi Sudharsanan,

    I did not face any issue with it, I just noticed it while debugging other things.

    My application is telnet and ECAT Slave (CoE & FoE) on the 28388 CM. I am changing the way the example code works, in order to move LWIP processing out of the ISR and into a polling mainloop. I have no RTOS, so LWIP is built with NO_SYS. My polling loop calls Ethernet_transmitISR() and Ethernet_receiveISR() directly, and the ethernet interrupts are never enabled.

    My application seems to work pretty well now *without* me changing f2838xif_process_transmit() or the use of nextPacketDesc. I am almost 100% sure that my test cases won't use the wait queue, and even if they did, it would probably be OK because no other code is calling mem_malloc().

    Thank you for taking the time to analyze and answer.

    Regards,

    Nik

  • 0 in reply to Nicholas Langrind
    TI__Expert 5240 points

    Hi Nik,

    Thanks for the details of your application. 

    Nicholas Langrind said:
    I am almost 100% sure that my test cases won't use the wait queue, an

    But by design all the incoming packets to the driver are put in wait queue and then added to hardware queue. You may not end up having multiple items in wait queue.

    Regards,

    Sudharsanan