NRF5340: FW OTA

[Jason]

Hi:

I am working on the NRF5340 FW OTA.

By reading this document Secure bootloader chain, I think our FW architecture should use MCUboot as the upgradable second-stage bootloader as below.

As I know, the default MCU Boot is not able to receive the FW, just swap the FW. I have questions as below:

1. how to custom the MCUBoot to be able to receive the FW by BLE like the application?  because if the application is corrupted(e,g, overwrites parts of the application firmware image) somehow by the bug, the device should stay in the MCU boot and be able to recover the application by BLE.  Is there any sample code or document for this?

2. if question 1 is not a recommended method, what is the recommended method?

Thanks!

[AHaug]

Hi,

I recommend you have a look at this repository written by a colleague of mine in addition to the SDK documentation you're already looking at: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples

1. how to custom the MCUBoot to be able to receive the FW by BLE like the application?  because if the application is corrupted(e,g, overwrites parts of the application firmware image) somehow by the bug, the device should stay in the MCU boot and be able to recover the application by BLE.  Is there any sample code or document for this?

The most basic smp_ble sample showcases how to use BLE to perform DFU https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp/mcuboot_smp_ble 

I do see that you've tagged the nRF5340 in the case tags. Is this the board you're going to use in development?

If it is the nRF5340, I would recommend you to have a look at the 5340 folder in the repository and choose if you want to do simultaneous (easier, but requires external flash), or non-simultaneous (more complex, but does not require external flash): github.com/.../nrf5340

2. if question 1 is not a recommended method, what is the recommended method?

This is a good solution for this purpose, so I would recommend you to investigate the samples in the github-repository. 

However, do note that it will be slightly different if you're going also include that MCUboot should be upgradable. In that case, you will have to add the Immutable Bootloader as a first stage bootloader illustrated in the image.

Let me know if this answers your questions, or if you have any additional questions related to the topic

Kind regards,
Andreas

[Jason]

Hi AHaug,

AHaug said:

I do see that you've tagged the nRF5340 in the case tags. Is this the board you're going to use in development?

yes, our product uses the NRF5340 with an external flash.

I check the links you shared, but it seems to implement the SMP server on the application level, I know how to use the SMP server on the application side, my question is if the application is corrupted/crash somehow, how does MCUboot recover the application via BLE?

For example, if a bug overwrites parts of the application firmware image, then the system will reboot due to a fault, and the MCUBoot will detect the firmware was corrupted and will not run the application, then how does the MCUBoot recover the application(except the serial recovery)?

[Jason]

Hi AHaug,

Thanks for your clear explanation.

So the MUCBoot can make sure the upgrade is secure, even if there is hardware reset during swapping(I just tested on the nrf5340 DK by pressing the reset button during swapping, and it seems to work after reset.)  So I don't need to worry about the security of the upgrade process, right?

However, the main point that I am concerned about is that the new FW has been upgraded successfully, but there is a bug that occurred during runtime and caused infinite restarts. (e.g The application accesses the error setting information stored in the internal flash and does not handle it well, resulting in a bus fault), or other bug leads to the impossible to upgrade the FW again. we have another product using nrf52840 with NRF SDK instead of the NCS, for this case, we can force the device to enter the bootloader when reset via the button combination, and you know, the bootloader of NRF SDK has the OTA feature so that can recover the application via the BLE. For NRF5340, how to handle this case(except the serial recovery, which is impossible for this product)?

[AHaug]

Hi,

Apologies for the slight delay in response time

Jason said:

So the MUCBoot can make sure the upgrade is secure, even if there is hardware reset during swapping(I just tested on the nrf5340 DK by pressing the reset button during swapping, and it seems to work after reset.)  So I don't need to worry about the security of the upgrade process, right?

Yes, this is correct. Given that you sign the new firmware with the key the bootloader expects you to use as well as build a upgrade image that is compatible with your memory address map (for instance with regards to where the applications start address is and size of the primary slot), this should work out of the box and you should not need to worry about the security for faulting during the upgrade process. 

Jason said:

However, the main point that I am concerned about is that the new FW has been upgraded successfully, but there is a bug that occurred during runtime and caused infinite restarts. (e.g The application accesses the error setting information stored in the internal flash and does not handle it well, resulting in a bus fault), or other bug leads to the impossible to upgrade the FW again.

If you have a bug during run time in the application, you should implement some sort of way to get the device in bootloader mode so you can be certain you have redundancy w.r.t. managing to patch your device. Typically we recommend serial recovery.

And I also know that this is an obvious statement that you probably already know, and that you're asking for "what if this happens even though we've tested properly", but a proper test-setup is always recommended before pushing apps that may induce device breaking bugs during run time.

Jason said:

we have another product using nrf52840 with NRF SDK instead of the NCS, for this case, we can force the device to enter the bootloader when reset via the button combination, and you know, the bootloader of NRF SDK has the OTA feature so that can recover the application via the BLE. For NRF5340, how to handle this case(except the serial recovery, which is impossible for this product)?

Could you elaborate on why serial recovery is impossible? In the case where the application breaks during runtime there are no possible way for the application to enter a mode where you can patch it over BLE as the smp server with BLE is only supported in the application and the bootloader. If you have serial recovery in the bootloader, then you can patch the broken image when you enter serial recovery mode. Other than that, the only other option is to patch the broken image with a device with a programmer

You may implement some way of checking if a pin is low or high (one of the options) at the start and if the condition you set is met, then you can initiate the bootloader. Do note that this is just a suggestion and is up to you to solve.

Kind regards,
Andreas

[Jason]

Hi,

AHaug said:

Could you elaborate on why serial recovery is impossible?

I thought the serial recovery only supported UART, so it is impossible for the user to recover the device because they don't have USB-to-UART hardware. now I find the serial recovery also supports USB CDC, this may be an option. But the best way is the recovery mode to support BLE. so that is very easy for the user to recover the crashed device. (we have a smartphone  APP for our product).

[AHaug]

Thank you for elaborating.

Yes, USB CDC could be an option for you in that case. I would recommend you to have a look at the serial recovery samples in this repository written by a colleague of mine. (The samples here are free for you to use in your applications, but do note that they are unofficial and have not been tested by us to be put into the official SDK, so the responsibility is on you if you use them. Nonetheless, they are great at illustrating how to do that specific thing they are written to do.)

Full link: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples

As always, please feel free to ask additional questions related to the topic if anything is left unclear

Kind regards,
Andreas

[Jason]

Hi AHaug,

No more questions, Thanks for your support.