Key Points in Automotive ECU Bootloader Development

Content Summary

Introduction

1. Function of Bootloader

2. How to Establish Reliable Bus Communication?

3. Parsing Programming Files (S19/HEX/BIN)

4. NVM Driver Development

5. Other Key Points in Bootloader Development

a. Relationship Between Bootloader and Application

b. Methods to Jump from Bootloader to Application

c. Knowledge and Debugging Techniques Required for Bootloader Development

d. Download Methods for Bootloader and Application During Mass Production

Conclusion

Introduction

On one hand, with the continuous advancement of semiconductor technology (according to Moore’s Law), the logic functions integrated within the MCU are becoming increasingly complex, and memory is growing larger; on the other hand, consumers are demanding more from cars in terms of energy efficiency (economic and regulatory requirements for emissions), comfort, connectivity, and safety (functional safety and information security). Particularly, the rise of new energy electric vehicles, vehicle networking, and autonomous driving technologies in recent years has greatly accelerated the development of automotive electronic technology. The functions integrated within automotive electronic ECUs (Electronic Control Unit) are becoming increasingly complex, leading to a growing demand for software remote (online) function upgrades (adding new features) and bug fixes, thus increasing the need for BootLoader (bootloader). This article will detail the key points in the development of automotive electronic ECU BootLoader for everyone’s learning.

1. Function of Bootloader

BootLoader, as the name suggests, is a segment of program loading code residing in the non-volatile memory of the ECU, which runs every time the ECU is reset. It checks for remote program loading requests from the communication bus; if there are any, it enters bootloader mode, establishes bus communication with the program downloader (usually a PC host), receives the application program downloaded via the communication bus, parses its address and data code, runs the NVM (Non-Volatile Memory) driver to program it into NVM, and verifies its integrity, thus completing the application program update. If there are no remote program loading requests from the communication bus, it directly jumps to the application’s reset entry function (reset interrupt ISR, also known as Entry_Point() — using Processor Expert’s CodeWarrior project or Startup() function — standard CodeWarrior project), and runs the application.

Based on this, the three main functions of the automotive ECU’s bootloader are as follows:

  • Establishing reliable bus communication with the remote program downloader to obtain the application program to be updated;

  • Parsing the application program’s programming files (S19/HEX/BIN) to obtain its address and program code and data in NVM;

  • Running the NVM driver to program the application code and data into NVM and verify;

2. How to Establish Reliable Bus Communication?

Common data buses for automotive ECUs include CAN and LIN, so the bootloader for automotive ECUs is usually designed to download data via CAN or LIN. Other buses can also be used, such as SPI or I2C (typical for some function safety ECUs with safety monitoring, upgrading the program of the safety monitoring MCU via the main MCU) and Ethernet (for central control units or fully LCD instrument clusters based on Ethernet communication, and next-generation high-speed gateways and ADAS ECUs).

Tips:

a. Different ECUs use different communication buses; the specific bus required depends on the actual application;

b. The communication bus has the MCU peripherals implemented, so the bootloader must develop the corresponding communication bus peripheral driver to achieve basic data sending and receiving functions;

c. To ensure communication reliability, a complete communication protocol based on the communication bus must be developed. Mechanisms such as request command, acknowledge, block wait, and error re-send need to be established between the application downloader and the bootloader. The bootloader completes different tasks based on different request commands and confirms whether the operation is completed (ACK) and whether the data is being transmitted completely. If data errors occur (through checksum or ECC), automatic re-transmission is required;

d. The application downloader needs to develop GUI software based on VC, C#, QT, Labview, etc., on the PC to implement the required bus communication protocol, generally through calling the dynamic library (DLL) API interface of the corresponding bus device, such as USB to CAN/LIN forwarding devices, to achieve data transmission and reception. Therefore, bootloader developers generally need to have some PC host software development capabilities;

e. To achieve reliable data transmission, source coding is generally added to the bus communication protocol, meaning that checksums or ECC calculations are performed on valid data during transmission, and the results are sent together with the valid data in the communication data frame. The bootloader receives the data frame, performs the same checksum or ECC calculation on the valid data field, and compares the result with the received checksum or ECC calculation result to determine the data’s integrity. Programming files (S19/HEX/BIN) generally have corresponding checksum mechanisms, so direct transmission of program programming files can be adopted; otherwise, users need to first parse the programming file in the host software, then package the addresses, data, and code into a custom communication protocol, which the bootloader must then unpack, making it slightly cumbersome. However, some OEMs have their own bootloader protocols for intellectual property protection, in which case the bootloader developer must develop according to the OEM’s requirements;

