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

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

TylerD — Tue, 07 Jan 2020 07:55:56 GMT

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!

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

Susheel Nuguru — Mon, 06 Jan 2020 12:53:21 GMT

[quote user=""]Is there any recommendations on how to manage concurrent accesses to the softdevice API from multiple tasks?[/quote]

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

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

TylerD — Fri, 03 Jan 2020 15:17:55 GMT

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.

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

TylerD — Fri, 03 Jan 2020 15:02:16 GMT

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.