TMDS64EVM: MCU PLUS SDK8.6.0.45 seems to drop except for the first one in consecutive Rx packets

Hi Hideomi,

Thanks for your query.

Can you help me to reproduce the issue with bare minimum variable (like removing dependency on EtherCAT) ? 

Can you try with simple test case involving only Rx/Tx frame on ICSSG1-P1 and update the results ?

Meanwhile, I will also check this internally and get back to you.

Best Regards

Ashwani

Hi Ashwani,

I chose EtherCAT as my experimental platform for two reasons.

• Not rely on IP protocol libraries (LWIP library etc.)
• Simple as Ethernet opposing machine (any ethercat slave device)

But I also agree with your suggestion.

--- enet_layer2_icssg.c	2023-06-13 16:12:23.000000000 +0900
+++ enet_layer2_icssg.c	2023-06-23 18:48:28.193545600 +0900
@@ -1593,6 +1593,93 @@
         }
     }
 
+/*************************************************************************************************/
+    uint8_t S_abyFrameData[61] =
+    {
+       0xff, 0xff, 0xff, 0xff, 0xff, 0xff,   /* Dest Mac */                            /*0-5*/
+       0x00, 0x00, 0xcc, 0xf0, 0x30, 0x54,   /* Src Mac */                             /*6-11*/
+       0x88, 0xa4,                           /* Type ECAT */                           /*12-13*/
+       0x2d, 0x10,                           /* E88A4 Length 0x0e, Type ECAT (0x1) */  /*14-15*/
+       0x01,                                 /* APRD */                                /*16*/
+       0xe0,                                 /* Index */                               /*17*/
+       0x00, 0x00,                           /* Slave Address */                       /*18-19*/
+       0x00, 0x00,                           /* Offset Address */                      /*20-21*/
+       0x14, 0x80,                           /* Length - Last sub command */           /*22-23*/
+       0x00, 0x00,                           /* Interrupt */                           /*24-25*/
+       0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+       0x00, 0x00,                           /* WKC */
+       0x07,0x00,0x00,0x00,0x30,0x01,0x01, 0x00,0x00,0x00,0x00, /* Data 2 */           /*28-*/
+       0x00, 0x00                            /* Working Counter */                     /*59-60*/
+    };
+    /**********************/
+    /* TRANSMIT FIRST ONE */
+    /**********************/
+    EnetQueue_initQ(&txSubmitQ);
+
+    /* Retrieve TX packets from driver and recycle them */
+    EnetMp_retrieveFreeTxPkts(perCtxt);
+
+    /* Dequeue one free TX Eth packet */
+    txPktInfo = (EnetDma_Pkt *)EnetQueue_deq(&gEnetMp.txFreePktInfoQ);
+    if (txPktInfo != NULL)
+    {
+        /* Fill the TX Eth frame with test content */
+        memcpy(txPktInfo->sgList.list[0].bufPtr, &S_abyFrameData, sizeof(S_abyFrameData));
+        txFrame = (EthFrame *)txPktInfo->sgList.list[0].bufPtr;
+        txPktInfo->sgList.list[0].segmentFilledLen = sizeof(S_abyFrameData);
+        txPktInfo->appPriv = &gEnetMp;
+
+        /* Set timestamp info in DMA packet.
+         * Packet timestamp currently enabled only for ICSSG. */
+        if (gEnetMp.enableTs &&
+            Enet_isIcssFamily(perCtxt->enetType))
+        {
+            /* Save the timestamp of received packet that we are about to send back,
+             * so we can calculate the RX-to-TX time diffence in TX timestamp callback */
+            txPktInfo->tsInfo.enableHostTxTs = true;
+            txPktInfo->tsInfo.txPktSeqId     = perCtxt->txTsSeqId++;
+            txPktInfo->tsInfo.txPktMsgType   = 0U; /* Don't care for ICSSG */
+            txPktInfo->tsInfo.txPktDomain    = 0U; /* Don't care for ICSSG */
+            reqTs++;
+        }
+        else
+        {
+            txPktInfo->tsInfo.enableHostTxTs = false;
+        }
+
+        EnetDma_checkPktState(&txPktInfo->pktState,
+                              ENET_PKTSTATE_MODULE_APP,
+                              ENET_PKTSTATE_APP_WITH_FREEQ,
+                              ENET_PKTSTATE_APP_WITH_DRIVER);
+
+        /* Enqueue the packet for later transmission */
+        EnetQueue_enq(&txSubmitQ, &txPktInfo->node);
+    }
+    else
+    {
+        EnetAppUtils_print("%s: Drop due to TX pkt not available\r\n", perCtxt->name);
+    }
+
+    /* Transmit all enqueued packets */
+    status = EnetDma_submitTxPktQ(perCtxt->hTxCh[0], &txSubmitQ);
+    if (status != ENET_SOK)
+    {
+        EnetAppUtils_print("%s: Failed to submit TX pkt queue: %d\r\n", perCtxt->name, status);
+    }
+
+    /* Wait for TX timestamp */
+    while (gEnetMp.run && (reqTs != 0U))
+    {
+        Enet_MacPort macPort = perCtxt->macPort[0];
+
+        Enet_poll(perCtxt->handleInfo.hEnet, ENET_EVT_TIMESTAMP_TX, &macPort, sizeof(macPort));
+        semStatus = SemaphoreP_pend(&perCtxt->txTsSemObj, 1U);
+        if (semStatus == SystemP_SUCCESS)
+        {
+            continue;
+        }
+    }
+/*************************************************************************************************/
 
     while ((ENET_SOK == status) && (gEnetMp.run))
     {

Setup: one Ethernet cable looping ICSSG port 1 to port 2 on the EVM. (not need any slave)

I added some simple code that transmits a single packet on the 1st port when enet_layer2_icssg starts. Since it echoes back all received packets, the first transmit kicks off a continuous stream of packets that are echoed back and forth between the ICSSG ports.

Certainly in SDK 8.5.0.24 environment that's right, but in SDK 8.6.0.45(8.6.0.43) environment that immediately stops and fails. I guess because it drops continuous Rx packets in 8.6.0.45 environment.
(Although 8.5.0.24 experiment shows many "Drop due to TX pkt not available" message, its continuous stream does not stop .)

Regards,

hideomi

Thanks Hideomi for updates,

What I am planning to try is below.

1. External Packet generator will Tx frames (Let's say 1000 count).
2. Then check stats on ICSSG-Port1 and Port2.
3. It should be  equal to 1000.
4. With SDK 8.5.0.24
   1. It should PASS
5. With SDK 8.6.0.45
   1. It should immediately stop and fail

Is it similar to (bare minimal) what you are trying or let me know your inputs ?

Best Regards

Ashwani

Hi Ashwani,

I think very interesting experiment that you have proposed also. And I also would be trying it.

I would be concerned that it difficult performace to test two ports at the same time. Therefor let's be testing one by one.

Thanks and regards,

hideomi

Hideomi Hanaoka said:

I would be concerned that it difficult performace to test two ports at the same time. Therefor let's be testing one by one.

Thanks Hideomi for update,

I will make setup and perform test one port at a time.

Please allow me some time (1-2 days) for this activity and get back to you.

Best Regards

Ashwani

Hi Ashwani,

I did the experiment using Corasoft Packet Builder as external generator. Here are the results:

• Compared sdk versions:  08.06.00.45  enet_layer2_icssg_am64x-evm_8_6_0_45.zip  08.05.00.24  enet_layer2_icssg_am64x-evm_8_5_0_24.zip

• Target:  TMDS64GPM    Icssg1-p1
• Packet Generator:  Corasoft Packet Generator  Version 2.0  (Build 215)

Packet Data:  2248.Packets.zip

Packet send:  

As Result:    sdk 8.6.0.45 did not stop but received packets were less than 1000. (389)

Here I noticed an interesting fact.

If patch enet_layer2_icssg.c as follow:

--- enet_layer2_icssg.c	2023-06-27 14:43:39.646007200 +0900
+++ enet_layer2_icssg.c	2023-06-27 14:26:12.806973600 +0900
@@ -1679,7 +1679,7 @@
 
     while ((ENET_SOK == status) && (gEnetMp.run))
     {
-#if 1
+#if 0
         /* Wait for 1 milli-sec */
         ClockP_usleep(1000);
 #else

 receive packets became 1000. 

This fact seems to indicate that the receiving behavior depends on design my application, weither sleep or semaphore wait.

I may need a little more time to investigate this fact carefully.

Thanks and regards,

hideomi

Thanks Hideomi for updating.

Best Regards

Ashwani