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

[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?

[Andy Liu]

Hi Amanda,

Thanks for your support over the past week. While we appreciate the suggestions provided so far, the issue remains unresolved.

Given that this problem is already affecting several customers with products currently on the market, we would sincerely appreciate a more definitive solution. Your prompt and SOLID guidance would be invaluable in helping us move forward.

Andy

[Amanda Hsieh]

Hi, 

From the team:

One suspicion is that due to the fact that fprotect is enabled soon after the application boot it may happen that it will block the memory area and will not allow to confirm the new software image. The Matter application has common module that takes care of that and confirms the image before the fprotect is enabled. NCS 2.7.0 samples use it, so it should confirm the image properly. Are you using unmodified window covering sample from NCS 2.2.0 and 2.7.0 in your test or you have migrated your window covering application from 2.2.0 to 2.7.0 on your own? The goal would be to make sure that OtaConfirmNewImage method from the samples/matter/common/src/dfu/ota/ota_util.cpp is called in your application in the right moment. It's done by the DoInitChipServer from matter_init.cpp file.

 
Another suspicious might be that the image size is too big for the given partition.

Do you have any logs from the application that contain error messages related to the image confirmation? Which SoC do you use?

Please also include your build/APP/zephyr/.config and build/zephyr/.config files.

-Amanda H.