Online Upgrade Method of Electric Vehicle Electronic Control Unit Bootloader

Introduction The rapid proliferation of electric vehicles (EVs) has revolutionized the automotive industry, driven by advancements in electronic control unit (ECU) technology. As EVs rely heavily on electronic systems rather than traditional mechanical components, the role of ECUs in managing vehicle functions has become indispensable. A critical component of ECU software is the Bootloader, which enables software updates post-manufacturing. However, traditional Bootloader upgrade methods require physical removal of the ECU, leading to inefficiencies and increased costs. This paper presents an innovative online upgrade method for EV ECU Bootloaders, eliminating the need for hardware disassembly and enhancing maintenance scalability.

ECU Software Structure The software architecture of an EV ECU is divided into three primary regions within the microcontroller’s Flash memory: the Bootloader program area, the jump flag storage area, and the application program area. Table 1 summarizes the memory partitioning:

Region	Start Address	End Address	Size	Function
Bootloader Program Area	Flash Address1	Flash Address2	几 kB–几十 kB	Stores the Bootloader firmware, responsible for system initialization and updates.
Jump Flag Storage Area	Flash Address2	Flash Address3	32 B	Stores a flag (e.g., 0x10, 0x30) to determine whether to jump to the application program.
Application Program Area	Flash Address3	End of Memory	Remaining space	Contains the ECU’s operational software, managing vehicle-specific functions.

The Bootloader occupies a minimal Flash footprint (几 kB–几十 kB) to ensure efficiency, while the application program utilizes the remaining space. The jump flag (32 B) acts as a critical trigger for switching between Bootloader and application modes.

Bootloader Functions The Bootloader performs three core functions essential for EV ECU operation: power-on self-test, application integrity verification, and program jump management.

1. Power-On Self-Test Upon power-up, the Bootloader initiates a self-test sequence to validate hardware functionality:

Clock System Check: Ensures the microcontroller’s clock is within operational limits.
Flash/RAM Integrity Check: Scans for read/write errors in non-volatile (Flash) and volatile (RAM) memory. If any failures are detected, the ECU enters a fault state and reports an error code. The self-test flowchart (simplified in text) follows these steps:

Power on → Bootloader activation.
Execute clock and memory checks.
If pass → Proceed to application; if fail → Report fault.

2. Application Integrity Verification To ensure reliable application software execution, the Bootloader employs a Cyclic Redundancy Check (CRC) algorithm. The process involves two stages:

2.1 CRC Data Padding

The application hex file is compiled, and a CRC checksum is calculated by a host computer.
The checksum is embedded into a fixed location in the hex file (Figure 1 in original document, described in text).
Formula:\(\text{CRC}_{\text{calculated}} = f(\text{Application Data})\) where f represents the CRC algorithm.

2.2 Integrity Check

After flashing the application data, the Bootloader recalculates the CRC and compares it with the pre-embedded checksum.
If matching, the application is deemed valid; if not, a fault is reported.
Pseudocode:plaintextif (CRC_calculated == CRC_embedded) { jump to application; } else { report integrity error; }

3. Program Jump Management The Bootloader manages transitions between its own environment and the application program based on multiple conditions:

Successful self-test.
Receipt of a valid flash connection command (e.g., via CAN bus).
Passed integrity check. The jump logic flowchart (simplified) is as follows:

Power on → Bootloader self-test.
If self-test passes, check for a flash connection command.
If command received → Enter flash mode; else → Verify application integrity.
If integrity valid → Jump to application; else → Report error.

Online Bootloader Upgrade Method The proposed online upgrade method eliminates hardware disassembly by leveraging a two-layer Bootloader architecture: a base Bootloader and an application-layer Bootloader. The process involves seven steps, combining flash operations and jump sequences.

Step 1: Jump to Base Bootloader

Action: Write the jump flag 0x10 to the flag storage area and switch to the base Bootloader at Flash Address1.
Purpose: Initialize the upgrade process from the current application program.

Step 2: Flash Application-Layer Bootloader

