The old version of MCUBoot cannot successfully load the new Matter OTA firmware unless a confirmed OTA firmware is uploaded

[SemiBrain]

This issue is a follow-up to the previous one：341132

When upgrading our device from Matter 1.1 to Matter 1.3 firmware via OTA, the MCUBoot program in the old firmware fails to load the new version. The MCUBoot log indicates that the new firmware cannot be loaded or confirmed, leading to an automatic rollback to the previous version.

I: Starting bootloadert image slot
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
D: erasing trailer; fa_id=3
D: initializing status; fa_id=3
D: writing swap_info; fa_id=3 off=0xeafd8 (0xf3fd8), swap_type=0x2 image_num=0x0
D: writing swap_size; fa_id=3 off=0xeafd0 (0xf3fd0)
D: writing magic; fa_id=3 off=0xeaff0 (0xf3ff0)
D: erasing trailer; fa_id=1
D: writing copy_done; fa_id=3 off=0xeafe0 (0xf3fe0)
I: Bootloader chainload address offset: 0x9000
I: Starting bootloadert image slot
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
D: erasing trailer; fa_id=1
D: writing image_ok; fa_id=1 off=0xeafe8 (0xeafe8)
D: writing swap_size; fa_id=1 off=0xeafd0 (0xeafd0)
D: writing magic; fa_id=1 off=0xeaff0 (0xeaff0)
D: erasing trailer; fa_id=3
D: initializing status; fa_id=3
D: writing swap_info; fa_id=3 off=0xeafd8 (0xf3fd8), swap_type=0x4 image_num=0x0
D: writing image_ok; fa_id=3 off=0xeafe8 (0xf3fe8)
D: writing swap_size; fa_id=3 off=0xeafd0 (0xf3fd0)
D: writing magic; fa_id=3 off=0xeaff0 (0xf3ff0)
D: erasing trailer; fa_id=1
D: writing copy_done; fa_id=3 off=0xeafe0 (0xf3fe0)
I: Bootloader chainload address offset: 0x9000
I: Jumping to the first image slot

To work around this, I enabled the following two parameters when building the new firmware and uploaded a confirmed OTA firmware. Only then was MCUBoot able to successfully boot the new firmware.

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y
CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm"

We would like to explore whether there are alternative solutions, other than providing a confirmed OTA firmware, to resolve the issue of the old MCUBoot version failing to correctly boot the new firmware.

Additional information:
The old version of MCUBoot is v1.9.99-ncs3-rc2 with ncs 2.2.0
The neew version of MCUBoot is v2.1.0-ncs1 with ncs 2.7.0

[Amanda Hsieh]

Hi, 

It has to use the same static partition to build with the new image for updating. In other words, the partition cannot be modified to the updated image. Otherwise, it will fail to update.

Regards,
Amanda H. 

[Andy Liu]

Hi Amanda,

Thanks for your prompt response. I'm a colleague of SemiBrain.

Even with the same static partition layout, we still observe that the workaround we mentioned in the original ticket is required. Specifically, we need to add the following options to the new firmware build:

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y
CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm"

We’d like to confirm whether there are any alternative solutions that would more robustly address this issue. Could you provide some guidance?

Best regards,
Andy

[Amanda Hsieh]

You can call boot_write_img_confirmed(), see this example https://github.com/nrfconnect/sdk-nrf/blob/v2.9.1/samples/matter/common/src/dfu/smp/dfu_over_smp.cpp#L150 

[SemiBrain]

The function can only execute successfully if the App is running normally. However, during the test swap phase, the new app fails to launch properly, which prevents the function from running as intended.

[Amanda Hsieh]

That's true. If the new image cannot boot in the test mode, the function will not work. You need to figure out why the new image cannot work and check if using the same static partition. 

[SemiBrain]

Yes, this remains the critical issue we aim to resolve with Nordic's support.
As noted by my colleague Andy, despite maintaining identical flash static partition configurations, the new image continues to malfunction in test swap mode.

[Amanda Hsieh]

Are you able to flash and run the new image without issue before DFU?

SemiBrain said:

As noted by my colleague Andy, despite maintaining identical flash static partition configurations, the new image continues to malfunction in test swap mode.

Could you provide the log?