DFU sample, missing boot_set_pending or boot_request_upgrade

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

cagri — Thu, 15 May 2025 08:28:21 GMT

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:

Is app_signed.hex the correct file to write into the mcuboot_secondary slot?
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?
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

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

Vidar Berg — Tue, 02 Aug 2022 11:57:00 GMT

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.

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

BvdP4Celsius — Tue, 02 Aug 2022 11:23:35 GMT

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:

Build the MCUboot (mcuboot\boot\zephyr)
Flash the MCUboot on the nRF52840DK with VSCode
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.
Created a blinky2, building it and flashed it with JFlash to address 00086000!!
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 ...

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

BvdP4Celsius — Tue, 02 Aug 2022 06:38:19 GMT

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.

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

Vidar Berg — Mon, 01 Aug 2022 15:16:47 GMT

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

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

BvdP4Celsius — Mon, 01 Aug 2022 14:48:36 GMT

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

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

BvdP4Celsius — Mon, 01 Aug 2022 13:36:13 GMT

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?

RE: DFU sample, missing boot_set_pending or boot_request_upgrade

Vidar Berg — Mon, 01 Aug 2022 12:16:22 GMT

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