Action:
1. Verify the jump flag 0x10.
2. Erase the application-layer memory region.
3. Receive and write the new application-layer Bootloader data.
4. Validate data integrity via CRC.
Formula:\(\text{Flash Erase}({\text{App\_Bootloader\_Region}}) + \text{Data Write}({\text{New\_App\_Bootloader}})\)

Step 3: Jump to Application-Layer Bootloader

Action: Write 0x30 to the flag storage area and jump to the newly flashed application-layer Bootloader at Flash Address3.
Purpose: Transition to the new Bootloader for subsequent base Bootloader updates.

Step 4: Flash New Base Bootloader

Action:
1. Receive a flash connection command.
2. Erase the base Bootloader region (Flash Address1–Flash Address2).
3. Write the new base Bootloader data and validate via CRC.
Key Formula:\(\text{CRC}_{\text{new\_base}} = f(\text{New Base Bootloader Data})\)

Step 5: Jump to New Base Bootloader

Action: Write 0x10 to the flag storage area and switch to the new base Bootloader at Flash Address1.
Purpose: Activate the updated base Bootloader for final application software validation.

Step 6: Flash Updated Application Program

Action:
1. Verify the jump flag 0x10.
2. Erase the application program region.
3. Receive and write the new application data, followed by CRC validation.

Step 7: Jump to Updated Application Program

Action: Write 0x30 to the flag storage area and jump to the application program at Flash Address3.
Outcome: Completion of the end-to-end upgrade, with the ECU now running the updated software.

Table 2: Summary of Upgrade Steps

Step	Type	Key Operations	Jump Flag	Target Address
1	Jump	Write `0x10` and switch to base Bootloader	0x10	Flash Address1
2	Flash	Erase and write application-layer Bootloader	N/A	Flash Address3
3	Jump	Write `0x30` and switch to application-layer Bootloader	0x30	Flash Address3
4	Flash	Erase and write new base Bootloader	N/A	Flash Address1
5	Jump	Write `0x10` and switch to new base Bootloader	0x10	Flash Address1
6	Flash	Erase and write updated application program	N/A	Flash Address3
7	Jump	Write `0x30` and switch to application program	0x30	Flash Address3

Application Cases Two real-world fault scenarios in EV 倒车雷达 (reverse radar) systems illustrate the practical utility of robust Bootloader functionality and diagnostic protocols.

Case 1: Reverse Radar System Failure

Symptom: No buzzer sound and non-responsive radar sensors when in reverse gear.
Diagnosis:
1. Checked connector integrity → No issues.
2. Measured power supply (12V) and ground continuity → Normal.
3. Tested signal line voltage (0V vs. expected 12V) → Signal line open circuit.
Conclusion: Faulty signal wiring required replacement.

Case 2: Reverse Radar Abnormal Alarm

Symptom: Buzzer emits a short beep, long beep, and two short beeps; sensors 2–4 unresponsive.
Diagnosis:
1. Verified power (12V) and ground for sensors 2–4 → Normal.
2. Checked signal line voltage (12V, within normal range) → No wiring issues.
3. Tested sensor functionality → Sensors 2–4 failed due to water ingress.
Conclusion: Replaced faulty sensors.

Table 3: Case Comparison

Parameter	Case 1	Case 2
Symptom	No response	Abnormal beeping sequence
Primary Fault	Signal line 断路 (open)	Sensor internal failure
Diagnostic Steps	Power → Ground → Signal	Power → Ground → Signal → Sensor
Resolution	Repair signal wiring	Replace sensors

Conclusion This paper presents a robust online upgrade method for EV ECU Bootloaders, addressing the inefficiencies of traditional hardware-dependent approaches. By leveraging a dual-layer Bootloader architecture and systematic flash/jump sequences, the proposed method enables seamless in-vehicle updates, reducing maintenance costs and enhancing EV reliability. The integration of CRC validation and modular memory partitioning ensures data integrity and operational safety, while real-world diagnostic cases highlight the practical relevance of efficient ECU management in modern electric vehicles. As the EV industry continues to evolve, such innovations in software maintenance will remain critical to advancing vehicle performance and sustainability.

Leave a Comment Cancel Reply