Is nrf_drv_spi_transfer interrupt safe?

[Samer Mattar]

My application runs on nRF52832 with SDK11. what happens if I call nrf_drv_spi_transfer in blocking mode from different contexts on the same SPI instance. in my case the instance is SPI1 configured without a handler (blocking mode) with priority LOW what are the consequences of calling nrf_drv_spi_transfer on this instance from main loop, LOW priority context and MID priority context with no synchronization between the calls ?

[Jørgen Holmefjord]

Hi,

First I would like to warn you that using blocking calls, or while loops in general, inside interrupt handlers is not recommended. Interrupt handlers should process events as quickly as possible, and leave time-consuming task to main context.

Spesifically for your question, it should not be an issue to call it from different interrupt context, as long as you use the function in blocking mode. There is a check inside nrf_drv_spi_transfer() that will return NRF_ERROR_BUSY error code, if a transfer is already in progress. Make sure you filter this error before passing the returned error code to APP_ERROR_CHECK, as this is a recoverable error. Note that you cannot busy-loop inside a higher priority interrupt context, waiting for the transfer to finish, as this will preemt the lower priority blocking tansfer function call. You will therefore need some kind of scheduling system that can start the transfer at a later stage. I would recommend that you take a look at the SPI transaction manager library, if you want the posibility to schedule transfers from different interrupt context.

Best regards,

Jørgen