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.