Best practice for when to enable SoftDevice (sd_* vs. NVIC_*)

[ned_zeppelin]

The issue is that if a peripheral needs to enable interrupts (or anything else partly protected by the SoftDevice) and is configured before enabling the SoftDevice, the NVIC_* functions must be used in the initialization and the sd_* functions for disabling/de-initialization. This can quickly lead to strange code and unforeseen bugs. The same is true for using the sd_mutex* etc.

So what is considered "best practice" for this issue when using the SoftDevice?

My initial thought would be to enable the SoftDevice immediately after initializing clocks and anything else that the SoftDevice might be depend on, and always use sd_* everywhere. And wait to enable the device manager, advertising, etc. until it makes sense to do so.

This does make debugging a bit more problematic. But are there any other drawbacks that I am missing? Or does anyone have a better approach?

A define to indicate if a SoftDevice is used could be added to make drivers etc. more general, but for BLE-centered applications this define would need to be checked quite a lot of places.

[Hung Bui]

@ned_zeppelin: From my point of view:

• If you don't have to use the interrupt/peripheral that is partly protected by the softdevice before the softdevice is enabled, you should enable the softdevice first and enable the interrupt using sd_* function.

• If you need to use the interrupt before the softdevice is enabled, you can use NVIC_* function. However, when you enabled the softdevice, you would need to reconfigure the interrupt using sd_* provided functions. This mainly is to avoid your interrupt priority violated with the priority levels reserved for the softdevice.

[ned_zeppelin]

As a request, It would be nice if the SDK followed some guideline regarding this. If the drivers had a consistent use of a define so that they could be used either with the SoftDevice enabled from the start (i.e. using sd_* functions everywhere) or SoftDevice not enabled (using NVIC_* etc. everywhere), it would save the users some error-prone editing of the SDK.

My current issue is to have a safe debug printout using the sd_mutex* functions, which requires editing of most of the drivers.