A microcontroller is a small, low-cost computer chip that is programmed to perform various input/output and processing functions in an embedded system. Unlike a general-purpose desktop PC, a microcontroller is designed for a very specific purpose and is embedded into electronic devices and appliances to control them.
When power is first applied to a microcontroller, it needs to load its program code into memory in order to execute it and perform its intended function. This initial program load operation is called booting, similar to how a PC boots up its operating system on power up. A microcontroller can perform this boot process in different ways:
Using a dedicated external bootloader IC
Some microcontroller-based systems use a separate, external bootloader IC chip along with the main microcontroller chip. On power up, this dedicated bootloader IC first loads the program code into the microcontroller’s memory from an external source like an EEPROM or flash memory chip. Once loaded, the microcontroller starts executing the program normally. The external bootloader chip manages the initial program loading independently without needing any bootloader firmware on the microcontroller itself.
Bootloader code resident in internal ROM
Many microcontroller chips have a small internal ROM section that contains a preset bootloader program hardcoded into the silicon by the manufacturer. When the microcontroller powers up, this built-in bootloader automatically loads the main application firmware from an external source into the microcontroller’s writable memory (usually flash memory) and transfers execution control to the loaded application code.
Bootloader firmware uploaded to microcontroller
If a microcontroller does not have a hardware bootloader built into internal ROM, an external bootloader can be uploaded and stored in reserved flash memory space on the microcontroller itself. On reset or power-up, this resident bootloader firmware will execute first before the main application code, initializing hardware and loading the application firmware into memory so that it can run.
The benefit of this approach is that the bootloader can be upgraded or customized by reprogramming if needed. Also, it saves the cost of an additional standalone bootloader chip.
Self-booting operation
Some microcontrollers, usually lower-end models aimed at very cost-sensitive applications, do not require an explicit bootloader at all. The microcontroller is designed so that the application program can be directly programmed into internal flash memory. On power-up, the microcontroller fetches and executes the application code directly without needing a bootloader to load it.
However, this means that the application code must include initialization and hardware setup functions that are normally handled by a bootloader. Also, the lack of a bootloader makes it difficult to upgrade the firmware, as the microcontroller flash memory would need to be directly reprogrammed each time.
When is a bootloader needed?
Here are some key factors that determine if a separate bootloader is needed or recommended for a microcontroller-based design:
- Ability to easily update firmware – With a bootloader, new firmware can be uploaded without having to directly access or remove the microcontroller chip.
- Cold boot initialization – A bootloader can handle low-level hardware init like clocks, memory, and peripherals that is complex to do from app code.
- Validating firmware image – The bootloader can verify a firmware update is valid before loading it.
- Encryption – Some bootloaders support decrypting encrypted firmware images before loading.
- Multi-image swapping – Having multiple firmware images and selecting between them at boot time.
- Secondary image rollback – Ability to fall back to a prior working firmware version if an update fails.
- Upgradability – Bootloader code can be patched/enhanced without changing application firmware.
A microcontroller that needs to support over-the-air firmware updates, field upgrades, fail-safe firmware rollback, encryption enabled memory, advanced application switching/partitioning, or other firmware flexibility will benefit greatly by having a bootloader even if it increases BOM cost slightly.
Example bootloader solutions
Here are some commonly used bootloader options for various microcontroller architectures:
ARM Cortex MCUs
- mbed – Open source bootloader from ARM’s mbed OS framework.
- STMicro Bootloaders – Vendor bootloaders for STM32 MCUs.
- NXP i.MX RT Series – On-chip ROM bootloaders for NXP RT MCUs.
- Texas Instruments Bootloaders – Built-in ROM or flash bootloaders for TI MSP430, MSP432, TM4C, and Hercules MCUs.
- Cypress PSoC Bootloaders – PSoC Creator IDE includes configurable bootloader projects.
- Microchip Bootloaders – For SAM and PIC32 microcontrollers.
8-bit AVR MCUs
- Arduino Bootloader – Open source bootloader targeting AVR chips that can be used independently.
- Optiboot – Open source, performance optimized AVR bootloader.
- MICROCHIP Bootloader – For all Microchip AVR 8-bit MCUs.
- EEPIC Bootloader – Supports EEPROM wear leveling and flash encryption for AVR.
ESP32 SoC
- ESP-IDF Bootloader – Espressif’s open source bootloader designed for the ESP32.
- AtomMCU Bootloader – Customizable bootloader for ESP32.
In summary, most microcontroller applications can benefit from having a bootloader, either built-in or uploaded into reserved flash memory. The bootloader acts as a foundation on which upgradable, flexible, and robust firmware solutions can be built.
