MCUBoot stuck after 'Jumping to first image slot'

[allard.p]

I'm trying to integrate MCUboot into my application, as immutable bootloader (CONFIG_BOOTLOADER_MCUBOOT=y). Building succeeded, but after programming the board gets stuck at 'I: Jumping to the first image slot'. To verify I also tried the hello_world example, only enabling MCUboot in the .conf, this results in the same problem.

When I try to debug in VScode main is never reached and I'm unable to halt. When I try Ozone I can see that the board is stuck at address 0x000196C8 which is a branch instruction to itself (so a while(1) loop).

In partitions.yml in the build folder I can find the following:

tfm:
  address: 0x10200
  end_address: 0x20200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x10000

Address 0x000196C8 is within this range, so I guess the board becomes stuck in TF-M. There is no output on UART1. I found another Q&A about this topic, where someone stated this is a known issue, but I cannot find a entry of this in the known issue list of NCS 2.1.0. What is going on here? Is it my custom board? How do I debug TF-M?

I'm using:

NCS 2.1.0

Hello world example

Custom board

[allard.p]

Hi,

Any news on this?

[allard.p]

I managed to debug this further. The application is successfully booted by MCUBOOT, but is stuck in TFM initialization.

It is stuck on the following assert inside nrf_spu_flashregion_set:

NRFX_ASSERT(!(p_reg->FLASHREGION[region_id].PERM & SPU_FLASHREGION_PERM_LOCK_Msk));

The function is called with the following arguments:

p_reg: 0x500030000

region_id: 0

secure_attr: true

permissions: 7

lock_conf: false

and p_reg->FLASHREGION[0].PERM is 277

The call stack is the following:

nrf_spu_flashregion_set

spu_regions_reset_all_secure

spu_init_cfg

tfm_hal_set_up_static_boundaries

tfm_core_init

main

Any ideas what is going on here? Solutions given in this topic  do not work.

[allard.p]

I managed to track down the issue, with help of this topic, and further debugging.

The problem is FPROTEXT, mcuboot locks sectors. When TF-M boots it tries unlock all sectors in spu_regions_reset_all_secure. This is not possible and causes the system to hang in an assertion.

The solution is to add an overlay for MCUboot where FPROTECT is disabled. Add the following to CMakeLists.txt:

# Use custom MCUBoot definitions
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
    list(APPEND mcuboot_OVERLAY_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
endif()

Then add mcuboot.conf in the same directory, containing the following:

CONFIG_BOOT_MAX_IMG_SECTORS=256
CONFIG_FPROTECT=n

I think Nordic needs to set CONFIG_FPROTECT to n by default in MCUboot now SPM is replaced by TF-M?

[ClemensG]

Might be I had the same with ncs 2.1.2 (same symptoms - didn't checked source or debugged).

Sadly your solution leads to:

*** Booting Zephyr OS build v3.1.99-ncs1-1 ***
I: Starting bootloader
W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
W: Cannot upgrade: not a compatible amount of sectors
E: Unable to find bootable image

Due to time reasons I switched to SPM.