MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Fri, 28 Nov 2025 12:44:49 GMT

Thanks, I'll try to check it out. Does the sample work out of the box with this fix, or is additional configuration required?
i.e. zephyr/sysbuild/with_mcuboot for nrf54l15dk/nrf54l15/ns.

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Menon — Fri, 28 Nov 2025 10:41:03 GMT

Hello,

Sorry for the delay with this issue. Please check the PRs below for the FPROTECT issue:

https://github.com/nrfconnect/sdk-mcuboot/pull/576

https://github.com/nrfconnect/sdk-nrf/pull/25655

Kind Regards,

Abhijith

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

BloPoPs — Thu, 23 Oct 2025 14:54:12 GMT

Hello,

any update on this? Will it be fixed on NCS v3.2.0? I have the same problem on my own custom board using MCUBoot and TF-M. And I cannot remove the TF-M.

It can also be reproduce following the NCS intermediate course, Lesson 9 Exercise 5, on the nRF54L15DK cpuapp/ns

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Wed, 22 Oct 2025 12:47:49 GMT

Hi.

The size of MCUBoot alone is what causing the issue in your case, 96 kiB > 64 kiB. Are you using all that space, or can you reduce it?

I usually find 0xc000 (48 kiB) to be sufficient for mcuboot, and leaves room for debug and logging. If that's sufficient for you, I would suggest editing pm_static.yml like so:

mcuboot:
  address: 0x00000000
  size:    0x000c000

Setting size to 0x10000 might work as well, although I'm not sure as it sits right at that 64 kiB limit.

Since that is all you have in your pm_static.yml, the automatic partition manager should resolve the rest of the partitions as well.

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Yannick Bus — Wed, 22 Oct 2025 12:37:18 GMT

Hello,

Our pm_static.yml has only a single entry:

mcuboot:
  address: 0x00000000
  size:    0x00018000

as far as i can see from the generated partitions.yml there isnt anything too crazy:

mcuboot:
  address: 0x0
  end_address: 0x18000
  region: flash_primary
  size: 0x18000
mcuboot_pad:
  address: 0x18000
  end_address: 0x18800
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x800
mcuboot_primary:
  address: 0x18000
  end_address: 0x165000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x14d000
  span: *id001
mcuboot_primary_app:
  address: 0x18800
  end_address: 0x165000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x14c800
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x14d000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x14d000

The only thing i can think of is that we are using an external flash chip for the mcuboot_secondary?

Thank you for your reply!

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Wed, 22 Oct 2025 12:17:15 GMT

Hi. Maybe I can provide some help. If FProtect fails it is likely that your MCUBoot primary partition has a too big offset from the start of the flash. On ns-builds, this will typically be caused by TFM partitions as discussed above. Since you are on a non-ns build, it means something else is taking up that space. For instance, I wouldn't be surprised if this happens when using MCUBoot as a second stage bootloader.

If you don't need flash protection you can use CONFIG_FPROTECT=n (in sysbuild/mcuboot.conf) to disable it as mentioned, although I would not recommend this as it increases the chance of bugs related to flash-writes (FOTA etc.) to brick your device.

If you need flash protection it would be useful if you can share your pm_static.yml if you have one, or build/partitions.yml. In the latter file, you can check which partitions are before mcuboot_primary. mcuboot_primary address needs to be before 0x10000 on nRF54L15.

If I'm not mistaken, I believe MCUBoot simply looks for the begining of mcuboot_primary, and tries to protect everything before it (including mcuboot itself), and the maximum fprotect size is 64 kiB (0x10000).

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Yannick Bus — Wed, 22 Oct 2025 11:56:48 GMT

Hello,

We are having the same issue as the gentleman above, enabling FProtect for us seems to result in "<err> mcuboot: Protect mcuboot flash failed, cancel startup." However we are allready on a non-ns build.

Have there been any updates or workarounds for this issue found in the meantime?

