Application fails to boot with MCUboot image in external flash and TF-M

RE: Application fails to boot with MCUboot image in external flash and TF-M

andvib — Sat, 18 Jul 2026 14:13:43 GMT

You were spot on - now it works! I misunderstood how app, tfm_nonsecure and mcuboot_primary ties together, so cleaning them up fixed it.

Thanks a lot!

RE: Application fails to boot with MCUboot image in external flash and TF-M

AHaug — Tue, 14 Jul 2026 12:56:15 GMT

Hi,

Apologies for the wait.

I think this might show the issue. In your attached pm_static:

tfm_nonsecure has span: [app] yet is smaller than app: 0x172000 (0x73000–0x1e5000) vs 0x18a000 (0x73000–0x1fd000). A span can never be smaller than its member.
mcuboot_primary, mcuboot_primary_app, and tfm_nonsecure all end at 0x1e5000, but app runs to 0x1fd000, i.e. 0x18000 past the slot and past the image trailer region.

And from the device logs:

"[00:00:00.055,659] <inf> mcuboot: Image index: 0, Swap type: none" should also indicate that we do not touch the spi at this point (at least w.r.t the external flash), so if theres an SPI contestion it isn't here

Could you do a pristine build with SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y and let Partition Manager place everything, relocating only mcuboot_secondary to the external_flash region, i.e do not use a static partition map yet to see if partition manager sets things up properly, and then after create the static file based on the generated partition map (You can find it here build/partitions.yml) and move only mcuboot_secondary, leaving app, tfm_nonsecure, and the mcuboot_primary* entries as PM produced them.

After regenerating, the map must satisfy: app == tfm_nonsecure (same address and size), app nested inside mcuboot_primary_app, mcuboot_primary_app starting at 0x29000 (after the pad), and app ending at 0x1e5000. The extra 0x18000 at 0x1e5000–0x1fd000 should be free or a separate storage partition, not part of app.

The fact that MCUboot boots suggests that here suggests that CONFIG_BOOT_MAX_IMG_SECTORS is adequate for reading the primary, but you could also increase CONFIG_BOOT_MAX_IMG_SECTORS for the external-flash erase-block size. Default might be a little to small for this configuration.

Kind regards,
Andreas

RE: Application fails to boot with MCUboot image in external flash and TF-M

andvib — Fri, 10 Jul 2026 07:51:47 GMT

Getting the partitions right for TF-M is difficult, so I'm also open to this being the issue. This is the compiled parititons.yml, or you can see the pm_static in my fork.

app:
  address: 0x73000
  end_address: 0x1fd000
  region: flash_primary
  size: 0x18a000
bootconf:
  address: 0xffd080
  end_address: 0xffd084
  region: bootconf
  size: 0x4
external_flash:
  address: 0x0
  end_address: 0x800000
  region: external_flash
  size: 0x800000
mcuboot:
  address: 0x0
  end_address: 0x28000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x28000
mcuboot_pad:
  address: 0x28000
  end_address: 0x29000
  placement:
    before:
    - app
  region: flash_primary
  size: 0x1000
mcuboot_primary:
  address: 0x28000
  end_address: 0x1e5000
  region: flash_primary
  size: 0x1bd000
  span:
  - mcuboot_pad
  - app
mcuboot_primary_app:
  address: 0x28000
  end_address: 0x1e5000
  region: flash_primary
  size: 0x1bd000
  span:
  - mcuboot_pad
  - app
mcuboot_secondary:
  address: 0x0
  end_address: 0x1bc000
  placement:
    align:
      start: 0x1000
  region: external_flash
  size: 0x1bc000
mcuboot_sram:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id001
  - tfm_sram
  region: sram_primary
  size: 0x10000
  span: *id001
otp:
  address: 0xffd500
  end_address: 0xffd980
  region: otp
  size: 0x480
sram_nonsecure:
  address: 0x20010000
  end_address: 0x2007fe40
  orig_span: &id002
  - sram_primary
  region: sram_primary
  size: 0x6fe40
  span: *id002
sram_primary:
  address: 0x20010000
  end_address: 0x2007fe40
  region: sram_primary
  size: 0x6fe40
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id003
  - tfm_sram
  region: sram_primary
  size: 0x10000
  span: *id003
tfm:
  address: 0x29000
  end_address: 0x68800
  placement:
    before:
    - app
  region: flash_primary
  size: 0x3f800
tfm_its:
  address: 0x68800
  end_address: 0x6c800
  inside:
  - tfm_storage
  placement:
    before:
    - tfm_otp_nv_counters
  region: flash_primary
  size: 0x4000
tfm_nonsecure:
  address: 0x73000
  end_address: 0x1e5000
  orig_span: &id004
  - app
  region: flash_primary
  size: 0x172000
  span: *id004
tfm_otp_nv_counters:
  address: 0x6c800
  end_address: 0x6e800
  inside:
  - tfm_storage
  placement:
    before:
    - tfm_ps
  region: flash_primary
  size: 0x2000
tfm_ps:
  address: 0x6e800
  end_address: 0x73000
  inside:
  - tfm_storage
  placement:
    after:
    - tfm_secure
  region: flash_primary
  size: 0x4800
tfm_secure:
  address: 0x29000
  end_address: 0x68800
  orig_span: &id005
  - tfm
  region: flash_primary
  size: 0x3f800
  span: *id005
tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
tfm_storage:
  address: 0x68800
  end_address: 0x73000
  orig_span: &id006
  - tfm_ps
  - tfm_its
  - tfm_otp_nv_counters
  region: flash_primary
  size: 0xa800
  span: *id006

This is the runtime logs I get from MCUboot:

*** Booting Zephyr OS build ncs-v3.3.0-2-gda4454231faa ***
*** Booting My Application v2.3.0-dev-fce4dac2e629 ***
*** Using nRF Connect SDK v3.3.0-a7f2e9d655e2 ***
*** Using Zephyr OS v4.3.99-da4454231faa ***
[00:00:00.024,078] <inf> mcuboot: Starting bootloader
[00:00:00.030,154] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.040,139] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.050,121] <inf> mcuboot: Boot source: none
[00:00:00.055,659] <inf> mcuboot: Image index: 0, Swap type: none
[00:00:00.154,197] <inf> mcuboot: Bootloader chainload address offset: 0x28000
[00:00:00.161,754] <inf> mcuboot: Image version: v0.0.0
[00:00:00.167,384] <inf> mcuboot: Jumping to the first image slot

This is the runtime logs from TF-M (which do look a bit cut off):

Pins have been configured as secure.
GPIO port: 0x00000000
Pin: 0x00000000
Pin: 0x00000001
Booting TF-M v2.2.2**

I get no output from the application, even when I've tried to disable the UART for MCUboot and TF-M to make sure they don't fight over the peripheral. I also added blinky code to Hello World to have a visual confirmation other than UART logs, and the LED is not blinking which supports the app never booting.

RE: Application fails to boot with MCUboot image in external flash and TF-M

AHaug — Thu, 09 Jul 2026 14:08:58 GMT

Hello!

Could you share the runtime logs and/or any error messages that you run into when trying?

Could you share your memory map (generated partitions,yml in your build folder is fine)?

I'm more leaning towards the option of there being a non-correct partitioning w.r.t tf-m partitions rather than a conflict of spi resources, but I'm not excluding that this could be the case

Kind regards,
Andreas