I haven't been on the front line of code development for a long time. Recently, I started a project independently. I feel that the technical engineer is possessed and has regained the enthusiasm for technology in the past.

In the era of software-defined cars, ECU software updates are very important. This requires the ECU to have the BootLoader function.

The auto BootLoader update is updated through the communication link, mainly including CAN, Lin, UART, Ethernet and other communication methods. Now the most used software upgrade is based on CAN communication.

Let's talk about the BootLoader upgrade and refresh scheme based on CAN bus.

To download a new program to the ECU through CAN communication, this process requires three components:

1. ECU controller (lower computer) that supports Bootloader function;

2. Burn the host computer (the host computer on the PC side);

3. CAN connector (CANoe or PCAN, Zhou Ligong CAN box, etc.);

The development work related to the software is mainly: the upper computer and the lower computer.

The main function of the host computer is to read the binary programming file tocertain organization, send this file to the lower computer through the CAN connector.

There are many tools for developing the host computer, and the languages ​​used are mainly high-level languages ​​such as C#/VB.

The host computer mentioned above records the files in a certain organizational manner. This refers to the refreshed protocol. NowThe mainstream is the UDS diagnostic protocol, which is ISO14229 (with the transport layer protocol ISO15765). Some manufacturers also use a calibration-based refresh process, such as the CCP protocol. There are also some manufacturer-defined refresh protocols.

So what are the main tasks to be done in the development of the upper computer?

Mainly include: host computer interface production, binary file (bin, hex, s19, mot, etc. formats) parsing, CAN card (CANoe, pcan or Zhou Ligong CAN or other) driver call, UDS flashing process implementation, etc.

Well, after talking for a long time, it seems to be a bit off topic. Isn't it about BootLoader? Let's start talking about the next machine.

BootLoader actually has two meanings,start upandload. The BootLoader software project is independent of the APP application project and is a project developed separately.

The main function of BootLoader is very simple, just to update the program, but it looks various, and there are many configurable options. The following mainly lists several common configuration items:

1. Whether the host computer supports CAN cards from multiple manufacturers;

2. Whether the host computer supports burning files in multiple formats;

3. Whether the FlashDriver needs to be downloaded from the upper computer or the lower computer has its own FlashDriver;

4. Whether the host computer supports both the UDS protocol and the CCP protocol;

5. Whether the host computer supports the configurable UDS flashing process;

6. Whether the software update is an overall update or a partial update;

7. Whether the lower computer has the function of file backup and software rollback;

8. Whether the lower computer BootLoader has the self-update function (level 2 BootLoader);

In short, there are too many changes in BootLoader, and it is a lot of work to complete a completely general BootLoader solution. Maybe that's why Vector's FBL tools are so expensive.

The development content of BootLoader lower computer mainly includes: FLASH/RAM/EEPROM address allocation, Flash driver development, EEPROM driver development (may require SPI or serial communication, etc.), CAN driver development, UDS protocol stack development, jump function development, etc.

I'll just write here today. I'm taking a break from my busy schedule. The boss called me to put out the fire.

The author's level is limited, and there are deficiencies or errors. I hope colleagues and experts can supplement and criticize.

Welcome to communicate