nRF51822 S110 Re-entrancy Question

RE: nRF51822 S110 Re-entrancy Question

Mike Thomspon — Tue, 11 Feb 2014 17:30:10 GMT

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

RE: nRF51822 S110 Re-entrancy Question

Ole Morten — Tue, 11 Feb 2014 09:05:40 GMT

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.

RE: nRF51822 S110 Re-entrancy Question

Mike Thomspon — Tue, 11 Feb 2014 08:47:32 GMT

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.

RE: nRF51822 S110 Re-entrancy Question

Ole Morten — Mon, 10 Feb 2014 12:02:34 GMT

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.