Manual firmware upload to trigger MCUBoot swap

RE: Manual firmware upload to trigger MCUBoot swap

Dymek117 — Wed, 20 Apr 2022 20:47:35 GMT

Hung,

Hex generated your way succesfully worked 🙂

The problem was I didn't called boot_request_upgrade(BOOT_UPGRADE_TEST) between transfer done and system reboot.
After reboot boot_write_img_confirmed() should be called from freshly booted app to prevent revert.

Thanks :)

RE: Manual firmware upload to trigger MCUBoot swap

Dymek117 — Wed, 20 Apr 2022 14:48:13 GMT

OK, I did this and flash this either via nrfjprog and west, but after reboot still old image is loading.
So, after your instructions I have .hex file signed and linked to SLOT1 address, but I still need to add trailer basing on smp_svr example?

In documentation i see that you use mcumgr tool like here:

sudo mcumgr <connection string> image test <hash of slot-1 image>

But how can I use mcumgr from my application? I mean marking new image for swap or rebooting?

RE: Manual firmware upload to trigger MCUBoot swap

Hung Bui — Wed, 20 Apr 2022 13:58:50 GMT

Hi Dymek,

One of my coworkers successfully sign an image and put it to 2nd slot by these command (using the -x option in imgtool.py)

imgtool.py sign --header-size 0x200 --align 4 --slot-size 0x79e00 --version 1.0.0 --pad-header --key child_image/mcuboot/custom_priv.pem -x 0x86000 build/zephyr/zephyr.hex app_manually_signed.hex

nrfjprog --sectorerase --program app_manually_signed.hex

The 2nd image will then be listed when you call mcumgr list.

RE: Manual firmware upload to trigger MCUBoot swap

Dymek117 — Wed, 20 Apr 2022 13:27:35 GMT

Address space actually don't make a difference to me - I can easily remap hex from slot0 to slot1, then app_signed.hex will be saved to the proper slot. But this still wont make swap happen, right?
After saving app_signed.hex in slot1 I should still add trailer at the end, right?

RE: Manual firmware upload to trigger MCUBoot swap

Hung Bui — Wed, 20 Apr 2022 12:45:34 GMT

[quote user="Dymek117"]I used app_update.bin with NSC iOS app and after upload mcuboot processed swap, so trailer was written rather by application or mcumgr and was not included during build process?[/quote]

This is correct. MCUBoot will write to the trailer the progress of DFU update to continue if interrupted. It also write to the trailer the swap status of the image.

In the list of the images in the link you provided, you can find that:

app_signed.hex - Signed variant of the firmware in intelhex format. This HEX file is linked against the same address as the application. Programming this file to the device will overwrite the existing application. It will not trigger a DFU procedure.

So flashing app_signed.hex will just overwrite the current application and you won't have the image in the secondary slot.

In the list of the files I think the app_moved_test_update.hex is the closest to what you want to do. But you may want to study the file to modify the trailer so that test won't automatically performed on the next boot.

RE: Manual firmware upload to trigger MCUBoot swap

Dymek117 — Wed, 20 Apr 2022 11:18:21 GMT

Thanks for quick reply.

Basing on your answer I assume, that none of files listed here:
Using MCUboot in nRF Connect SDK — MCUboot 1.8.99 documentation (nordicsemi.com)
Is containing proper trailer for mcuboot?

I used app_update.bin with NSC iOS app and after upload mcuboot processed swap, so trailer was written rather by application or mcumgr and was not included during build process? How is that possible if image trailer contains encryption key - image signing takes place after build on a PC.

I was pretty sure that on of files listed in a link above contains proper trailer and is ready for mcuboot to trigger swap - could you clarify this ambiguity? :)

Thanks,
Damian.

RE: Manual firmware upload to trigger MCUBoot swap

Hung Bui — Wed, 20 Apr 2022 11:00:43 GMT

Hi Dymek,
For the MCUBoot to detect if there is an image in the secondary (or primary) slot , it needs an image trailer at the end of the image's flash area.

Please have a look at the documentation here.

I haven't tried to write to the flash directly with the metadata but I would suggest to have a look at how we receive new image and store it to secondary slot and update image trailer in smp_svr example , the process is done most probably in img_mgmt.c file in \zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt\src.

Another option which might be easier is to do a DFU update and get the image being written into secondary slot with SMP_SVR , then after that you can read flash and copy only the secondary slot (including the image trailer) into a hex file. From that you can write the hex file to a different board and should have the same result.