Bootloader Tutorials
STM32F7 (ARM Cortex M7)
Bootloader Tutorials
Bootloader Basics - Bootloader Part 1
Bootloader Design – Bootloader Part 2
Simple STM32 Bootloader – Bootloader Part 3
Flashing Application using Bootloader - Bootloader Part 4
Bootloader Two slots and CRC32 - Bootloader Part 5
STM32 Firmware Update Over the Air (FOTA) – Bootloader Part 6
STM32 Firmware Update using SD Card – Bootloader Part 7
STM32F103 (ARM Cortex M3)
Bootloader Tutorials
Bootloader Basics - Bootloader Part 1
Simple STM32F103 Bootloader Implementation – Bootloader Part 2
STM32F1 Firmware Update using Custom Bootloader – Bootloader Part 3
STM32 MikroC Bootloader Tutorials
Bootloader Basics – Part 1
STM32 MikroC Custom Bootloader – Part 2
STM32 MikroC Bootloader using SD Card – Part 3
Bootloader Basics
The bootloader is a very important component in any operating system. A
bootloader, also known as a boot program or bootstrap loader. It is special
operating system software that loads into the working memory of a computer after
start-up. So, you must be clear that this is also software like an application. The
term bootloader is a shortened form of the words “bootstrap loader”.
What is a Bootloader in Embedded
systems?
Like a normal OS, the bootloader in a microcontroller also serves the same purpose.
This is the first piece of code that runs when you press the reset button if you have a
bootloader. If you don’t have a bootloader, then directly an application will start
running. We have already discussed, what happens when we press the reset
button if the bootloader is not present in STM32 (Cortex M4).
What is the need for Bootloader in
Microcontroller?
Firmware update
Is it really useful? Why do we need this? Still, I am using a project which doesn’t
have a bootloader. I will try to answer the questions.
I agree that when you don’t have a bootloader, it is very simple. We are not
complicating by writing an extra bootloader. Only application is enough. But when
you are planning to sell your products to the customers, what will do if you want to
update the application/firmware in the device that you sold already? Every time go to
the field and connect the JTAG/J-LINK and flash the firmware or application? It is not
possible, right? So, If you have your bootloader, then you don’t need to worry about
that. You can update the firmware or application without connecting any debugger or
flasher.
Security
When you have the product which has to be secured, then what will you do when
someone overwrites the application or firmware with their customized firmware to
hack your product? How do you find it? In this case, we can use the bootloader to
check whether the firmware is valid or not. If it is valid, then only we give control to
the firmware or application.
What happens when you have a
bootloader?
When your project has a bootloader, then you will be having two binaries. One is a
Bootloader image and another one is an application. The bootloader will be placed in
the 0x00000000 with its Vector Table. The application will be placed in another area
of the flash memory with its vector table.
When you press the reset button, it will start from the bootloader. So, it
will copy the Stack pointer to MSP (Main Stack Pointer) from the
location of 0x00000000.
Then it moves to the bootloader’s reset handler.
The bootloader will do some operations based on your need like check
for firmware version, upgrade the firmware, etc.
Once it has done with its operation, it will jump to the application’s
vector table.
Then it will initialize the MSP (Main Stack Pointer) again.
Now we have to tell the controller to use the application’s vector table
instead of using the bootloader’s vector table. That will be done using
the Vector Table Offset Register (VTOR).
Then it goes to the application’s reset handler. There it will copy and
initialize the data segments to the RAM (Global, Static variables).
Finally, it moves to the main function of the application.
Reset Sequence in ARM Cortex-M4
Before starting this we must know about the microcontroller memory architecture.
Please find the below image to know about the Memory map of ARM Cortex-M4.
Here, we have a code region, where we are going to write our final binary. That
memory is starting from 0x00000000 to 0x1FFFFFFF. Now we will forget about
other regions. We will take only the SRAM and Code region. We know that the code
region has the final output of our program (.hex or .bin or etc). SRAM will be having
stack, heap, global RW variables, and Static variables, etc.
Memory layout of the program
Now we have to know how the final output of our program is stored in the code
region. The below image will explain how our program is stored in the code region.
As you can see from the above image, the final output of our program will be ordered
in this way by using a linker. If you want to know the memory layout of the program,
you can refer to this tutorial. So, the vector table is starting from 0x00000000.
Note: By default vector table will be starting from 0x00000000.