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

[OguzhanBalci]

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.

 

 

My App Code


Jump Code


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

[Pavel A.]

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.

[Radosław]

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

[OguzhanBalci]

Why

[Tesla DeLorean]

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.

[OguzhanBalci]

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))?

[Tesla DeLorean]

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..

 

[OguzhanBalci]

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).

[OguzhanBalci]

same app on f769 fully working

 

 

 

 

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?

[Tesla DeLorean]

If the External Flash Loader is working properly it shouldn't mess with the Internal FLASH.

The caution with the code is that you need to get all the executing code to be in the Internal FLASH up to the point that the External FLASH is mapped into the usable address space.

Otherwise you'll get a Hard Fault

[OguzhanBalci]

I use the external loader in this repo .

[Tesla DeLorean]

Not sure how that would break the Internal Flash

You could try this one  https://github.com/cturvey/stm32extldr/blob/main/h7_w25q128/CLIVEONE-W25Q128_STM32H7XX-PB2-PB6-PD11-PD12-PE2-PD13.stldr

 

I'd be suspicious you still have a HORSE-CART issue, most everyone has the HORSE and CART as separate things, and the HORSE goes in front of the CART.

[OguzhanBalci]

There is still a problem uploading the code

 

I used the appropriate external loader from the repo you suggested (it works on its own without any problems)