MCUBoot bad magic in boot sequence

[n.marty]

Hi all

We observed a strange behaviour with mcuboot / bootutil in our nrf9160 based project.

The bootloader log messages showed that something with the primary image is not ok:

*** Booting Zephyr OS build v2.6.0-rc1-ncs1-6-g6eb6528fde28  ***
I: Starting bootloader
I: Primary image: magic=bad, swap_type=0x0, copy_done=0x2, image_ok=0x2
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
*** Booting Zephyr OS build v2.6.0-rc1-ncs1-6-g6eb6528fde28  ***

magic=bad, swap_type=0x0 is undefined, copy_done and image_ok 0x2 maps to BOOT_FLAG_BAD.

Despite this bad message, MCUBoot loads the image. Our firmware selfcheck detects after startup that something is wrong with the image. This prevents the firmware from proper operation, leaving the device bricked.

In the end of the selfcheck, the image gets confirmed. And that's where the problem gets detected. The function boot_write_img_confirmed() returns an I/O error which is based on those bad boot flags.

I'm trying to figure out what lead to this situation and how this can be prevented from happening again.

Do you know under what circumstances those boot flags can be set and how swap_type=0x0 can happen?

best regards

[n.marty]

Hi Torbjørn


The image was loaded into flash via J-Link debug interface using nrfjprog (via west flash). The Upgrade mechanism with swapping from secondary to primary slot was not involved.

Flashing merged.hex with nrfConnect Tool solved the problem, and since then it did not happen again.

best regards

[ovrebekk]

Hi

Thanks for the update. I will consider the case resolved then, unless you have some other questions?

Best regards
Torbjørn