With the continuous advancement of semiconductor technology (according to Moore's Law), more and more logic function peripherals are integrated inside the MCU, and the memory is also getting larger and larger. Consumers have higher and higher requirements for vehicle energy saving (economic and regulatory requirements for emissions), comfort, connectivity, and safety (functional safety and information security), especially in recent years, new energy electric vehicles, Internet of Vehicles and The rise of autonomous driving technology has greatly accelerated the development of automotive electronics technology. The integrated functions of automotive electronic ECUs (Electronic Control Units) are becoming more and more complex. In order to cope with the needs of software remote (online) function upgrades (adding new functions) and bug fixes, the demand for bootLoader (boot loader) is increasing. more and more. This paper introduces the general working principle and development points of the automotive electronic ECU bootloader in detail , which is applicable to the development of all automotive electronic ECU bootloaders.
1. The function of bootloader
BootLoader, as the name implies, is a program loading code that resides in the non-volatile memory of the ECU. Each time the ECU is reset, the bootloader will run. It will check whether there is a remote program loading request from the communication bus, and if so, enter the bootloader mode, establish bus communication with the program downloader (usually a PC host computer) and receive the application program downloaded by the communication bus, parse its address and Data code, run NVM (None Valitale Momory--Non-Volatile Memory) driver, program it into NVM, and verify its integrity to complete the application update. If there is no remote program loading request from the communication bus, jump directly to the application reset entry function (reset interrupt ISR, also known as 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 bootloader of the automotive ECU are as follows:
Establish reliable bus communication with the remote program downloader 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 code and data of the application into the NVM and verify it;
Second, how to establish reliable bus communication?
Common data buses of automotive ECUs include CAN and LIN, so usually the bootloader of automotive ECUs 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 functional safety monitoring MCU is upgraded through the main MCU) and Ethernet (central control based on Enternet communication) Or ECUs with full LCD instrumentation and next-generation high-speed gateways and ADAS ECUs).
TIps：
a. Different ECU communication buses are different, and the specific need to use a certain communication bus 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 realize the basic data sending and receiving functions;
c. In order to ensure the reliability of communication, a complete communication protocol based on the communication bus must be developed. The application download end and the bootloader need to establish a request command (request command), confirmation (acknowledge), wait (block wait), and error reset. Mechanisms such as error re-send—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. or ECC implementation), automatic retransmission is required;
d. The application download terminal needs to develop GUI software based on VC or C#, QT, Labview, etc. on the PC to realize the bus communication protocol required in c, generally by calling the corresponding bus device at the bottom layer, such as USB to CAN The API interface of the dynamic library (DLL) of the repeater device of /LIN is used to realize the sending and receiving of data, and the corresponding bus USB repeater device will provide the corresponding driver library (DLL). Therefore, bootloader developers generally need to have certain PC software development capabilities;
e. In order to realize the reliable transmission of data, the source code is generally added to the bus communication protocol, that is, the checksum or ECC calculation is performed on the valid data during transmission, and the result is sent together with the valid data in the communication data frame, and the bootloader receives it. After receiving the data frame, perform the same checksum or ECC calculation on the valid data field at the sending end, and compare the result with the received checksum or ECC calculation result value to judge the integrity of the data. The application programming files (S19/HEX/BIN) all have the corresponding checksum mechanism, so the method of directly transmitting the program programming file lines can be adopted; The address, data and code are packaged into a customized communication protocol, which has to be unpacked in the bootloader, which is a little troublesome, but some OEMs (Car OEM) have their own for intellectual property protection. bootloader protocol, in this case, the bootloader developer must develop according to the requirements of the OEM;
f. Some regular major OEMs require their ECU suppliers to develop and put ECU bootloaders on the basis of UDS and other bus diagnostic protocols. The corresponding CAN IDs are specified in UDS for use by bootloaders, so the bootloader projects in such ECUs must be used for a long time. Add the corresponding UDS protocol stack to it;
3. Parse programming files (S19/HEX/BIN)
Different MCU software development IDEs 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. can use the corresponding conversion tool (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 with a text editor (such as Notepad, notepad++), just merge the S19 file lines starting with S1, S2 and S3 that contain address and data codes, you can manually copy, or You can write a window batch script to process it; 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, etc.;
The software development IDE of MCU generally integrates conversion tools between different programming files: such as objcopy (Create Flash Image) of S32DS
and Keil's Motorola S-Record to BINARY File Converter http://www.keil.com/download/docs/10.asp
Fourth, NVM driver development
The NVM of the ECU generally includes the EEPROM or Data-Flash integrated in its 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 erase, program, and verify for NVM, as well as encryption (secure)/decryption (unsecure) and protection (protection)/deprotection of NVM. (unprotection) operation.
Tips：
a. EEPROM/D-Flash and C_Flash/P-Flash in the NVM integrated on the MCU chip generally belong to different blocks, so you can directly run the NVM driver on the Flash to erase and program the EEPROM/D-Flash;
b. The NVM driver 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 registers. 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, the NVM must be initialized before running the NVM driver, and the operating frequency of the frequency divider should be set to the frequency range required for normal operation;
d. The NVM driver in the MCU chip cannot run the NVM driver to erase and program itself on the same block, otherwise there will be a bus access conflict of read while write (each NVM block has only one data bus, and only one data bus at a time. Can be read or written, does not support simultaneous read and write). Therefore, for a MCU with only one block Flash, its NVM driver must be called in RAM to erase and program itself. At the same time, the CPU global interrupt must be turned off during the period from launching the Flash command to waiting for the command to complete. Peripheral interrupt response, otherwise fetching interrupt vector and running interrupt ISR will access Flash. To enable interrupts, the interrupt vector table must be offset to RAM or NVM block (EEPROM/D-Flash) and the corresponding interrupt ISR must be copied to other RAM or NVM blocks (of course, the interrupt vector table must also be updated to guide new interrupt ISR);
e. Due to the requirements of the above b, it is usually necessary to copy the NVM driver of the bootloader to the RAM of the MCU to run. It can copy the completed NVM to the RAM to run, or just copy the NVM command launch to several lines waiting for the command to complete. The instructions 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. The NVM driver resides in the Flash. If the NVM driver is accidentally run, such as a stack overflow, the NVM content will be accidentally erased, lost 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 to not store the NVM driver in the NVM, but download it to RAM through the host computer at the beginning of the bootloader After the bootloader is finished, the RAM in this area is cleared, so as to avoid the loss and modification of NVM data caused by accidentally running the NVM driver. (PS: I will write an article to introduce related methods in the follow-up, please pay attention to reading)
g. Generally, MCU manufacturers will provide the NVM driver library of their MCU. Users can use this library to implement NVM operations. If it is an automotive-grade MCU of Freescale/NXP, you can also use the Processor Expert integrated in CodeWarrior IDE to generate the corresponding NVM driver. ;
Five, other points of bootloader development
a, the relationship between the bootloader and the application
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 to the NVM must be separate and independent, and cannot overlap (overlap), but its RAM allocation is not restricted, both can use the entire RAM space, because after jumping to the application project,
The startup code will reinitialize the RAM;
The bootloader must use the MCU's default interrupt vector table, because the MCU executes the address from the reset vector of its default interrupt vector table after each reset; the application's interrupt vector must be offset (through the corresponding interrupt vector offset register) , such as the IVBR register of the S12 (X) series MCU or the SCB->VTOR register of the ARM Cortex M series MCU); and the erasing of the NVM (P-Flash) is performed according to the sector, so in order to make full use of the NVM (P-Flash) Flash) space, partition the bootloader into several NVM (P-Flash) sectors containing the default interrupt vector table (the last several sectors of the NVM of the S12 (X) series MCU, and several sectors starting from the 0 address of the ARM Cortex M series MCU);
Tips：
If the application is powered off or reset unexpectedly during the new process, the application update fails, and the corresponding application integrity check fails. Of course, it must be downloaded again. In order to avoid application loss in this case, BootLoader often needs to update the application. Perform double backup, that is, use two different NVM partitions to save applications, and only after the new application is successfully updated, the old application will be erased, otherwise the old application will be run after the next reset
b. Jump method from bootloader to application
After the development and use of the bootloader, the bootloader will be run first after each ECU reset. If there is no remote application download request, it will directly jump to the application reset function address. There are two issues to consider:
How to obtain the application reset function address: The methods are: 1) Fix the application reset start function address through the link file; 2) Obtain from the reset vector address of the application interrupt vector table; Recommended method 2): Because of its good flexibility, After each application change, there is no need to care that the application reset function is compiled to the specific address of the NVM, just take out the reset vector in the application interrupt vector table and run it:
The typical method is as follows (assuming that the application program interrupt vector table base address register IVBR=0x7F of the S12 (X) series MCU):
typedef void （*near tIsrFunc）（void）;/* ISR prototype definition */
word *Ptr; /*pointer used for ISR vector fecth*/
Ptr = （word *）0x7FFE; /*get the ISR vector from the interrupt vector table of APP project */
（（tIsrFunc）（*Ptr））（）; /*covert and run*/
Jump timing: The methods are: 1) After the bootloader updates the application program and verifies its integrity is OK, restore the registers of the peripherals (such as CAN/LIN communication bus module, timer, GPIO, etc.) The default state, and then jump directly; after the bootloader updates the application and verifies its integrity is OK, wait for the watchdog timer to timeout and reset, and at the beginning of the bootloader judges that there is no remote application download request and jumps; the recommended method of use 2): Because method 1) is different from software reset, when it jumps to the application reset startup function, the hardware environment of the MCU may be different from running the application directly, while the watchdog reset of method 2) belongs to hardware reset. Resets most peripheral (analog, clock, and peripheral) circuits, closer to running the application directly.
c. Knowledge and debugging methods and skills needed to develop bootloader
First, the development of the bootloader needs to be very clear about the RAM and NVM resources of the MCU used by the ECU, and then partition it to ensure that the NVM allocation of the application and the bootloader does not overlap. Therefore, it is necessary to understand the use method and writing rules of the link file of the software development tool IDE used;
Then, it is necessary to judge whether the offset of the interrupt vector table is successful, the address and size of the NVM driver copy, so it is necessary to master the specific information of the map file in the compilation and link result of the software development tool IDE used;
In addition, it is also very useful to know how to redirect NVM functions (separate the storage address and runtime address of function program code) to RAM for execution;
Tips：
When developing an application, it needs to be debugged separately to ensure its normal function. At this time, although its peripheral interrupt vector table has been offset, its reset vector must be placed in the default interrupt vector table where the reset vector is located. If the reset vector of the application program is placed in the offset application program interrupt vector table, the default reset vector content is 0xFFFF (the state after the flash is erased) , the CPU core will fetch and run at the address of 0xFFFF, which is obviously not the real project startup function, so it cannot run. The result is the same as when a new MCU is powered on and runs without any program written, and illegal addresses will continue to appear. Reset; and after the application development is completed, offset it into the application interrupt vector to avoid conflict with the Flash address of the bootloader project;
Finally, it is also very practical to use the debugger's Hotsync or attach method to load the debugging information in the elf file to debug the bootloader and the application seamlessly, which can greatly improve the debugging efficiency of the bootloader;
d. Download method of bootloader and application program during mass production
It is recommended to combine the programming files generated by the bootloader and the application compilation link, and download the one-time mass production tool (such as Cyclone programmer) to improve production efficiency.