[STM32H750B-DK] MCUboot external flash support - application not linking to QSPI memory-mapped address

[cyq97]

Describe the bug

MCUboot External Flash Support Issue for STM32H750B-DK

Summary

I'm experiencing issues with MCUboot external flash configuration when using the samples/sysbuild/with_mcuboot example on the STM32H750B-DK board. The application image is not being linked to the external QSPI flash memory-mapped address (0x90000000) as expected.

Environment

• Zephyr Version: [Current version]
• Board: stm32h750b_dk
• Sample: samples/sysbuild/with_mcuboot

Build Command

west build -b stm32h750b_dk --sysbuild samples/sysbuild/with_mcuboot

Issue Description

Build Warnings

During the MCUboot compilation, I'm getting multiple warnings indicating that MCUboot cannot determine the flash parameters for external partitions:

CMake Warning at CMakeLists.txt:374 (message):
  WARNING: Using default MCUboot signing key file, this file is for debug use
  only and is not secure!

CMake Warning at CMakeLists.txt:521 (message):
  Unable to determine erase size of slot0 partition, cannot calculate minimum
  sector usage

CMake Warning at CMakeLists.txt:530 (message):
  Unable to determine erase size of slot1 partition, cannot calculate minimum
  sector usage

CMake Warning at CMakeLists.txt:544 (message):
  Unable to calculate minimum number of sector sizes, falling back to 128
  sector default.  Please disable CONFIG_BOOT_MAX_IMG_SECTORS_AUTO and set
  CONFIG_BOOT_MAX_IMG_SECTORS to the required value

CMake Warning at CMakeLists.txt:608 (message):
  Unable to determine erase size of slot0 or slot1 partition, setting to 1
  (this is probably wrong)

CMake Warning at CMakeLists.txt:613 (message):
  Unable to determine write size of slot0 or slot1 partition, setting to 8
  (this is probably wrong)

Incorrect Link Address

The generated application firmware (zephyr/build/with_mcuboot/zephyr/zephyr.signed.hex) shows the following header:

:020000040800F2
:100000003DB8F3960000000000040000FC49000029
:1000100000000000000000000000000000000000E0
:1000200000000000000000000000000000000000D0

The extended linear address record :020000040800F2 indicates that the application is being linked to internal flash (0x08000000) instead of the expected QSPI flash memory-mapped address (0x90000000).

Expected Behavior

For STM32H750B-DK, which has limited internal flash (128KB), the application images should be:

• MCUboot bootloader: Internal flash (0x08000000)
• Application images (slot0/slot1): External QSPI flash (0x90000000)

The hex file should show an extended linear address record like :020000049000XX for the application.

Hardware Configuration

STM32H750B-DK features:

• Internal Flash: 128KB (only suitable for bootloader)
• Memory Mapping: QSPI flash mapped to 0x90000000-0x91FFFFFF

Questions

1. Is this a known limitation with the current STM32H750B-DK board configuration in the SDK?
2. Are there additional configuration steps required to enable external flash for application images?
3. Should the board's device tree be updated to properly support MCUboot with external flash?

Regression

• This is a regression.

Steps to reproduce

No response

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

No response

[github-actions]

Hi @cyq97! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[JarmouniA]

Try using the patch in main...JarmouniA:zephyr_dev:h750b_dk_ext_flash_app and report back.

[cyq97]

Try using the patch in main...JarmouniA:zephyr_dev:h750b_dk_ext_flash_app and report back.

😊😊😊 Thank you very much for your help! This solution now works perfectly on my custom STM32H750 board as well.

I'm now trying to integrate this working configuration into the mcumgr/smp_svr sample, but I've encountered an interesting challenge:

The Problem

When using external QSPI flash for application images, I discovered that image-0 (which handles MCUmgr commands) cannot erase itself from QSPI flash when the QSPI controller is in memory-mapped mode. This creates a self-modification problem where the running application cannot update its own flash storage.

Root Cause

• image-0 runs from QSPI flash in memory-mapped mode (XIP - eXecute In Place)
• MCUmgr firmware upload/update commands are processed by image-0
• However, image-0 cannot erase/write to the QSPI flash it's currently executing from
• This prevents firmware updates via MCUmgr when using external flash

Proposed Solution

My understanding is that we need to:

1. Relocate critical code to RAM: Move the MCUmgr upload/flash handling routines to RAM
2. Exit memory-mapped mode: Temporarily disable QSPI memory-mapped mode
3. Perform flash operations: Handle the firmware update operations in SPI command mode
4. Re-enable memory-mapped mode: Return to XIP operation after completion

Question

Does Zephyr currently provide any built-in mechanisms or APIs to handle this self-update scenario for applications running from external flash?

Some potential approaches I'm considering:

• Runtime code relocation to RAM during flash operations
• Switching QSPI modes (memory-mapped ↔ command mode) dynamically
• Using a RAM-based flash driver for self-update operations

Any guidance on the recommended approach or existing solutions would be greatly appreciated!

---

Hardware Context:

• STM32H750 (128KB internal flash)
• MCUboot bootloader: Internal flash
• Application images: External QSPI flash (W25Q256)
• MCUmgr: Integrated into image-0 for OTA updates