How to boot STM32 from user flash?

Question

STM32 microcontrollers are capable to boot from different sources such as:

1. User-Flash
2. System-memory
3. Embedded-SRAM.

On the firmware side, does "boot from user Flash" means executing a custom bootloader?

Answer 1

No.

The "Boot from User Flash" mode means that the application code that will be run after reset is located in user flash memory. The user flash memory in that mode is aliased to start at address 0x00000000 in boot memory space. Upon reset, the top-of-stack value is fetched from address 0x00000000, and code then begins execution at address 0x00000004.

In contrast, the "Boot from System Memory" mode simply means that the system memory (not the user flash) is now aliased to start at address 0x00000000. The application code in this case must have already been loaded into system memory.

The "Boot from Embedded SRAM" mode does not alias the SRAM address. When this mode is selected, the device expects the vector table to have been relocated using the NVIC exception table and offset register, and execution begins at the start of embedded SRAM. The application code in this case must have already been loaded into embedded SRAM.

For more details, refer to the Reference Manual for the specific family of STM32 devices you are using, in the section titled "Boot Configuration".

Answer 2

It depends.

The option "Boot from user Flash" will run whatever is in the user flash. This code could be anything you want. It could be:

• a custom bootloader or
• it could be application code.

The distinction is a logical one based on what you write your code to do. i.e. it is even possible to have an app that rewrites part or all of itself (what you call it is up to you).

If you do use a custom bootloader then you will normally have two projects.

1. The custom bootloader will have its own projects with its own generated binary image loaded into the start of flash.
2. The application code also having its own project and generated .bin file.

The application is loaded into a specific address that the bootloader knows about when it was built (in some free statically allocated memory block - normally on page boundaries to allow for reflashing while keeping the bootloader unchanged). These addresses can be configured in linker files.

Custom bootloaders are a great way of allowing features like:

1. A custom coms stack, to reflash your application via some other coms protocol.
2. Dual redundancy of the application code.

Note the STM32 micros "System Memory" already contains ST's own bootloader which supports a range of serial links to reflash the micro without needing a fully custom bootloader.

Answer 3

ST's documentation is stupid. They mention this, but they don't also tell that you need to only configure BOOT0 & BOOT1 pins in order to select the boot source.

So these two pins binary speaking give you three options that are:

• (A) BOOT0 = 0, BOOT1 = whatever,
• (B) BOOT0 = 1, BOOT1 = 0 and
• (C) BOOT0 = 1, BOOT1 = 1.

Option A boots in FLASH, option B boots in bootloader and option C boots in SRAM.

So how to use this. First choose configuration B to start communicating with the bootloader to whom you instruct (in bootloader's own commands) to erase FLASH and upload your program inside FLASH. Then you change the configuration to A and reboot using MCU's RESET pin.

Note:

I perfer the NXP's documentation which has everything black on white. As a developper I value my time and good documentation is a way to go. Ditch ST and go for NXP if documentation is what you value. Here is NXP's sample documentation:

https://www.nxp.com/docs/en/user-guide/UM10562.pdf

I am really sorry ST, but you have to do better than what you are currently doing...