A bootloader is a piece of software that can be executed after a microcontroller starts up and loads, starts, or updates the application firmware. In microcontrollers, it is usually located in its own section of flash memory. After a reset, the bootloader decides whether to start an existing application or to initiate an update process.
Content
What is a bootloader?
A bootloader is code that runs before the actual application firmware. Its job is to manage an application in program memory. This can involve receiving new firmware, writing to flash memory, checking an existing application, and then jumping to that application.
In Arm Cortex-M systems, execution typically follows a fixed startup logic. After the boot ROM phase, code is executed from a defined address in program memory. If the bootloader resides at the flash base address, it is started first after reset. The application firmware then resides at a different flash address.
The bootloader and application are usually built as separate firmware projects. This results in two executable images with their own linker settings. The application does not necessarily need to know that a bootloader is present.
How does a bootloader work?
After startup, a bootloader typically goes through several checking steps. First, it determines if an update has been requested. Such a condition can be represented via a GPIO level, an entry in non-volatile memory, a RAM variable, or another application-specific mechanism.
If no update was requested, the bootloader often checks if the existing application is executable. For this, a CRC can be used over the application's memory area. The calculated checksum is compared with a previously stored value. If this check fails, the bootloader should not start the application, as the flash content may be incomplete or corrupted.
When an update is performed, the bootloader receives new firmware via a designated channel. This can be, for example, a USB connection, a network interface, or another communication interface. Some Microcontroller provide interfaces for this, such as In-System Programming or In-Application Programming. The specific erasing and writing of the flash memory depends on the microcontroller.
After a successful update or a passed test, the bootloader starts the application. On ARM Cortex-M systems, this transition involves several steps:
- deactivate enabled interrupts in the NVIC,
- clear pending interrupts,
- reset used peripherals to a suitable state,
- Disable SysTick if it was used by the bootloader,
- disable fault handler if necessary,
- set the Main Stack Pointer to the value from the application's vector table,
- write the address of the application's vector table into the VTOR register,
- load the application's reset vector and jump to it.
In Cortex-M systems, the application's vector table initially contains the start value of the Main Stack Pointer and then the reset vector. Therefore, the application's start address is not called like a normal function during a jump. The bootloader must establish the application's start conditions so that they do not depend on the bootloader's states.
A bootloader is used to start up a computer or other electronic device.
Bootloaders are used in microcontroller systems whose firmware is to be updated after delivery. This applies to devices that are operated in the field and for which an update must be performed via an existing interface.
A bootloader can be used if the microcontroller's pre-installed bootloader does not fit the system. Reasons can include an inaccessible interface, an unsuitable update trigger, or an incompatible memory organization. Custom requirements for check steps, update flags, or the firmware change process can also necessitate a custom bootloader.
Typical use cases include systems with separate application firmware, flash memory with fixed erase sizes, and update channels not covered by the manufacturer's bootloader.
Properties
A bootloader requires a permanently reserved memory area. If the bootloader is located at the beginning of program memory, it will be executed first after a reset. The application then starts at a higher address.
The memory allocation must match the erase structure of the flash memory. Flash memory is structured into pages, sectors, blocks, or banks. The smallest erasable unit determines how the bootloader and application must be separated. The bootloader and application should not reside in the same erasable unit, because otherwise, erasing a portion of the application could also remove bootloader code.
The linker configurations for the bootloader and application must match. The bootloader receives a reserved flash area. The application receives a starting address outside of this area. Separate linker files or separate linker settings are used for both firmware images.
A bootloader also needs an update condition. A GPIO pin can be queried on reset. Alternatively, the application can set a marker in Flash, EEPROM, or in a commonly defined RAM area before a software reset. The bootloader reads this marker after restarting and then switches to update mode. If a non-volatile marker is used, it should be erased again upon entering update mode so that a subsequent restart without a new update does not permanently remain in update mode.
Demarcation from related terms
In contrast to the bootloader, the boot ROM is permanently integrated into the microcontroller or system chip and is executed before the bootloader. It contains manufacturer-specific startup code. A bootloader in flash memory, on the other hand, can be part of one's own firmware and can be adapted to one's own memory layout and update processes.
The application firmware contains the actual device function. It can be built independently of the bootloader. The bootloader starts this application after completing checks and the update decision.
In-System Programming refers to a method of writing to program memory via a programming interface. In-Application Programming refers to mechanisms that allow code from the running firmware to modify flash contents. A bootloader can utilize such mechanisms but is itself the program part that controls the update process.
A linker script is not a bootloader. It describes which memory regions firmware can use. For a system with a bootloader, the application's linker script specifies that its code does not start at the bootloader's flash base address.
Zurück zum Glossar