nRF5340 bootloader with BLE transport

[Regie Roshan Magendiran]

Hello,

I am new to Zephyr and its ecosystem which includes MCUboot and also the NCS sdk. I have a question regarding the nRF5340 bootloader.

So we already have a product with nRF52833 that uses nRF5 sdk bootloader. It works perfectly without any issues. Kudos to the team! Now we are trying to move to nRF5340 as our application got bigger. 

The nRF5 sdk bootloader has a ble transport which was very useful for our product. The main reason is that, our product depends only on BLE transport for DFU and there is no other ways to do a DFU (no serial peripheral or other means). Having a BLE transport in the bootloader ensures that our product would never get bricked. Even if the application fails (enters a boot loop), we were able to use the bootloader (using hardware checks to make the product stay in bootloader) to update the buggy application.

With nRF5340, I understand we can use either MCUboot or NCS bootloader or a combination of both.

If I understand the implementation of MCUboot, I could see that there is no BLE transport included with it. The application must include SMP server which receives the image into slot 1 when DFU is triggered. Then the MCUboot on the next reset, validates the image in the slot1 and swaps the image to slot0 and boots slot0. Then the application confirms that the image is valid and the bootloader locks this image in slot 0. If the application does not confirm, then MCUboot would revert back to previous application.

For our product this implemetation would be an issue. I do not prefer the dependency of the application for DFU. Because if the application is buggy, we would have a bricked product at user side with no means to do a DFU.

One solution for this problem is to have the SMP server with MCUboot or NCS bootloader. I would like to know if this is possible? If yes, could you please point me to any implementation that is already available?

Thanks in advance for your time!

[Sigurd Hellesvik]

Hi Regie

We have no implementation of MCUBoot in the nRF Connect SDK that included Bluetooth Low Energy.

Because if the application is buggy, we would have a bricked product at user side with no means to do a DFU.

MCUBoot have functionality for testing the image before actually commiting to it.
This way, you can run your program first, to see if it breaks, and then verify it after you know it works.
If it breaks, a reset will revert to the previous image.
Will this work for you?

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

Hi Sigurd

Thanks for the quick response!

Yes I understand that the MCUBoot has this functionality where it can boot a test image, and let the application confirm it. But in my opinion, this idea is not fail proof. An application with an unknown bug could end up confirming the image 'accidentally' and the product could end up bricked. Especially products that does not have means for recovery through serial port.

Also one other reason a bootloader with BLE transport makes sense is the capability to have single bank upgrade. The bootloader with BLE can erase the single bank and flash it with new image. It could provide us more flash space for our application (reason why we wanted to move to nRF5340).

But I understand that currently there is no implementation with MCUboot and BLE in NRF Connect SDK. What about NSIB?(I am not familiar with NSIB yet). Also do you think MCUboot with BLE transport is possible? I am planning to try it out, but would like to know your opinion.

Thanks again!

[Sigurd Hellesvik]

Regie Roshan Magendiran said:

What about NSIB?

NSIB can not contain SMP over Bluetooth Low energy. From our nRF Secure Immutable Bootloader sample:
"Currently, this immutable bootloader does not support firmware updates over the SMP transport for either an upgradable bootloader or an application. If the application using this bootloader requires SMP-based firmware updates, such as Bluetooth LE DFU, include MCUboot as a second-stage bootloader."

I think that you should be able to make MCUBoot run Bluetooth Low Energy. In this case however, I believe you will have to add the SoftDevice Controller once for the application and once for MCUBoot. This will use up more flash, so that might be a problem.
I am not aware of any method for interfacing between MCUBoot and the applications Softdevice controller.

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

Sigurd Hellesvik said:

In this case however, I believe you will have to add the SoftDevice Controller once for the application and once for MCUBoot. This will use up more flash, so that might be a problem.

BLE controller is available in the network core for nRF5340 right? Shouldn't MCUboot (with SMP server) be able to communicate with the network core? Why should it be added to the application core separately for MCUboot? Am I missing something here?

[Sigurd Hellesvik]

That is a good point, I was thinking single-core here.

I will investigate if/how this works tomorrow.

Regards,
Sigurd Hellesvik

[Regie Roshan Magendiran]

Great! Thank you!

[Sigurd Hellesvik]

So I have asked around some.

TL;DR
The most important answer is that I do not recommend using Bluetooth Low Energy (LE) "inside" MCUBoot.
It is not supported in our implementation, so if you want to do this, you will have to do it yourself.

Some background into how the nRF5340 works with BLE and MCUBoot:
In the nRF5340, a Bluetooth LE Controller runs on the Network core, while a Bluetooth LE Host runs on the Application Core.
I beleive that the Controller takes up more space than the Host.