Kind Regards,
Yannick Bus

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Menon — Mon, 29 Sep 2025 14:03:21 GMT

Hello,

I understand your concern, and I completely agree that this needs to be fixed. I am closely following the issue and will update you as soon as it is resolved. I’m sorry for the delay and apologize for the inconvenience this has caused.

Kind regards,
Abhijith

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Thu, 18 Sep 2025 16:09:02 GMT

Thank you for the update, and thanks for reporting it internally.

I believe the build would probably succeed using the non-ns variant of the board, and I believe it would also work by disabling FPROTECT. However, this is a very big compromise considering it might make it challenging to get our product certified with regards to the upcoming IoT security regulations such as CRA, where DFU/FOTA will be a requirement and most points under CRA Annex 1 relates to the configurations discussed in this thread. It would also be surprising if such a compromise is required, considering security is one of the selling points of the nRF54 series is:

"
Advanced security features with physical protection
With more IoT security regulations, customers increasingly recognize the value of security. The nRF54L Series enables secure products, integrating features such as secure boot, secure firmware update, secure storage, a trusted execution environment enabled by TrustZone, and a cryptographic accelerator. These features, alongside side-channel leakage protection and tamper detectors, fulfill essential and rigorous security requirements.
"

Also, I imagine there are very few instances where you would want to use TFM without FPROTECT? I might be missing something, but wouldn't TFMs security be compromised by the fact that the application can simply modify the TMF? As far as I can tell they go hand in hand.

So to assist customers planning to use the nRF54 for its secure features, or customers that want to be compliant with existing and future cybersecurity regulations and care about certification, it would be very helpful to have a sample in the nRF Connect SDK that has security enabled by default (possibly two samples, one central device and one peripheral?). As a minimum for compliance with the most central IoT security regulations, it should probably include the following:

1. Builds for the _ns variant of the nRF54 development kits with TFM.
a. to be compliant with most points under CRA Annex 1.
2. Has secure bluetooth with recommended DFU services enabled.
a. Assuming most customers choosing the 54 series are interesting in using bluetooth.
b. DFU to be compliant with CRA requirements related to security updates and lifecycle support.
3. Uses the key provisioning and KMU for the benefits you mentioned.

Or whichever configuration you see fit to actually "fulfill essential and rigorous security requirements." and be compliant with "IoT security regulations", because that is essentially what I'm trying to achieve. This also ties into the "secure by default configuration" listed under CRA Annex 1.

I'm referring a lot to CRA considering it is one of the big upcoming IoT security regulations, and it will be become part of the CE requirements in 2027.

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Menon — Tue, 16 Sep 2025 12:40:05 GMT

Hello,

Sorry for the delay in getting back to you. This issue has been reported internally, and we are working on it. I will update you once we have a resolution. The error seems to occur because FPROTECT couldn’t protect the MCUBoot partition for some reason.

There is a similar case, but the customer there is apparently fine running without the _ns version of the build configuration.

Kind regards,
Abhijith

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Fri, 05 Sep 2025 08:18:27 GMT

Thank you for your detailed answer, it does seem quite challenging to fit NSIB+2xMCUBoot+TFM within the first 64 kiB though, so until I have fully resolved the FPROTECT issue I think I might have to stick with MCUBoot. Regardless I suppose:

[quote userid="115767" url="~/f/nordic-q-a/123779/mcuboot-sysbuild-ns-variant-e-protect-mcuboot-flash-failed-cancel-startup/547685"]This design allows MCUboot to be updated later if bugs or security issues are discovered[/quote]

is the core of the it. I have currently configured MCUBoot to use KMU with 3 slots and key revocation, and provision 3 keys during programming, so I would guess that would give most of the other benefits you mentioned using MCUBoot as immutable bootloader?

Returning to my original issue, it seems it isn't fully resolved after all. As soon as I enable bluetooth and want to have a secure connection, I get the following error:

