Background

In modern automotive electronic technology, software upgrades for ECUs (Electronic Control Units) are a critical task. Compression flashing technology has emerged to enhance the efficiency and security of data transmission. By compressing the data, bandwidth utilization can be effectively increased, reducing the data transmission volume between the flashing tool and the ECU, thereby significantly shortening the ECU upgrade time. Furthermore, to enhance data security and confidentiality, data transmission can also be encrypted. The ISO14229-1 standard defines that data can be transmitted in a compressed and encrypted manner through the Request Download Service (SID=0x34) and Request File Transfer Service (0x38). This article focuses on the data compression aspect, using the Request Download Service as an example.

1. Request Download Service (0x34) Request Message Format Defined in ISO14229-1:2020  

According to the ISO14229-1:2020 standard, the Request Download Service (0x34) allows data to be transmitted in a compressed and encrypted manner. In the request message format of this service, "dataFormatIdentifier" is a key parameter, occupying 1 byte, with the higher four bits (bit4-bit7) representing the "compressionMethod" parameter, which defines whether the data needs to be compressed. The lower four bits (bit0-bit3) represent the "encryptingMethod" parameter, defining whether the data needs to be encrypted. If the data to be downloaded neither needs compression nor encryption, this parameter value is 0x00; if a non-0x00 value is used, it indicates that the download data requires compression, encryption, or both. For example, if the "dataFormatIdentifier" value is 0x10, it indicates that the download data requires compression but not encryption. If the value is 0x11, it indicates that the download data requires both compression and encryption.

It is important to note that the compression and encryption requirements of the download data do not affect the "addressAndLengthFormatIdentifier" and "memoryAddress" parameters but do affect the "memorySize" parameter, which defines the size of the data to be flashed. This size will be compared with the size of the data transmitted through the TransferData (0x36) service.

When the data to be downloaded is compressed, the OEM defines whether the "memorySize" represents the size of the compressed data or the size of the data before compression. Different definitions lead to different implementation codes for the flashing process.

If the "memorySize" represents the size of the compressed data, then after the TransferData (0x36) service has completed the transmission of the compressed data, the ECU will determine whether the data download is complete based on the "memorySize" parameter. The ECU will compare the size of the transmitted compressed data with the data size defined by the "memorySize" parameter and send a positive or negative response accordingly.

If the "memorySize" represents the size of the uncompressed data, then the size of the compressed data transmitted by the TransferData (0x36) service is generally smaller than the value of "memorySize." In this case, the ECU will decompress the received compressed data and calculate the total size of all the decompressed data. After the compressed data transmission is complete, the ECU will compare the size of the decompressed data with the size defined by the "memorySize" parameter and send a positive or negative response accordingly.

Of course, whether the "memorySize" represents the size of the compressed data or the size of the uncompressed data, the method by which the ECU determines whether the downloaded data is correct after data transmission is completed may vary depending on the OEM's definition.

2. Comparison of Flashing Files Before and After Compression  

Software flashing involves burning or transferring a software program to a specific address segment of the ECU's memory, after which the ECU will run the software to achieve its unique functions. Common ECU flashing file formats include .hex, .s19, and .bin. Compressed flashing files are created using specific compression algorithms.

- Before Compression:

The flashing file is divided into three logical blocks, with the starting address, ending address, and length of each block as follows:

- Block 0: Start Address: 0x80138020, End Address: 0x801FFFDF, Length: 0xC7FC0

- Block 1: Start Address: 0x80300020, End Address: 0x804FFFDF, Length: 0x1FFFC0

- Block 2: Start Address: 0xA0078020, End Address: 0xA0137FFF, Length: 0xBFFE0

- After Compression:

After compression, the flashing file is still divided into three logical blocks, with the starting address, ending address, and length of each block as follows:

- Block 0: Start Address: 0x80138020, End Address: 0x8015E60E, Length: 0x265EF

- Block 1: Start Address: 0x80300020, End Address: 0x80448DD7, Length: 0x148DB8

- Block 2: Start Address: 0xA0078020, End Address: 0xA00AD0F6, Length: 0x350D7

It can be observed that the number of logical blocks in the flashing file has not changed before and after compression, the starting addresses have not changed, but the data length of each logical block has decreased, leading to changes in the corresponding ending addresses.

- Independent Compression of Each Logical Block:

  For flashing files that are divided into multiple logical blocks before compression, if the number of logical blocks remains unchanged after compression, this method can be referred to as "independent compression of each logical block." In contrast, there is also an "overall compression" method.

- Overall Compression:

  - Before Compression:

The flashing file is divided into three logical blocks, with the starting address, ending address, and length of each block as follows:

- Block 0: Start Address: 0x8FC0060, End Address: 0x9194FFF, Length: 0x1D4FA0

- Block 1: Start Address: 0x91C0000, End Address: 0x91D9EBF, Length: 0x19EC0

- Block 2: Start Address: 0x9200000, End Address: 0x9237FFF, Length: 0x38000

  - After Compression:

After compression, the flashing file has only one logical block and no starting address.

For the "overall compression method," the starting address and other information in the flashing process's memory erase (EraseMemory) service and 0x34 (RequestDownload) service are defined by the ECU supplier or OEM.

Compression Flashing Log Analysis  

- Non-Compressed Flashing Log:

- Compressed Flashing Log:

By analyzing the flashing logs, we can observe the main differences between compressed flashing and non-compressed flashing:

1) The "dataFormatIdentifier" parameter in the Request Download Service (SID=0x34) command differs.

- Non-Compressed: The flashing tool sends: 34 00 44 A0 07 80 00 00 10 00 01

- Compressed: The flashing tool sends: 34 10 44 A0 07 80 00 00 03 50 F7

  - Where 10 indicates: using compressed data; 00 indicates: using non-compressed data.

2) The "memorySize" parameter in the Request Download Service (SID=0x34) command differs.

- Non-Compressed Flashing: The flashing tool sends: 34 00 44 A0 07 80 00 00 10 00 01

- Compressed Flashing: The flashing tool sends: 34 10 44 A0 07 80 00 00 03 50 F7

In non-compressed flashing, the "memorySize" value in the Request Download Service (SID=0x34) is greater than the "memorySize" value in compressed flashing. If the maximum block length value is the same, the number of subsequent data transfer services (SID=0x36) is smaller in compressed flashing than in non-compressed flashing. For example, in the logs, the maximum block length values for compressed and non-compressed flashing are both 0xFFF, which can be calculated as follows:

- The number of subsequent data transfer services (SID=0x36) for non-compressed flashing is 257;

- The number of subsequent data transfer services (SID=0x36) for compressed flashing is 54.

The fewer the number of data transfer services (SID=0x36), the less time required for data transfer, which is the main reason why compressed flashing can improve flashing efficiency.

Summary  

As ECU software functions become increasingly complex, improving the efficiency of ECU software upgrades becomes more critical. Bootloader, as an essential functional software, plays a key role in achieving efficient ECU software updates. Polelink has successfully implemented a compression flashing testing solution and looks forward to engaging in exchanges and collaborations with interested parties.