In the nRF5340, MCUBoot runs on both the Application Core and the Network Core.
I have not read properly up on this, but you should be able to learn more on nRF5340: Network core bootloader.

Here are some Pros and Cons:

Pros:
MCUBoot will be self-contained. If the Bluetooth LE part of the application stops working, you could still use MCUBoot to fix this.

Cons:

Space
MCUBoot needs to contain both the Bluetooth LE Host and Controller. MCUBoot APP+Host and MCUBoot NET+Controller.
The storage space on the Network Core is small. So it could be problematic to run two copies of the Controller on this. You will have to do your own math to find out if it would be space for all you need on the Network core.

"Stale" software
An alternative to have two different Bluetooth LE Controllers on the Network Core, would be to have a Host+APP MCUBoot and have it interface with the Controller already on the Network Core.
Your argument is that you do not want to trust updates, as they might break stuff. So in this case, you would not want to update the Network core ever either. You are stuck with only updating the application running on the Application core.
The issue with never updating the Bluetooth LE Host in the MCUBoot(APP) or the Controller on the Network core is that you miss out on future updates on Bluetooth LE. This will also mean security updates, which could leave your Bluetooth LE operation insecure.

One man vs a community
EDIT: changed this section a bit.
Making major changes to MCUBoot, such as adding Bluetooth LE to it, is likely to introduce bugs that can impact functionality or even security.
The team working on MCUBoot have many people who cooperate on making it as good as possible. They also have worked on it for a long time, so the project is well "honed".
If one person or a few people makes major changes to MCUBoot for a single project, bugs have a lower chance of getting caught and fixed. Especially if the project ends after completion, in which case the "scrutiny" of the MCUBoot will not continue. In other words, there is less time to discover the bugs than in the ongoing MCUBoot project.

In the end
I do not recommend to change MCUBoot yourself, but rather use the time on other improvements, such as better test routines.

Of course, you do as you please, but we mainly support MCUBoot as it is intended to be used, and if you change this drastically, we can only provide limited support.
If you have any questions about this, let me know, and I will try to elaborate

Regards,
Sigurd Hellesvik

[Regie]

Hi Sigurd,

Apologies for the delayed response!

Thanks for the detailed explanation and concerns you see with any MCUboot modifications.

Sigurd Hellesvik said:

Space
MCUBoot needs to contain both the Bluetooth LE Host and Controller. MCUBoot APP+Host and MCUBoot NET+Controller.
The storage space on the Network Core is small. So it could be problematic to run two copies of the Controller on this. You will have to do your own math to find out if it would be space for all you need on the Network core.

I thought of using the Network core bootloader (B0n) ("developer.nordicsemi.com/.../README.html I understand that the network core bootloader kind of uses RAM to get the updates from the Application core's MCUboot. So when there is a new update for network core, MCUboot in the app core will send these data through the shared RAM space to the network core's B0n which will update the network image. Please correct me if my understanding is wrong.

But I agree to your concern that it is security issue when modifying the MCUboot.

Sigurd Hellesvik said:

but rather use the time on other improvements, such as better test routines.

I agree we should spend time in improving our test routines to identify issues before deployment. But bugs are always the one that 'escapes' the test routines that we develop :) I think that's the reason, MCUboot has a recovery method as well (serial transport), but unfortunately we can't use it for our product. It is necessary for us to have a recovery as well for our product to avoid recalls.

I am trying to find a better solution and test few things with the bootloader and it is taking time to complete my work. I will come back to this post, once I have more information to share.

Regards,
Regie

[Sigurd Hellesvik]

Regie said:

I thought of using the Network core bootloader (B0n) ("developer.nordicsemi.com/.../README.html I understand that the network core bootloader kind of uses RAM to get the updates from the Application core's MCUboot. So when there is a new update for network core, MCUboot in the app core will send these data through the shared RAM space to the network core's B0n which will update the network image. Please correct me if my understanding is wrong.

Yes, I have the same understanding of the process. See nRF5340: Network core bootloader and Peripheral CPU DFU (PCD) for more information on the topic.

Regie said:

I am trying to find a better solution and test few things with the bootloader and it is taking time to complete my work. I will come back to this post, once I have more information to share.

Spoke to a couple of my colleagues about this, and unfortunately we can't come up with a way to make a device 100% recoverable device without access to serial recovery.
If you find any solutions to make your device more secure, I would be interested to hear about them, as it could be useful to other customers later on.
And if you have any questions, do not hesitate to ask.
Good luck with your testing!

Regards,
Sigurd Hellesvik