best practices to nrf_drv_spi_transfer sequentially

RE: best practices to nrf_drv_spi_transfer sequentially

Kenneth — Tue, 19 Mar 2019 13:25:03 GMT

Do you have any logic analyzer trace? I would like to check that the SPI transaction looks good. This can be checked by looking at the CSN line toggling as expected between each transfer and there is a SPI clock present for each transfer. If that all looks good, then I think the problem may be the SPI slave implementation not able to handle the transfers fast enough (~thereby a 85us delay is required). You may also for test try to tie MISO to MOSI, and check if you loopback the correct data, this can confirm that the SPI master works as intended here.

Best regards,
Kenneth

RE: best practices to nrf_drv_spi_transfer sequentially

wpaul — Mon, 18 Mar 2019 23:38:22 GMT

[quote userid="71716" url="~/f/nordic-q-a/44849/best-practices-to-nrf_drv_spi_transfer-sequentially"]2) which is the difference between SPI master and SPIM driver?[/quote]

There are a couple of ways to use the SPI controller: using programmed I/O and using EasyDMA.

Using the programmed I/O approach, you basically just write data a byte at a time into the SPI TX data register, and the SPI controller will wiggle the MOSI pin to match the bits. For completion, you can either test a status register in a loop or you can wait for a completion interrupt to trigger.

With EasyDMA, you don't need to send each byte one at a time: you give the controller the address of the buffer you want to send and its length and then start a DMA transfer. The controller will clock all the bits out for the whole buffer. Again, you can test a status register for transfer completion or wait for a completion interrupt.

Note that except for the SPIM4 controller in the nRF52840, you can only use EasyDMA to send 255 bytes at a time. With the SPIM4 controller on the nRF52840, I think this is increased to 65536 bytes. Also, SPIM4 supports clock speeds up to 32MHz. (The other controllers are limited to 8MHz.)

I'm not sure of your context when you say "SPI master" but in a general sense, it implies the master side of the transfer (i.e. not the slave). SPIM implies that the controller is a master _and_ that is uses DMA instead of PIO for handling transfers.

I think the older nRF52 design only supported the PIO mode, then they added EasyDMA mode for later chips. The same applies for the TWI (I2C) controller.

[quote userid="71716" url="~/f/nordic-q-a/44849/best-practices-to-nrf_drv_spi_transfer-sequentially"]3) are there differences between SPI (clock rate, easy DMA) on nRF52832 and nRF52840?[/quote]

The nRF52840 has one high speed SPIM controller (SPIM4) which supports clock speeds up to 32MHz. The nRF52832 is limited to 8MHz for all controllers. Also, the SPIM controllers on the nRF52832 can only transfer 255 bytes at a time via EasyDMA (larger buffers are sent using multiple transfers). The high speed SPIM controller on the nRF52840 supports up to 65535 byte transfers. (I'm not sure offhand if that also applies to the low speed controllers too.)

-Bill

RE: best practices to nrf_drv_spi_transfer sequentially

MeliodasD — Mon, 18 Mar 2019 23:23:07 GMT

for example, I tried to replicate my issue with the SPI and SPIs original examples(both have RTT nrf_log enabled), where the only modification I did to the SPI Master example was:

        // Reset rx buffer and transfer done flag
        memset(m_rx_buf, 0, m_length);
        spi_xfer_done = false;
        APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, m_length, m_rx_buf, m_length));
        while (!spi_xfer_done)
        {
            __WFE();
        }
				//unreliable transfer when no delay or it is lower 85us, reliable if delay are higher than 150us
				nrf_delay_us(85);
				
		memset(m_rx_buf, 0, m_length);
        spi_xfer_done = false;
        APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, m_length, m_rx_buf, m_length));
        while (!spi_xfer_done)
        {
            __WFE();
        }
        NRF_LOG_FLUSH();

        bsp_board_led_invert(BSP_BOARD_LED_0);
        nrf_delay_ms(2000);

where I call a second transfer after the first one was already completed, and repeat it every 2 seconds

getting unreliable transfers

For my main application, I am not allowed to use delays between each transfer because I am calling the transfers from an IRQ context where I try to exit as fast as possible

RE: best practices to nrf_drv_spi_transfer sequentially

MeliodasD — Mon, 18 Mar 2019 20:28:09 GMT

Hi Kenneth, when I am sending any message without any delay after called nrf_drv_spi_transfer() I have 2 scenarios, one where the SPI slave is not able to process it, and the 2nd scenario where I got the corrupted data in the Slave (usually the last two bytes),

with a delay or not delays added to the code, I am always making sure not transfers are in progress waiting for the flag transfer = 0 (it is cleared on the SPI handle after a transfer is done on the code above) and I check that flag before call nrf_drv_spi_transfer(), but it is very suspicious that transfers work fine only when a delay is added between each nrf_drv_spi_transfer()

RE: best practices to nrf_drv_spi_transfer sequentially

Kenneth — Mon, 18 Mar 2019 09:53:05 GMT

Hello,

I don't see any obvious reason why you need a 1ms delay here on the master to not "overflow" the slave. May check that you have set:

#define NRF_LOG_DEFERRED 1

Since that will ensure you don't have wait for each NRF_LOG() output to complete before it will resume code execution.

Other than that I think you will need to add some gpio toggling to check what in your code may take a ~1ms to execute.

Best regards,
Kenneth