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

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

Amanda Hsieh — Mon, 14 Apr 2025 12:26:33 GMT

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.

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

Andy Liu — Fri, 11 Apr 2025 11:37:25 GMT

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

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

SemiBrain — Fri, 11 Apr 2025 10:38:20 GMT

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?

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

Amanda Hsieh — Thu, 10 Apr 2025 18:17:42 GMT

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.

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

Andy Liu — Wed, 09 Apr 2025 05:33:49 GMT

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:

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

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

Amanda Hsieh — Mon, 07 Apr 2025 18:13:12 GMT

[quote user="Andy Liu"]

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"

[/quote]

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

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

SemiBrain — Mon, 07 Apr 2025 15:35:55 GMT

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.

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

Amanda Hsieh — Mon, 07 Apr 2025 13:48:56 GMT

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

[quote user="SemiBrain"]As noted by my colleague Andy, despite maintaining identical flash static partition configurations, the new image continues to malfunction in test swap mode.[/quote]

Could you provide the log?

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

SemiBrain — Sat, 05 Apr 2025 15:36:17 GMT

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.

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

Amanda Hsieh — Fri, 04 Apr 2025 19:34:58 GMT

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.

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

SemiBrain — Fri, 04 Apr 2025 12:47:34 GMT

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.

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

Amanda Hsieh — Thu, 03 Apr 2025 14:53:41 GMT

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

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

Andy Liu — Thu, 03 Apr 2025 01:36:05 GMT

Hi Amanda,

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

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

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

Amanda Hsieh — Wed, 02 Apr 2025 15:04:15 GMT

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.

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

SemiBrain — Wed, 02 Apr 2025 06:08:45 GMT

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