Torrox News

Bootloader in Production

Bootloader in Production

A customer approached us with the question of how he could build a single hex file that contains the Torrox bootloader and the customers application.

A simple post production approach would be to flash the bootloader on the micro controller of the freshly produced product using JTAG or SWD. In a second step, the installed bootloader could then be used to install the first firmware version via the CAN bus. While most hardware / PCB assembly facilities are most likely well prepared to install an initial firmware on microcontrollers, running an additional step to install the firmware via CAN bus might be quite an effort. Not only has the freshly produced PCB to be connected to the CAN bus, the bootloader client would have to be invoked and the result (in case, that an error occurred) of the client would have to be evaluated.

So, the customers request is totally reasonable. Merging the firmware and the bootloader would make the second post production step superfluous. Just appending the application to the bootloader would not be sufficient. The bootloader uses a tiny bit of flash memory to keep track of some meta data associated with the installed firmware. This meta data also contains the CRC over the application binary, used by the bootloader to verify the correctness of the firmware to prevent corrupted firmware to be started. If the bootloader does not find the correct CRC in the meta data, the bootloader will not start the application!

The layout of the meta data block used by the bootloader is not a secret and is shared with interested customers. With the layout information, the customer could build a tool to merge the bootloader with the application and reconstruct the meta data block from the applications binary (basically calculate the CRC over the firmware).

However, we found this requirement so interesting, that we wrote this tool and added it to the tools that are accompanied with the Torrox bootloader. This hopefully makes our customers more satisfied with our product and leaves us the freedom to change the layout of the meta data block without breaking our customers build processes.

Torrox News

Support for Texas Instruments Dual Core C2000 Microcontrollers added

We recently added support for the Dual Core versions TMS320F2837xD of the microcontroller provided my TI to our C2000 Bootloader. The bootloader protocol was extended by support for multiple banks, as both cores have separated address spaces.

During startup, the bootloader will check the integrity of the flash content for both cores and will only start the application, if both cores report correct flash memory checksums and the very same application version.

This way, the bootloader will only activate applications that has been flash correctly and which are known to work together correctly.

The size of the bootloader is less than 32kByte and thus consumes just a small fraction of the available flash memory.

The bootloader can be licensed by our customers for their own projects or can be customized by us to suit our customers needs. Get in touch, if you are interested in more details.

Torrox News

Support for f2806x added

The range of devices, supported by our Bootloader for the Texas Instruments C2000 DSP family, was extended by the mid performance TMS320F2806x devices. The bootloader allows reliable firmware update over the CAN bus. The size of the bootloader is less than 32kByte and thus consumes just a small fraction of the available flash memory.

The bootloader can be licensed by our customers for their own projects or can be customized by us to suit our customers needs. Just get in touch, if you are interested in more details.

Torrox News

C2000 Bootloader

Torrox developed a Bootloader that supports the TMS320F28379S and TMS320F28377D from Texas Instruments C2000 DSP family. The bootloader allows reliable firmware update over the CAN bus. The size of the bootloader is less than 32kByte and thus consumes just a small fraction of the available flash memory. With a default CAN speed of 500,000kbit/s, the installation of new firmware on a device is much faster than by using the original debug probes (like XDS100, XDS200) from TI. This makes the usage of the bootloader even beneficial during the development phase of a project, as it speeds up the usual development cycles by quite a margin. 

The bootloader can be licensed by our customers for their own projects or can be customized by us to suit our customers needs. Just get in touch, if you are interested in more details.

Blog Posts

A Bootloader Checklist

A Bootloader Checklist

When looking systematically on bootloaders involved in embedded software projects, listing the requirements to the bootloader can help to estimate required hardware resources, project costs, and time. No matter if the bootloader is tailored to the project, open source, or comes embedded in the hardware. Checking the requirements once will prevent surprises at the end of the project or even later, when a firmware update in the field is required.

Bootloaders are often added or implemented very late in projects as they usually don’t add value to the development process. Searching for values, that early bootloader integration can add to the project, can help to argue for an early integration. The earlier a bootloader is regularly used during the development process, the better tested the bootloader will be!

Sometime there is only the requirement, that the product under development have to have a bootloader, without any further specification beside the used interface to communicate with the bootloader. I hope this article might be useful to others who are currently in the process to make certain decisions about the use and requirements of a bootloader (or bootloaders) in a project ahead.

What are the questions to ask? What might be the details to keep in mind? What can prove usefulness in the future (even things, one currently can’t think of)? This list does not claim to be complete. If you find something missing on the list, please contact me and I’ll try to add your suggestion to the list.

Update / Install firmware

The ability to update existing firmware or to install firmware the first time on an embedded device might be the feature that is required the most by projects using a bootloader. This feature allows to fix bugs in the firmware, that where found after the firmware was deployed, to add features to the product after it was sold, or even defer the installation of the first firmware until the moment, the product is used the first time. To implement that feature, the bootloader needs to obtain the new firmware somehow and has to store it somewhere. Implementing incremental updates of a firmware can reduce the required bandwidth by an order of magnitude, if only tiny changes to the firmware have to be transmitted.

Used protocols and data formats depend highly on the overall set of implemented requirements, list of supported interface, and hardware to be supported. That’s why bootloaders are often tailored to a specific project.

A bootloader can not only update or install firmware, but of cause also any kind of data like configuration data, licence data, library code, or the bootloader itself.

Integrity Check of the Firmware

