Date
1 - 2 of 2
MCU Bootloader offset incorrect #firmwareupdate
Benedikt Schmidt
Hi there,
I have got a problem with the MCU bootloader. To get it up and running I am following the steps documented in https://docs.zephyrproject.org/latest/guides/west/sign.html.
With some slight modifications I ended up with the following process:
west build -b stm32h735g_disco -s bootloader/mcuboot/boot/zephyr -d build/mcuboot
west build -b stm32h735g_disco -s zephyr/samples/hello_world -d build/hello-signed -- -DCONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\"
west flash -d build/mcuboot
west flash -d build/hello-signed
Unfortunately, the end result does not work, the bootloader is getting overriden by the application hello-signed. I verified this with the STM32 Cube Programmer and also checked the hex files with objdump:
build/hello-signed/zephyr/zephyr.hex: file format ihex
build/hello-signed/zephyr/zephyr.hex
architecture: UNKNOWN!, flags 0x00000000:
start address 0x0800167d
Sections:
Idx Name Size VMA LMA File off Algn
0 .sec1 0000411c 08000000 08000000 00000011 2**0
CONTENTS, ALLOC, LOAD
SYMBOL TABLE:
no symbols
build/mcuboot/zephyr/zephyr.hex: file format ihex
build/mcuboot/zephyr/zephyr.hex
architecture: UNKNOWN!, flags 0x00000000:
start address 0x0800219d
Sections:
Idx Name Size VMA LMA File off Algn
0 .sec1 0000a8a0 08000000 08000000 00000011 2**0
CONTENTS, ALLOC, LOAD
SYMBOL TABLE:
no symbols
If I understand it correctly, VMA and LMA of the hello-signed hex-file should be a different value? The corresponding flash partitions are:
&flash0 {
write-block-size = <8>;
partitions {
compatible = "fixed-partitions";
#address-cells = <0x1>;
#size-cells = <0x1>;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x0 0x10000>;
read-only;
};
storage_partition: partition@1e000 {
label = "storage";
reg = <0x1e000 0x2000>;
};
slot0_partition: partition@20000 {
label = "image-0";
reg = <0x20000 0x60000>;
};
slot1_partition: partition@80000 {
label = "image-1";
reg = <0x80000 0x60000>;
};
scratch_partition: partition@e0000 {
label = "image-scratch";
reg = <0xe0000 0x20000>;
};
};
};
Interestingly, when I program the two bin files (bootloader and signed hello-world-app) using the STM32 Cube Programmer manually at the correct offsets 0x08000000 and 08020000 the bootloader finds a valid image and tries to jump into it. The execution then still fails hard, but I would consider this already a progress:
*** Booting Zephyr OS build zephyr-v2.6.0-2414-g5224b01c96ad ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Swap type: none
I: Bootloader chainload address offset: 0x20000
I: Jumping to the first image slot
E: ***** USAGE FAULT *****
E: Illegal use of the EPSR
E: r0/a1: 0x00000020 r1/a2: 0x00000000 r2/a3: 0x08000000
E: r3/a4: 0x24005500 r12/ip: 0x00000000 r14/lr: 0x08001861
E: xpsr: 0x20000000
E: Faulting instruction address (r15/pc): 0x08020000
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x240000f0 (unknown)
E: Halting system
So basically I have got two questions:
Regards,
Benedikt
I have got a problem with the MCU bootloader. To get it up and running I am following the steps documented in https://docs.zephyrproject.org/latest/guides/west/sign.html.
With some slight modifications I ended up with the following process:
west build -b stm32h735g_disco -s bootloader/mcuboot/boot/zephyr -d build/mcuboot
west build -b stm32h735g_disco -s zephyr/samples/hello_world -d build/hello-signed -- -DCONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\"
west flash -d build/mcuboot
west flash -d build/hello-signed
Unfortunately, the end result does not work, the bootloader is getting overriden by the application hello-signed. I verified this with the STM32 Cube Programmer and also checked the hex files with objdump:
build/hello-signed/zephyr/zephyr.hex: file format ihex
build/hello-signed/zephyr/zephyr.hex
architecture: UNKNOWN!, flags 0x00000000:
start address 0x0800167d
Sections:
Idx Name Size VMA LMA File off Algn
0 .sec1 0000411c 08000000 08000000 00000011 2**0
CONTENTS, ALLOC, LOAD
SYMBOL TABLE:
no symbols
build/mcuboot/zephyr/zephyr.hex: file format ihex
build/mcuboot/zephyr/zephyr.hex
architecture: UNKNOWN!, flags 0x00000000:
start address 0x0800219d
Sections:
Idx Name Size VMA LMA File off Algn
0 .sec1 0000a8a0 08000000 08000000 00000011 2**0
CONTENTS, ALLOC, LOAD
SYMBOL TABLE:
no symbols
If I understand it correctly, VMA and LMA of the hello-signed hex-file should be a different value? The corresponding flash partitions are:
&flash0 {
write-block-size = <8>;
partitions {
compatible = "fixed-partitions";
#address-cells = <0x1>;
#size-cells = <0x1>;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x0 0x10000>;
read-only;
};
storage_partition: partition@1e000 {
label = "storage";
reg = <0x1e000 0x2000>;
};
slot0_partition: partition@20000 {
label = "image-0";
reg = <0x20000 0x60000>;
};
slot1_partition: partition@80000 {
label = "image-1";
reg = <0x80000 0x60000>;
};
scratch_partition: partition@e0000 {
label = "image-scratch";
reg = <0xe0000 0x20000>;
};
};
};
Interestingly, when I program the two bin files (bootloader and signed hello-world-app) using the STM32 Cube Programmer manually at the correct offsets 0x08000000 and 08020000 the bootloader finds a valid image and tries to jump into it. The execution then still fails hard, but I would consider this already a progress:
*** Booting Zephyr OS build zephyr-v2.6.0-2414-g5224b01c96ad ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Swap type: none
I: Bootloader chainload address offset: 0x20000
I: Jumping to the first image slot
E: ***** USAGE FAULT *****
E: Illegal use of the EPSR
E: r0/a1: 0x00000020 r1/a2: 0x00000000 r2/a3: 0x08000000
E: r3/a4: 0x24005500 r12/ip: 0x00000000 r14/lr: 0x08001861
E: xpsr: 0x20000000
E: Faulting instruction address (r15/pc): 0x08020000
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x240000f0 (unknown)
E: Halting system
So basically I have got two questions:
- What have I configured incorrectly so that the offset for the application is missing?
- Why does the application then immediately fails?
Regards,
Benedikt