DFU sample, missing boot_set_pending or boot_request_upgrade

[BvdP4Celsius]

Hi, I want to update an existing image in slot 1 with a new image in slot 2.

Both are flashed on the device and in my image 1 I want to initiate the DFU process, as mentioned in https://interrupt.memfault.com/blog/mcuboot-overview#triggering-firmware-upgrades-from-main-application. Also found some info in https://devzone.nordicsemi.com/f/nordic-q-a/78575/upgraded-firmware-image-not-confirmed-by-mcuboot-dfu

However the call boot_set_pending and/or boot_request_upgrade are not defined.
Is there some setting that will enable updating the image by the program itself?

[Vidar Berg]

Hello,

If the update image has already been flashed to the second 2 slot, then it should be become activated (i.e. copied from slot 2 to 1) on next reboot. Calling boot_set_pending and/or boot_request_upgrade should not be necessary.

Are you sure the image in slot 2 is a valid update image? And do you have logging enabled in the MCUboot to see if it detects the new update in slot 2?

I would also recommend you have a look at this guide here:  Add DFU support to your applicationas it is written specifically for the Zephyr / nRF connect SDK port of the MCUboot bootloader unlike the memfault article.

Best regards,

Vidar

[BvdP4Celsius]

Hi Vidar,

Thanks for your reply.

I am a bit lost here. I build the MCuboot and flashed it on the development kit. It shows

*** Booting Zephyr OS build v3.0.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=0
E: Unable to find bootable image

Next I flash my blinky_slot0 application. 
After a reset it shows:
*** Booting Zephyr OS build v3.0.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.0.99-ncs1 ***
[00:00:00.004,241] <inf> Blinky_slot1: Led ports initialized
[00:00:00.010,559] <inf> Blinky_slot1: Led pins configured
[00:00:00.016,906] <inf> mcuboot_util: Swap type: none
[00:00:00.022,735] <inf> Blinky_slot1: Next action on the next reboot = NONE

When I understand you correctly, flashing a second variant of the Blinky application in slot 1 (address 0x00067000) should result in a swap after a reset? What about the mcumgr command image test? I tried the proces mentioned in your link before. That one worked fine.
As we do not add the mcumgr stuff, I hoped to initiate the swapping by the  boot_request_upgrade command. 

So when the second Blinky (blinky_slot1) was flashed a reset did not start the second variant, but again the first.
Activating the boot_request_upgrade and reset shows:

*** Booting Zephyr OS build v3.0.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
I: Boot source: none
I: Swap type: perm
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.0.99-ncs1 ***
[00:00:00.004,241] <inf> Blinky_slot1: Led ports initialized
[00:00:00.010,528] <inf> Blinky_slot1: Led pins configured
[00:00:00.016,876] <inf> mcuboot_util: Swap type: none
[00:00:00.022,705] <inf> Blinky_slot1: Next action on the next reboot = NONE

It looks like something is gong on?
But still the first image is running. A next rest will show the previous output.

( Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3).

Do I miss something here?

[BvdP4Celsius]

Some update:

I flashed the second Blinky at address 073000, not 067000

When calling boot_request_upgrade I see

[00:00:05.784,973] <dbg> mcuboot_util: boot_write_magic: writing magic; fa_id=5 off=0x79ff0 (0xffff0)
[00:00:05.795,257] <dbg> mcuboot_util: boot_write_swap_info: writing swap_info; fa_id=5 off=0x79fd8 (0xfffd8), swap_type=0x2 image_num=0x0
[00:00:05.808,746] <inf> Blinky_slot1: Button 1 pressed, boot_request_upgrade
[00:00:05.816,711] <inf> mcuboot_util: Swap type: test
[00:00:05.822,509] <inf> Blinky_slot1: Next action on the next reboot = TEST

[Vidar Berg]

Looks like the new image is being copied to the primary slot based on the log output. Do you see if the new application starts up?