If the bootloader is the first piece of software that runs on an embedded hardware, it’s up to the bootloader to start the firmware. There might be reasons (constrains in the startup time for example), to start the firmware without the interaction of the bootloader. If the bootloader is starting the firmware, the bootloader has the opportunity to check the integrity of the firmware before starting the firmware.

By checking the integrity, the bootloader makes sure that the firmware binary was not modified unexpectedly. This can be done, for example by calculating a checksum over the firmware and compare that checksum against a checksum that was calculated when installing the firmware or when the firmware was build. Testing the checksum of the firmware binary before starting the firmware prevents from starting damaged firmware. The reason for damaged firmware binaries could be buggy firmware that wrote configuration data to the wrong address in the flash memory, that is shared between firmware and configuration data or defect storage devices like a defect SD card.

When the integrity check fails, the bootloader would normally not start the firmware but inform the user, start a prior version of the firmware, or go into some kind of error mode.

Such a test could also easily be implemented in the startup code of the firmware itself.

Correct Hardware / Hardware Version?

If a bootloader and it’s associated protocols and update formats are used in multiple projects, care should be taken, that a bootloader does not accept and install firmware from one project to hardware that the firmware is not intended to run on. In that case meta data could be added to the firmware update formats and protocols and the bootloader will then check, that the firmware update is indeed targeted to the hardware, the bootloader is running on.

Authenticity Check the Firmware

In opposite to an integrity check, an authenticity check guaranties, that the checked firmware update comes from a trusted source that is authorized to issue firmware updates for the intended hardware. Cryptographic functions are used to detect tampered firmware. Usually this can not prevent installing software on a device if access to the hardware is given and for example the SWD or JTAG interface of a microcontroller can still be used.

Encrypted Firmware Updates

Most microcontrollers allow to enable some kind of read-back-protection, that prohibits to read the firmware from flash using SWD or JTAG. If this feature is used to protect the intellectual property of the firmwares author, firmware updates have to be encrypted, if the firmware update process implemented by the bootloader is invoked by a not trusted person.

If a connection to a trusted computer can be established, key exchange algorithms could be implemented to encrypt the connection and use it to receive the firmware update.

If read-back-protection is enabled, encryption keys can be stored in flash along with the bootloader. If an attacker would be able to read-back the key, the attacker would probably also be able to read the firmware itself. Once a key was revealed all later updates could also be decrypted.

Communication Interfaces

A bootloader needs some kind of interface (or even multiple interfaces) to receive firmware updates. This could be either bidirectional interfaces like an UART or unidirectional like a firmware image on a read-only boot device. The options greatly differ in terms of bandwidth, reliability, protocol complexity, latency, implementation effort, and so on.


The bootloader sits on one end of the communication interface, on the other end, there have to be a client speaking the same protocols. In the simples case, this client is a file on a SD card. In more complex situations, the client is an application on its own or has to be integrated into existing software or products.

The set of planned supported client platforms can change the design of the client protocol. In most cases, the client has more computing and power resources, which should be kept in mind to keep the design of the bootloader simple and robust.

In any case, thinking about what clients have to be implemented, should help to estimate the required resources.

Different Architectures

Usually, the bootloader is deployed to the same hardware and is responsible to update the firmware for a single, given device. To share communication interfaces or to update multiple device, different architectures / topologies can be used.

For example one device (the Gateway or Hub) contains a bootloader or part of an application, that logically connects the communication interface of the device to bootloaders that are deployed on other microcontrollers on the system. That Gateway device uses other communication interfaces to communicate with other bootloaders or directly flashed firmware to other microcontrollers by using their SWD or JTAG interface.

The reason to use that pattern could be to reuse a single communication interface for all devices that need firmware updates in the system or because not all devices have an interface that is accessible.

Bootloader Update

Usually bootloaders should be simple enough to not need to be updated. However, especially, if complex communication protocols like WLAN or TCP/IP are used, there is a good chance that some of these protocols need an update during the live time of the device.

In the simplest case, a bootloader could be updated by temporarily installing a firmware, that simply reinstalls a new bootloader. Care have to be taken, that flash write protections, enabled by the bootloader does not prohibit this approach.


Reliability is required by every project, but it comes with a price. Basically, there are only three ways, an embedded microcontroller based hardware system can be bricked: First, by corrupting the bootloader itself, second, by not given the bootloader access to the microcontroller (e.g. never running it) and last, but not least by having bugs in the bootloader itself.

If the bootloader gets damaged by a firmware that tries to store some configuration parameters in flash memory, but accidentally stores the configuration in the part of the flash memory, where the bootloader resides, running the bootloader will most likely result in crash. A lot of hardware architectures provide means to secure the bootloader image against being overwritten or being deleted by malfunctioning firmware. If that feature is used, care has to be taken, that this feature does not prevent an update of the bootloader itself.

If the cooperation of the firmware is required to start the bootloader, a bug in the firmware can easily brick the system. By running the bootloader first and by implementing some mean to prevent the bootloader from starting the firmware immediately, the bootloader will always have a chance to replace broken firmware. This could be implemented by sampling a button press or by listening on a communication interface for a defined period, before starting the firmware.

Bugs in the bootloader itself are prevented best, by keeping the bootloader as simple as possible and by thoroughly testing the bootloader. Using a bootloader as early as possible in a project gives confidence, that the used bootloader is reliable and that most bugs are found.

The Check List