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.

AM2634: MCSPI driver not stable at certain clock configuration

Part Number: AM2634
Other Parts Discussed in Thread: LP-AM263

Hi experts

I'm using MCSPI in Single Master mode with DMA Mode / Blocking.

At certain clock frequencies the driver is not stable and the task in FreeRTOS crashes. If that happens, the CPU stays in Application Idle Hook. If more than one task is used, other tasks continue operation.

Because it depends on clock configuration of the MCSPI it may is related to a known problem: https://jira.itg.ti.com/browse/MCUSDK-9595

Do I have to provide an example?

Is there a solution?

Thanks for any help.

Best regards

Dominik

  • Hi Dominik,

    I check the latest update on the JIRA ticket MCUSDK-9595. The software team cannot reproduce the issue. If you can provide your example and the steps to produce the issue, that may help them to reproduce the issue and therefore find the fix quickly.

    Best regards,

    Ming 

  • Hi Ming Wei

    I made a lot of tests today with my LP-AM263. Im using the current SDK (mcu_plus_sdk_am263x_08_05_00_24).

    CCS Project: mcspi_loopback_dma_am263x-lp_r5fss0-0_freertos_ti-arm-clang

    With some slight modifications, I was able to reproduce my problems:

    /*
     *  Copyright (C) 2021-22 Texas Instruments Incorporated
     *
     *  Redistribution and use in source and binary forms, with or without
     *  modification, are permitted provided that the following conditions
     *  are met:
     *
     *    Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     *    Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the
     *    distribution.
     *
     *    Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
     *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
     *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
     *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
     *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
     *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
     *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
     *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
     *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
     *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
     *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    
    /* This example demonstrates the McSPI RX and TX operation configured
     * in DMA mode of operation.
     *
     * This example sends a known data in the TX mode of length APP_MCSPI_MSGSIZE
     * and then receives the same in RX mode. Internal pad level loopback mode
     * is enabled to receive data.
     * To enable internal pad level loopback mode, D0 pin is configured to both
     * TX Enable as well as RX input pin in the SYSCFG.
     *
     * When transfer is completed, TX and RX buffer data are compared.
     * If data is matched, test result is passed otherwise failed.
     */
    
    #include <kernel/dpl/CacheP.h>
    #include <kernel/dpl/DebugP.h>
    #include "ti_drivers_config.h"
    #include "ti_drivers_open_close.h"
    #include "ti_board_open_close.h"
    
    #define APP_MCSPI_TRANSFER_LOOPCOUNT    10
    #define APP_MCSPI_MSGSIZE               4
    
    uint32_t gMcspiTxBuffer[APP_MCSPI_MSGSIZE] __attribute__((aligned(CacheP_CACHELINE_ALIGNMENT)));
    uint32_t gMcspiRxBuffer[APP_MCSPI_MSGSIZE] __attribute__((aligned(CacheP_CACHELINE_ALIGNMENT)));
    
    void *mcspi_loopback_dma_main(void *args)
    {
        int32_t             status = SystemP_SUCCESS;
        uint32_t            i, j;
        int32_t             transferOK;
        MCSPI_Transaction   spiTransaction;
        uint64_t            startTimeInUSec, elapsedTimeInUsecs;
    
        Drivers_open();
        Board_driversOpen();
    
        DebugP_log("[MCSPI] Loopback example DMA mode started ...\r\n");
    
        /* Memfill buffers */
        for(i = 0U; i < APP_MCSPI_MSGSIZE; i++)
        {
            gMcspiTxBuffer[i] = i + 1U;
            gMcspiRxBuffer[i] = 0U;
        }
    
        /* Writeback buffer */
        CacheP_wb(&gMcspiTxBuffer[0U], sizeof(gMcspiTxBuffer), CacheP_TYPE_ALLD);
        CacheP_wb(&gMcspiRxBuffer[0U], sizeof(gMcspiRxBuffer), CacheP_TYPE_ALLD);
    
        /* Initiate transfer */
        MCSPI_Transaction_init(&spiTransaction);
        spiTransaction.channel  = gConfigMcspi0ChCfg[0].chNum;
        spiTransaction.dataSize = 32U;
        spiTransaction.csDisable = TRUE;
        spiTransaction.count    = APP_MCSPI_MSGSIZE;
        spiTransaction.txBuf    = (void *)gMcspiTxBuffer;
        spiTransaction.rxBuf    = (void *)gMcspiRxBuffer;
        spiTransaction.args     = NULL;
        startTimeInUSec = ClockP_getTimeUsec();
        for(j = 0U; j < APP_MCSPI_TRANSFER_LOOPCOUNT; j++)
        {
        transferOK = MCSPI_transfer(gMcspiHandle[CONFIG_MCSPI0], &spiTransaction);
        }
        elapsedTimeInUsecs = ClockP_getTimeUsec() - startTimeInUSec;
    
        DebugP_log("----------------------------------------------------------\r\n");
        DebugP_log("McSPI Clock %d Hz\r\n", gConfigMcspi0ChCfg[0U].bitRate);
        DebugP_log("----------------------------------------------------------\r\n");
        DebugP_log("Data Width \tData Length \tTransfer Time (micro sec)\r\n");
        DebugP_log("%u\t\t%u\t\t%5.2f\r\n", spiTransaction.dataSize, APP_MCSPI_MSGSIZE,
                            (float)elapsedTimeInUsecs / APP_MCSPI_TRANSFER_LOOPCOUNT);
        DebugP_log("----------------------------------------------------------\r\n\n");
    
        if((SystemP_SUCCESS != transferOK) ||
           (MCSPI_TRANSFER_COMPLETED != spiTransaction.status))
        {
            DebugP_assert(FALSE); /* MCSPI transfer failed!! */
        }
        else
        {
    
            /* Invalidate cache */
            CacheP_inv(&gMcspiRxBuffer[0U], sizeof(gMcspiRxBuffer), CacheP_TYPE_ALLD);
            /* Compare data */
            for(i = 0U; i < APP_MCSPI_MSGSIZE; i++)
            {
                if(gMcspiTxBuffer[i] != gMcspiRxBuffer[i])
                {
                    status = SystemP_FAILURE;   /* Data mismatch */
                    DebugP_log("Data Mismatch at offset %d\r\n", i);
                    break;
                }
            }
        }
    
        if(SystemP_SUCCESS == status)
        {
            DebugP_log("All tests have passed!!\r\n");
        }
        else
        {
            DebugP_log("Some tests have failed!!\r\n");
        }
    
        Board_driversClose();
        Drivers_close();
    
        return NULL;
    }
    

    Modifications:

    - Changed Buffer and dataSize to 32U
    - Reduced message size to 4

    Insights:

    - With a message size of 2 or 4 this example crashes (when using 32 bit dataSize)
    - With a message size of 1 or 10 (may also others) this example is working fine

     

    Can you try to reproduce this problem?

    Thank you.

    Regards Dominik

  • Hi Dominik,

    I thought the problem was caused by changing the MCSPI clock frequency. Why do you change the buffer, data size and message size to produce the problem?

    Best regards,

    Ming 

  • Hi Ming

    For my application I use 32bit and a different message size. I didn't realize at first that data and message size is part of the problem.

    The not working code provided above will work at low frequencies (as example 10 MHz), but fails at higher frequency (as example 50 MHz).

    Can you take a look at this please?

    Best Regards

    Dominik

  • Hi Dominik,

    I have tested your program with on AM263x CC. It does not work for the higher frequencies like 50000000, 25000000. It does work properly for lower frequency such as 16666666, 12500000, 10000000, 5000000. I think it is related to the  https://jira.itg.ti.com/browse/MCUSDK-9595. I will update the JIRA ticket accordingly.

    Best regards,

    Ming

  • Hi Ming

    Very good that this can be reproduced now. Since MCSPI with high frequency is very important in my project, can you keep me up to date in this thread? Thank you.

    Best regards

    Dominik

  • Hi Dominik,

    I will certainly keep you updated on this JIRA ticket. Would you mind to close this e2e thread?

    Best regards,

    Ming 

  • Is there any update to MCUSDK-9595. ?

  • Hi Dominik,

    Here is the workaround for the reported issue:

    McSPI_Clock_Issue_Fix.zip

    Please read the ReadMe.txt first.

    Best regards,

    Ming

  • The fix is working for my application. Thanks.