• State Verified Answer
  • Replies 9 replies
  • Subscribers 70 subscribers
  • Views 2399 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296978
Options

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

Parents
  • 0

    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?

Reply
  • 0

    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?

Children
  • 0 in reply to allard.p

    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.

Related