What is the proper way to generate an image that is confirmed with MCUBoot

[Oskar]

Hei!

I am currently working on a project where we have implemented FOTA and I have had a lot of issues with flashing fresh boards with the complete firmware package.

Our project has a "self test" procedure, so it will check if the currently running image is confirmed, do the self-test, which confirms the image, and then reboot.

What I have experienced is that flashing a brand new chip with the merged.hex file will cause an infinite reboot loop. I think I have concluded that the issue is with the MCUBoot trailer not being included in the merged.hex file. I have modded the CMake files in the nRF Connect SDK to create a confirmed image by adding the --confirm flag to the target which creates the test update.

Flashing first the merged.hex, then the app_test_update.hex, which now is padded and confirmed, fixes this issue.

Is there a way that I can generate a fully confirmed image with the nRF Connect SDK?

We are using v1.9.1 of the SDK.

[Marte Myrvold]

Hi,

When you build an application with MCUboot you will get an autogenerated signed image, app_signed.hex. So you can just program the chip with this instead of merged.hex. You can find an overview of the different files that are generated here: Using MCUboot in nRF Connect SDK.

Best regards,

Marte

[Oskar]

Hmm, but the app_signed.hex is still not a confirmed image?

It is signed, yes, but the image trailer is still not included so the image is not set as confirmed by MCUBoot.

I have managed to create the confirmed image manually, using this script:

python ../bootloader/mcuboot/scripts/imgtool.py sign \
		--key path/to/signing_key.pem \
		--header-size 0x200 \
		--align 4 --version x.y.z+0 \
		--pad-header --slot-size 0x70000 --confirm \
		build/zephyr/mcuboot_primary_app.hex \
		build/zephyr/app_confirmed.hex

python ../zephyr/scripts/mergehex.py -o build/zephyr/merged_and_confirmed.hex --overlap=replace \
		build/zephyr/merged.hex build/zephyr/app_confirmed.hex

But this requires me to add additional steps to the build process, which is undesirable.

Especially since there seems to be a flag that should do this automatically.

[Oskar]

MCUBoot does not write the image trailer either, so using the app_signed.hex still causes the same issues as I described in the original post.

[Oskar]

This is the output from MCUBoot after flashing merged.hex, then app_signed.hex:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,409] <inf> mcuboot: Starting bootloader
[00:00:00.227,630] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,118] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,546] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.622,161] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,497] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,409] <inf> mcuboot: Starting bootloader
[00:00:00.227,630] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,118] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,546] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.622,100] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,467] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,379] <inf> mcuboot: Starting bootloader
[00:00:00.227,600] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,088] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,515] <inf> mcuboot: Boot source: none
[00:00:00.228,881] <inf> mcuboot: Swap type: none
[00:00:00.621,673] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,039] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,440] <inf> mcuboot: Starting bootloader
[00:00:00.227,661] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,149] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,576] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.621,673] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,009] <inf> mcuboot: Jumping to the first image slot

This is the output using my generated image:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.362,670] <inf> mcuboot: Starting bootloader
[00:00:00.363,891] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.364,379] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.364,807] <inf> mcuboot: Boot source: primary slot
[00:00:00.368,591] <inf> mcuboot: Swap type: none
[00:00:00.761,627] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.761,993] <inf> mcuboot: Jumping to the first image slot

[Marte Myrvold]

Hi,

How are you confirming the image with your self test procedure? Can you share your implementation?

Best regards,

Marte

[Oskar]

We connect  to LTE, read some data from MQTT, and call the `boot_write_img_confirmed`, when all functionality is verified.

The `boot_write_img_confirmed` call never fails, but an image without the image trailer seems to not be able to write this flag properly.

The functionality works as expected, as long as the mcuboot image trailer is present in flash.