DFU target API on NCS v3.4.1

RE: DFU target API on NCS v3.4.1

Tom01 — Wed, 30 Sep 2026 14:07:44 GMT

[quote userid="5203" url="~/f/nordic-q-a/129300/dfu-target-api-on-ncs-v3-4-1/571754"]There are different boot-loader setups, and one has the name "SECURE_BOOT" and uses an immutable b0 boot-loader and additional mcuboot (2 stages). So the terms you used truggered me to clarify, what your intention is.[/quote]

It's a bit confusing, because the secure boot architecture documentation uses the term "immutable bootloader" for the bootloader selected for a single stage setup and the NSIB has "immutable bootloader" in its name... 😃

I tried your fix, but unless I have done something wrong it doesn't solve the secure fault. Also, I think the partition selection might not be the issue, because the secure fault is triggered on the start of the flash range of my slot1 partition. That looks like slot1 is correctly selected, doesn't it?

[quote userid="5203" url="~/f/nordic-q-a/129300/dfu-target-api-on-ncs-v3-4-1/571754"]Not sure, what they mean by "image swap"[/quote]

Image swap/swap mode seems to be the default mode for MCUboot, where the application always runs from the primary slot and the update is always written to the secondary slot. It made the impression that this case is best documented, so I wanted to start out there.

RE: DFU target API on NCS v3.4.1

Achim Kraus — Wed, 30 Sep 2026 11:44:51 GMT

Just to mention: I'm a developer and not related to Nordic ;-).

There are different boot-loader setups, and one has the name "SECURE_BOOT" and uses an immutable b0 boot-loader and additional mcuboot (2 stages). So the terms you used truggered me to clarify, what your intention is.

Your app crashes, because in your partition setup "flash_img.c" gets it wrong. It takes then the primary slot for upload and that crashes.

At the begin of the year, it also toke the primary slot for the Thingy:91/X, but there the root cause was slightly different.

The patch is pretty small, you may even try to edit "flash_img.c" to see, if that works for you.

> it is listed that NSIB only supports Dual-slot direct-xip upgrades.

Not sure, what they mean by "image swap", at least I'm mainly common with the

"Dual-slot direct-xip"

but that swaps the slots as well, means, download to secondary slot, and on update swap primary and secondary. For that I write the app (tf-m + ns-app) to the secondary slot, and mucboot copies both to the primary and executes it from there.

Anyway, let me recommend, you start with the fix and we will see, if that is changing something.

RE: DFU target API on NCS v3.4.1

Tom01 — Wed, 30 Sep 2026 08:15:30 GMT

Hey Achim,

I saw that thread, but did not fully recognize it as being relevant here...

[quote userid="5203" url="~/f/nordic-q-a/129300/dfu-target-api-on-ncs-v3-4-1/571736"]Do you mean a two stage approach?[/quote]

My understanding is probably lack-luster:

I meant a single stage approach. The documentation for the secure bootloader chain (nrfconnectdocs.nordicsemi.com/.../bootloader.html states that "The first implementation (i.e. the ) provides the first stage in the chain, the immutable nRF Secure Immutable Bootloader, which could be either nRF Secure Immutable Bootloader or MCUboot. It does not support bootloader upgradability, but it is useful if you need just the capability to update your application."

Further down in the same documentation (https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.html#immutable-bootloader) the following is stated: "You should add a second-stage bootloader only when necessary by the design or firmware upgrade needs. Adding the second stage bootloader for no reason will lead to a degradation of the system’s overall security, as attackers can exploit bugs that may exist in either bootloader.".

In this documentation (https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.html#supported-features-and-configurations) it is listed that NSIB only supports Dual-slot direct-xip upgrades.

That would conflict with the secure-labeled TF-M partitions again, wouldn't it?

Therefore my approach was to go with a single stage approach using only MCUboot with image swapping.

Do you or Sigurd Hellesvik have a different take on the documentation's recommendation to not use a two stage approach if it is not strictly necessary?

Or is my understanding false, that Dual-slot direct-xip upgrades would conflict with secure partitions because the non-secure partition would have to write to a secure flash section?

Thanks,

Tom

RE: DFU target API on NCS v3.4.1

Achim Kraus — Wed, 30 Sep 2026 05:17:45 GMT

> My goal is to use the immutable MCUboot bootloader

Do you mean a two stage approach? Because

> boot_partition: partition@0

indicates, that only one is used.

> The code compiles and runs, but causes a "SECURE FAULT" when running `dfu_target_write`:

Yes, that's the case since start of the year on different devices and NCS versions. It was caused by different issues, mainly failing to select the right partition to upload the update in "flash_img.c". Maybe it works, if you really switch to the "immutable 2 stage" approach, because that seems to be the used one in the samples.

For the single stage bootloader, the current issue is NCS 3.4.0, nRF91, DFU without external flash and without SECURE_BOOT is broken . You may cherry-pick the patch from fix.

RE: DFU target API on NCS v3.4.1

Tom01 — Tue, 29 Sep 2026 09:35:47 GMT

Hey Sigurd,

thank you for the quick reply!

So, you would update the slot1_partition as the following?

slot1_partition: partition@80000 {
    compatible = "zephyr,mapped-partition";
    label = "image-1";
    reg = <0x00080000 0x70000>;
    ranges = <0x0 0x80000 0x70000>;
    #address-cells = <1>;
    #size-cells = <1>;
};

Do I need to add something like this?

/ {
    chosen {
        nordic,slot1_partition = &slot1_partition;
    };
};

I tried combinations of the above, but I still get the same secure fault.

May I ask you to explain which image number is required when using "dfu_target_init"?

Best,

Tom

RE: DFU target API on NCS v3.4.1

Sigurd Hellesvik — Tue, 29 Sep 2026 09:21:53 GMT

Hi,

With normal MCUboot swap behaviour, MCuboot does not know about TF-M. It just swaps the application as one blob.

The application uploads the DFU candidate to the secondary slot. And the application only has Non-Secure access.
So the secondary slot needs to be fully Non-Secure.

From your DTS file:

"
* 0x0008_0000 Secondary image area (448 KB):
* 0x0008_0000 Secure image secondary (192 KB)
* 0x000b_0000 Non-secure image secondary (256 KB)
"

For a normal swap-based DFU, I would recommend not splitting the Secondary slot int two partitions; Just use one.

Regards,
Sigurd Hellesvik