# Custom bootloader passing control to application code in STM32

I am trying to understand that if for STM32F405 MCU a custom bootloader is used on the MCU then each of the two projects for the custom bootloader and the application code will have their own 'startup.s" files.

What I understand is that both of the two binaries, ie the bootloader and the application code, they both reside at different locations in the flash.

Now when the custom bootloader will exit and return the control then the control should pass-on to the startup code of the application code. But I don't know how it actually happens. Does the two binary programs resides at contiguous locations so that after the bootloader finishes the next instruction is that of the startup code?

Or they are at different locations and somehow the start address of startup of application code is saved as jump address at the end of the bootloader binary?

Will it make a difference in the way it is actually implemented if I use Keil or GCC compiler?

• While you have received answers that are for the most part correct, they gloss over a lot of key detail. There are several existing questions here which cover practical difficulties you are likely to encounter in handing off control from one program to another, particularly with regard to chip configuration... In many cases it becomes best to set a flag, reset the CPU and then detect the flag in startup assembly and branch to the target before the initialization functions of the bootloader can run and again put the chip in a different state than the main program expects. – Chris Stratton Jul 9 at 12:34
• Why do we need to reset the CPU for control hands-off from bootloader to main program? – alt-rose Jul 10 at 6:00

The compiled image of an STM32 application begins with a vector table, in which the first word contains the initial stack pointer value, the next one has the address of the first instruction.

The bootloader must obviously know the address the application is loaded at (how could it load it otherwise?), so it can look at the first two words of the image it had just flashed.

You must take the layout of the flash sectors into account when deciding the start address of the application. If parts of the bootloader and the application end up in the same flash sector, then the bootloader won't be able to reflash the app.

The designers of this MCU had arranged a few shorter sectors at the beginning of the flash exactly for this purpose. You might want to reserve 32k for the bootloader, and place the application at 0x08008000 for example, it's up to you (and the complexity of the bootloader).

Will it make a difference in the way it is actually implemented if I use Keil or GCC compiler?

The only difference would be in the linker configuration files, which tell the linker where to load the application. The GNU linker takes it from a linker script (*.ld), Keil calls it scatter file. They have the same purpose, but different syntax. You should adjust the linker script/scatter file of the bootloader too, limiting the amount of flash available to it.

Compiler does not matter, one can be used for bootloader and another for application. First you write the bootloader and see how large it is. Then you round up to nearest flash sector boundary as you don't want to erase a sector with bootloader code. Make the bootloader jump to start of first free sector. And then instruct the linker to generate code so that the application code is not loaded to start of flash (bootloader is there) but start of first free sector after bootloader.

• "Make the bootloader jump to start of first free sector." Does it mean that while writing the 'Bootloader' we should know before hand where to jump after the bootloader exits? So we will write that jump address as the last instruction in the bootloader code? Or do we have to write the jump address outside of the bootloader code somewhere else in the other files? – alt-rose Jul 9 at 7:54