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.

IWR1443: large transfer overhead via SPI driver

Part Number: IWR1443

There are IWR1443 connected to 23K256 SRAM via SPI (master mode)

Needed to transfer 10000 bytes for one session (23K256 supports such SPI "sequence" mode)

SPI clock is 20Mhz, then session latency must be ~5ms....  However, time measure shows >10ms

SPI_MULT_ICOUNT_SUPPORT is on, dma mode switching cause nothing changes.

(Of course, -O1/2/3 compiler options used)

What other way to fix driver or its parameters for speedup SPI transfer ?

Regards.

  • Hi Andrey,

    Would you be able to post a scope shot of this?

    This is a good question and I will need to interface with my team before providing a response. I will try to have a response in the next few days.


    Cheers,
    Akash
  • Hi Andrey,

    Do you have a scope shot you can provide or some kind of data that supports your measurement?


    Cheers,
    Akash
  • Sorry for the delay.

    At first, our SPI init:

    -------------------------------------------------------------------------------------------------------------------

        SPI_Params      params;
        SPI_Transaction spiTransaction;
        SPI_Params_init(&params);
        params.mode  = SPI_MASTER;
        params.pinMode=SPI_PINMODE_3PIN;
    //    params.csHold=1U;
        params.frameFormat=SPI_POL0_PHA1; //SPI_POL0_PHA1
        params.dataSize=8U;
        params.u.masterParams.c2tDelay=2U;
        params.u.masterParams.t2cDelay=2U;
        params.u.masterParams.wDelay=0U;
        params.u.masterParams.bitRate = (uint32_t)(16*1000000);
        params.u.masterParams.numSlaves = 1U;
        params.dmaHandle=gMmwMCB.gDmaHandle;
        params.dmaEnable=0;
        params.u.masterParams.slaveProf[0].chipSelect = 0U;
        params.u.masterParams.slaveProf[0].ramBufLen = (uint8_t)(MIBSPI_RAM_MAX_ELEM);
        params.u.masterParams.slaveProf[0].dmaCfg.txDmaChanNum =1U;
        params.u.masterParams.slaveProf[0].dmaCfg.rxDmaChanNum =0U;
        params.u.masterParams.slaveProf[1].chipSelect = 1;
        params.u.masterParams.slaveProf[1].ramBufLen = (uint8_t)MIBSPI_RAM_MAX_ELEM/2;
        params.u.masterParams.slaveProf[1].dmaCfg.txDmaChanNum =3U;
        params.u.masterParams.slaveProf[1].dmaCfg.rxDmaChanNum =2U;
        gMmwMCB.spiHandle = SPI_open(0, &params);
        if (!gMmwMCB.spiHandle) {
            DebugAssert (0);
        }

    //    SPI transaction settings
        GPIO_write (SOC_XWR14XX_GPIO_30, 1U);       // CS enable
        gMmwMCB.spiTransaction.count = 1; // default value
        gMmwMCB.spiTransaction.txBuf = NULL;
        gMmwMCB.spiTransaction.rxBuf = NULL;
        gMmwMCB.spiTransaction.slaveIndex = 0;  // external RAM spi channel

  • Sending...
    ----------------------------------------------------------------------------------
    trans->count = 10000;
    trans->rxBuf=NULL;
    trans->txBuf = p;

    errCode |= SPI_transfer(gMmwMCB.spiHandle, trans);
  • At end, scope shot

    Upper ray - CS

    Lower ray - CLK (highly discontinuous !)

  • Hi Andrey,

    Can you confirm you are using the IWR1443BOOST or are you using the IWR1443 on a custom board?


    Cheers,
    Akash
  • Hello.

    It's a custom board with IWR1443 and 23K256(on SPI) .

    On other board, with another SoC, same RAM works via SPI without such delays well. As slave, why not...

  • Hi Andrey,

    I am currently discussing your issue with our hardware team, we will try to have an answer for you early next week.


    Cheers,
    Akash
  • Hi,

    Looking at the scope shot, the time between the data transfer blocks seems to vary. Is there some delay on the slave side?
    Also are the individual blocks of data shown on the scope sending with the expected timing?

    Regards,
    Charles O
  • Hello.

    I guess, choosen SPI protocol don't to let the slave paused a master.

    Besides our slave chip (23K256 SRAM) can't do that.

    And on other master SoC in another working scheme - it runs continously (10K data block).

    Of course, if all delays subtract from measurement time then will be about right (expected) period.

    Thanks.