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

[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?

[AHaug]

Hi kuchx

Thank you for sharing 

kuchx said:

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?

No worries, to my understanding this API should help you https://docs.zephyrproject.org/apidoc/latest/group__mcuboot__api.html :) 

If you have any additional follow ups that are urgent I would recommend you raise the questions as a new Devzone case, since the original question in this case has been resolved, so answer time might be shorter in a new case

Kind regards,
Andreas