TMS570LS3137: Problem appending to TX descriptor list

Umm... am I expected to copy the previous post's information here, or could you simply respond to it here?

Hi Tom,

Can you please try the code used in lwip demo? The file is attached2526.emac.c

 /* For the first time, write the HDP with the filled bd */

 if(txch->active_tail == NULL) {

   /*SAFETYMCUSW 439 S MR:11.3 <APPROVED> "Address stored in pointer is passed as as an int parameter. - Advisory as per MISRA" */

   /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */      

   EMACTxHdrDescPtrWrite(hdkif->emac_base, (uint32)(active_head), (uint32)EMAC_CHANNELNUMBER);

 }

 /*

  * Chain the bd's. If the DMA engine, already reached the end of the chain,

  * the EOQ will be set. In that case, the HDP shall be written again.

  */

 else {

   /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */  

   curr_bd = txch->active_tail;

   /* Wait for the EOQ bit is set */

   /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */

   /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

   /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */  

   while (EMAC_BUF_DESC_EOQ != (EMACSwizzleData(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ))

   {

   }

   /* Don't write to TXHDP0 until it turns to zero */

   /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */

   /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

   while (((uint32)0U != *((uint32 *)0xFCF78600U)))

   {

   }

   /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */  

   curr_bd->next = (emac_tx_bd_t *)EMACSwizzleData((uint32)active_head);

   /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

   /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */      

   if (EMAC_BUF_DESC_EOQ == (EMACSwizzleData(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ)) {

     /* Write the Header Descriptor Pointer and start DMA */

     /*SAFETYMCUSW 439 S MR:11.3 <APPROVED> "Address stored in pointer is passed as as an int parameter. - Advisory as per MISRA" */

     /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */          

     EMACTxHdrDescPtrWrite(hdkif->emac_base, (uint32)(active_head), (uint32)EMAC_CHANNELNUMBER);

   }

 }

Hi QJ Wang,

I am confused by your response since I am not asking you to do any kind of test.

I have the following questions which are still unanswered:

Why is the sample code you provided waiting for TX0HDP to be 0? The TRM does not mention the need to do this so I would like to understand this.

Can I append to a tx descriptor list? And if so, how? The TRM says it is possible but I have been unable to reliably do this. The provided sample code waits for any previous transmission(s) to complete, so it is not appending to a list.

Thanks,

Tom

Hi Tom,

Yes, you can append a new TX descriptor to the existing list. This new descriptor must be NULL terminated. 

If the next descriptor pointer is zero, the current buffer is the last buffer in the queue. The SW application must set this value prior to adding the descriptor to the active transmit list.

The value of pNext should never be altered once the descriptor is in an active transmit queue, unless its current value is NULL. If the pNext pointer is initially NULL, and more packets need to be queued for transmit, the software application may alter this pointer to point to a newly appended descriptor.

The EMAC will use the new pointer value and proceed to the next descriptor unless the pNext value has already been read. The software can detect this case by checking for an end of queue (EOQ) condition flag. When EOQ is detected, the application may submit a new list (TX0HDP=0).

To be honest, I didn't test the feature of appending a new descriptor to the linked list.

Hi Tom,

I did a test with EMAC loopback. A packet is appended to an existing packet, and the appended packet is transferred successfully. Attached is my test project (CCS).

The received packet is located 0x08001500 (existing packet), and 0x08001AEA (appended).

The existing packet: total length is 470, each buffer is 94 bytes.

The appended packet: total length is 470, each buffer is 94 bytes. But the payload is different.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/5657.TMS570LS3137_5F00_EMAC_5F00_LPBK_5F00_PacketAppend.7z

Hi QJ,

The idea of appending to a list is to allow software to add messages to the EMAC without stalling the software.  Therefore, appending to a list consists of two parts.  The first part is adding the new packet to the buffer descriptor list.  You have pointed me to that part.  The second part is updating the Header Descriptor pointer IF NECESSARY.  The IF NECESSARY is important to the idea of not stalling the software.  If software is required to wait/stall for the current list to complete, then the added packet is simply a new packet, not an appended packet.

If you look just a few lines down at line 1517, you can see that line is stalling software until the current list completes.  Per the TRM this is not required so why is this line there?  Looking just a few more lines down at line 1530, the code checks to see if the hardware is still processing a list.  This is per the TRM to ensure the hardware is still running after the added packet data has been added to the list.  The idea here is if the hardware has completed the existing list, then the hardware needs to be restarted to process the new data.  If the hardware is still running, then the added data should be processed when the hardware gets to that point in the list.

I have copied the lines of code in question below.  The lines in question have been highlighted in green, while my questions and comments are in red.

/*
* Chain the bd's. If the DMA engine, already reached the end of the chain,
* the EOQ will be set. In that case, the HDP shall be written again.
*/
else {
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */
curr_bd = txch->active_tail;
/* Wait for the EOQ bit is set */
/*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */

why is this here?  This is not mentioned by the TRM.

while (EMAC_BUF_DESC_EOQ != (curr_bd->flags_pktlen & EMAC_BUF_DESC_EOQ))

{
}
/* Don't write to TXHDP0 until it turns to zero */
/*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

why is this here? This is not mentioned in the TRM.

while (((uint32)0U != *((uint32 *)0xFCF78600U)))
{
}
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */
curr_bd->next = active_head;
/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */

This check is mentioned in the TRM, but it will always be true because of the code above which I am asking about.

if (EMAC_BUF_DESC_EOQ == (curr_bd->flags_pktlen & EMAC_BUF_DESC_EOQ)) {
/* Write the Header Descriptor Pointer and start DMA */
/*SAFETYMCUSW 439 S MR:11.3 <APPROVED> "Address stored in pointer is passed as as an int parameter. - Advisory as per MISRA" */
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */
EMACTxHdrDescPtrWrite(hdkif->emac_base, (uint32)(active_head), (uint32)EMAC_CHANNELNUMBER);

Regards,

Tom

Hi QJ,

The first packet is too small to create my problem.  Please increase the size of the first packet to max packet size.  I have not had time to understand your entire test case, but I was able to verify it is not hitting my condition.

Thanks,

Tom

Hi QJ,

Since we are not getting consistent results and I do not want the EMAC to be interrupt driven, I prefer not spending more time looking at this code.

I am interested in the results of the code I sent you that is not interrupt driven.  I had heard from your digital FAE that you had duplicated the issue I am seeing using this code.  Since we seem to have consistent results with this code and it is what I am trying to use, I would prefer to determine why there is an issue with this code. BTW, this code works fine if I simply add the same type of stalling while loop your code has.  Can you please review the code file and comment?

Thanks,

Tom

Hi QJ,

I connect the HDK Enet to my PC so I can use wireshark to look at what is sent.  The following is pasted from a previous email to the FAE but there is an image that is not coming through.  I will attempt to attach it.

To generate and see the problem, do the following. 

1. Put a breakpoint at sys_main.c line 88.
2. Put a breakpoint at urdc_enet.c line 312.
3. Load and run/resume the program.  We are using the tms570ls3137 hdk.
4. When it breaks at sys_main(88), modify variable i to 900 decimal. 
5. Run/resume the program
6. When it breaks at urdc_enet(312), you can see the following:
   1. Variable tx_status is 0x40000000 which indicates there is no EOQ.
   2. Use memory browser to look at descriptors at 0xFC520200.  Address 0xFC52022C has value 0x50000000.  This is the same address read to obtain 0x40000000 value at step 6.a.
   3. Wireshark trace only shows the first of the two packets has been sent.

 Some notes/observations/interpretations:

• FYI, The code initializes the flag_pktlen words of the descriptor list to 0x50000000.  Only addresses 0xfc520210 – 0xfc52024f are used when the test case fails.
• The values at 6.a and 6.b are different.  This is a temporal thing.  The descriptors shown in the memory browser are grabbed after the breakpoint.  By this time, the EMAC has indicated an EOQ.
• The second packet appended from 0xfc520230 – 0xfc52024C should have been transmitted since tx_status did not show an EOQ.
• The descriptors at 0xfc52022c and 0xfc52024c and a wireshark trace indicate the second packet did not get sent.
• If you do not set the first breakpoint at main(88), two packets will repeatedly get sent.  In this case, the first packet is short enough the EOQ is set before the second packets information has completely been added to the descriptor list. This is evident since the breakpoint at urdc_enet.c(312) is never hit.  Since the two packets are repeatedly sent, it would also indicate the logic setting the descriptors is good.

 Thanks,

Tom

Hi QJ,

Just curious what the status on this is.

Thanks,

Tom

Hi QJ,

Please provide status on this issue.

Thanks,

Tom

It has now been six months since my initial post on this issue and a month since your last response on this post.  Can I get some status on this?

Now six weeks since (8/10) I was told by TI a test case would be run. Another week with total silence. Amazing. Not even a reply to repeated attempts for status both in the forum and in emails.