How to manage concurrent accesses to BLE stack in a FreeRTOS based application

[TylerD]

I am setting up a relatively complex project that runs on top of FreeRTOS and it is based on the HRS freertos sample app from SDK 16.0.0. The device will need to run in several different modes (e.g. peripheral and/or central) and I am trying to keep it organized by separating functionality into RTOS tasks.

One thing that puzzles me is how to manage accesses to the BLE stack safely and efficiently. I may have multiple tasks that need to call some softdevice API functions (for example, one task is updating advertising data while other task is reading data from a connected peripheral).

Is there any recommendations on how to manage concurrent accesses to the softdevice API from multiple tasks? I am quite sure that if I let many tasks poke the stack without any coordination then it will result in some instability sooner or later. The device will be running 24/7 unsupervised so reliability is of high importance here.

I was thinking of decoupling the BLE stack and the other tasks using queues; one for BLE requests that are put into the queue by the task that needs to e.g. write a characteristic. Then all the request would be centrally processed by one task (= the "BLE task" in the FreeRTOS example). Once the request is completed, the response would be written into response queue so that it can be accessed by the task that created the request.

Any comments on this approach? 

I'm a bit unsure about how to add my BLE request handler in the BLE task. In the example main.c there is the event loop (ble_evt_handler) that is processing events from BLE stack and that is executed in BLE task context.  I can't add my code there because this function is only invoked when the BLE stack is producing some events. My BLE request handler must be able to continuously check for incoming requests because those may occur even when the BLE stack is completely idle.

Any suggestions or comments are more than welcome. If the FreeRTOS & softdevice integration already has some protection to make sure that any task can call softdevice functions at any time then that would be nice. However, the documentation on the FreeRTOS setup seems to be very minimal (non-existent?)

[TylerD]

I read through the code that implements the BLE task (softdevice_task, implemented in nrf_sdh_freertos.c) and it looks like my queue-based solution will not work. Here's the relevant code snippet:

void SD_EVT_IRQHandler(void)
{
    BaseType_t yield_req = pdFALSE;

    vTaskNotifyGiveFromISR(m_softdevice_task, &yield_req);

    /* Switch the task if required. */
    portYIELD_FROM_ISR(yield_req);
}


/* This function gets events from the SoftDevice and processes them. */
static void softdevice_task(void * pvParameter)
{
    NRF_LOG_DEBUG("Enter softdevice_task.");

    if (m_task_hook != NULL)
    {
        m_task_hook(pvParameter);
    }

    while (true)
    {
        nrf_sdh_evts_poll();                    /* let the handlers run first, incase the EVENT occured before creating this task */

        (void) ulTaskNotifyTake(pdTRUE,         /* Clear the notification value before exiting (equivalent to the binary semaphore). */
                                portMAX_DELAY); /* Block indefinitely (INCLUDE_vTaskSuspend has to be enabled).*/
    }
}

If I read this correctly, the task will pop any events from the stack and then it blocks indefinitely (ulTaskNotifyTake) until there is an interrupt from the BLE stack. And if the stack is idle or there is very little radio activity it may take long (or forever) until the task gets into running state.

What next? I was thinking about maybe creating one additional task for managing BLE requests that are initiated by one or more "worker" tasks in my setup. The purpose of this task would be to collect the requests that are coming from several tasks (through a queue) and then call the relevant softdevice calls and process the responses. This would make sure that there is no overlapping accesses to the BLE stack. I'm quite sure this is doable and safe, but seems kind of an overkill to have two RTOS tasks to manage the BLE operations.

Another more lightweight(?) solution could be to disable context switches while performing any softdevice API calls.

And a brute-force (and perhaps unnecessary?) approach would be to use critical section for any code that accesses the BLE stack. 

[TylerD]

Found an interesting thread from about half a year back: https://devzone.nordicsemi.com/f/nordic-q-a/47389/is-sd_ble_gatts_hvx-api-thread-safe

According to that thread, softdevice calls are thread safe (all of them?). If that's the case, then maybe I'm worrying too much. However, I'd like get confirmation from Nordic folks, or any other customers who have worked on real designs based on FreeRTOS.

[Susheel Nuguru]

Is there any recommendations on how to manage concurrent accesses to the softdevice API from multiple tasks?

 All FreeRTOS tasks are running at thread priority which is less than the SVC priority with which all softdevice API are implemented.

I do not see any need of any of your tasks co-ordinating to process or push softdevice activity, since if the FreeRTOS task is running, that means none of the interrupt context roles are running, including the any softdevice API (since it is running in SVC context).

Maybe I am missing to see what you are seeing, can you please give me one scenario where you need the tasks to co-ordinate for accessing softdevice API? All you need to do, is to make your tasks self aware of the current role your device is in (advertising or connected) and handle the INVALID_STATE error returned by the softdevice graciously., in case of calling any softdevice API that do not fit the role or state it is in 

[TylerD]

Thanks for the feedback. I am currently not running into any problems, but I was just thinking ahead how to guarantee my program will run stable and there will be no race conditions etc.

If the softdevice API is thread safe then there should be no problems. The scenario that I was thinking about was something like this:

1) task 1 calls some SD function, such as sd_ble_gattc_read 

2) before the above call is finished, there is a context swich and task 2 is resumed

3) task 2 calls some other SD function (e.g. sd_ble_gattc_write) 

Potential issue here would have been that the 2nd SD function call is invoked before the 1st one is finished. I thought this could happen for example when there are two connections that are managed by two different tasks.

I just noticed a note about thread-safety in the softdevice specification, Chapter 5 -> "SVCs are software triggered interrupts conforming to a procedure call standard for parameter passing and return values. ....  This SVC interface makes SoftDevice API calls thread-safe; they can be invoked from the application's different priority levels without additional synchronization mechanisms."

This is perfectly in line with your response above. So that's good news for me, no additional synch code needed because the API is inherently thread safe. Nice!