Boot up without SoftDevice possible? (nRF Connect)

[jose321]

Hello!

As part of our risk mitigation, we are interested to know whether during the boot up procedure, we can temporarily boot into a mode where the SoftDevice is fully disabled, with the customer application fully in control of the chip?

Within this state, we mean-

• Application owns all interrupts (I assume we can configure the interrupt priorities?)
• SoftDevice not started (so no events or interrupts generated)

To clarify, the boot sequence would look like so-

1. Boot up
2. Application initialises with highest priority interrupts. BLE unavailable.
3. Application performs system integrity tests
4. If all OK, hands over interrupts to SoftDevice (i.e. interrupts as normally configured on nRF platform)
5. Initialise SoftDevice (if such an API call exists)
6. Business as usual after this point until the next reset. BLE available.

Some specific questions-

• Is it possible to configure the SoftDevice interrupt priorities by application, or its hardcoded?
• Does the above (1-5) sequence make sense? Do you think its feasible?
• Can a hypothetically faulty SoftDevice prevent reaching step 3 above?
• Is not starting the SoftDevice a problem? Will it result in increased power consumption or any other unexpected issues?
• Are there any reference examples that demonstrate operation with SoftDevice disabled (no BLE is necessary)?

Whilst I am posting this for nRF52840, this question is also relevant for nRF5340. And I ask this primarily for the nRF Connect SDK (where I understand SoftDevice controller is extracted, and SoftDevice as a whole no longer exists).

I know this image is from nRF5 SDK (I could not find one for nRF Connect SDK), but we mean the application would temporarily be assigned the interrupt priority 0 & 1-

[Edvin]

Hello,

You can use MPSL, and this will be initialized on boot (before you hit your main() function). However, you can use CONFIG_MPSL_DYNAMIC_INTERRUPTS, and call mpsl_lib_uninit() before you call bt_enable. This way you will get access to all interrupts, as if there was no softdevice at all. Is that something that you can utilize?

Best regards,

Edvin

[jose321]

 Edvin , thank you for getting back to me! I am checking this out in more detail. Probably not, but just wondering if there are any example codes that touch upon this, or I can use for inspiration? 

Quick couple of questions-

1. Does your comment apply equally to nRF Connect based operation in nRF52 as well as nRF53? 
2. When I see the MPSL library, it mentions interrupts like RADIO_IRQn & RTC0_IRQn (e.g. developer.nordicsemi.com/.../mpsl_lib.html). Where can I get a complete list of these interrupts & also ideally the default priorities used within nRF Connect? 

Thank you!

Jose

[jose321]

Hello, I dug around the nRF Connect examples & also the nRF5 SDK, just to understand the interrupt priorities more. 

1. In both, it appears that SysTick takes a higher priority. However I am confused because I thought the SoftDevice always took a higher priority? (see header files attached below with interrupt priorities listed)

2. For the header file for nRF5 SDK, the interrupts don't match the values given in this Nordic document (the image in the original post). Is that because the interrupts are configured after boot, after these values are initialised? And is that the same for nRF Connect SDK? 

3. I also found this document- https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/processor_avail_interrupt_latency/interrupt_forwarding_to_application.html. This says that the SoftDevice (from nRF5 SDK) always gets the interrupts and then chooses what to forward to the application. Is it the same with nRF Connect SDK?

Thank you

Jose

The header files I refer to are attached below-

nrf5340_application from nRF Connect SDK 2.5.1.h

nrf52 from nRF5 SDK17.1.0.h

nrf52840 from nRF Connect SDK 2.5.1.h

[Edvin]

1. Systick is not used in any of our SDKs. 

2. The link you provided is for the s132 softdevice, which is intended for the nRF52832. I believe you are looking for "this Nordic document".

3. Yes, by default, if you enable the softdevice controller (using bt_enable()) then the softdevice controller in nRF Connect SDK will handle all interrupts, and forward most of them to the application. But if you use the mpsl library as described in the previous reply, and make sure to disable it before you enable the bluetooth stack, you will have direct access to all interrupts. Then you would need to enable both MPSL and the bluetooth stack when your self test is done.

Best regards,

Edvin

[jose321]

Hi Edvin , thank you for the answer, that helps with better understanding.

Regarding the suggestion of MPSL initialised at boot with CONFIG_MPSL_DYNAMIC_INTERRUPTS & calling mpsl_lib_uninit(), can you point me to any examples which might be the closest starting point I can use to understand this further?

Thank you

[Edvin]

As far as I know, there are no samples that are doing this. The typical use case in our samples is to either use the radio stack, or not at all. Also, most customers use a different application to run radio tests, and when it passes, they flash the final application to the nRF. And I don't think they run the radio test on all devices. Just a selection.

However, you should be able to just add a line saying CONFIG_MPSL_DYNAMIC_INTERRUPTS=y to your prj.conf. 

Best regards,

Edvin

[jose321]

Hello Edvin,

Thanks for the response! Ok noted.

For the samples that don't use the radio, am I correct in assuming mpsl_lib_uninit() will have to be called?

I will be trying this out in the coming few days, and I will feedback on how I get on!

Thank you

Jose

[Edvin]

jose321 said:

For the samples that don't use the radio, am I correct in assuming mpsl_lib_uninit() will have to be called?

If you are not using the radio at all, you can avoid including any stacks by just not including them (CONFIG_BT=y, CONFIG_THREAD=y, and so on). If they are not included, then you don't need to do anything. But if you want to include BT in your application, you need to set CONFIG_BT=y. By default, it is already enabled when you hit your main() function, so it is not possible to avoid it being enabled. If you want that option, you need to use MPSL, which then gives you the option to uninit itself.

BR,
Edvin