MCUBoot Issues

[wliao]

Hi,

We were testing MCUboot uisng nRF52 Dev Kit and ran into an issue that updated firmware in slot1 couldn't be booted:

Since we don't need bootloader upgradability, CONFIG_SECURE_BOOT was not enabled.

After we used DFU subsystem API function flash_img_buffered_write() to write the image to slot 1, we used MCUBoot API boot_request_upgrade() to mark the image in slot 1 as test or permanent. The old image at slot 0 still got running during next reboot / power reset.

The nRF Connect SDK version we used is v2.4.0.

So my questions are:

1. Why after the updated image was flashed to slot 1, it didn't get swapped with slot 0 and ran at next reboot?

2. Which hex file should be used to flash slot1? Should app_signed.hex be used?

3. After the device was flashed with merged.hex and rebooted, there's no indication that the bootloader was verifying the image at slot 0 which it's trying to boot from. Is it normal?

Thanks for your help!

[AHaug]

Hi,

Could you first explain what transport method you're using for DFU? Is it by using BLE, mcumgr or other?

1. Why after the updated image was flashed to slot 1, it didn't get swapped with slot 0 and ran at next reboot?

This is expected as you only flagged the image in slot1 for testing, meaning that the device performs one "test" of the firmware in image one to check if it is OK and then reverts back to the original firmware which were already residing in slot0 before you performed the test. If you wish to perform the update, you will need to 

1. Flag it for test as you already did
2. Flag it with confirm 
3. Perform a pin-reset (reset the DK with the reset button or nrfjprog --reset)

2. Which hex file should be used to flash slot1? Should app_signed.hex be used?

This page explains the various output files and how they can be used https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/config_and_build_system.html#output-build-files 

Depending on your DFU transport and the device you're developing with you may be needing to use different files. 

The Mcumgr documentation at https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/mcumgr.html as well as these samples created by a colleague of mine are useful tools to see how you can use these files together with Mcumgr github.com/.../smp

3. After the device was flashed with merged.hex and rebooted, there's no indication that the bootloader was verifying the image at slot 0 which it's trying to boot from. Is it normal?

Since you didn't do any swap as I described in step 0, it is not needed to verify the image at slot 0

Let me know if this clarifies things for you!

Kind regards,
Andreas

[wliao]

Hi Andreas,

We are not using any Nordic DFU or SMP to do OTA transfer. We have our own protocol to transfer the image from the server (PC) to the device, using BLE communication, like reading attributes. After a block of binary is received by the device, it is written into the flash by using API function flash_img_buffered_write(). 

AHaug said:

Flag it with confirm

1. You mentioned to flag slot-1 image with confirm. How would I confirm it within my application? Any API function available to perform the confirmation? I only found API function to confirm currently running image or image at primary slot, but not for slot-1.

2. As we are not using SMP, can we still use Mcumgr tool? To be able to use Mcumgr tool, do we need to include Mcumgr related code in our application?

The document states it is not for the production. 

Thanks!

[AHaug]

Hi,

Noted, thank you for clarifying! :)

I found this case (which is from last year so there might be discrepancies with how it's done her and in your firmware) that might give you a hint for the procedure  DFU sample, missing boot_set_pending or boot_request_upgrade  

In the meanwhile I will do some digging around and see if I can find newer documentation that states how to do this . I will return to you with an answer as soon as I know more, and let me know if you're able to resolve it using the case I mention while waiting

Kind regards,
Andreas

[wliao]

Hi Andreas,

I was able to update firmware by calling boot_write_img_confirmed() when the image is booted and up running. 

In this case it seems like MCUBoot doesn't care what firmware revision is and just swap the image from slot 1 to slot 0, correct? If we need to control which revision can be booted, what else needs to be done?

Thanks!

[AHaug]

Hi,

Apologies for the long response time

wliao said:

I was able to update firmware by calling boot_write_img_confirmed() when the image is booted and up running. 

Glad to hear that your firmware was up and running

wliao said:

In this case it seems like MCUBoot doesn't care what firmware revision is and just swap the image from slot 1 to slot 0, correct? If we need to control which revision can be booted, what else needs to be done?

The firmware revision for the application is AFAIK mainly there for developers to keep track on the revisions, and as long as the firmware is different, i.e modified, flagged for confirm and has passed tests to check that it is running, then MCUboot simply swaps the image from slot 1 to slot 0 as you describe

If you want, you can track the revision number by adding https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_FW_INFO_FIRMWARE_VERSION and increment this as you go along

In the case you have an updatable bootloader and want to update that, then the revision number is used to determine which of these bootloader images are the newest and which to boot from. See https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/updatable_bootloader/nsib_mcuboot_smp for a simple sample for how this is done

Kind regards,
Andreas

[kuchx]

Hello, 

I've basically stumbled upon the same issue as the original post, only for data transfer I am using CoAP blockwise. With flash_img_buffered_write() FW writes chunks in slot 1 and with boot_request_upgrade(BOOT_UPGRADE_TEST) I set the flag that on next reset the slot 1 FW should be started and it should be running till next reset to flip back to the original, as I understood. And I am calling  sys_reboot(SYS_REBOOT_COLD) for system reset (need a FW reset since button reset is not an option). Based on this exercise, I need to download app_update.bin to device, which is exactly what I do.

After the reset I get this output:

I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Bootloader chainload address offset: 0x10000

from MCUboot and device continues with slot 0 image. I tried to mark current running image (slot 0) as confirmed before DL thought that might help but the function returned error

So can you clarify what do you mean by:

1. Flag it for test as you already did
2. Flag it with confirm 

I just need to set slot 1 fw as test using boot_request_upgrade() and immediately after set it as confirmed with the same function? 

Edit: Sorry I misunderstood. boot_request_upgrade sets only test or permanent run of FW. But still, how can I confirm image, if the MCUboot never runs slot 1 image?