Manual firmware upload to trigger MCUBoot swap

[Dymek117]

Hey,

I have implemented BT FOTA process for my zephyr based application. DFU over Bluetooth works fine.
But now I struggle to implement manual upload of image (it will be done via spi in future).

What I'm trying to do?
I want to generate .hex or .bin file shifted to slot1 address space and flash this file via west to trigger mcuboot swap.

As far as I know, west build does not generate .hex file with shifted addresses that can trigger DFU procedure.
There is app_update.bin - it is working fine when i upload via bluetooth with NCS application. But i would like to upload this file via west,
then reboot my MCU and see that mcu boot swaps images - but this didn't happen for now

I tried with all .hex files generated by west, I also translated app_update.bin to .hex with this tool:
arm-none-eabi-objcopy --change-addresses  0x3E000 -I binary -O ihex build/zephyr/app_update.bin app_update.hex
But flashing this hex via west also does not trigger swap and always old image is booted.

Maybe you guys are able to point what I am missing here. Official BT DFU was warking excellent, but my app has to handle OTA over interfaces not supported by zephyr.
This is why I have to implement manual upload.

Thanks!

[Hung Bui]

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. 

[Dymek117]

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.

[Hung Bui]

Dymek117 said:

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?

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. 

[Dymek117]

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?

[Hung Bui]

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. 

[Dymek117]

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?

 

[Dymek117]

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 :)