Bootloader Architecture
The purpose of the Torrox C2000* bootloader is to allow firmware updates over the CAN bus (or any similar communication path), so that C2000* microcontroller based hardware can be updated with new firmware after the hardware was shipped to customers.
The architecture of the Torrox C2000* bootloader is not tailored to the C2000* microcontroller but could also be mapped to other, similar microcontrollers. That’s why I think, this article could be helpful to others who are looking for inspiration for their bootloaders.
Requirements
There were some decisions to be made and the best way to make design or architectural decisions for software, is to have some requirements and goals. This is a list of things that drove the decision making process when the Torrox C2000* bootloader was developed:
Robustness
Getting bricked is the worst thing that could ever happen to an electronic device during firmware updates. Being bricked means, that hardware is then neither able to run a firmware nor to update the firmware, so that it is finally as useful as a brick (or a doorstop).
A nightmare for any professional provider of bootloaders that probably no customer would forgive. That’s why this is the number one priority.
Flash Size
Especially on microcontrollers with smaller flash memory sizes, it is important that the bootloader does not consume too much of that flash memory. The bootloader has to share the flash with the application. Lower flash memory requirements directly translate to lower system costs.
Configurability
While a bootloader is somehow a standard component, every project imposes some additional and different requirements. Be it the frequency of the used crystal oscillator, the baudrate of the CAN bus or the external pin that has to be driven to activate the CAN bus driver, all projects have slightly different requirements that have to be addressed by the bootloader.
Portability
There are a lot of variants in the C2000* microcontroller family. They have sometimes subtle differences, not only in the amount of flash memory. Other differences are: available CAN peripherals, clock trees (details in the PLLs), number of CPUs, number of flash sectors and banks, or required flash wait states.
While portability is probably not a number one concern for our customers, portability allows us to quickly port the bootloader to new microcontrollers.
Easy to Integrate
Customers buy a bootloader off the shelf to save time in the product development and thus, do not expect to spend days on integrating the bootloader into their system. As a provider, happy customers also mean fewer service requests.
Architecture
The overall system consists of two parts, the bootloader running on the C2000* microcontroller and a client that communicates with the bootloader and provides the new firmware to be installed. That client usually runs on PC-like hardware and is connected to a CAN bus via special CAN / USB hardware.
KISS
The bootloader has to be as simple as possible to make sure the bootloader is as robust as possible. So, the protocol used between bootloader and client is designed to move all complicated stuff into the client. The bootloader simply deletes the flash memory dedicated to the firmware and then receives blocks of firmware and writes those blocks to the flash memory of the microcontroller. As a final step, the bootloader and the client, both calculate a CRC over the entire firmware and if they agree on the CRC, the bootloader will store that CRC next to the firmware.
That CRC can then be used by the bootloader to check the integrity of the firmware, before starting the firmware.
Of cause, that does not free the bootloader from doing essential tests. The bootloader will not accept to write into areas, that the bootloader is not supposed to write to, for example. Such tests could not be left to the client as it would allow to brick the device.
Smart Client
Example for more complicated stuff, that has been moved into the client, is the requirement to not write to a certain aligned block twice. That requirement is imposed by the ECC (error correction) flash memory, that would have to change the error correction checksum in flash memory if that block’s content would change. With a first write, the CRC over the block is calculated and could then not be changed without erasing the flash memory again.
The client will get the firmware in blocks that do not take care of the above requirement. The client will iterate over all blocks of a firmware and will rearrange them to satisfy ECC block and other alignment requirements.
Protocol Testability
When moving all the more sophisticated details into the client it also makes automated unit tests for the client more valuable (when 90% of the protocol details are implemented in the client side, testing the client side will result in a test coverage of 90%).
To make the client testable, the CAN bus access, timers (required to implement timeouts), firmware content, and command line arguments have to be abstracted out of the client. The reason to also factor out the firmware content, is to remove the dependency to a file system and also the dependency on a firmware file format (like Intel Hex).
By moving out these dependencies, the remaining client protocol implementation is a library, that can be used to easily implement a client by filling in the abstractions with some concrete implementations. The Torrox C2000* bootloader ships with a command line client, that runs easily on different operating systems, supports multiple CAN bus adapters, and reads the firmware content from an Intel hex file.
The client protocol library can also be used by customers to implement their own clients without the need to implement the protocol on their own. As the library does not make use of the heap or any platform specific features, it can be even run on tiny embedded hardware.
Drivers
On the bootloader side, there are several hardware abstractions that give the very same interface to the bootloader main code for different implementations of the same functionality. No matter, if the target microcontroller used a DCAN, MCAN, or even ECAN (different peripheral IPs with totally different interfaces) CAN peripheral, the interface to the bootloader main code looks always the same. No matter if the target microcontroller implements AES in hardware or if the bootloader has to provide the functionality in software, the interface to the main code looks the same. This approach allows to easily port the bootloader code to new targets.
The picture shows the different drivers used be the bootloader and by a client.
Bootloader Library
The bootloader library is a small set of useful functions that allow the application running on the C2000* microcontroller to get services from the bootloader. The application can for example request the version of the bootloader installed on the device or the version of itself (the application).
Bootloader Installation
The bootloader has to be installed into the target microcontroller’s flash memory. Usually, this is done, by using a JTAG debug probe and appropriate software, like TI’s Uniflash. Once, the bootloader is installed on the target microcontroller, the bootloader can be used to install new firmware.
To initially install firmware and bootloader at once, the Torrox C2000* bootloader is accompanied by a tool, that allows to merge the firmware and the bootloader into a single Intel hex file. This tool will also add a 16 byte control block that contains the checksum required by the bootloader to check the integrity of the firmware.
Integration
To integrate the bootloader into an existing project, the application start address has to be moved by the size of the bootloader (16 KB) and the last 16 bytes of the flash memory has to be left free as this is used by the bootloader for necessary bookkeepings. This is usually done by changing the linker script(s) of the application. As not all developers are familiar with linker scripts, we provide examples that contain and document the required changes.
The left side shows the application without bootloader, the right side, shows the application with bootloader.
Starting the Bootloader
The bootloader must be started in some way to be able to install new firmware. Since the bootloader and the firmware never run in parallel, there are two options for which one starts first. For robustness, it is better to start the bootloader first.
After a reset, the bootloader runs, checks the integrity of the firmware, and then starts the firmware. Before launching the firmware, the bootloader listens on the CAN bus for a certain period of time for any instructions to update the firmware. If no update is initiated, the bootloader proceeds to start the firmware.
Choosing this startup order ensures that the bootloader can always install new firmware and also handles the case where no valid firmware is installed.
* C2000 is a Trademark of Texas Instruments Incorporated