nucleo_g0b1re: Swapping image in mcuboot results in hard fault and softbricks the device

[ycsin]

Describe the bug
On STM32G0B1RE devices, mcuboot image upgrade (swapping) would result in hard fault and the device will not be able to boot again. This initially occurs on my g0b1 custom board, which can be debugged using a Segger Jlink. I also verify this on the nucleo_g0b1 tree board, which ended in the same condition albeit can't verify that it is also a hard fault as there seems to be no easy way to debug it.

To Reproduce
Steps to reproduce the behavior:

1. Build and flash the mcuboot bootloader on the nucleo_g0b1re board
2. Build and flash the mgmt/smp_svr sample on the nucleo_g0b1re board
3. Use mcumgr to upload a hello_world image and perform image test
4. Reset the device so that it performs upgrade on the next boot

You should see something like this:

*** Booting Zephyr OS build zephyr-v2.6.0-1636-g549ecbf6ca46  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.007,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.007,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.021,000] <inf> mcuboot: Swap type: test
*** Booting Zephyr OS build zephyr-v2.6.0-1636-g549ecbf6ca46  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.007,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.007,000] <inf> mcuboot: Scratch: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Boot source: scratch

And it just stay here forever and can't boot into the bootloader (bootloader likely corrupted) anymore even after reset. If the bootloader is reflashed (but the application isn't), then it will repeat the whole thing again. To boot into the bootloader again, a full chip erase is required.

After some debugging the hard fault seems to occurs at when the bootloader is erasing the flash of the device here.

Expected behavior
The mcuboot should be able to finish the swapping of the image.

Impact
Unable to perform DFU.

Environment (please complete the following information):

• OS: Windows 10
• Toolchain: GNUARMEMB
• v2.6.0-1636-g549ecbf6ca46

Additional context
To compile the bootloader for the nucleo board, I declared a scratch partition in the dts like so:

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x00010000>;
			read-only;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
			reg = <0x00010000 0x00032800>;
		};
		slot1_partition: partition@42800 {
			label = "image-1";
			reg = <0x00042800 0x00032800>;
		};
		storage_partition: partition@75000 {
			label = "storage";
			reg = <0x00075000 0x0003000>;
		};
		scratch_partition: partition@78000 {
			label = "image-scratch";
			reg = <0x00078000 0x0008000>;
		};
	};
};

The smp_svr image is signed and confirmed.

[ycsin]

@ABOSTM @FRASTM @erwango
Any idea?

@str4t0m
Do you have experience with this, if you are developing something basing off stm32g0b1re?

[ABOSTM]

@ycsin,
I suppose that problem comes with introduction of nucleo_g0b1re, and more generally with introduction of stm32g0b1/stm32g0c1/...:
those MCU have flash dualbank whereas stm32g0 series formerly support only single bank.
So current stm32g0 flash driver is currently supporting only single bank.
Driver needs to be updated to support dual bank.

[ycsin]

@ycsin,
I suppose that problem comes with introduction of nucleo_g0b1re, and more generally with introduction of stm32g0b1/stm32g0c1/...:
those MCU have flash dualbank whereas stm32g0 series formerly support only single bank.
So current stm32g0 flash driver is currently supporting only single bank.
Driver needs to be updated to support dual bank.

Yup I noticed this just now, but so far I only found that the wait idle function needs to be updated as the G0X variant only checked BSY1 while the dualbank variants have BSY1 & BSY2. Haven't read through the G0B1 reference manual though.

[ycsin]

I got an updated flash driver from @str4t0m which solved this issue, it is indeed due to the driver not supporting dual-bank flash yet. Pending @str4t0m to do a PR.

[ABOSTM]

Thanks @str4t0m :-)

[str4t0m]

#37480 will address this issue.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[ycsin]

Pending #37480, please remove stale