A Beginners Guide to Automotive Bootloaders — Understanding basics
As the name suggests, Bootloader is the software algorithm that is executed during the booting of the system. It is usually the first code executed after a reset. Bootloaders enable the Electronic Control Units (ECUs) to be able to update their own software. They also check for completeness and consistency of the application code at each reset and only trigger the main task of ECU if the application is complete and consistent, hence it kind of is a sanity check of the ECU.
Let’s take a deeper dive to understand why an Automotive ECU should have software re-programming capability.
Why are Bootloaders so essential for Automotive ECUs
Just for comparison purposes, A Boeing 787 stands at a little higher than 6.5 million lines of code and on average a luxury car has close to 100 million lines of software code.
This is because Automotive ECUs support loads of features and functionalities, safety, ease, infotainment, comfort, assistance, efficiency to name a few, the possibilities are endless and competition stiff, which has lead the system to become more advanced and complex with time.
It has become imperative, in such a situation, for the Automotive Original Equipment Manufacturers’ (OEMs’) and Suppliers to ensure that these software-driven control units are always operating in a secure & efficient environment. This can be ensured only if the ECUs, within the vehicles, have the latest and updated version of the software and security patches.
As a result, the application software designed and ported on the Micro-controller (MCU) platform needs to be updated quite frequently, either through a remote location or at the service station. But the firmware update of an Automotive ECU is a tedious job, due to huge volumes of software code.
A Bootloader Software is designed to automate this process of flash re-programming. It occupies the ROM of the ECU, has been entrusted with the responsibility of facilitating the ECU software update. The following software architecture of a Bootloader Software will help you understand better,
At every Boot-up of the System, the Bootloader software checks if the latest/updated version of the ECU software is available. This is done in various ways i.e. a direct Unified diagnostic services (UDS) request sent from a downloader tool at a service station or an update request sent via OEM in case of Over-the-Air (OTA) updates. Both of these concepts are further explained in detail later in the article.
If there is a request for an update, then before the booting of the system, Bootloader software downloads, and stores the new updated version of the firmware. After this, the system boot-up is executed and the system now runs on the new version of the software in a completely secure environment.
To understand it further, lets have a step-by-step guide for firmware updates below:
A Step-by-Step Process Guide to Understanding how Firmware is Updated, using a Flash Bootloader:
As already discussed, Flash Bootloader module is designed to update the firmware without the use of any specialized downloading hardware, such as a JTAG, using simple wire connections over CAN, LIN, UART, FlexRay and even Ethernet. Some ECUs even support updates Over-the-Air using wireless connections, we’ll get into further challenges of OTA later.
Following is the list of the steps involved in ECU reprogramming using Flash Bootloader:
- The Bootloader is the first software module that gets activated during the booting of the system after the power supply of the device is switched on.
- The control is transferred to the Bootloader, which checks for the updated version of the firmware. If a new version is available, Bootloader analyzes the request to authenticate the source and cross-check all the pre-defined system security parameters. If the authentication is successful then Bootloader writes the newly updated firmware on the flash memory, at the pre-defined target address.
- Next, the updated program is again verified to check the integrity of the software in place, i.e. in the updated flash area. If no anomaly is found, the control is transferred from the Bootloader to the Application.
All these steps, involved in the process of ECU reprogramming, are usually performed by two different parts of the Bootloader- the Primary and the Secondary Bootloader.
In the next section, we explain both of them.
Primary Bootloader: Microcontroller Setup
After the microcontroller is reset, the control first comes to Primary Bootloader. This is the part of the Bootloader software that initializes and sets up the MCU resources.
In the context of a CAN based Bootloader, the resources include the CAN protocol and the CAN controller. The CAN controller is initiated to download the update, with the correct CAN speed.
Any update transmitted over CAN BUS is identified by the CAN protocol and subsequent actions are taken.
Secondary Bootloader: Microcontroller Reprogramming
Similar to the primary Bootloader that initializes various functionalities, this part of the Bootloader software gets active upon receiving the firmware update via the communication medium. It is known as the Secondary Bootloader. As a security measure, a Secondary bootloader is often downloaded into the RAM and activated with a specific request, so that the re-programming ability remains off-chip and is erased if the ECU power is interrupted or it is reset.
This secondary Bootloader then downloads the updates related to the target application and reprograms the flash memory. It has all the necessary flash routines and the UDS functions (if the Bootloader is UDS based) that are necessary for storing the updated data on the flash memory. After this, the Secondary Bootloader is erased from the RAM and control once again goes to the Primary Bootloader.
Role of UDS Software Stack in an Automotive ECU Re-programming
According to the AUTOSAR Standard, Unified Diagnostics Services (UDS) is the most suitable protocol for implementing Bootloader, for the purpose of ECU reprogramming. There are multiple reasons for that and it needs a full article of its own. For now, we will focus on the role played by UDS in a Bootloader operation.
Following are the key responsibilities of UDS in an ECU flashing operation:
- UDS sets the server into a reprogramming mode and starts the reprogramming sequence
- It handles the initiation and termination of the data transfer
- UDS takes care of the size and order of data blocks to be sent/received and memory blocks where the data will be stored
- The UDS services allow the client to start or stop a routine, which may be running on the server
- It allows the client to initiate a software reset event on the server
UDS performs all these responsibilities with the help of certain software services defined in ISO 14229–1 standard document.
Finally, as promised multiple times, lets have a look at OTA.
How does Remote ECU Flashing work (OTA)?
In order to perform automotive control unit reprogramming, the vehicle has to be brought to the garage where the service engineer will do the needful. However, as the software used in vehicles is growing in volume and complexity, numbers of software upgrades have also become more frequent.
In such scenarios, the OEMs cannot expect the vehicle owners to bring their car to the garage frequently, for the ECU flashing. A Bootloader software enabled with remote update capabilities over Ethernet is the key here.
With DoIP (Diagnostics over Internet Protocol), remote ECU update has become possible. While the rest of the components and services are similar, the usage of Ethernet as the medium for communication has made the remote update possible.
In simple terms, the firmware update that was transmitted over, say, CAN, is sent over Ethernet using a DoIP software stack. The DoIP stack inside the Bootloader software identifies the message and the entire process of ECU reprogramming is performed.
Whether based on DoIP or UDS, Flash Bootloader is a component that is indispensable, given the importance of regular ECU updates.
Want to learn more?
I am Ali Taqweem, Embedded Software developer specialized in Automotive domain, I have in-depth knowledge about Automotive Comm stacks, Bootloaders, Diagnostics, RTOS and AUTOSAR.
DM @ https://www.linkedin.com/in/ali-taqweem/
