DFU Target with MCUboot update file

[emilyd]

Hello,

I am attempting to use the DFU Target library to receive an update file over a custom protocol. I aim to do an MCUboot-style upgrade such that after the file upload, I can call dfu_target_schedule_update() and MCUboot will recognize the new image upon reboot. 

So far, I am able to upload the app_update.bin file and write it to the secondary partition (external flash in my case) using the DFU Target libraries. I finish the upload by calling dfu_target_done(1); followed by dfu_target_schedule_update(0); where 0 is to signify the application core image. Upon reboot, I get the following message:

 

I: Starting bootloader
I: Image index: 0, Swap type: test
E: Image in the secondary slot is not valid!
I: Image index: 1, Swap type: none
I: Bootloader chainload address offset: 0x18000
I: Jumping to the first image slot

It seems that MCUboot recognized my new image, but after debugging, the calculated hash does not match the hash that MCUboot wants. 

Is app_update.bin the appropriate image to write into the secondary partition with the DFU Target library? If not, what is the appropriate image? Also, does the DFU Target library take care of writing the image trailer into the secondary partition as well? 

I will note that I am using a pm_static.yml file, and that is getting recognized correctly by the build system.

Thank you, and I appreciate your help.

[Menon]

Hello,

Could you tell me which version of the nRF Connect SDK you are using here?

Is app_update.bin the appropriate image to write into the secondary partition with the DFU Target library? I

Yes, the app_update.bin file is the correct image to upload.

The error message "Image in the secondary slot is not valid!" typically occurs when the image is not signed, or the image trailer (which contains the hash and metadata) is missing or incorrect.

Since you're using a custom pm_static.yml, ensure that the secondary partition is correctly defined for MCUboot. The image is typically written to a specific partition (the secondary slot) where MCUboot expects to find it. Make sure the secondary partition in your pm_static.yml is properly configured and matches the expected partition layout that MCUboot uses.

Kind Regards,

Abhijith

[emilyd]

I will add that I notify the build system of the priv.pem key through CMakeLists.txt as shown below, and the build system seems to be successfully recognizing it :

set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/priv.pem\")