Diadrom Autotech Bootloader Product Information
Table of Contents
1.1 Primary and secondary bootloader concept 3
3 Unified Diagnostics Services. 4
4.1 Special Secondary Bootloader 5
5 Flexible memory structure. 5
1 Overview
Diadrom delivers the Diadrom Autotech Bootloader (DAB) for usage in ECUs.
The aim is to keep the bootloader as lightweight as possible, in order to avoid unnecessary complexity and achieve a robust bootloader, but still have a modular design where the implementation can be adapted to support multiple hardware platforms and protocols.
The bootloader has been developed during several software development and production projects. See section 8. Previous projects.
1.1 Primary and secondary bootloader concept
The bootloader is built on the concept of having a primary bootloader and a secondary bootloader.
The primary bootloader is started directly after a power on or ECU reset and is responsible for initializing the MCU and peripherals and to check the status of the rest of the software. The primary bootloader is implemented as a part of the hardware and the aim is that it shall not be replaced. It implements some basic diagnostic functionality (e.g. for reading data identifiers etc.).
The secondary bootloader includes functionality for flashing new software in the ECU and will be downloaded by the primary bootloader and resides in the RAM until a reset of the ECU is performed. See section 4. Download new software for further description of the software download concept.
Figure 1: Overview of responsibility for the different parts of the bootloader
2 Communication protocols
The communication stack of the bootloader is structured in layers as defined in the OSI-model. This enables reuse of upper layer concepts such as Software download and UDS communication and decrease the implementation time for new communication links and reduces the differences in integrations in the ECUs across the vehicle.
Figure 2: Communication stack according to OSI model
The communication stack also allows for the bootloader to access lower layers to be able to send and receive non-diagnostics communication, such as network management frames.
3 Unified Diagnostics Services
The bootloader is compliant to Unified Diagnostics Services (ISO14229) for diagnostic communication and uses the services defined in ISO14229-1 to perform the different concepts implemented in the bootloader.
The UDS services used by the bootloader are defined in the table below.
| Service ID | Service |
| 0x10 | Diagnostic Session Control |
| 0x11 | ECU Reset |
| 0x22 | Read Data By Identifier |
| 0x27 | Security Access |
| 0x2E | Write Data By Identifier |
| 0x31 | Routine Control |
| 0x34 | Request Download |
| 0x36 | Transfer Data |
| 0x37 | Request Transfer Exit |
| 0x3E | Tester Present |
4 Download new software
To download new software the primary and secondary bootloader concept is used.
The primary bootloader is used for downloading the secondary bootloader into the RAM. The primary bootloader does not contain any libraries for performing flashing of the ECU in order to avoid the possibility of an attacker gaining access to this functionality and be able to download unauthorized software into the ECU.
The secondary bootloader contains the flashing functionality and implements the concepts for software download defined by the OEM. The flashing functionality will not include possibility do erase and overwrite the primary bootloader and might also include protection for other sensitive data that shall not be able to overwrite, such as keys used for cyber security calculations etc. This is a protection measure for avoiding the risk of that the ECU gets “bricked”, i.e. is non-functional.
To avoid ending up in a state where the ECU starts a valid but non-functional application the bootloader will include functionality for staying in the primary bootloader after a power up and not start the application. Then the secondary bootloader can be downloaded, and the non-functional application can be replaced.
4.1 Special Secondary Bootloader
If there is a problem discovered in the primary bootloader of an ECU, e.g. a malfunctioning security algorithm, there is a possibility to implement and download a special secondary bootloader with the sole purpose of updating the primary bootloader with a new one. This is a risky operation and shall be avoided as far as possible, since the operation might brick the ECU depending on the implementation.
5 Flexible memory structure
The structure of the memory is downloaded as a separate software part and is not statically defined in the bootloader. This enables for a flexible structure that could be updated in the future if new functionality should be added or some software part outgrows its current memory section.
6 Cyber security
The bootloader enables for modern cyber security concepts to be used by being compliant to the Autosar Crypto Service Manager API and implement the OEM specific cyber security concepts on top of this.
Figure 3: Cyber Security stack overview
The compliance to the Crypto Service Manager API makes it possible to add crypto libraries specific for the hardware platform chosen for an ECU, which can include support for hardware accelerated calculations.
7 Test and verification
An important part of the integration of a bootloader to new hardware platforms are test and verification.
In order to test the integration of the bootloader, Diadrom provides an automated test tool called Diadrom Dolphin. The test tool includes test cases for testing the different layers in the communication stack, but also the concepts on a higher level such as Software Download.
Diadrom Dolphin is not dependent on a specific hardware interface and supports testing of communication protocols for CAN/CAN FD, DoIP/Ethernet, LVDS etc. It is also easy to add support for anything that has an API to connect to, such as power supplies, multimeters etc.
These test cases can be run to verify that an integrated bootloader still complies with the requirements defined.
Diadrom Dolphin also allows for running the test cases in a continuous integration environment, that can be of great value during integration of the bootloader.
8 Previous projects
The Diadrom Autotech Bootloader has been used in several projects and are thoroughly tested through use in these.
- Park Assist Camera (PAC) with LG Innotek for Lynk & co
- Head-up Display (HUD) with Nippon Seiki for Swedish OEM
- 2 x Park Assist Camera (PAC) with two Chinese Tier 1 suppliers for Chinese OEM
- Proof-of-Concept integration for CAN/CAN FD on NXP Processor (S32K148) for CEVT & VCC
9 Contact
For more info or a demonstration please send an email to: sales@diadrom.se
10 Links
- https://diadrom.se/products-and-solutions/diadrom-autotech-bootloader/
- https://diadrom.se/products-and-solutions/diagnostic-communcation-stack/
- https://diadrom.se/products-and-solutions/diadrom_encrypt/
- https://diadrom.se/products-and-solutions/diadrom-dolphin/
