• State Verified Answer
  • Replies 7 replies
  • Subscribers 70 subscribers
  • Views 389 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 334517
Options

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.

  • 0 in reply to emilyd

    Hello,

    emilyd said:
    I have now noticed that the in image header that MCUboot reads (hdr->ih_img_size), the size is always between 662 and 664 bytes less than the actual size of app_update.bin. For example, I have written 380692 bytes, but hdr->ih_img_size is 380028 bytes

    That's actually a great finding. Do you have an update on this? Were you able to tackle the issue?

    The difference of around 662-664 bytes might be coming from the size of the image trailer itself. The image trailer is usually appended to the end of the image and is not part of the ih_img_size. The MCUboot image header contains the ih_img_size field, which should match the size of the actual image (excluding the trailer). The size recorded in the header is critical because MCUboot uses this size to compute the hash for verification. If this size is wrong, MCUboot will compute the wrong hash, leading to validation failure.

    Kind Regards,

    Abhijith

  • +1 in reply to Menon

    Hello Abhijith,

    Yes, I believe that 662-664 byte length difference is due to the image trailer. I have another project that uses MCUboot successfully, and I saw this byte difference there as well.

    My invalid image error was due to there being occasional empty pages in my external flash when there should've been a portion of an image. These empty pages therefore caused the calculated hash to be incorrect, since the image actually was invalid. 

    I was able to solve this by setting the sck-delay parameter in my qspi devicetree entry. It was previously unset and defaulted to 0. 

    After consulting with my particular QSPI flash chip's datasheet, sck-delay = <60> resolved the errors that I was seeing, and the image in the QSPI was correct. 
    My device will now successfully recognize the new image in the secondary partition (app_update.bin) and write that to the primary partition. Making sure that the image is versioned correctly as well as signed using a key generated by imgtool.py are also key components for this to be successful. 
    To anyone using an external QSPI flash, I found Nordic command line tools to be very helpful. The nrfjprog --readqspi command in particular was very helpful, as well as nrfjprog --qspieraseall
    Thank you for your help!
     
Related