<err> bt_ecc: Failed to generate ECC key -134
<wrn> bt_smp: Public key not available

And if I try to initialize a pairing, I get:

<err> bt_ecc: psa_import_key() returned status -134
<wrn> bt_smp: Received invalid public key
<err> app: Security change failed for [xx:xx:xx:xx:xx:xx (random)]. Error: [1]

Which appears to be the same issue experienced here and here. The proposed solution in both cases is to ensure that CONFIG_TFM_PROFILE_TYPE_MINIMAL is not set.

Is there a way to get around this? Any options I can enable to only get the cryptography I need, or provision the keys required?

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Menon — Wed, 03 Sep 2025 19:49:43 GMT

Hello,

Good to hear that you figured out the partition side correctly.

[quote user="Erlend Isachsen"]However, searching through this raised another question. Do you know if there is a reason why the "hello world TFM" has options for NSIB+MCUboot two stage bootloader, and not just MCUboot as immutable bootloader? Are there any benefits to using NSIB+MCUboot as opposed to only MCUboot (appart from being able to upgrade MCUboot). I'm thinking especially with regards to security, KMU etc.[/quote]

The reason the hello_world_tfm sample on nRF54L uses NSIB + MCUboot is because NSIB anchors the Root of Trust in hardware by storing the boot verification keys in the Key Management Unit (KMU) instead of inside the bootloader binary. See the documentation here.

This ensures the keys cannot be modified by software and can even be rotated or revoked securely if needed. See the section Revoking private keys

NSIB is very small and fixed, so its main function is to verify that MCUboot is genuine using the KMU keys, and then hand over control. This design allows MCUboot to be updated later if bugs or security issues are discovered, while the trust foundation remains protected in hardware.

Using only MCUboot would still work, but it would rely only on flash protection, which is not as strong as KMU based security.

Kind Regards,

Abhijith

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Erlend Isachsen — Thu, 21 Aug 2025 10:57:00 GMT

Hi Menon, thank you for your answer.

The problem seems to be that the size of MCUboot and TFM NVS storage (mcuboot, tfm_its, tfm_otp_nv_counters) shifts the MCUboot primary as far back as 0x16000, which is beyond what fprotect can handle. This is similar to what is discussed in this thread.

I also figured out that the "hello world TFM" sample actually supports nrf54l15dk/nrf54l14/cpuapp/ns, and had some extra KConfig fragments for sysbuild and the application that handle MCUboot with TFM. While the fragments in that sample are meant for a two-stage bootloader, I noticed the prj_bootloaders.conf had the option CONFIG_TFM_PROFILE_TYPE_MINIMAL=y. I tried to take that over to the "with_mcuboot" sample which made the sample boot with FPROTECT enabled (see attached image for the working build configuration, if anyone else encounters the same problem). With the reduced size, mcuboot_primary ends up at 0xe000 which is just within the limit for FPROTECT on nRF54l15.

So from this I believe I will be able to extract a pm_static.yml that I can use for my application, and build it with MCUboot and TFM.

However, searching through this raised another question. Do you know if there is a reason why the "hello world TFM" has options for NSIB+MCUboot two stage bootloader, and not just MCUboot as immutable bootloader? Are there any benefits to using NSIB+MCUboot as opposed to only MCUboot (appart from being able to upgrade MCUboot). I'm thinking especially with regards to security, KMU etc.

RE: MCUBoot+sysbuild+ns-variant: E: Protect mcuboot flash failed, cancel startup.

Menon — Thu, 21 Aug 2025 09:13:38 GMT

Hello,

Sorry for the delayed response. I have been working on this and was able to see the issue here. It’s not related to your setup. The error you’re seeing is coming from here, and I believe it’s caused by the fprotect backend. The sample works fine with the build configuration nrf54l15dk/nrf54l15dk/cpuapp.

Kind regards,
Abhijith