• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 817 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: Problem appending to TX descriptor list

Tom Pruitt
Prodigy 250 points
Part Number: TMS570LS3137

I am trying to append to a TX descriptor list while a descriptor list is being processed.  After the additional information is ready, the starting location of the new information is added to the executing list.  Following the update to point to the new information, the previous information is evaluated for EOQ to know if the state machine is still executing. 

Using Code Composer memory browser, I have debug information showing the descriptor list is what was expected except for status which is addressed later,  This includes the initial information with the updated pointer to the appended information, along with the appended information.  It also shows the variable holding the contents of the EOQ value is not set which indicates the state machine is still running so the appended part of the list should be processed.  

However, there are several indications the appended portion of the list is not processed. 1) External Wireshark trace does not see appended packet information.  2) The Memory browser shows the initial list EOQ bit is set and 3) the appended list owner bit indicates the list has not been processed.  I assume the reason the EOQ bit is set in the memory browser window versus it not being set in the variable mentioned earlier is the state machine continued running to the point of finally updating the EOQ bit before the memory browser information was pulled from the system.

Chapter 29 of the TRM indicates the process of appending to this list to ensure the race condition between the state machine execution and software appending to the list is handled correctly.  This process has been followed but is not working.  I have seen a few other posts regarding this issue on other devices but I did not find a post that documented a resolution to the problem.

Please advise on ability to append to an executing TX descriptor list and if a workaround is available. Our intent is to not use interrupts for Ethernet handling and to not have to wait for the EOQ condition before adding a new descriptor.

Thanks,

Tom

  • 0
    TI__Guru**** 196566 points
    Hi Tom,

    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.

    This process applies when adding packets to a transmit list, and empty buffers to a receive list.

    How can I modify the demo to produce the problem?
  • 0 in reply to QJ Wang
    Prodigy 250 points

    Hi QJ,

     

    I am not using the lwip demo program. What I have is much simpler. I am developing a low level driver for handling the descriptor list and writing to the pointer register.  I can provide an archive of my project that duplicates the issue.  I am using the Hercules Safety MCU Development Kit, TMS570 MCU.  Let me know if that would work for you.

     

     

    This is the TX descriptor data after updating the descriptor list with the first packets infomation, but before writing to the pointer register with value 0xFC520010.

    Tx_status is the contents at 0xFC52000C which was read just before the breakpoint used to collect this data. This location is initialized to this value so the driver sees an EOQ condition. This EOQ condition is used by the driver to determine a write of the pointer register is needed to start the state machine.

     

     

     

    This is the TX descriptor data after updating the descriptor list with the second packets information.

    TX status was read from the previous EOP location at 0xFC52003C just prior to the breakpoint. It indicates a non-EOQ status so the pointer register is not updated since it is expected the appended portion of the list will be executed.

    By the time the memory browser is updated after hitting the breakpoint, the EOQ status at 0xFC52003C has been updated, but you can see the second packet SOP location at 0xFC52004C and EOP location at 0xFC52006C are not updated. This indicates the appended part of the list (the second packet) was not processed even though the previous EOP (tx_status) indicated a non-EOQ condition at the time the list was appended.  This is confirmed by not seeing the second packet in a Wireshark trace.  It appears the EOQ status suffers from the same race condition that it is meant to overcome.

     

     

     

    Thanks,

     

    Tom

  • 0 in reply to Tom Pruitt
    Prodigy 250 points

    Wow, looks like pasting from word dropped the screens6443.Hi QJ.docxhots from my previous post.  I have attached the previous post with the two screenshots here.