With the continuous advancement of semiconductor technology (according to Moore's Law), there are more and more logic function peripherals integrated in the MCU, and the memory is getting larger and larger. Consumers are increasingly demanding automotive energy efficiency (economic and regulatory requirements for emissions), comfort, connectivity, safety (functional safety and information security), especially in recent years, new energy electric vehicles, car networking and The rise of autonomous driving technology has accelerated the development of automotive electronics technology. The integration of automotive electronic ECUs (Electronic Control Units) is becoming more and more complex. In order to cope with software remote (online) function upgrades (adding new features) and bug fixes, the need for bootLoader (boot loader) is increasing. The more you come. This article details the general working principle and development points of the automotive electronic ECU bootloader, which is applicable to all automotive electronic ECU bootloader development.
First, the function of the bootloader
BootLoader, as its name implies, is a program load code that resides in the ECU's non-volatile memory. The bootloader is run after each ECU reset. It checks if there is a remote program load request from the communication bus, and if so, enters the bootloader mode, establishes a bus communication with the program download (usually the PC host) and receives the application downloaded by the communication bus, parsing its address and The data code, running the NVM (None Valitale Momory--non-volatile memory) driver, programming it into the NVM, and verifying its integrity to complete the application update. If there is no remote program load request from the communication bus, jump directly to the application reset entry function (reset interrupt ISR, also known as Entry_Point()--use Processor Expert's CodeWarrior project or Startup() function--general CodeWarrior project ), run the app.
Based on this, the three main concepts of the car ECU bootloader are as follows:
Establish reliable bus communication with the remote program downloader to obtain an application to be updated;
Parsing the application programming file (S19/HEX/BIN) to obtain its address and program code and data in the NVM;
Run the NVM driver to program the application's code and data into the NVM and verify it;
Second, how to establish reliable bus communication?
The common data buses of automotive ECUs are CAN and LIN, so usually the car ECU's bootloader downloads data via 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, upgrade the MCU program through the main MCU) and Ethernet (based on Enternet communication) Or the ECU of the full LCD instrument and the next-generation high-speed gateway and ADAS ECU).
TIps:
a, different ECU communication bus is different, the specific need to use a certain communication bus depends on the actual application;
b, the communication bus has the MCU peripheral implementation of the ECU, so in the bootloader must develop the corresponding communication bus peripheral driver to achieve basic data transmission and reception functions;
c. In order to ensure the reliability of communication, it is necessary to develop a communication protocol based on the communication bus. The request command (request command), acknowledgement (acknowledge), wait (block wait), and error are required between the application download terminal and the bootloader. Mechanisms such as error re-send----the bootloader completes different tasks according to different request commands and confirms whether the operation is completed (ACK) and whether the data is being completely transmitted. If a data error occurs (passing the checksum) Or ECC implementation), automatic retransmission is required;
d, the application download side through the need to develop GUI software on the PC based on VC or C#, QT, Labview, etc., to achieve the bus communication protocol required in c, generally in the bottom layer is by calling the corresponding bus device, such as USB to CAN /LIN's transponder device's dynamic library (DLL) API interface to achieve data transmission and reception, the corresponding bus USB forwarding device will provide the corresponding driver library (DLL). Therefore, bootloader developers generally need to have certain PC PC software development capabilities;
e. In order to achieve reliable data transmission, the source code is generally added in the bus communication protocol, that is, the check is performed on the valid data or the ECC calculation, and the result is sent together with the valid data in the communication data frame, and the bootloader receives At the end, after receiving the data frame, the same checksum or ECC calculation is performed on the valid data field, and the result is compared with the received checksum or ECC calculation result value to judge the integrity of the data. The application programming file (S19/HEX/BIN) has a corresponding checksum mechanism, so you can directly transfer the program programming file line; otherwise, the user needs to first parse the programming file in the PC software, and then the The address and data and code package are packaged into a customized communication protocol, which has to be unpacked in the bootloader. This is a little troublesome, but some OEMs have their own protection for intellectual property protection. Bootloader protocol, in this case, the bootloader developer must be developed according to the requirements of the host factory;
f. Some regular large-scale OEMs require their ECU suppliers to develop ECU bootloaders based on bus diagnostic protocols such as UDS. In the UDS, the corresponding CAN ID is specified for the bootloader. For a long time, the bootloader project must be used in this type of ECU. Add the corresponding UDS protocol stack;
Third, the analysis of the programming file (S19/HEX/BIN)
Different MCU software development IDE compilation links may generate different programming file formats, 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. You can use the corresponding convert tool to convert on the host computer;
The purpose of parsing the programming file is to obtain the program code and data of the application and its storage address in the NVM;
In order to parse the programming file, you must first understand the encoding format and principle. For the format description of the 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 using a text editor (such as Notepad, Notepad++). You only need to merge the S19 file lines starting with S1, S2 and S3 containing the address and data code. You can copy them manually. You can write a window batch script to handle; of course, there are also special support for the merger of two S19 files, online can find a lot of open source software, such as the common Srecord;
MCU software development IDE generally integrates conversion tools between different programming files: such as S32DS objcopy (Create Flash Image)
And Keil's Motorola S-Record to BINARY File Converter
Fourth, NVM driver development
The NVM of the ECU generally includes an EEPROM or Data-Flash integrated in the MCU for storing data and a Code-Flash/Program-Flash for storing program code/data and an off-chip NOR Flash or NAND-Flash for MPU expansion; The NVM driver includes basic operations such as erasing, programming, and verifying of the NVM, as well as encryption/unsecure and protection (protecTIon)/deprotection of the NVM. (unprotecTIon) operation.
Tips:
a, MCU integrated on the NVM EEPROM / D-Flash and C_Flash / P-Flash generally belong to different blocks, so you can run the NVM driver directly on the Flash to erase and program the EEPROM / D-Flash;
b. NVM drivers are generally run by running an NVM command sequence in which different NVM operation command codes, NVM programming data, and destination addresses are given by the NVM controller registers. The typical NVM command sequence is as follows (Freescale S12) (X) series MCU Flash write command sequence):
c. Since the working speed of the NVM is generally lower than the CPU core frequency and the bus frequency, the NVM must be initialized before running the NVM driver, and the operating frequency of the frequency divider is set to the frequency range required for normal operation;
d, NVM on the MCU chip can not run the NVM driver on the same block to erase and program itself, otherwise it will send out the bus access conflict of read while write (each NVM block has only one data bus, one time only Can read or write, does not support simultaneous reading and writing). Therefore, for an MCU with only one block Flash, it must call its NVM driver in RAM to erase and program itself, and must shut down the CPU global interrupt during the execution of the launch Flash command to wait for the command completion. The peripheral interrupt responds, otherwise the interrupt vector and the run interrupt ISR will access Flash. To enable interrupts, the interrupt vector table must be shifted to RAM or NVM block (EEPROM/D-Flash) and the response interrupt ISR is also copied to other RAM or NVM blocks (of course the interrupt vector table must also be updated) New interrupt ISR);
e. Due to the requirements of b above, it is usually necessary to copy the bootloader's NVM driver to the MCU's RAM. It can copy the completed NVM to RAM, or just copy the NVM command to wait for the command to complete. The instruction can be executed in RAM, because other operations in the NVM driver (such as filling in NVM operation commands, writing programming addresses and data, etc.) do not write data to the NVM on the occupied data bus;
f, NVM driver resides in Flash, if there is a stack overflow, etc. Unexpected program runaway Unexpectedly running NVM driver will cause NVM content to be accidentally erased or modified. Therefore, it is necessary to protect key data or code (such as the bootloader itself) to prevent accidental modification, or a safer method is not to store the NVM driver in the NVM, but at the beginning of the bootloader to download it to the RAM through the host computer. In the middle run, the area RAM is cleared after the bootloader ends, thus avoiding NVM data loss and modification caused by accidental running of the NVM driver. (PS: I will write an article to introduce related methods, please pay attention to reading)
g, the general MCU manufacturers will give their MCU NVM driver library, users can use this class library to achieve NVM operation, if it is Freescale / NXP car-level MCU, you can also use the CodeWarrior IDE integrated Processor Expert to generate the corresponding NVM driver ;
Five other points of bootloader development
a, the relationship between the bootloader and the application
The bootloader and application are two complete MCU software projects, each with its own startup code, main() function, link file, peripheral driver, and interrupt vector table;
Therefore, in the link file of the bootloader and the application, the address space allocation of the NVM must be separated and independent, and cannot be overlapped, but the RAM allocation is not constrained, and both can use the entire RAM space because after jumping to the application project,
[1] [2]
Fiber Optic Cabinet,Fiber Cabinet,Fiber Distribution Cabinet,Outdoor Fiber Cabinet
Cixi Dani Plastic Products Co.,Ltd , https://www.dani-fiber-optic.com