Note that you can flash the app_moved_test_update.hex.hex from the <build dir>/zephyr/ if you are building the app with the CONFIG_BOOTLOADER_MCUBOOT setting enabled. Then you don't have to specify the start address.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-ncs.html#using-mcuboot-in-nrf-connect-sdk

[BvdP4Celsius]

Hi Vidar,

The second application is not starting. Only the first one is always running. 

I am aware of the setting you mentioned. That is how I flash the first image. Only the second one is done by jflash. My goal is to toggle between the first and second image.

[BvdP4Celsius]

Hi Vidar,

My concept if finally working! I was able to use the smp_svr and foud out what was wrong in my setup.

I took the following steps:

1. Build the MCUboot (mcuboot\boot\zephyr)
2. Flash the MCUboot on the nRF52840DK with VSCode
3. Created a blinky1, building it and flash it with VSCode
   The application will flash all leds.
   The application will call boot_request_upgrade(BOOT_UPGRADE_TEST); when button 1 is pressed
   The application will reboot when button2 is pressed.
   The application will call boot_write_img_confirmed(); when button 3 is pressed.
4. Created a blinky2, building it and flashed it with JFlash to address 00086000!!
   
5. The application will flash 2 leds.
   The application will call boot_request_upgrade(BOOT_UPGRADE_TEST); when button 1 is pressed
   The application will reboot when button2 is pressed
   The application will call boot_write_img_confirmed(); when button 3 is pressed.
   

 Now I am able to switch from blinky1 to blinky2 as planned.

Still one important question. Why do I need to flash the second blinky to address 00086000 while the dts file stated:

slot1_partition: partition@73000 {

      label = "image-1";

      reg = <0x00073000 0x00067000>;

    };

 I was expecting the address to be 0x00073000 ...

[Vidar Berg]

Hi,

Thanks for the update. I'm glad to hear that it works now.

The Partition Manager takes over and controls the placement of the various sections when you do a multi-image build. This is why the DT entries are ignoreg, which can be confusing. You can find the actual placement of the different flash regions listed in the <build dir>/partitions.yml file.

[cagri]

Hello,

I’m working on a similar setup and I believe I’m encountering the same issue. That’s why I’d like to ask you a few questions.

First, let me briefly explain the structure of my project:
I’m using an external SPI flash configured with FATFS as mass storage (the external flash is only used for storage — mcuboot_secondary is not defined in the external flash region).
The test scenario I’m trying to implement is quite similar to yours.

I built the Blinky1 firmware in a way that it checks whether "app_signed.hex" exists in the external flash. I then flashed Blinky1 to the board using J-Link through VS Code.
If app_signed.hex is found, it is copied into the mcuboot_secondary region (FLASH_AREA_ID(mcuboot_secondary)), and then boot_request_upgrade(BOOT_UPGRADE_PERMANENT) is called.
Right after that, the system is rebooted via sys_reboot(SYS_REBOOT_COLD) to trigger the update.

Later, I modified the firmware to Blinky2, which activates different LEDs and does not check for app_signed.hex (to avoid repeated updates).
While Blinky1 is running, I connect the board via USB and copy the app_signed.hex file to the mass storage disk.
The file is detected, the steps mentioned above are executed, and the MCU resets — but it boots into Blinky1 again instead of Blinky2.

My questions are:

1. Is app_signed.hex the correct file to write into the mcuboot_secondary slot?

2. While writing to mcuboot_secondary, I encountered alignment issues. I had to pad the end of the file with 0xFF bytes to complete the write. Is this a correct approach, or am I doing something wrong?

3. After calling boot_request_upgrade(BOOT_UPGRADE_TEST);, I immediately call sys_reboot(SYS_REBOOT_COLD);. Do I need to perform any additional steps (such as confirming the upgrade) before rebooting?

I’d really appreciate any help or guidance you can provide.
Best regards,
Cagri