A bootloader is a piece of code that allows the re-programming of application software without using a debugger. An automotive bootloader does exactly the same thing but in a different way. Flash Bootloader (FBL) is the alternate name and is most commonly used in the industry.
Below factors are the reasons that make automotive bootloaders stand apart from a typical bootloader implementation.
- A pre-defined download sequence based on the Unified Diagnostics Services (UDS) protocol is used for re-programming the ECU application software.
- The bootloader software is divided into two parts.
- Primary Bootloader (PBL) boots the ECU application if valid.
- Secondary Bootloader (SBL) is used for re-programming.
Primary Bootloader
The role of the primary bootloader is to boot the application software when it is valid. It is also responsible for downloading the secondary bootloader into the RAM region of memory and then passes on the control to it for reprogramming. The PBL resides in the ROM region of memory and it may be one-time programmable.
It excludes flash memory drivers. This by design is a really good approach to avoid accidental erasing or re-programming of the application software. Furthermore, it increases the level of security as it requires SBL which will be made available only to authorized tools or personnel.
The primary bootloader is flashed into the memory using an external debugger. On reset, it is the first entity that runs.
Secondary Bootloader
The role of the secondary bootloader is to re-program the ECU and it resides in the RAM region of memory. It contains all of the services offered by the PBL along with the flash memory driver and some additional UDS services. It acts as a super-set of PBL. SBL should first be downloaded only then reprogramming is possible.
The flash memory driver resides in RAM. This is really good because it avoids all possible issues when writing into flash memory. Here are a few reasons which we came across in our experience.
- It is not possible to read while writing the flash memory because it is not possible to erase/write into a region of flash memory which the CPU core is fetching instructions from. Which is basically the ROM region.
- When it’s not possible to reserve flash memory regions/blocks in an optimal way due to limited size or internal partitioning. This is MCU-dependent.
- Also using SBL, it is possible to update the PBL if it doesn’t reside in the one-time programmable area of memory.
UDS Protocol
Unified Diagnostics Protocol is one of the diagnostics communication protocols within an ECU and is based on a client-server model. An ECU that offers diagnostics services acts as a server. An external diagnostics tool known as Tester is used as a client by connecting it to the communication system such as CAN, Ethernet…etc of the ECU. It is better known as Tester-Client.
The diagnostics services offered by the ECU are based on sessions. There are two types of sessions.
- Default session.
- Non-Default session.
Only one session can be active at any given time. An active session offers only a certain set of UDS services and not all of the available UDS services. Each service may have a set of sub-functions. For your reference, this Wikipedia page lists all of the services defined by the UDS specification.
The following are the most commonly used UDS services in FBL.
- Diagnostic Session Control ($10)
- Routine Control ($31)
- Request Download ($34)
- Transfer Data ($36)
- Request Transfer Exit ($37)
- ECU Reset ($11)
The Programming session is one of the Non-Default sessions and is used for reprogramming the ECU. However, On power-on, the ECU is in the Default session. It continues to remain in the Default session until the Programming session is enabled. This means the ECU must transition from the Default session to the Programming session. A Diagnostic Session Control ($10) service is used for session transitions.
To switch sessions the Tester-Client must send a request with the required session identifier. To switch from the Default session to the Programming session the Tester-Client sends a [0x10 0x02] request. Where ”0x10” is the service identifier for the Diagnostic Session Control service and “0x02“ is the session identifier for the Programming session.
Programming Sequence
The programming sequence uses the UDS diagnostics protocol. There are three phases
The Pre & Post programming phase is handled by the application. The bootloader handles the programming phase alone. During the Pre-Programming phase, the application must ensure that all pre-programming conditions such as the vehicle is stationary, the DTC communication is disabled, and Diagnostics communication is disabled for other ECUs so that full bandwidth is available during reprogramming. In the Post-Programming phase the settings that were disabled in the Pre-Programming phase are re-enabled.
However, the entire programming sequence may be OEM-dependent.
Programming Phase
In the programming phase, the ECU application software is reprogrammed. The PBL must first download the SBL into the RAM region first. Then the SBL erases the application region of the memory and then programs the application software. This process is carried out in an ordered sequence. Below we have listed the ordered sequence in a simplified way.
- Activate the programming session using the Diagnostics Session Control service ($10).
- Download the SBL to the RAM region using UDS services ($34, $36, $37).
- Erase the application area using the SBL. A routine control service ($31) is used to trigger the erase routine function.
- The SBL downloads the application to the flash memory in the application region using UDS services ($34, $36, $37).
- Using routine control service ($31) perform integrity checks and software dependency checks if required.
- Reset the ECU ($11).
Closing Remarks
The entire programming sequence can be customized to meet OEM requirements. The sequence described above is the simplified version. The OEMs, for example, might require security features so they might want to integrate some security modules or libraries, some might introduce additional steps such as updating fingerprint data before updating the application and some might have different requirements for diagnostic session transitions. So the programming sequence should be flexible to meet the OEM requirements.