NRF53 Gracefully Revert Multi-image DFU

[Ian]

Hello,

I want to add multi-image dfu over BLE to my NRF53. A simultaneous update seems to be the only option for this. Unfortunately, it seems we lose the ability to revert any images by default. 

I see CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY allows it to revert, but will brick the cpunet when it does. Serial recovery isn't an option for us to recover from this.

1. Is there any way to gracefully revert both cpuapp and cpunet images if one of them fails to run? If not, are there plans to add this?
2. What is the use case for CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY if it bricks the cpunet core? Is it just for cpuapp image dfus?
3. Does a simultaneous update require both images to be updated, or can either image be updated alone?

Kind regards,

Ian

[Menon]

Hello,

Is there any way to gracefully revert both cpuapp and cpunet images if one of them fails to run? If not, are there plans to add this?

Without using the serial recovery option, it’s difficult to gracefully revert both the cpuapp and cpunet images. However, I would like to point out that there is an image swap mechanism with MCUboot that allows the device to revert to a known-good state if an update fails. For more details, see the section on image swapping, swapping operations, and boot swap types.

What is the use case for CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY if it bricks the cpunet core? Is it just for cpuapp image dfus?

The `CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY` setting lets you manage the DFU process without being limited to upgrade-only actions. This means you can do other DFU tasks like image swaps or reverts. However, if not handled correctly, especially if the cpuapp doesn't properly coordinate the update, there is a risk of bricking the cpunet core.

Does a simultaneous update require both images to be updated, or can either image be updated alone?

You are not strictly required to update both images simultaneously. You can perform a non-simultaneous update for the nRF5340, meaning you can update either the cpuapp or the cpunet image independently, as long as the new image is compatible with the other existing image.

Kind Regards,

Abhijith

[Ian]

Menon said:

However, if not handled correctly, especially if the cpuapp doesn't properly coordinate the update, there is a risk of bricking the cpunet core.

Do you have an official/unofficial example of how this can be handled correctly?

Also, I came across a similar ticket but no answer yet:

 How to add Dependency to multiple images for nRF5340 multi image DFU 

Perhaps the dependency feature of imgtool can be used to revert cpuapp/cpunet? Thoughts?

[Menon]

Hello,

Sorry for the delay in responding. It's summer vacation here in Norway, and only a few of us are working, which is causing the delay.

The official sample showcasing the nRF5340 DFU is the one mentioned in the Developer Academy course.

Ian said:

Perhaps the dependency feature of imgtool can be used to revert cpuapp/cpunet? Thoughts?

I think utilizing the dependency of the imgtool is a valid approach. You can specify the required version of the cpunet firmware when signing the cpuapp firmware image, and vice versa if needed. This way, you can ensure that both cores are running compatible versions of their respective firmware. The MCUboot bootloader will check these dependencies during the DFU process. If the cpunet firmware version does not match the specified version, the update for the cpuapp firmware will not proceed, ensuring compatibility. Something like below:
--dependencies "cpunet:1.0.0" cpuapp_firmware.bin signed_cpuapp_firmware.bin

Ian said:

Also, I came across a similar ticket but no answer yet:

I went through this ticket, and it belongs to me. The customer has not responded to my initial query, which caused the ticket to vanish from my list. That's why it is still in an unanswered state.

Kind Regards,

Abhijith