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.

MCU-PLUS-SDK-AM243X: Impact on CPU due to continuous EnetDma_submitTxPktQ operations

Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: AM2432

Tool/software:

Hello,

I am working with [enet_layer2_icssg] which I modified for EtherCAT communication experiments.

The Tx Task runs with an interrupt every 500μs, and a frame of about 1300Bytes is sent to the slave periodically each time.

There are no problems with sending and receiving frames, but I found that a delay of about 2s occurs about every 16s.
The measurement was done using the ECAP module from the 500μs interrupt to measure the time when the frame was actually sent from the PHY.
As a result, although it usually takes about 70μs to send, a delay of 90~120μs occurs about 2s every 16s.

For debugging purposes, I stopped using "EnetDma_submitTxPktQ(perCtxt->hTxCh[0], &txSubmitQ);" and set the send task to only create frames and not send them, so naturally there is no delay.
For this reason, I think that if EnetDma_submitTxPktQ is continued to be used, some process such as memory refresh will be performed,
consuming CPU resources and causing high load.

What is the cause of this delay?

SDK mcu_plus_sdk_am243x_11_00_00_15
Board used AM243xEVM / Custom Board (AM2432)
Board has one ICSSG port connected to the slave and the other is disconnected

Code (partially omitted)

		// tx EtherFrame 
		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 */
                     txFrame = (EthFrame *)txPktInfo->sgList.list[0].bufPtr;

			// EtherNet hdr setting
			pre_fill_ecat_frame(txFrame);
			// EtherCat data setting
			fill_ecat_frame(txFrame);

                        txPktInfo->sgList.list[0].segmentFilledLen = 1300;
			txLen = txPktInfo->sgList.list[0].segmentFilledLen;
                        txPktInfo->sgList.numScatterSegments = 1;
                        txPktInfo->chkSumInfo = 0U;
                        txPktInfo->appPriv = &gEnetMp;

                        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);

                	status = EnetDma_submitTxPktQ(perCtxt->hTxCh[0], &txSubmitQ);

  • 15	// EtherCat data setting
    16	fill_ecat_frame(txFrame);

    This function creates the frame to be sent.
    In order to send data received from another module on a frame, this function disables the cache once,
    fetches the data from memory, and then enables the cache again.

    CacheP_disable(CacheP_TYPE_ALLD);

    CacheP_enable(CacheP_TYPE_ALLD);

    is used, but commenting them out eliminated the large delays.

    I don't know if this function is the cause, but shouldn't I be using it?

    CacheP_inv((void *)Address ,0x600, CacheP_TYPE_ALLD);

    CacheP_wb((void *)Address ,0x600, CacheP_TYPE_ALLD);

    Should I be using this function?

  • Hi,

    I've assigned the thread to the corresponding owner for further support. Feel free to ping here if you don't get a reply by tomorrow.

    Regards,
    Aaron

  • Hi Kazushige,

    Disabling cache operations during runtime is not a suggested call just to retrieve a small segment of memory. Instead, to retrieve the latest data from another module, it is preferable to use writeback and invalidate calls.

    But I don't see a reason why it would cause an additional latency of 120 us for a prolonged 2 seconds periodically. Let me check internally if we can reproduce it internally, or review places which could cause such issues.

    Please provide more details on various cases of reproducibility. Let us know if this issue is seen on out-of-box example, made to stream packets, or any other ways to reproduce the issue you are observing.

    Regards,
    Teja.