f. Some major OEMs require their ECU suppliers to develop bootloaders based on bus diagnostic protocols like UDS. If UDS specifies corresponding CAN IDs for bootloader use, the UDS protocol stack must be included in the bootloader project of such ECUs;

3. Parsing Programming Files (S19/HEX/BIN)

Different MCU software development IDEs may generate programming files in different formats, but S19, HEX, and BIN files can be converted into one another, so only one programming file parsing program needs to be developed in the bootloader, while others can use corresponding conversion tools on the host to perform conversions;

The purpose of parsing programming files is to obtain the program code and data of the application program and its storage address in NVM;

To parse programming files, one must first understand the encoding formats and principles within them. Common formats for S19, HEX, and BIN files can be referenced in the following Wikipedia links:

  • S19 File: https://en.wikipedia.org/wiki/SREC_(file_format)

  • HEX File: https://en.wikipedia.org/wiki/Intel_HEX

  • BIN File: https://en.wikipedia.org/wiki/Binary_file

4. NVM Driver Development

The NVM of the ECU generally includes EEPROM or Data-Flash integrated within the MCU for data storage, Code-Flash/Program-Flash for storing program code/data, and external NOR Flash or NAND-Flash for MPU expansion; the NVM driver includes basic operations such as erasing (erase), programming (program), and verification (verify), as well as operations for securing (secure)/decrypting (unsecure) and protecting (protection)/unprotecting (unprotection) the NVM.

Tips:

a. The integrated NVM within the MCU, including EEPROM/D-Flash and C_Flash/P-Flash, generally belongs to different blocks, so NVM drivers can directly erase and program EEPROM/D-Flash on Flash;

b. NVM drivers are generally completed by running an NVM command sequence, where different NVM operation command codes, NVM programming data, and target addresses are provided through the NVM controller register. A typical NVM command sequence is as follows (Freescale’s S12(X) series MCU Flash write command sequence):

Key Points in Automotive ECU Bootloader Development

c. Since the working speed of NVM is generally lower than that of the CPU core frequency and bus frequency, the NVM must be initialized before running the NVM driver, setting the frequency divider to the normal working frequency range;

d. The NVM driver cannot operate on the same block of NVM for erasing and programming itself, as this will cause a read while write bus access conflict (each NVM block has only one data bus and can only perform read or write at one time, not both simultaneously). Therefore, for MCUs with only one block Flash, the NVM driver must be called in RAM to erase and program itself, and during the launch of the Flash command to wait for the command to complete, all CPU global interrupts must be disabled to prevent peripheral interrupt responses; otherwise, accessing interrupt vectors and running interrupt ISRs will access Flash.

To enable interrupts, the interrupt vector table must be moved to RAM or an NVM block (EEPROM/D-Flash), and the corresponding interrupt ISR must also be copied to other RAM or NVM blocks (of course, the interrupt vector table must also be updated to guide the new interrupt ISR);

e. Due to the requirements in b above, the NVM driver of the bootloader is usually copied to run in the MCU’s RAM. It can copy the completed NVM to run in RAM or only copy a few instructions to launch the NVM command to RAM for execution since other operations (such as filling NVM operation commands, writing programming addresses and data, etc.) will not write data to NVM on the data bus;

f. The NVM driver resides in Flash; if a stack overflow or other unexpected program runaway occurs, it may cause unexpected erasure or modification of NVM contents. Therefore, it is necessary to protect critical data or code (such as the bootloader itself) to prevent accidental modification, or a safer method is not to store the NVM driver in NVM but to download it to run in RAM through the host at the beginning of the bootloader, and then clear that RAM area after the bootloader ends, thus avoiding data loss and modification in NVM due to unexpected execution of the NVM driver. (PS: I will write a dedicated article on related methods later, please stay tuned for reading)

g. Generally, MCU manufacturers provide their NVM driver libraries, which users can use to implement NVM operations. If it is a Freescale/NXP automotive-grade MCU, the integrated Processor Expert in CodeWarrior IDE can also generate corresponding NVM driver programs;

5. Other Key Points in Bootloader Development

