nRF52840 - SPIM Blocking mode with SD and FreeRTOS

[Elkana]

Hi,

I am using SDK 14.0 on nRF52840 (DK), with sofdevice enabled and FreeRTOS port.

My question reagrds the "blocking mode" transfer - event handler was not provided in nrf_drv_spi_init().

How would a FreeRTOS system behave when a task is using the “blocking” transaction mode:

1. When task is high priority (relative to other task(s))
2. When task is low priority (relative to other task(s))
3. When other task(s) are ready before it’s call to MCU sleep
4. When other task(s) are becoming ready via ISR during it’s sleep
5. Is there any difference if I use EasyDMA or not in this case?

Thanks, Elkana.

[Susheel Nuguru]

All tasks are running in thread mode. The RTC tick and Scheduler are running in interrupt context with least priority, which is one level higher in priority than thread mode. In short, any enabled interrupt would preempt a FreeRTOS task.

1. Then the high priority task will be scheduled until it yields check this

2. Then it will run until other high priority tasks become runnable either after unblocking by the current task or after the tick handler runs which in turns runs the scheduler.

3. Then there will be a context switch to higher priority task.

4. nothing happens during sleep. When an ISR has yielded forcing scheduler to run, then it will choose the newly available high priority task to run.

5. you are freeing up CPU for this task. The callback from EasyDMA will be called from SPI interrupt context, so it is little different than running it in your task which is running in thread mode.

[Elkana]

I am not sure you understood my question. Assume The highest priority task (higher than other tasks, not ISRs), is using nrf_drv_spi_transfer in blocking mode. It should "free CPU" before going to sleep, but I have doubts if it yields, so if another (lower priority) task is ready when the SPI transaction is performed "in background" - it won't get the CPU until an ISR occurs (think of 250Khz SPI and 256 bytes DMA buffer..)

[Susheel Nuguru]

First of all, its not safe that high priority task goes to sleep. Since it cannot yield before going to sleep. And wakeup from sleep will make the scheduler run the high priority task again. If you say that the SPI transaction makes another task ready, then if the other task is higher in priority than the one that slept, then this newer task will be scheduled as soon as the RTC tick handler is run (not after SPI *R, since no one is yielding here). FreeRTOS always selects the higher priority tasks to run,

[Elkana]

Thanks for your answer. I looked into the driver code and it is not sleeping, but busy waiting. Either way this method is not recommended for multitasking.

[Susheel Nuguru]

please accept which ever comment you think is suitable for an answer to this thread. This is important so that others can see this thread resolved