Why does SD use SWI2 for passing events?

[Nick]

Why does the soft device raise a SWI2 interrupt to indicate to the application that an event occurred? In the SDK, callbacks are implemented using function pointers. A function pointer is typically passed in to an initialization function and then later invoked when a callback is required. An example is app_timer which uses a app_timer_timeout_handler_t function pointer which is passed in to the app_timer_create function and then invoked when the time-out occurs. It seems to me that the same mechanism could be used to register BLE/system event handlers with the SDK.

Are there reasons why it is not possible to use function pointers to register handlers with the SD? Are there benefits to raising a SWI2 interrupts over the function pointer approach?

The only reason I ask is because I am curious.

[Håkon Alseth]

Hi Nick,

The main reason for this is to change the interrupt level, so that it's easier for the developer to use. When the stack has an event for you, it sets the SWI2 ISR pending, which again lets you poll the event, and run this in your application.

If you were to call a sd_somefunc() directly from a callback from the SoftDevice, then you will run into problems. Main reason is because sd_ functions will be triggered through the SVC handler, meaning, it's running in interrupt priority. If you are running in ISR and calling a new ISR with the same priority or higher, the CPU core will trigger a fault.

Cheers, Håkon

[Nick]

Thanks for the explanation. I see your point about the priorities. I guess it saves having to implement something like the scheduler in the softdevice (if this is even possible?). Interesting point about the sd_ functions all running at high priority. I previously had a bug where I was calling sd_ble_gatts_hvx() from a timer ISR. It took me a while to figure out why I was getting a hardfault!