Bootloader for STM32H747-DISCO to jump app present in QSPI

[Vimal126]

Hi All,

I'm trying to boot to an app present in QSPI.

I created a project from TouchGFX and generated code, same.ioc file I used to make my bootloader code.

When I used the bootloader to jump to the app that was present at address 0x0802000 it jumped successfully, and my app was running normally. Now I want to move this app completely to QSPI and want to run from there via a bootloader.

How to achieve that. I tried to move the whole application to QSPI by changing the .ld file, but not able to jump.

[Tesla DeLorean]

Your boot-loader should bring up the external memories (SDRAM, QSPI), and clocks (PLL, etc) and the Application should not repeat that.

The external memories will need all the pins initialized, and the memory-mapping enabled, so the 0xC0000000 and 0x90000000 memory spaces are visible to the MCU within it's memory-map. See also MPU configurations

You should STRONGLY avoid doing this a second time as it will be very disruptive, takes additional time, and repetitive.

With the memory suitably mapped you will be able to perform the transfer of control.

[ahsrabrifat]

You can’t execute arbitrary code directly from QSPI unless XIP is enabled and correctly configured.

STM32H7, STM32F7, STM32L4+, etc., support QSPI memory-mapped mode to allow execution directly from QSPI flash.

TouchGFX apps rely heavily on external QSPI for GUI assets, but the core code (startup, RTOS, etc.) often still runs from internal flash.

[nebulaamr]

Hi,

I’ve been trying to implement a similar project on STM32H743 (single core), 

where my application is located in QSPI flash (memory-mapped mode), and a small bootloader in internal flash jumps to it. 

Unfortunately, after jumping, my application often ends up in HardFaults or doesn’t behave correctly. I test my bootloader cde with simple led blinking and worked fine. But when qspi,fmc,... the app doesn't work.

SCB->VTOR 0x08020000

Flash orgin in linker file: 0x08020000

I saw your post here and that you’ve successfully managed it on STM32H747-DISCO.

Could you please share what *specific changes* you made in your bootloader and application to make this work reliably?

[Pavel A.]

> SCB->VTOR 0x08020000  

> Flash orgin in linker file: 0x08020000

@nebulaamr Address 0x08020000 is the internal flash. The app in QSPI flash has different addresses. It likely has its own vectors table, which can be copied to internal RAM.

[Tesla DeLorean]

Debug the Hard Fault, understand why.

It will need to point to a viable / read-able vector table.

When the QSPI is working SCB->VTOR = 0x90000000, this often gets set in SystemInit()

The addresses in the vector table are fixed / set by the linker.

Your small bootloader should bring up the clocks, buses, and external memory interfaces so subsequent code can use them.