• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 168 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.

AM2732: MCAL_AM273x_09.01.00 ethernet interrupt issue

ning wang
Prodigy 40 points
Part Number: AM2732

Tool/software:

Dear expert,

Recently, I found that MCAL_AM273x_09.01.00 can cause AM2732 ethernet transmit interrupt (MSS_CPSW_FH_INT) to be abnormal in some cases.

The case is like this: Suspend all interrupts through Os, transmit ethernet messages ten times in a loop, and then resume all interrupts through Os.

By analyzing the logic of the mcal source code, I think the first interrupt should send the first frame,

then in the first transmit intrrrupt continue to call CPDMA to send the remaining ethernet packets,and trigger the ethernet transmit interrupt again.

However, the actual phenomenon is that the transmit interrupt only entered once and did not enter the second time.

According to the CPDMA register, the interrupt is in a pending state and has not been triggered.

May I ask if this is a known issue? If not, can you provide me with some help based on this issue?

Regards,

Ning Wang

  • 0
    Prodigy 40 points

    Add test code.

    TASK(OsTask_BSW_50ms_Core0_QM)
{
    /* Record some counter */
    static uint32 buffFailCnt = 0, buffSuccessCnt = 0,txFailCnt = 0, txSuccessCnt = 0;

    BufReq_ReturnType   bufStatus = BUFREQ_NOT_OK;
    uint8              *bufPtr;
    Eth_BufIdxType      bufIdx;

    uint16              lenByte   = ETH_DATA_LEN;

    Eth_FrameType       frameType = 0x0800;
    uint8               gBCstMacAddr[ETH_MAC_ADDR_LEN] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};

    AppUtils_SchM_Enter_EXCLUSIVE_AREA_0();

    for( uint8 loopTimes = 0; loopTimes < 10; loopTimes++ )
    {
        BufReq_ReturnType   bufStatus = BUFREQ_NOT_OK;
        Std_ReturnType      retVal    = E_NOT_OK;

        /* Provide a transmit buffer to send data. */
        bufStatus = Eth_ProvideTxBuffer( 0x00, 0x00, &bufIdx, &bufPtr, &lenByte );

        if ( BUFREQ_OK == bufStatus )
        {
            buffSuccessCnt++;

            /* Fill data into buffer provided by driver */
            for ( uint16 i = 0U; i <= lenByte; i++ )
            {
                bufPtr[i] = i % 256;
            }

            /* Transmit data by CPDMA. */
            retVal         = Eth_Transmit( 0x00, bufIdx, frameType, 0x00, lenByte, gBCstMacAddr );

            if ( E_OK == retVal )
            {
                txSuccessCnt++;
            }
            else
            {
                txFailCnt++;
            }
        }
        else
        {
            buffFailCnt++;
        }
    }

    AppUtils_SchM_Exit_EXCLUSIVE_AREA_0();

    (void)TerminateTask();
}

  • 0 in reply to ning wang
    TI__Genius 12560 points

    Hi Wang,

    I have assigned this to Eth expert. He will check and get back to you.

    BR,

    Sunil MS

  • +1 in reply to ning wang
    TI__Genius 9295 points

    The packet transmission should start when you call Eth_Transmit(), then the descriptor/buffer will be reclaimed and recycled once the TX interrupt occurs. Packets are not transferred in the interrupts as the question seems to be alluding to.

    If you are using TX interrupt pacing, it's possible that you enqueue multiple descriptors/buffers (via subsequent calls to Eth_Transmit()) and then you get one single interrupt for the entire queue. If this scenario is happening or not will depend on the interrupt pacing period.

    If interrupts were disabled throughout the test, then the first TX interrupt (which is a completion interrupt) will be serviced once the interrupts are re-enabled. The TX ISR is going to process the descriptors of all transmitted packets so far(i.e. 10 packets).