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.

LP-CC2652RSIP: SSIDataGet() never returns in call to spiPollingTransfer()

Part Number: LP-CC2652RSIP
Other Parts Discussed in Thread: CC2652RSIP, SYSCONFIG

I have encountered a problem with the SPI driver. 

I am using the LP-CC2652RSIP and simplelink_cc13xx_cc26xx_sdk_5_40_00_40.

SSIDataGet() will reliably get stuck  if you increase the SSI bit rate to 12,000,000 and increase the minimum dma transfer size to greater than 10, and attempt to SPI transfer of 10 bytes.

I have also encountered this problem with a smaller minimum transfer size, but this is not as reproducible.

I have created a demonstration of this problem using the  example  simplelink_cc13xx_cc26xx_sdk_5_40_00_40/examples/rtos/LP_CC2652RSIP/drivers/nvsinternal/tirtos/ccs as a starting point.

The demonstration is accessible at https://github.com/tuckersteve/SSI_test.git

  • Hello Steve,

    Thanks for providing this information.  Basically, using nvsexternal with the following loop:

    int i;
    for (i = 1; i <= 20; i++) {
        NVS_write(nvsHandle, 0, (void *) signature, i, NVS_WRITE_ERASE | NVS_WRITE_POST_VERIFY);
        Display_printf(displayHandle, 0, 0, "Writing %d bytes", i);
    }

    Then a SysConfig -> NVS -> SPI Flash Device -> Bit Rate of 12 Mbps and a SysConfig -> SPI -> Min DMA Transfer Size of 11 bytes.  Lowering the Bit Rate to 8 Mbps or the Min DMA Transfer Size to 10 will resolve the issue.  Thus polling for large amounts of SPI data at an accelerated bit rate without using the DMA causes the issue.  This could be a limitation of the TI Drivers given the variables involved and I will request that the SysConfig Development Team consider placing an error or warning in the modules and documentation.

    Regards,
    Ryan

  • Hello Ryan,

    You don't have to be polling for a large amount of data.  A single polling transfer of 10 bytes at 12 Mbs will cause SSIDataGet() to not return. Furthermore, at least at 12 Mbps, a minimum  DMA size of 10 is not always sufficient, and I've had to reduce the DMA size to 8, but who knows if this will always work.  I can see in these cases  that SSIDataGet() polls the SSI_O_SR register, but always gets the value that the Receive FIFO is empty. The SPI driver would at least be a little more robust in this scenario, if when you pass it a null pointer for the rx buffer, it didn't wait on the RX FIFO to receive the same number of bytes as written, and just returned.