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

[SemiBrain]

Here’s a concrete example:

If the slot partition size of the new firmware is smaller than that of the old firmware, the previously mentioned configuration options alone will not resolve the issue where the old MCUBoot version fails to load the new firmware. The size discrepancy prevents the old MCUBoot from correctly retrieving the necessary confirmation data.

To ensure OTA updates function correctly, we need an alternative approach to address this issue and enable the old MCUBoot version to successfully load the new firmware.

Old version partition size

mcuboot:
    address: 0x0
    size: 0x9000
    region: flash_primary
mcuboot_pad:
    address: 0x9000
    size: 0x200
app:
    address: 0x9200
    size: 0xebe00
mcuboot_primary:
    orig_span: &id001
        - mcuboot_pad
        - app
    span: *id001
    address: 0x9000
    size: 0xec000
    region: flash_primary
mcuboot_primary_app:
    orig_span: &id002
        - app
    span: *id002
    address: 0x9200
    size: 0xebe00
user_param:
    address: 0xf5000
    size: 0x2000
    region: flash_primary
factory_data:
    address: 0xf7000
    size: 0x1000
    region: flash_primary
settings_storage:
    address: 0xf8000
    size: 0x8000
    region: flash_primary
mcuboot_secondary:
    address: 0x0
    size: 0xec000
    device: MX25R80
    region: external_flash
external_flash:
    address: 0xec000
    size: 0x14000
    device: MX25R80
    region: external_flash

Net version partision size

mcuboot:
    address: 0x0
    size: 0x7000
    region: flash_primary
mcuboot_pad:
    address: 0x7000
    size: 0x200
app:
    address: 0x7200
    size: 0xece00
mcuboot_primary:
    orig_span: &id001
        - mcuboot_pad
        - app
    span: *id001
    address: 0x7000
    size: 0xed000
    region: flash_primary
mcuboot_primary_app:
    orig_span: &id002
        - app
    span: *id002
    address: 0x7200
    size: 0xece00
user_param:
    address: 0xf4000
    size: 0x2000
    region: flash_primary
factory_data:
    address: 0xf6000
    size: 0x1000
    region: flash_primary
settings_storage:
    address: 0xf7000
    size: 0x8000
    region: flash_primary
vendor_production_data:
    address: 0xff000
    size: 0x1000
    region: flash_primary
mcuboot_secondary:
    address: 0x0
    size: 0xed000
    device: MX25R80
    region: external_flash
external_flash:
    address: 0xed000
    size: 0x13000
    device: MX25R80
    region: external_flash

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