stm32h573i_dk and similar: MCUBoot with external flash not able to update image

[Jowllel]

Describe the bug

When trying to run the "boards/st/hello_world_xip" sample from #88579 (or the upcoming Zephyr release) with the following lines added to prj.conf:

CONFIG_FLASH=y
CONFIG_LOG=y
CONFIG_FLASH_LOG_LEVEL_ERR=y

The external flash initialisation fails with the following log message: "flash_stm32_xspi: XSPI Init failed"

However, the flash API is used to update or manage the MCUBoot images. (E.g. Flash Image API, MCUboot image contol API, IMG_MANAGER). So if the external flash isn't initialised, the image can't be updated or swapped.

Regression

• This is a regression.

Steps to reproduce

1. Use stm32h5 run application in external flash memory XIP #88579 or the upcoming Zephyr release, if the PR is already merged into main.
2. Add the following lines to prj.conf of the "boards/st/hello_world_xip" sample

CONFIG_FLASH=y
CONFIG_LOG=y
CONFIG_FLASH_LOG_LEVEL_ERR=y

3. build the sample: west build -p -b stm32h573i_dk samples/boards/st/hello_world_xip/ --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y
4. flash the sample to a stm32h573i_dk board: west flash
5. Open UART Port of the ST-Link and the error should appear in the log.

Relevant log output

flash_stm32_xspi: XSPI Init failed

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

• OS: Windows
• Zephyr: stm32h5 run application in external flash memory XIP #88579

Additional Context

No response

[Jowllel]

@FRASTM

[erwango]

I don't think it is appropriate to raise issue on non merged PR, specially if you're adding your own configuration on top.
I understand this is a requested feature for you, but this isn't a bug from our perspective (if anyone does the same we'll be quickly overwhelmed by issues).
Please convert to discussion to follow up on this point.

[Jowllel]

I just thought that I'd create a new Issue, because the supporters from the mentioned PR said they wouldn't fix it. So nothing about the flash API Initialisation should change in the PR.
I'm sorry if I'm a bit stressful about this. But I have a project deadline in 2 weeks, where our mainboard need an Image which can be remotely updated, because their getting deployed in the country.
So if there's any workaround or similar I'd be happy to. I just need a remotely updateable Image.
Or should we wait with the Issue until the PR is merged an then proceed? Maybe with a quick-fix until then.
But, however. Thanks a lot for your help.

[FRASTM]

What I see with that usecase is :
when starting the execution on the xspi NOR flash (in XiP, after mcuboot) the flash_stm32_xspi driver is calling the flash_stm32_xspi_init. This function should retrun without trying to re-init the xspi where we are executing on
That's the prupose of the check (if stm32_xspi_is_memorymap at line

zephyr/drivers/flash/flash_stm32_xspi.c

Line 2050 in 732a3a5

#ifdef CONFIG_STM32_MEMMAP

1. The #ifdef CONFIG_STM32_MEMMAP must be replaced by #ifdef CONFIG_FLASH_STM32_XSPI_XIP
2. The check on the clock_control_get_status returns CLOCK_CONTROL_STATUS_UNKNOWN. I would propose to replace with

if (clock_control_get_status(DEVICE_DT_GET(STM32_CLOCK_CONTROL_NODE),
				     (clock_control_subsys_t) &dev_cfg->pclken)
				     != CLOCK_CONTROL_STATUS_OFF) {

[FRASTM]

If you prefer, I can now add this change in a new commit on the original PR.

[Jowllel]

That would be great, yes.
Thanks a lot

[FRASTM]

That would be great, yes. Thanks a lot

done in the #88579

[Jowllel]

Okay. The Flash init error disappeared now, but it still seems that there's a problem with the external flash, because everytime when the flash is accessed there's a bus fault. (Tested with the MCUboot command in shell)

LOG:

*** Booting MCUboot v2.2.0-59-g6e488501298c ***
*** Using Zephyr OS build v4.2.0-rc1-269-gbba24ce6b54a ***
I: Starting bootloader
I: Primary image: magic=bad, swap_type=0x0, copy_done=0x2, image_ok=0x2
I: Secondary image: magic=bad, swap_type=0x0, copy_done=0x2, image_ok=0x2
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x0
I: Image version: v0.0.0
I: Jumping to the first image slot
Hello World! from external flash  stm32h573i_dk
--> PC at 0x90000ae6

*** Booting Zephyr OS build v4.2.0-rc1-269-gbba24ce6b54a ***
uart:~$ mcuboot 
[00:00:02.723,000] <err> os: ***** BUS FAULT *****
[00:00:02.723,000] <err> os:   Precise data bus error
[00:00:02.723,000] <err> os:   BFAR Address: 0x0
[00:00:02.723,000] <err> os: r0/a1:  0x00000000  r1/a2:  0x26f49876  r2/a3:  0x0000000f
[00:00:02.723,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00005dc0 r14/lr:  0x9000a0e5
[00:00:02.723,000] <err> os:  xpsr:  0x61000000
[00:00:02.723,000] <err> os: Faulting instruction address (r15/pc): 0x9000e768
[00:00:02.723,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:02.724,000] <err> os: Current thread: 0x20000770 (shell_uart)
[00:00:02.799,000] <err> os: Halting system

With the following prj.conf: (To enable the mcuboot command):

#CONFIG_XIP=y

CONFIG_FLASH=y
CONFIG_LOG=y
CONFIG_FLASH_LOG_LEVEL_ERR=y
CONFIG_SHELL=y
CONFIG_FLASH_SHELL=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SHELL=y
CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_FLASH_MAP=y