Welcome to the second entry of the Bootloader series! Today we are going to be discussing the design and basic architecture of the bootloader application.

As we talked about on the last post, we are not going to be using any libraries, other than the C++ standard library in order to maximize portability and performance and limit code bloat. This means that we will be writing our own Hardware Abstraction Layer for all the peripherals and core features of the bootloader.

We are introducing a new series to the blog, containing all about bootloaders for small ARM Cortex-M microcontrollers. I hope you like it.

What is a bootloader?

A bootloader is a piece of firmware that takes care of booting the target application, as well as providing a mechanism to update the firmware on the field, where you don’t have the means to flash the device using more advanced hardware interfaces such as JTAG, SWD or ICSP.

After researching some alternatives for mp3 decoding on STM32 microcontrollers, I found ST’s X-CUBE-AUDIO, a set of libraries and components for audio processing. It turns out that SpiritDSP developed a version of their MP3 decoding libraries for STM microcontrollers.

You can download the software expansion kit following this link. It contains much more than just the SpiritDSP MP3 decoder, but this article will be focused just on how to get the MP3 decoder up and running.

When developing bare metal applications it is required to supply some functions that we normally take for granted when developing code for mainstream OS’s. Setting the startup code is not inherently difficult but beware: some of the nastiest bugs you will ever see on bare metal can come from the startup code.

What is actually needed to start the execution of the main function? Well, there are a few things that the C and C++ language specifications assume when starting a new program. Some of them are:

Developing code for embedded devices is somewhat different from code for mainstream computers. One of these differences is the development environment.

Most of the target microcontrollers or microprocessors won’t usually be suited for local development. Imagine trying to build your code on the target when the target is a simple 8-bit Microcontroller. First of all you would need a compiler for the target architecture on the target device and it would probably be extra slow and inconvenient. That is the reason behind cross-compilers (provided that the uC has enough power and memory to perform the compilation process).