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]

Thank you for the detailed response.

I guess my question should have been stated simpler. Is the context of the callback set in softdevice_ble_evt_handler_set() in the interrupt context or the main context?

Your answer indicate its from the SWI2_IRQHandler() context so data structures accessed from this context and the main context would need some type of protection.

Is there a Nordic document that gives a general overview of the different contexts related to the softdevice and SDK? I've a number of books on ARM Cortex programming that cover this in general, but the Nordic SDK is my first experience of putting such considerations in practice and it's not always clear what context a function is called from.

Thanks.

[Ole Morten]

As long as the softdevice_handler module is not initialized to use the SDK scheduler (app_scheduler), the callback will run directly from interrupt context. Service handlers and similar will normally run in the same context as the softdevice event handler.

The same goes for app_timer, app_button and app_gpiote handlers; unless the module is initialized with the scheduler, the callbacks will run in interrupt context. You typically choose whether to use the scheduler or not with the last parameter of the init function.

You can adjust the interrupt priority using the regular sd_nvic_SetPriority() function.

There isn't any document that covers this in detail, so if you're in doubt, I will normally recommend you to just take a look at the source code. All SDK BLE modules are delivered with full source code, enabling you to fully investigate what happens.

[Mike Thomspon]

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