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

[nordicjm]

@dleach02 does this device have ECC on memory which faults upon attempting to read data where the ECC is bad?

[ofirshe]

Cc @DerekSnell @decsny

[DerekSnell]

Hi @ofirshe and @nordicjm ,
The RT1061 is a flashless MCU. ECC features in the flash would depend on the flash ofirshe is using on their board, and how that flash is configured. The RT1060 also has flash security protection features in the ROM bootloader like encrypted boot, but those features are not enabled by default, so how the RT1060 boots here and reads the flash would depend on ofirshe's boot configuration.

@ofirshe, can you explain your testing process more? When you alter that single byte, are you erasing the entire flash sector and reprogramming the entire sector with the 1 Byte changed? Or are you altering that byte without erasing the sector? And are you using warm resets to reboot here, or cycling power?

@butok what are your thoughts on this MCUboot behavior?

Thanks

[ofirshe]

Hi @DerekSnell,

My application has been rebased onto the v4.1-branch, which currently points to the 346f7374ff4467e40b5594658f8ac67a5e9813c9 revision of mcuboot.
I upload my application to the secondary slot by erasing the entire sector and programming it using zephyr.signed.bin. After that, I read the first sector from flash, erase it, and modify only the first byte before writing it back. Then I call boot_request_upgrade(BOOT_UPGRADE_PERMANENT) and perform a power cycle (the issue also reproduces with sys_reboot(SYS_REBOOT_WARM)).
Ideally, I would expect the bootloader to detect any corruption in the image—regardless of the offset—and revert to the primary slot within the same boot, without requiring a second reboot to revert to the primary slot. The corruption only affects the secondary slot; both the bootloader and primary slot remain intact and functional as you can see.

I'm not sure if image validation covers the entire image or only specific parts—maybe @nordicjm can clarify?

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