a. Relationship Between Bootloader and Application

  • The bootloader and application are two complete MCU software projects, each with its own startup code, main() function, link files, peripheral drivers, and interrupt vector tables;

    Key Points in Automotive ECU Bootloader Development

  • Therefore, the link files of the bootloader and application must independently allocate the address space for NVM without overlapping, but there are no constraints on RAM allocation, as both can use the entire RAM space since jumping to the application project will reinitialize RAM;

  • The bootloader must use the MCU’s default interrupt vector table, as the MCU always executes from its default interrupt vector table’s reset vector address after each reset; the application program’s interrupt vector must be offset (through corresponding interrupt vector offset registers, such as the IVBR register of S12(X) series MCUs or SCB->VTOR register of ARM Cortex M series MCUs);

    While NVM (P-Flash) erasure is sector-based, to fully utilize the NVM (P-Flash) space, the bootloader is partitioned to include several NVM (P-Flash) sectors containing the default interrupt vector table (S12(X) series MCUs’ last several sectors of NVM, ARM Cortex M series MCUs’ several sectors starting from address 0);

b. Methods to Jump from Bootloader to Application

After developing and using a bootloader, every time the ECU is reset, the bootloader will run first. If there are no remote application download requests, it will directly jump to the application reset function address. Two issues need to be considered here:

How to obtain the application reset function address: Methods include: 1) fixing the application reset start function address through the link file; 2) obtaining it from the reset vector address of the application interrupt vector table;Recommended method 2): due to its flexibility, after each application change, there is no need to care about the specific address where the application reset function is compiled into NVM; just take the reset vector from the application interrupt vector table to run;

A typical method is as follows (assuming the application interrupt vector table base address register IVBR of the S12(X) series MCU = 0x7F):

typedef void (*near tIsrFunc)(void);/* ISR prototype definition */

word *Ptr; /*pointer used for ISR vector fetch*/

Ptr = (word *)0x7FFE; /*get the ISR vector from the interrupt vector table of APP project */

((tIsrFunc)(*Ptr))(); /*convert and run*/

Jump Timing: Methods include: 1) after the bootloader updates the application program and verifies its integrity OK, restore the used peripherals (such as CAN/LIN communication bus modules, timers, GPIO, etc.) to their reset default states, then jump directly; 2) after the bootloader updates the application program and verifies its integrity OK, wait for the watchdog timer timeout overflow reset, and jump if no remote application download request is detected at the start of the bootloader; Recommended method 2): because method 1) may lead to differences in the MCU’s hardware environment when jumping to the application reset start function compared to directly running the application, while method 2) using the watchdog reset is a hardware reset, which will reset most peripherals (analog, clock, and peripheral) circuits, making it closer to directly running the application.

c. Knowledge and Debugging Techniques Required for Bootloader Development

First, developers need to have a very clear understanding of the RAM and NVM resources used by the MCU in the ECU, and then partition them to ensure that the NVM allocation for the application program and bootloader does not overlap. Therefore, it is essential to understand the usage and writing rules of the link file in the software development tool IDE being used;

Specific reference: CodeWarrior IDE usage tips on prm link file details (custom memory partitioning and custom RAM data initialization and running functions in RAM) (click to read)

Next, it is necessary to determine whether the interrupt vector table offset is successful, and the address and size of the NVM driver copy, so one must master the specific information in the map file of the compilation link results of the software development tool IDE being used;

Specific reference: CodeWarrior IDE usage tips on map file details (click to read)

Additionally, mastering how to redirect NVM functions (separating the storage address and runtime address of function program code) to execute in RAM is also very useful;

Tips:

When developing the application program, it is necessary to debug it separately to ensure its functionality is normal. Although the peripheral interrupt vector table has been offset, the reset vector must be placed at the address where the reset vector is located in the default interrupt vector table; otherwise, after downloading, it cannot run and debug normally. If the reset vector of the application program is placed in the offset application interrupt vector table, the content of the default reset vector will be 0xFFFF (the state after Flash erasure), and the CPU core will fetch instructions from the address 0xFFFF, which is clearly not the real project startup function, so it cannot run, resulting in illegal address resets, similar to a new MCU running without any program written. Finally, after the application program is completed, it can be offset to the application interrupt vector to avoid conflicts with the bootloader project’s Flash address;

Lastly, mastering the use of the debugger’s Hotsync or attach methods to load debugging information from the elf file for seamless debugging of the bootloader and application is also very practical, significantly improving debugging efficiency for the bootloader;

Specific reference: CodeWarrior IDE usage tips on bug locating techniques — hotsync and attach debugging (click to read)

d. Download Methods for Bootloader and Application During Mass Production

It is recommended to merge the programming files generated by compiling and linking the bootloader and application, using mass production tools (such as Cyclone programmers) for one-time downloading to improve production efficiency.

Conclusion

