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

[SemiBrain]

We have attempted to flash the new image together with the old version of mcuboot, and this combination functions as expected.
As for the log information, if you are referring to the logs from the successful startup of the new image after flashing, I will provide them shortly.
If the log refers to the issue where the new image fails to load correctly, this is already detailed in the text box at the beginning of the case.

[Amanda Hsieh]

Andy Liu said:

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"

As your colleague, Andy, said, it needs to confirm the image that uses the same partition layout.  

[Andy Liu]

Hi Amanda,

I’d like to share the results of our recent OTA testing to provide better context for our request.

We evaluated the OTA behavior under three different conditions. Please note that the exact same flash layout was used across all tests:

Test Condition 1

• Window Covering App: NCS SDK v2.2.0 (default settings)

• OTA Image: NCS SDK v2.2.0 (default settings)

• Result:  OTA succeeded. The new firmware ran as expected.

Test Condition 2

• Window Covering App: NCS SDK v2.2.0 (default settings)

• OTA Image: NCS SDK v2.7.0 (default settings)

• Result:  OTA failed. After reboot, the firmware rolled back to the original version.

Test Condition 3

• Window Covering App: NCS SDK v2.2.0 (default settings)

• OTA Image: NCS SDK v2.7.0 with the following additional configurations:

  CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y
  CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm"
• Result:  OTA succeeded. The new firmware ran as expected.

Our Questions/Requests:

1. Based on the results of Test Condition 2, we believe that the OTA image built with NCS SDK v2.7.0 is not compatible with a firmware base running SDK v2.2.0.  We'd like know the root cause.

2. While adding the two configuration options mentioned in Test Condition 3 does allow the OTA to succeed, we don't believe this is the recommended or proper solution. Could you advise on the official fix for this case?

We appreciate your support and look forward to your guidance.

Best regards,
Andy

[Amanda Hsieh]

Try to enable SB_CONFIG_MATTER_OTA in the sysbuild.conf if you are using sysbuild in v2.7.0. It should also enable CONFIG_CHIP_OTA_REQUESTOR for this OtaConfirmNewImage function. 

[SemiBrain]

We’ve verified that the relevant configuration is enabled, but it doesn’t resolve our issue.
Our concern remains that, even with identical static partitions, the new version of the application fails to boot correctly during the Test swap stage.
Have you attempted upgrading a Matter application from NCS 2.2 to NCS 2.7? If so, were you able to reproduce the issue we’re encountering?