As the automotive industry evolves, the demands placed on the motor control unit (MCU) are escalating. The proliferation of in-vehicle electronic products has transformed application software from simple entertainment modules like TV and music players to critical systems controlling the engine, suspension, chassis, and even autonomous driving functions. Consequently, the electronic control units within vehicles have grown exponentially more complex, and the frequency of electronic component updates has increased. When an application requires an update after the product is installed in the vehicle, the traditional method of physical disconnection and chip reprogramming is prohibitively cumbersome. Utilizing a chip-specific Bootloader circumvent this issue by enabling direct reprogramming via a bus connection, eliminating the need for disassembly. This functionality facilitates convenient updates, saving operational costs and preventing potential damage from repeated hardware removal.
Currently, the prevalent method for in-application programming (IAP) in the international automotive electronics market is a bootloading software developed based on the Unified Diagnostic Services (UDS) communication protocol. Implementing software updates through a UDS service-based Bootloader is a low-cost, high-efficiency, simple-to-operate technology that has gained widespread adoption.
Analysis of UDS Bootloader Based on CAN Bus
1.1 UDS Based on CAN Bus
UDS on Controller Area Network (CAN), standardized by ISO 14229, plays a pivotal role in diagnostic protocols. At the application layer, ISO 14229 is defined, while the in-vehicle implementation of these diagnostic services over CAN bus is specified by ISO 15765. This protocol stack enables Unified Diagnostic Services on a CAN network. Within the seven-layer OSI/ISO model, UDS over CAN utilizes five layers: Application, Session, Network, Data Link, and Physical layers. The functional model of CAN-based UDS services differs significantly from early OBD services, as summarized in the table below.
| OSI/ISO Layer | Primary Function | CAN UDS (ISO) | OBD (ISO) |
|---|---|---|---|
| Application Layer | Provides services for actual applications. | 14229-1 / 15765-3 | 15031-5 |
| Session Layer | Controls correct data transmission/reception for session-based communication. | 15765-3 | 15765-4 |
| Network Layer | Routes data (e.g., exchange, addressing). | 15765-2 | 15765-4 |
| Data Link Layer | Assembles frames, provides flow/error control (e.g., format, access, synchronization). | 11898-1 | 15765-4 |
| Physical Layer | Defines electrical signal specs (e.g., levels, cables, transceivers). | 11898-2 | 15765-4 |
1.2 Brief on CAN Bus Protocol
Developed by Bosch, the CAN bus was initially designed to standardize communication among numerous control and monitoring nodes within automobiles. It is a broadcast, message-based, serial communication protocol using two wires where differential voltage levels represent logic 0 and 1. A single CAN bus can support over 100 nodes effectively communicating with each other. Its robustness and deterministic arbitration make it ideal for the harsh automotive environment. The relationship between data rate ($R$) and maximum bus length ($L_{max}$) is often approximated by the empirical formula relevant for network design:
$$L_{max} \approx \frac{k}{R}$$
where $k$ is a constant dependent on transceiver characteristics and network topology. In practice, with rates of a few kb/s, distances can reach several kilometers, while at shorter distances (tens of meters), rates can approach 1 Mb/s. CAN frames are relatively short, with a maximum payload of 8 bytes for the standard base frame format, necessitating higher-layer protocols like ISO 15765 for segmentation and reassembly of longer data streams, such as those required for reprogramming a motor control unit firmware.
1.3 Implementation Methods for UDS-Based Bootloader
A Bootloader is the first code executed upon hardware reset. It initializes critical hardware, establishes memory maps, configures the system environment, and ultimately decides whether to update the application software or jump directly to its execution. Given the dominance of the CAN bus interface in automotive electronics, the Bootloader discussed here uses CAN-based UDS for data interaction.
1.3.1 Data Update for Single or Multiple Nodes
In a CAN network, some diagnostic and programming requests target a specific motor control unit (single node), while others, like a software update for a common module type, could target multiple nodes simultaneously. Optimizing update sequences is crucial. Broadcast or multi-cast addressing mechanisms can be employed to make a single download instruction from the tester effective on several nodes, significantly improving update efficiency. Message priority on the CAN bus must be orchestrated, prioritizing one-to-many multi-node downloads over one-to-one single-node updates to minimize total network occupation time.
1.3.2 Intelligent Node Design
Data packet loss during programming is inevitable. Therefore, nodes must be designed intelligently to verify the integrity of newly programmed code, for instance, using a Checksum or Cyclic Redundancy Check (CRC). The result of this verification must be reported back promptly, requiring efficient bidirectional data flow on the CAN bus. The CRC verification process for a data block $D$ can be represented as:
$$\text{CRC}(D) = R$$
where $R$ is the computed remainder. The node compares this computed $R$ with the one received from the tester to confirm data integrity.
1.3.3 Entering Bootloader Mode
The bootloading process is typically initiated by a command from a diagnostic tester (upper computer). While a hardware trigger (e.g., a button press) is possible, it is impractical for an embedded motor control unit. The standard method is to use a dedicated UDS service (e.g., Diagnostic Session Control) sent via CAN bus after ignition to switch the ECU from its default application session to a programming session, thereby invoking the Bootloader.
1.3.4 Requirements for a UDS-Based Bootloader
Key requirements include: update speed and data transfer rates meeting practical needs; high programming accuracy; immediate feedback to the tester upon failure; and robust error detection and recovery capabilities (e.g., retry mechanisms, fallback to previous software version).
1.4 Bootloader Tester (Upper Computer) Software Design
The Bootloader tester software facilitates interaction between the PC and the vehicle’s ECUs, controls the bootloading process, and provides a user interface. It is structured into three functional layers, as shown below.
1.4.1 Data Interaction Layer
This layer handles all data exchange. It packs, encodes, and formats data such as the update file (e.g., HEX/S19 format), control commands from the tester, and communication data from vehicle nodes into transmissible CAN frames (following ISO 15765). Conversely, it decodes incoming CAN messages into information usable by the upper layers.
1.4.2 UDS Diagnostic Service Module
This module implements the UDS client functionality. When the user initiates an action, this module constructs the appropriate UDS request frame (e.g., `0x34` for Request Download, `0x36` for Transfer Data, `0x37` for Request Transfer Exit) and passes it to the interaction layer. It also parses and interprets the UDS responses received from the motor control unit.
1.4.3 Graphical User Interface (GUI)
The GUI allows users to control the process: selecting the target ECU, choosing the update file, sending diagnostic commands (read data, clear faults), initiating the download, and monitoring progress (e.g., status, transfer percentage, logs). The GUI calls the underlying UDS service module, which in turn uses the data interaction layer to communicate with the vehicle.
Design and Implementation of the Motor Control Unit Bootloader Program
2.1 Bootloader Design Scheme
The Bootloader firmware for the motor control unit is developed in a modular fashion, comprising the following core components integrated into a cohesive system.
- CAN Driver Module: Implements low-level CAN controller initialization, frame transmission, and reception (polling or interrupt-based), adhering to the ISO 11898 standard.
- UDS Protocol Module: Implements the server-side of key UDS services (ISO 14229) and the ISO 15765 transport protocol for segmentation and flow control.
- Flash Driver Module: Provides low-level routines to erase, program, and verify the MCU’s internal Flash memory, ensuring reliability and protecting critical bootloader code.
- Bootloader Main Program: The central state machine that orchestrates the sequence: initialization, communication, diagnostics, and programming.
- PC Tester Software: The companion application providing the GUI and UDS client logic.
2.2 Implementation of CAN Driver
The CAN driver handles the physical sending and receiving of frames. The transmission process validates data length (≤ 8 bytes for standard frames), configures the CAN controller’s transmit registers with identifier, data, length, and priority, then triggers the send command. Reception typically employs an interrupt service routine (ISR) or periodic polling. Upon receiving a frame, the driver reads the identifier to determine the frame type (standard/extended), extracts the data length and payload, stores it in a software FIFO buffer, and clears the hardware receive flag. The upper UDS layer then processes messages from this buffer. The real-time performance requirement can be modeled by ensuring the service time $T_{service}$ for the receive ISR is less than the minimum inter-frame time $T_{frame}$:
$$T_{service} < T_{frame}$$
This guarantees no frame loss under maximum bus load during critical programming phases.
2.3 Flash Memory Management
All UDS and bootloader code resides in a protected section of Flash. The memory map of the motor control unit (e.g., based on an STM32F407 with 1024 KB Flash) is strategically partitioned as follows:
| Memory Region | Size | Address Range | Purpose |
|---|---|---|---|
| Bootloader Region | 32 KB | 0x0800 0000 – 0x0800 7FFF | Stores the permanent bootloader code. Never updated in-field. |
| APP Info / Parameters | 16 KB | 0x0800 8000 – 0x0800 BFFF | Stores metadata: active application pointer, checksums, version info. |
| Application Slot A | 384 KB | 0x0802 0000 – 0x0807 FFFF | Primary application image. |
| Application Slot B | 384 KB | 0x0808 0000 – 0x080D FFFF | Secondary (update) application image. |
The dual-application slot strategy enables robust fail-safe operation. The Bootloader checks a flag in the APP Info region to determine the active slot. During an update, the new firmware is programmed into the inactive slot (e.g., Slot B). Only after a successful download and verification is the active pointer switched. The old firmware in Slot A can then be erased, ready for a future update. This ensures there is always a valid, working application for the motor control unit. Flash operations are guarded and only permitted after successful security access and validation of received addresses and data lengths.
2.4 Implementation of the Bootloader Main Program
After the motor control unit resets, the Bootloader main program executes from its fixed Flash location. Its operational flowchart is implemented as follows.
- Initialization: Critical hardware modules are initialized: clocks, CAN controller, GPIOs, and the Flash interface. The program also validates its own integrity.
- Update Check: The Bootloader listens on the CAN bus for a predefined time window for a diagnostic session control request entering programming mode. If no such request is received, it proceeds to the application jump.
- Application Validation and Jump: It reads the active application pointer from the APP Info sector, verifies the application’s checksum or CRC. If valid, it performs a vector table relocation and jumps to the application’s start address.
- Programming Session: If a programming session request is received, the Bootloader remains active. It executes the UDS service sequence: Security Access to unlock programming, then services like `RoutineControl` to erase Flash, `RequestDownload` and `TransferData` to receive the new firmware, and finally `RequestTransferExit` to conclude. After successful programming and verification, it updates the application pointer and reset the motor control unit to run the new software.
The core logic can be described by a state machine $S$ with states ${S_{Init}, S_{Check}, S_{AppRun}, S_{Prog}}$ and transitions triggered by events $E$ (timeout, valid CAN message): $$S_{next} = f(S_{current}, E)$$
2.5 Implementation of the PC Tester
The tester software was developed in Python for flexibility and rapid prototyping. It follows a Model-View-Controller-like pattern. The GUI, designed with Qt, provides buttons and displays corresponding to UDS functions. Each user action sets an internal variable or triggers a callback function. The backend logic consists of a CAN interface layer (using a library like python-can), a UDS client module that builds and parses packets, and a file parser for the HEX file. The HEX file, an ASCII representation of binary code, is parsed to extract memory addresses and data bytes, which are then sent sequentially to the motor control unit via the `TransferData` service. Progress is calculated based on the total data size and the number of frames acknowledged.
Testing and Analysis of Bootloader Performance
3.1 Test Objectives
The primary objectives of the integration test were to validate functional correctness, assess performance against specifications, and ensure robustness. The key verification points were:
- Feasibility & Basic Function: Does the UDS Bootloader operate as intended, performing startup, application validation, and mode switching correctly?
- Protocol Conformance: Do the implemented UDS diagnostic services comply with ISO 14229 and ISO 15765 protocols in terms of request/response format and timing?
- Data Integrity & Reliability: Is the data transmission accurate throughout the multi-step programming process? Can the system recover from simulated errors (e.g., interrupted communication)?
3.2 Bootloader Performance Test Setup
A laboratory test bench was established, comprising:
- A development board with the target motor control unit (STM32F407).
- A regulated DC power supply.
- A professional CAN interface (e.g., Vector VN1610) connected to the PC.
- The custom Python UDS Tester software.
- CANoe software for independent bus monitoring and validation.
Tests conducted included: power-on self-test and default application boot; manual invocation of the Bootloader via diagnostic session change; full firmware update cycles using sample HEX files of varying sizes; and negative tests like sending invalid service requests or interrupting power during programming.
3.3 Test Results and Analysis
The comprehensive testing yielded positive results, confirming the design’s validity:
| Test Category | Result | Observation / Metric |
|---|---|---|
| Basic Functionality | PASS | Bootloader initialized correctly, jumped to valid app, and entered programming mode on command. |
| UDS Service Compliance | PASS | All implemented services (0x10, 0x27, 0x31, 0x34, 0x36, 0x37, 0x3E) responded with correct positive/negative response codes as per ISO standards. |
| Firmware Update Integrity | PASS | Multiple update cycles were performed successfully. The CRC verification post-download passed every time. The new application executed flawlessly. |
| Data Transfer Performance | ACCEPTABLE | With a CAN bus speed of 500 kb/s and using ISO 15765 flow control, the effective data transfer rate for the motor control unit was measured. The time $T_{update}$ for a firmware of size $S$ can be estimated as: $$T_{update} \approx T_{overhead} + \frac{S}{R_{effective}}$$ where $R_{effective}$ accounts for protocol overhead. The achieved rate was sufficient for production and service needs. |
| Error Handling | PARTIAL PASS | The Bootloader correctly rejected invalid security keys and reported failed CRC checks. Recovery from a mid-transfer communication break required a full restart, highlighting a potential area for enhancement with a resume feature. |
Conclusion
This project involved the design and implementation of a robust, production-ready UDS-based Bootloader for automotive motor control units. Based on an in-depth analysis of industry standards (ISO 14229, ISO 15765) and practical engineering requirements, a system comprising embedded firmware for the target MCU and a PC-based tester application was successfully developed. The design employs a safe dual-application memory partition strategy, comprehensive UDS diagnostic services, and integrity checks to ensure reliable field updates. Laboratory testing validated the system’s functionality, protocol compliance, and data integrity. The implemented Bootloader provides a crucial foundation for efficient software lifecycle management in modern vehicles, significantly reducing update complexity and cost while enhancing the scalability and maintainability of automotive electronic systems. Future work may focus on adding differential update capabilities, support for additional communication backbones (Ethernet), and more advanced security features for the motor control unit software.