This article detailed the general working principles and development key points of automotive electronic ECU bootloaders, applicable to all automotive electronic ECU bootloader development. Of course, different MCUs have different software development tools IDEs and interrupt handling mechanisms, so I will continue to release a series of articles introducing bootloader development examples for S12(X) series MCUs, MagniV S12Z series MCUs, Qorivva MPC56xx/57xx series MCUs, and KEA/S32K series MCUs, providing corresponding demo projects for reference and learning. Please stay tuned!

The above is what I shared with everyone today. I hope it is useful to you.

The personal original quality articles already published by this public account on embedded system technology are linked below, welcome everyone to refer to and share:

  • List of articles in the automotive electronic expert growth series

  • Discussing three common misconceptions in embedded MCU development

  • Discussing the stack and heap of application engineering in embedded MCU software development

  • Discussing interrupt priority and interrupt nesting in embedded MCU software development

  • Discussing code style and code optimization in embedded MCU software development

  • Discussing the startup process in embedded MCU software development (preparation from reset vector to main function)

  • Discussing the startup process in embedded MCU software development (implementing custom RAM initialization in CodeWarrior 5.1)

  • Discussing three writing methods of interrupt ISR in CodeWarrior 5.1 IDE for S12(X) series MCU

  • Discussing the minimum system circuit design of MCU in embedded hardware design

  • In-depth explanation of on-chip memory resources and paging access mechanisms of S12(X) series MCUs (Part 1)

  • In-depth explanation of on-chip memory resources and paging access mechanisms of S12(X) series MCUs (Part 2)

  • Principles of encryption (Secure) and decryption (Unsecure) of S12(X) series MCUs

  • Programming on-chip NVM of S12(X) and MagniV S12Z series MCUs using Cyclone offline programmer

  • Mode control and switching of Qorivva MPC56xx/57xx series MCUs (enabling on-chip peripheral resources and power control)

  • Peripheral usage tips for MSCAN receiving ID filter settings

  • Peripheral usage tips for TIM timer usage FAQ and experiences

  • Peripheral usage tips for configuring and using SWT watchdog timers in automotive-grade MPC574xP series MCUs

  • S32DS usage tips — downloading S19 or elf files from file

  • S32DS usage tips — migration and upgrade methods and considerations from S32DS for ARM v1.3 project to S32DS for ARM V2.0

  • S32DS usage tips — project property configuration (compilation options and C compiler, assembler, and linker settings)

  • CodeWarrior IDE usage tips on map file details

  • CodeWarrior IDE usage tips on prm link file details (custom memory partitioning and custom RAM data initialization and running functions in RAM)

  • CodeWarrior IDE usage tips on bug locating techniques — hotsync and attach debugging

  • Differences in version selection, license functions (features) and prices, authorization forms, activation methods, and installation usage of CodeWarrior IDE

    If you like the articles from this public account, please click to follow at the beginning of the article or WeChat directly long press to scan the QR code below to follow. You can also add friends in WeChat –> public account –> enter “Automotive Electronics Expert Growth Path” to search and follow. If you have any opinions or suggestions regarding the viewpoints in this article, please feel free to leave a message. Your attention, likes, and shares are the greatest affirmation of my hard work in writing.

Key Points in Automotive ECU Bootloader Development

Hu Enwei

NXP Automotive Electronics FAE

September 17, 2017, in Chongqing

Related posts

  1. Detailed Explanation of STM32 Microcontroller Minimum System
  2. Common Software Architectures in Embedded Development
  3. Understanding ECU: From Simulink Model to Automotive Controller
  4. Key Considerations for Hardware Design in Embedded System Development
  5. MCU Self-Test and Diagnosis Methods
  6. Choosing Between Arduino and STM32: Which is More Suitable for Beginners?
  7. Why Do Microcontrollers Have So Little RAM?
  8. Engine Damage After ECU Tuning: 328 Engine Revival Journey
  9. Creating a Rotating Sphere in C Language
  10. Rapid Development of Embedded System Simulation for Automotive Controllers
  11. Key Design Points for Handheld Medical Devices
  12. How Automotive HMI Enhances In-Car Experience?
  13. The New Battlefield of Industrial IoT – Edge Intelligent Servers
  14. Summary of STM32 Embedded Interview Knowledge Points
  15. Why Is Your Home Wi-Fi Sometimes Fast and Sometimes Slow?
  16. An Overview of Makefile, Kconfig, and .config in the Kernel
  17. Deep Dive Analysis of CanFestival Architecture
  18. Application of Murata Micro Batteries in Mobile Medical Devices
  19. Portable Medical Imaging Diagnostic Equipment for Bedside Use

Leave a Comment