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.

IWR6843: Speed up larger SPI transfers

Part Number: IWR6843


Hello,

I am using the SPI interface in master mode to stream out radar data in fixed 4096[byte] packets.

During transfer there are periodic large gaps in the clock which I understand are caused by the DMA filling the output buffer.

I would like to know how to eliminate or significantly reduce these gaps which reduce the overall data throughput.

I have seen references to enabling SPI_MULTI_ICOUNT_SUPORT, but this define does not appear to exist in SDK 3.3.0.3.

Can MIBSPI_RAM_MAX_ELEM be increased beyond 64 to allocate more RAM for the MibSPI driver?

Cheers,

Curtis

  • Hi Curtis,

    Its SPI_MULT_ICOUNT_SUPPORT and it is still supported in SDK. How-ever it cannot be used in all modes. Please check table below:

    SPI transfer with multiple RAM buffer (icount)

    SPI hardware has an internal RAM buffer that stores transmit/receive data element in 8bits or 16bits. The SPI driver has a compile time option to transfer data bigger than RAM buffer size. This is intended for high throughput transfers. But it has some limitations and not supported in all SPI modes.

    SPI modePin ModeSupported?Limitations
    Master 4-pin Yes Note1
    Master 3-pin Yes Note1
    Slave 4-pin Yes Note2
    Slave 3-pin No None

    Note1: There will be gaps between every transfer of the RAM buffer size for internal DMA copy of the data. During this time, Clock and CS will be inactive.

    Note2: Slave needs time to do DMA copy of received data for every RAM buffer. Hence require the SPI master to deactivate CS/ClK signal during this time. When using another XWR1xxx device as master, it can be achieved by setting C2Tdelay/T2Cdelay/wdelay.

    The maximum elements is defined as MIBSPI_RAM_MAX_ELEM. For multiple slaves scenarios, this number is divided among all slaves. This information is provided from application in SPI_MasterModeParams. The maximum icount value is 32. Please make sure the transfer length is not exceed 32 * ramLen. For High clock rate, it is recommended to use small icount values.

  • Hi Yogesh,

    Sorry about the typo and thanks for including the above table, however this did not answer my question.

    As per note1 "There will be gaps between every transfer of the RAM buffer size for internal DMA copy of the data. During this time, Clock and CS will be inactive"; I'd like to know if the RAM buffer size can be increased. Can MIBSPI_RAM_MAX_ELEM be increased above 64?

    Additionally, it is stated that "For High clock rate, it is recommended to use small icount values." What is the reasoning behind this? Smaller DMA transfers?

  • Hello,

    You can use 16 bits data size to transfer 128 bytes. Lower icount means less DMA request.

    Thanks

    Yogesh

  • Again, I'd like to know if MIBSPI_RAM_MAX_ELEM be increased above 64?

  • 64 is the current driver limitation.

  • Where does this limitation come from? Is this a compile time limitation that can be modified? Or is this buried is some pre-compiled library?

    If it is in the pre-compiled library, what needs to be modified to increase it?

  • Hi Curtis,

    If you need to increase the throughput, you need to enable SPI_MULT_ICOUNT_SUPPORT. With this you can test with 256 or 1024 bytes.

    Thanks

    Yogesh