This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hello World Hard Fault When Executed from mcuboot

Hi,

I am trying to have mcuboot in Zephyr to execute the hello world sample (mcuboot\samples\zephyr\hello-world).

I generated the bin for hello world and signed it as shown below:

python.exe .\imgtool.py sign --key <my_path>\bootloader\mcuboot\root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --slot-size 0x60000 --pad-header <my_path>\bootloader\mcuboot\samples\zephyr\hello-world\build_nrf5340dk_nrf5340_cpuapp\zephyr\zephyr.bin <my_path>\bootloader\mcuboot\samples\zephyr\hello-world\build_nrf5340dk_nrf5340_cpuapp\zephyr\signed-hello.bin

I then program the signed bin to the slot0 partition which starts at address 0x10000. So far so good.

Then, I run mcuboot in Segger, it appears to validate the signed image correctly, but when it jumps to it a hard fault is generated, see below:

*** Booting Zephyr OS version 2.4.99 ***
[00:00:02.678,649] [0m<inf> mcuboot: Starting bootloader[0m
[00:00:02.679,382] [0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3[0m
[00:00:02.679,901] [0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3[0m
[00:00:02.680,328] [0m<inf> mcuboot: Boot source: none[0m
[00:00:02.680,725] [0m<inf> mcuboot: Swap type: none[0m
[00:00:02.773,071] [0m<inf> mcuboot: Bootloader chainload address offset: 0x10000[0m
[00:00:02.773,437] [0m<inf> mcuboot: Jumping to the first image slot[0m
[00:00:06.367,126] [1;31m<err> os: ***** HARD FAULT *****[0m
[00:00:06.367,401] [1;31m<err> os: Fault escalation (see below)[0m
[00:00:06.367,675] [1;31m<err> os: ***** BUS FAULT *****[0m
[00:00:06.367,950] [1;31m<err> os: Precise data bus error[0m
[00:00:06.368,225] [1;31m<err> os: BFAR Address: 0xc[0m
[00:00:06.368,499] [1;31m<err> os: r0/a1: 0x24822bd9 r1/a2: 0x0eef9269 r2/a3: 0xbf1a8b0a[0m
[00:00:06.368,957] [1;31m<err> os: r3/a4: 0x8e883ccf r12/ip: 0xec0c134d r14/lr: 0xb818b317[0m
[00:00:06.369,415] [1;31m<err> os: xpsr: 0xf9e12b51[0m
[00:00:06.369,689] [1;31m<err> os: Faulting instruction address (r15/pc): 0xc5ce9894[0m
[00:00:06.370,056] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0[0m
[00:00:06.370,422] [1;31m<err> os: Fault during interrupt handling
[00:00:06.370,697] [1;31m<err> os: Current thread: (nil) (unknown)[0m
[00:00:06.376,007] [1;31m<err> os: Halting system[0m

So I think I need to better understand how the signing and addition of the header to the signed image affects the resulting binary. As mentioned, the partition for the image starts at 0x10000, so the code is linked having that as the start address. But if the header is added to the image prior to where it starts, to which address should the signed binary be flashed to? I don't think it should be flashed to 0xFF80 so the header starts there and the application at 0x10000, because that would be overlapping to the mcuboot partition. On the other hand, flashing the image to start at 0x10000 is what I'm currently doing; I think the cause of fault may be because of the shift of addresses due the addition of the header.

Thoughts?

Thanks in advance!!

Parents Reply Children
No Data
Related