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?)

[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!