Hello!
I think there is a problem in NCS v3.3.0. nRF54L target, sysbuild build with MCUboot and TF-M, partition layout coming from devicetree (SB_CONFIG_PARTITION_MANAGER=n) — the standard combined slot0_partition with slot0_s_partition/slot0_ns_partition underneath.
The image signs and flashes fine, MCUboot loads it, then the device drops straight into:
??@0x0001171e (tfm_hal_system_halt)
??@0x00010f4a (ns_fault_service_call_handler)
VTOR_NS=0, MSP_NS/PSP_NS garbage, no NS log because NS never gets to run.
After poking around, what's happening is memory_regions.non_secure_code_start is pointing CONFIG_TFM_MCUBOOT_HEADER_SIZE (0x800) short of where the NS vector table actually lives. So TF-M reads SP and PC from the ROM_START_OFFSET zero-pad at the start of the NS partition and faults.
The interesting bit is that NCS already passes the offset through for the secure side. In nrf/modules/trusted-firmware-m/CMakeLists.txt line 111:
-DTFM_MCUBOOT_OFFSET=${CONFIG_TFM_MCUBOOT_HEADER_SIZE}
tfm_boards/partition/region_defs.h picks that up and S_CODE_START ends up correct. But the NS side over in upstream TF-M (platform/ext/target/nordic_nrf/common/core/target_cfg.c) uses a different macro:
.non_secure_code_start =
(uint32_t)®ION_NAME(Load$$LR$$, LR_NS_PARTITION, $$Base) +
BL2_HEADER_SIZE,
BL2_HEADER_SIZE, not TFM_MCUBOOT_OFFSET. And nothing in NCS sets it, so it sits at its TF-M default of 0x000. Two halves of the same idea, only one of them gets told.
Easiest fix I can see — one line right next to the existing offset line:
-DTFM_MCUBOOT_OFFSET=${CONFIG_TFM_MCUBOOT_HEADER_SIZE}
-DBL2_HEADER_SIZE=${CONFIG_TFM_MCUBOOT_HEADER_SIZE}
I don't think it'll break the older Partition Manager flows — on those LR_NS_PARTITION$$Base is already past the header, so adding BL2_HEADER_SIZE is just adding zero.
In the meantime I'm working around it per-app by appending the same -DBL2_HEADER_SIZE=... to TFM_CMAKE_OPTIONS in my app's CMakeLists.txt, which works fine but feels like something that should live in NCS.
Cheers Dom!