The integrated logic function peripherals in the MCU are becoming more and more popular with the advancement of semiconductor technology (according to Moore's Law), 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.
This article refers to the address: http://
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)
The programming file format generated by different MCU software development IDE compilation links may be different, but the S19, HEX and BIN files can be converted to each other, so it is only necessary to open a parsing program of the programming file 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)
Fourth, NVM driver development
The NVM of the ECU generally includes an EEPROM or Data-Flash integrated in the MCU for storing data, 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.
Liquid Crystal Display,Lcd Screen Displays,Calculator Lcd Display,Lcd Display For Car Bluetooth
Dongguan Yijia Optoelectronics Co., Ltd. , https://www.everbestlcdlcm.com