Skip to content

Execution halts after "Jumping to the first image slot" #2535

@suarvid

Description

@suarvid

Hi, I don't have that much experience with MCUBoot, so apologies in advance if this is just something that I am doing wrong.

I am using MCUBoot built with Zephyr, to manage applications that are also built with Zephyr.

For this issue, I've used a STM32 Nucleo H563ZI development board, and the hello world Zephyr application sample.

The application image was signed with the MCUBoot imagetool, using the command python imgtool.py sign --key ../root-rsa-2048.pem --header-size 0x400 --slot-size 0x80000 --version 1.2.3 ~/zephyrsandbox/build/zephyr/zephyr.bin hello_world_signed.bin

When using the commit with SHA 8ff6b67 and later, the following issue occurs:
I cannot get the bootloader to successfully boot start the application present in the slot0_partition. The bootloader starts, is able to validate the image magic, and proceeds to print Jumping to the first image slot. After this, the execution seems to halt, and the expected output from the application is not printed. See the terminal output below.

*** Booting MCUboot v2.2.0-207-g4ccbf41fab8d ***
*** Using Zephyr OS build v4.3.0-rc2-135-gc102a8e30e16 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Image version: v0.0.0
I: Jumping to the first image slot

Note also that the image version is set to all zeroes, even though I passed the flag --version 1.2.3 when signing the image.

However, if I revert to the commit before the one mentioned above, which has SHA dd4b01f, the application seemingly boots as expected:

*** Booting MCUboot v2.2.0-207-g4ccbf41fab8d ***
*** Using Zephyr OS build v4.3.0-rc2-135-gc102a8e30e16 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Image version: v1.2.3
I: Jumping to the first image slot*** Booting Zephyr OS build v4.2.0-3996-g7b91e8f32c4e ***
Hello World! nucleo_h563zi/stm32h563x

The signed binary was flashed to the Nucleo board using the following command: probe-rs download --chip stm32h563zi --binary-format bin --base-address 0x8010000 hello_world_signed.bin.

Am I doing something wrong? Has there been some user-facing change in how the images must be signed or the bootloader configured that I've missed, or could some issue have been introduced by or close to the first commit mentioned above?

Thanks for a great bootloader.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions