nRF51822 S110 Re-entrancy Question

[Mike Thomspon]

When a callback function is registered via the softdevice_ble_evt_handler_set(), are there re-entrancy issues when the callback is called by the softdevice?

For instance, in the S110 example code the following is indicated about the callback: "Function for dispatching a S110 SoftDevice event to all modules with a S110. This function is called from the S110 SoftDevice event interrupt handler after an event has been received."

This would seem to indicate that the callback could be an asynchronous call from an interrupt and there could be re-entrancy or other issues that could corrupt data structures if protections aren't put in place. If this is a danger, what mechanisms are provided by the nRF library to synchronize the callback so that it doesn't occur at a dangerous time such as when sensitive data structures being manipulated by the main code?

Thanks,

Mike

[Ole Morten]

I'm not absolutely certain that I fully understand your question, but in general, you have to take care to protect any data structure that you share between interrupt and main contexts.

The softdevice provides a function called sd_nvic_critical_region_enter()/_exit(), which should be usable for this. Beware that this protects your code snippet only against application level interrupts, so interrupts that are fully handled internal in the softdevice may still occur. The call hence does not make any guarantees about timing, only about data safety.

Also, since these functions are SVC calls, they can only be called from interrupt priority 3 (APP_LOW) and from main. However, when in APP_HIGH, you are in effect already in a critical region, since no application level interrupt can interrupt you. The SDK macro CRITICAL_REGION_ENTER()/_EXIT() in app_util.h wraps this difference, and can hence be used from any level.

In SDK applications that does not use the scheduler, the sd_ble_evt_get() and the resulting ble_evt_dispatch() are both run directly from the SWI2_IRQHandler() context (as can be seen in softdevice_handler.c). Hence, if you manipulate data in this event handler, but also from main context, you should protect this data access from main, to avoid the SWI2 interrupt being triggered during the manipulation.

If you use the scheduler or some other mechanism to transfer the actual retrieving of events from the softdevice and the ble_evt_dispatch() call to main context, there should however not be any concerns like this.

Let me know if I misunderstand anything, or if anything is still unclear.

[Mike Thomspon]

Yes, I've started to find the SDK BLE source code very helpful. Thanks again for supplying the missing details.