MCUBoot Issues

RE: MCUBoot Issues

AHaug — Thu, 19 Sep 2024 07:28:14 GMT

Hi kuchx

Thank you for sharing

[quote user="kuchx"]
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?[/quote]

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

RE: MCUBoot Issues

kuchx — Wed, 18 Sep 2024 13:43:33 GMT

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:

Flag it for test as you already did
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?

RE: MCUBoot Issues

AHaug — Thu, 19 Oct 2023 10:39:07 GMT

Hi,

Apologies for the long response time

[quote user="wliao"]I was able to update firmware by calling boot_write_img_confirmed() when the image is booted and up running. [/quote]

Glad to hear that your firmware was up and running

[quote user="wliao"]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?[/quote]

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

RE: MCUBoot Issues

wliao — Fri, 13 Oct 2023 13:59:35 GMT

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!

RE: MCUBoot Issues

AHaug — Tue, 10 Oct 2023 14:00:17 GMT

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

RE: MCUBoot Issues

wliao — Tue, 10 Oct 2023 13:46:28 GMT

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().

[quote userid="107683" url="~/f/nordic-q-a/104497/mcuboot-issues/449559"]Flag it with confirm[/quote]

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!

RE: MCUBoot Issues

AHaug — Tue, 10 Oct 2023 12:25:38 GMT

Hi,

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

[quote user=""]1. Why after the updated image was flashed to slot 1, it didn't get swapped with slot 0 and ran at next reboot?[/quote]

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

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

[quote user=""]2. Which hex file should be used to flash slot1? Should app_signed.hex be used?[/quote]

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

[quote user=""]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?[/quote]

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