Mcuboot Corruption Fallback

[ofirshe]

Hi, I’ve successfully set up MCUboot with two image slots (slot-0 and slot-1) using the default configuration:

CONFIG_BOOTLOADER_MCUBOOT=y  
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="bootloader/mcuboot/root-rsa-2048.pem"

My application acts like smp_svr— it writes the new image directly to slot-1. When I call boot_request_upgrade() and then perform a power cycle, the swap process completes as expected, and the new image from slot-1 boots successfully.

However, for testing purposes, I manually corrupted the first few bytes of the slot-1 image before rebooting. When I reboot the device, the bootloader hangs at this point:

*** Booting MCUboot v2.1.0-rc1-233-g346f7374ff44 ***
*** Using Zephyr OS build v4.1.0-16-g4a3d158f21c3 ***
I: Starting bootloader  
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1  
I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1  
I: Boot source: none  
I: Image index: 0, Swap type: perm

Only after manually resetting the device again does the bootloader finally revert back to the image in slot-0.
Is there any MCUboot configuration option that allows the bootloader to immediately detect image corruption (whether in the magic header, the app body, or elsewhere) and revert to the previous valid image within the same boot cycle — instead of hanging or requiring a second reboot for recovery?
Thanks for help!

[JarmouniA]

Cc @nordicjm

[nordicjm]

Was answered on discord:

it should not hang, would suggest checking backtrace using gdb. If you are using something like an stm32, and it has ecc, chances are it's locked up in a fault handler caused by the memory controller because the data is garbage

[ofirshe]

Hi,
I injected corruptions at random offsets in the second slot. The corruption appears to be detected, but the system consistently hangs at the same point (as I posted earlier). It only reverts back to the primary image after a power cycle.
@DerekSnell @butok — Have you managed to reproduce the issue on your side?

[butok]

Hi, I injected corruptions at random offsets in the second slot. The corruption appears to be detected, but the system consistently hangs at the same point (as I posted earlier). It only reverts back to the primary image after a power cycle. @DerekSnell @butok — Have you managed to reproduce the issue on your side?

Not yet. It's look like a general MCU-Boot behavior, not NXP-specific.

[ofirshe]

But as @nordicjm mentioned here, it shouldn't hang.
Unfortunately, I only have access to our custom board with the RT1061, so I’m unable to test on other platforms.
@DerekSnell @butok If you're able to test on your side, that would help in identifying the root cause—whether it's something I missed in my setup/configuration or an issue elsewhere.

[ofirshe]

I identified the root cause: the bootloader isn’t actually hanging. In the version Zephyr currently points to, MCUboot detects that the image in the secondary slot is invalid. However, before printing the message
"mcuboot: Image in the secondary slot is not valid!", it first erases the entire secondary slot. This erasure process takes time, which gives the false impression that the bootloader is unresponsive.

In the latest upstream Zephyr, there’s an available option: MCUBOOT_MINIMAL_SCRAMBLE. Enabling this significantly reduces the delay by minimizing or skipping the full erase operation, allowing MCUboot to fall back to the primary slot much faster.

[butok]

In the latest upstream Zephyr, there’s an available option: MCUBOOT_MINIMAL_SCRAMBLE. Enabling this significantly reduces the delay by minimizing or skipping the full erase operation, allowing MCUboot to fall back to the primary slot much faster.

You mean MCUBOOT_STORAGE_MINIMAL_SCRAMBLE.

@nordicjm
Should MCUBoot set MCUBOOT_STORAGE_MINIMAL_SCRAMBLE to 'y' by default, to minimize number of erases?