Showing results for 
Search instead for 
Did you mean: 

Can the bootloader and application code be in the same CubeIDE project?

Associate III

I have a bootloader project that can jump to a QSPI application under normal conditions. When I first install this application and then install my application that I created separately for QSPI, it works without any problem.(Bootloader + App).
But what I want to do is to combine bootloader and application projects. I tried to add the App code into the Bootloader application with a method like below, but even if the compilation result was successful, the debugger gave an error and I could not load the application to flash.


Ekran görüntüsü 2024-05-18 200425.png


My App Code
Ekran görüntüsü 2024-05-18 200442.png

Jump Code
Ekran görüntüsü 2024-05-18 200604.png

I've never tried anything like this before. Maybe I'm being ridiculous, sorry.

Pavel A.
Evangelist III

Yes, bootloader and application code can be in the same CubeIDE project.

But why one can want it? No idea. People want so many different things, some more reasonable, some less.

Senior II

If this wil be true bootloader, then this will not work correccly.

Associate III

I think the problem is that I use qspi and flash together. The two work fine separately but I can't use them in the same project. This may be a problem with stm32h750vbt6 rev V (old ?) or maybe it is related to the external external loader I am using (works smoothly on cube programmer and as App (without FLASH section))?


Well calling main() in an entirely different application won't correctly initialize the statics, ie your variables, either with content, or zeros.

The idea is that the Boot Loader and Applications are two separate entities, and can reuse RAM independently.

Now with the STM32 and QSPI you REALLY want the loader to bring up the bulk of the system, things like the primary clocking, PLL, external memories (peripherals and pins). The QSPI needs to be viable before you can copy content from it and execute.

It is best to do this ONCE and EARLY, so the system is running at optimum speed, and you don't have to worry about the ground underneath you shifting.

Not sure how well CubeIDE permits multiple builds under one project, they allow for Debug / Release, but things like Keil allow for one project to have multiple build contexts, allowing for a Boot Loader, with it's own main.c, main(), vectors etc.

I don't know if this is significantly helpful, even for source code control, as loaders typically don't need to do a lot of faffing around, they have a very simple defined goal, and shouldn't need constant rework over the life of a project/design. They just need to get the board to basic viability, sanity check the application image, and transfer control. Perhaps allow for recognizing and update condition, and replacing old app with new one.

Build the loader for 0x08000000 and the app for 0x90000000, have them be operationally independent, and don't have the app mess with the PLL, MCU or QSPI, except for situations where you account for the fact you can't break the memory you're currently executing from.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Right, and why would you want the stress of them working together in some mixed hybrid? You'd have to deal with the code foot-print, and where code and libraries in the working-set live, and what the call-tree dependencies are..  ie you can only use code that's in functional memory at the time you call it.


The boot loader that can live in a few KB, only needing to bring up the MCU, clocks and the external memory, it can then hand-off to an application that can then, contractually, expect both internal and external memories to be completely viable.


You're trying to push water up-hill, it's a bunch of effort, and it's not clear you've understood the assignment..


Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Associate III

Actually, when I tried a similar code with f769-disco, no problem. I'm not sure but the external loader seems to corrupt the FLASH SECTIONs content. Also now I can't even use the QSPI memory as read only (BL+APP is no longer. like FLASH + QSPI). Whe external loader can't be used with FLASH section (0x08000000).

Associate III

same app on f769 fully working

Ekran görüntüsü 2024-05-20 204113.png



Ekran görüntüsü 2024-05-20 203913.png


Ekran görüntüsü 2024-05-20 203849.png


I think there is a problem either in the mcu or in the external loader. Is it possible that the external loader can access the flash section?

Associate III

I use the external loader in this repo .