Understanding automotive ECU bootloader development in one article

With the continuous advancement of semiconductor technology (according to Moore's Law), the number of logical function peripherals integrated inside the MCU is increasing, and the memory is also increasing. Consumers have higher and higher requirements for automobile energy saving (economic and regulatory requirements for emissions), comfort, connectivity, and safety (functional safety and information security). In particular, the rise of new energy electric vehicles, vehicle networking, and autonomous driving technology in recent years has greatly accelerated the development of automotive electronic technology. The functions integrated in automotive electronic ECUs (Electronic Control Units) are becoming increasingly complex. In order to cope with the needs of software remote (online) function upgrades (adding new functions) and bug fixes, there is an increasing demand for bootloaders (boot loaders). This article details the general working principles and development points of automotive electronic ECU bootloaders, which are applicable to all automotive electronic ECU bootloader development.

1. Function of bootloader

BootLoader, as the name implies, is a program loading code residing in the non-volatile memory of the ECU. The bootloader will be run every time the ECU is reset. It will check whether there is a remote program loading request from the communication bus. If so, it will enter the bootloader mode, establish bus communication with the program download end (usually a PC host computer), receive the application downloaded from the communication bus, parse its address and data code, run the NVM (None Valitale Momory--non-volatile memory) driver, program it into the NVM, and verify its integrity, thereby completing the application update. If there is no remote program loading request from the communication bus, it will directly jump to the application reset entry function (reset interrupt ISR, also called Entry_Point()--CodeWarrior project using Processor Expert or Startup() function--ordinary CodeWarrior project) to run the application.

Based on this, the three main concepts of the automotive ECU bootloader are as follows:

Establish reliable bus communication with the remote program download terminal to obtain the application program to be updated;

Parse the application programming file (S19/HEX/BIN) to obtain its address, program code and data in NVM;

Run the NVM driver to program the application code and data into the NVM and verify it;

2. How to establish reliable bus communication?

Common data buses for automotive ECUs are CAN and LIN, so usually the bootloader of automotive ECU downloads data through CAN or LIN. Of course, it can also be based on other buses, such as SPI bus or I2C bus (typically, some functional safety ECUs with safety monitoring, the program of the functional safety monitoring MCU is upgraded through the main MCU) and Ethernet (central control or full LCD instrument ECU based on Enternet communication, as well as the next generation of high-speed gateways and ADAS ECUs).

Tips:

a. Different ECUs have different communication buses. The specific communication bus you need to use depends on the actual application;

b. The communication bus is implemented by the MCU peripherals of the ECU, so the corresponding communication bus peripheral driver must be developed in the bootloader to implement basic data sending and receiving functions;

c. In order to ensure the reliability of communication, a perfect communication protocol based on the communication bus must be developed. Mechanisms such as request command, acknowledgement, block wait, and error re-send need to be established between the application downloader and the bootloader. The bootloader completes different tasks according to different request commands and confirms whether the operation is completed (ACK) and whether the data is correctly and completely transmitted. If a data error occurs (implemented by checksum or ECC), automatic retransmission is required.

d. The application download end needs to develop GUI software on the PC based on VC or C#, QT, Labview, etc. to implement the bus communication protocol required in c. Generally, at its bottom layer, it realizes data reception and transmission by calling the API interface of the dynamic library (DLL) of the corresponding bus device, such as the USB to CAN/LIN transponder device. The corresponding bus USB transponder device will provide the corresponding driver library (DLL). Therefore, the bootloader developer generally needs to have certain PC host computer software development capabilities;

e. In order to achieve reliable data transmission, source coding is generally added to the bus communication protocol, that is, the valid data is checked or ECC calculated when it is sent, and the result is sent together with the valid data in the communication data frame. The bootloader receiving end performs the same checksum or ECC calculation on the valid data field after receiving the data frame, and compares the result with the received checksum or ECC calculation result value to determine the integrity of the data. The application programming file (S19/HEX/BIN) has a corresponding checksum mechanism, so the program programming file line can be directly transmitted; otherwise, the user needs to first parse the programming file in the host computer software, and then encapsulate the address, data and code into a customized communication protocol, and then unpack it in the bootloader, which is a bit troublesome, but some OEMs (Car OEM) have their own bootloader protocols for intellectual property protection. In this case, the bootloader developer must develop according to the requirements of the OEM;

f. Some regular large OEMs require their ECU suppliers to develop ECU bootloaders based on bus diagnostic protocols such as UDS. The corresponding CAN ID is specified in UDS for the bootloader to use. Therefore, the corresponding UDS protocol stack must be added to the bootloader project in this type of ECU.

3. Parsing programming files (S19/HEX/BIN)

The programming file formats generated by different MCU software development IDE compilation and linking may be different, but S19, HEX and BIN files can be converted to each other, so you only need to open a programming file parsing program in the bootloader, and the others can be converted on the host computer using the corresponding conversion tool;

Parsing the programming file is aimed at obtaining the program code and data of the application and its storage address in the NVM;

In order to parse programming files, you must first understand the encoding format and principle. For the format description of commonly used S19, HEX and BIN files, please refer to the following Wikipedia link:

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

Tips:

Both S19 and HEX files can be opened directly with a text editor (such as Notepad, Notepad++). You only need to merge the S19 file lines starting with S1, S2, and S3 that contain the address and data code. You can copy them manually or write a window batch script to process them. Of course, there are also special ones that can support the merging of two S19 files. You can find a lot of open source software on the Internet, such as the common Srecord.

MCU software development IDE generally integrates conversion tools between different programming files: such as S32DS's objcopy (Create Flash Image)

and Keil's Motorola S-Record to BINARY File Converter http://www.keil.com/download/docs/10.asp

4. NVM driver development

The NVM of ECU generally includes the EEPROM or Data-Flash integrated in the MCU chip for storing data, the Code-Flash/Program-Flash for storing program code/data, and the off-chip NOR Flash or NAND-Flash extended by the MPU; the NVM driver includes basic operations such as erasing (erase), programming (program) and verifying (verify) the NVM, as well as encryption (secure)/decryption (unsecure) and protection (protection)/unprotection (unprotection) operations on the NVM.

Tips:

a. In the NVM integrated on the MCU chip, EEPROM/D-Flash and C_Flash/P-Flash generally belong to different blocks, so the NVM driver can be directly run on the Flash to erase and program the EEPROM/D-Flash;

b. NVM driving is generally completed by running an NVM command sequence, in which different NVM operation command codes, NVM programming data and target addresses are given through the NVM controller register. The typical NVM command sequence is as follows (Freescale's S12 (X) series MCU Flash write command sequence):

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

d. The NVM driver cannot be run on the same block in the MCU chip to perform erase and programming operations on itself, otherwise a read while write bus access conflict will occur (each NVM block has only one data bus, and can only read or write at a time, and does not support simultaneous reading and writing). Therefore, for an MCU with only one block Flash, its NVM driver must be called in RAM to perform erase and programming operations on itself. At the same time, the CPU global interrupt must be turned off and peripheral interrupt responses must be prohibited during the period from launching the Flash command to waiting for the command to complete, otherwise both the interrupt vector and the interrupt ISR will access the Flash. To enable interrupts, the interrupt vector table must be offset to the RAM or 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);