How to debug MCUboot swap failure after OTA DFU? boot_request_upgrade() has no effect

[QBSho]

Hi everyone,

I'm facing an issue where MCUboot doesn't perform a swap after reboot, even though the DFU download to slot 1 completes successfully and boot_request_upgrade() is called.

My devices are in production and had no issues in the paste with BLE DFU update. As we update to 2.9.0 the problems starts. Some devices are not working after BLE DFU and swap back to the old version. We find it out while implementing OTA over LTE-M that the partition not swapping. There seams an issue with my swapping. The goal is to use the external flash for updating, but if the main flash works it will be good enough again.

Context:

I'm doing firmware updates via OTA DFU, and writing the upgrade request like this:

int err = boot_request_upgrade(BOOT_UPGRADE_TEST); // or int err = boot_set_pending(0);

MCUboot debug logs confirm that both the magic and swap info are written:

<dbg> mcuboot_util: boot_write_magic: writing magic; fa_id=6 off=0x77ff0 (0xfbff0)

<dbg> mcuboot_util: boot_write_swap_info: writing swap_info; fa_id=6 off=0x77fd8 (0xfbfd8), swap_type=0x2 image_num=0x0

However, after reboot, the old image from slot 0 is still running — no swap occurs.

I have CONFIG_MCUBOOT_UTIL_LOG_LEVEL_DBG=y enabled, but I’m unsure how to debug MCUboot itself (e.g., with west debug or bt) since getting not output west attach.

Note on Flash Patch:

I also experimented with:

# CONFIG_DISABLE_FLASH_PATCH=y

When I enable this config, the DFU (BLE) no longer works — so I’ve kept it disabled.

prj.conf (partial):

CONFIG_PARTITION_MANAGER_ENABLED=y

CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=n

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n

CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y

pm_static.yml (simplified):

mcuboot: 0x00000 - 0x0c000

mcuboot_primary: 0x0c000 - 0x84000

mcuboot_secondary: 0x84000 - 0xfc000

settings_storage: 0xfc000 - 0x100000

My questions:

1. What could prevent MCUboot from initiating the swap even when magic/swap_info are written? (Could a mismatch in partition maps between MCUboot and the application prevent the swap?)

2. Is there a correct way to attach to MCUboot for runtime debugging? (e.g., debugging from reset?)

3. Any known issues with OTA DFU + MCUboot + CONFIG_DISABLE_FLASH_PATCH?

4. Are there additional configs I should double-check?

5. How can I verify that MCUboot has the correct view of the flash layout?

Thanks in advance — happy to share more if needed!

[AHaug]

Hi,

What could prevent MCUboot from initiating the swap even when magic/swap_info are written? (Could a mismatch in partition maps between MCUboot and the application prevent the swap?)

Here's a couple of thoughts 

1. Mismatch in size between primary and secondary (both of your partitions are similar if my math checks out)
2. That you don't enough room for swapping (NCSDK-20567 in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/known_issues.html note that there are two instances of 20567 in this list)
3. That the image is rejected due to either
   1. That the update image is not signed with the same key that MCUboot has (injection protection)
   2. That the update image is rejected due to versioning not being newer than the current version (downgrade protection)

Item 3 is typically occurring after the image has been swapped, so based on your description I don't think that this is the case.

Is there a correct way to attach to MCUboot for runtime debugging? (e.g., debugging from reset?)

 Trying to debug with MCUBOOT enabled fails to boot. and  B0 secure bootloader logging with RTT not working. might be helpful as well as https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/ 

Any known issues with OTA DFU + MCUboot + CONFIG_DISABLE_FLASH_PATCH?

Not that I'm aware of, i.e nothing stated in the known issues page and I can't think of any conflicts based on the description https://docs.nordicsemi.com/bundle/ncs-latest/page/kconfig/index.html#CONFIG_DISABLE_FLASH_PATCH 

Are there additional configs I should double-check?

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/ there could be some pointers here

How can I verify that MCUboot has the correct view of the flash layout?

MCUboot uses the pm_static.yml that you build it with, so verify it by comparing the partition manager report, i.e west build -t partition_manager_report, up against the generated build partition map that you can find within build/mcuboot/ and/or build/<your_app>

Kind regards,
Andreas

[QBSho]

Thanks Andreas, 

tried all things - but don't get it working!

[AHaug]

Hi,

Could you please post more details? Do you get any build logs, device logs or anything when you're trying the various items? 

Oh, are you certain that the image is uploaded?

And thirdly; do you mark the new image to be confirmed for update? This should be more described in steps in for instance the Bootloader and DFU lesson here  https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-1-dfu-over-uart/ 

1. Using mcumgr CLI

You can confirm the currently running image with the following command (no hash needed for the running image): mcumgr <connection-options> image confirm ""

Or, to confirm a specific image by its hash: mcumgr <connection-options> image confirm <hash>

Confirming the image ensures that the bootloader will not revert to the previous image on subsequent resets. If you do not confirm, the device will revert to the previous image after a reset. This is especially important in dual-slot configurations where images are swapped during DFU. The confirmed flag will be set for the image once this is done Verifying and testing the image.

2. In Application Code

You can also confirm the image programmatically after verifying that the new firmware is working as expected. This is typically done by calling the boot_write_img_confirmed() function in your application code:

#include <bootutil/bootutil.h>

if (!boot_is_img_confirmed()) {
int err = boot_write_img_confirmed();
if (err == 0) {
// Image successfully confirmed
} else {
// Handle error
}
}

This approach is useful if you want the device to self-confirm after passing certain checks (e.g., after a successful BLE connection or other validation) MCUboot test and confirm with DFU Target library.

3. DFU Target Sample

If you are using the DFU Target sample, you can use the shell command: dfu_target mcuboot_confirm

This will mark the update as confirmed. If you skip this step, the device will revert to the previous image on the next reboot DFU Target Sample - Testing.

Kind regards,

Andreas