Application software validity verification method based on dual verification and self-verification in Bootloader

Abstract

The invention provides an application software validity verification method based on double verification and self-verification in Bootloader, and belongs to the technical field of automobile controllers. The method comprises the following steps: when Bootloader software is initialized, trying to read an effective flag bit of the application software from a nonvolatile memory, if the effective flag bit fails to read, executing self-checking, and writing the effective flag bit after the self-checking succeeds. In the Bootloader flashing process, double verification is needed when integrity verification is executed, one is to verify a verification code sent by an upper computer, the other is to verify again according to specified address content of a controller chip, and effective bits can be written after the double verification succeeds. The verification information required by the self-verification and the dual-verification is automatically generated by a script compiled by the application software. According to the method and the device, the flashing safety of the Bootloader software is improved, a secondary flashing step is avoided, and the production efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile controllers, and in particular to a method for verifying the validity of application software based on double verification and self-verification in a Bootloader. Background Art

[0002] The bootloader software in the automotive controller is a core component for maintaining and upgrading application software. Its main functions are to bootload application software and download and update application software through a bootloader flashing process based on the UDS diagnostic service, ultimately achieving application software upgrades and maintenance for the automotive controller.

[0003] Existing automotive controller bootloader software has the following problems: 1. Security limitations of the bootloader flashing process: In the existing bootloader flashing process, the validity of the downloaded application software is generally verified through integrity and compatibility check routines. However, the integrity check code calculated by the host computer based on the contents of the flashing file can only detect errors that occur during data transmission. If the host computer parses the contents of the flashing file incorrectly, the data downloaded in the bootloader process is not the data of the original flashing file, and the integrity check code calculated by the host computer cannot detect application software integrity errors. In this case, the bootloader software will mistakenly determine that the application software is valid. After executing the jump to the application software, the controller will freeze.

[0004] 2. Production efficiency issues on the controller production line: Existing bootloader software only writes the application software validity flag to non-volatile memory after a complete bootloader flash process, allowing the application software to be jumped to. This requires that after the bootloader software is burned into the controller chip via the Jtag port, the production line must also flash the application software to the controller chip through the bootloader process. A single bootloader flash process takes one to three minutes, seriously affecting the production efficiency of the controller production line.

[0005] In summary, there is still room for optimization in the existing Bootloader software in terms of Bootloader software flashing process, controller production efficiency, and software development efficiency. Summary of the Invention

[0006] The present invention aims to provide a method for verifying the validity of application software in a bootloader based on dual verification and self-verification. This method improves the security of bootloader software flashing and allows the production line to flash both the bootloader and application software into the controller chip at once, eliminating the need for a secondary flashing step and improving production efficiency. Furthermore, the method uses a compiled script to automatically generate flashable files in a specified format, improving version traceability and software development efficiency.

[0007] To achieve the above objectives, the present invention provides a method for verifying the validity of application software in a bootloader based on double verification and self-verification, including a self-verification mechanism during bootloader initialization, a double verification mechanism during the bootloader flashing process, verification information of the application software occupying the fixed address space of the controller chip Code Flash, and a script for generating verification information and flashable files after the application software is compiled.

[0008] The bootloader software, application software, and verification information of the application software are stored in the CodeFlash of the controller chip. The validity flag of the application software is stored in the internal or external non-volatile memory of the controller chip. A specified value indicates that the application software is valid. This value is defined as FLAG_APP_VALID in the bootloader software code. Another specified value indicates that the application software is invalid. This value is defined as FLAG_APP_INVALID in the code. When the Bootloader software is running, it is allowed to jump from the Bootloader software to the application software only after the application software validity flag value read from the non-volatile memory is equal to FLAG_APP_VALID; The bootloader software can only verify the integrity and compatibility of the application software through self-verification or double verification. When the integrity and compatibility of the application software are confirmed to be valid, the bootloader writes the validity flag of the application software to the non-volatile memory, and the written validity flag value is equal to FLAG_APP_VALID.

[0009] Preferably, the specific technical solution of the Bootloader's verification method for application software integrity and compatibility is as follows: In the Code Flash address space of the controller chip, a fixed address area is allocated to store verification information for the validity and compatibility of the controller application software, including the application software start address, application software end address, application software length, application software compatibility check code, and application software integrity check code. This verification information is calculated based on the contents of the flashable file generated by the compilation of the application software after the application software is compiled. After the calculation is completed, the verification information will be filled into the specified address of the application software flashable file. When burning the software on the controller production line, or when executing the Bootloader process to flash the application software, this verification information should be downloaded as part of the application software flashable file to the specified address of the Code Flash of the controller chip. The address space of the verification information must not overlap with the address space of the application software code data.

[0010] Preferably, the integrity check code of the application software is an integrity check code calculated based on the data in the compiled and generated flashable file. The specific check algorithm should be determined by the software developer based on its own needs and customer needs. CRC32 check code or MD5 hash algorithm can be selected.

[0011] Preferably, the application software's compatibility check code is a software compatibility identifier stored at a specified address on the controller chip's CodeFlash, as specified by the software developer. The specific value of the compatibility check code should be specified by the software developer and may include software project information, such as product name, project name, part number, and supplier code.

[0012] Preferably, when the specified conditions are met, the Bootloader software can use the application software verification information to perform double verification or self-verification, thereby verifying the integrity and compatibility of the current application software in the controller Code Flash. After successfully verifying the integrity and compatibility of the application software, the Bootloader software should write the validity flag of the application software to the non-volatile memory of the controller. Regarding the application software validity flag, a specified character should be used to indicate that the application software is valid, and the macro definition of this value in the Bootloader software code is FLAG_APP_VALID; another specified character should be used to indicate that the application software is invalid, and the macro definition of this value in the Bootloader software code is FLAG_APP_INVALID. The specific definition of its value can be determined by the software developer.

[0013] Preferably, when the controller's non-volatile memory does not store the application software valid flag, or when the non-volatile memory stores the application software flag but the flag value is not equal to FLAG_APP_VALID, the bootloader software will perform a self-check during initialization. The self-check mechanism of the bootloader software includes the following steps: S1. Read the application software validity flag: During the initialization phase, the bootloader software attempts to read the application software validity flag from the controller's non-volatile memory. If the validity flag is not successfully read from the non-volatile memory, the process proceeds to step S2. If the validity flag is successfully read from the non-volatile memory, but its value is not equal to FLAG_APP_VALID, the process proceeds to step S2. If the validity flag is successfully read from the non-volatile memory and its value is equal to FLAG_APP_VALID, the process proceeds to step S8.

[0014] S2. Obtain application software verification information: The bootloader software obtains the verification information of the application software from the specified address, including the starting address, ending address, length, integrity check code, and compatibility check code of the application software. Then, step S3 is executed.

[0015] S3. Perform compatibility check: Compare the compatibility check code value of the application software to see if it is equal to the specified compatibility identifier. If the compatibility check code value is equal to the specified compatibility identifier, execute step S4; otherwise, execute step S10.

[0016] S4. Compare application software length information: Add the length to the application software start address in the application software verification information and subtract 1, and compare whether the calculated result is equal to the application software end address. If the calculated result is equal to the end address, execute step S5; otherwise, execute step S10.

[0017] S5. Perform integrity check: Based on the data between the start address and the end address in the controller chip's Code Flash address space, a checksum is calculated using a specified checksum algorithm. This checksum is then compared with the integrity checksum in the application software's verification information. If the two are identical, step S6 is executed; otherwise, step S10 is executed.

[0018] S6. Write the application software validity flag: The application software validity flag is written into the non-volatile memory of the controller, and the written value is equal to FLAG_APP_VALID. Then, step S7 is executed.

[0019] S7. Check whether there is a Bootloader flash request: The controller chip reads the flag bit at the specified address in the RAM memory area. Based on this flag bit, it is determined whether the bootloader initialization was caused by the application software jumping to the programming session via the UDS service. If the bootloader was jumped to from the application software, it is considered that a bootloader flash request has been received. If no bootloader flash request has been received, step S8 is executed; otherwise, step S11 is executed.

[0020] S8, stay in the Bootloader software for 20 milliseconds: The bootloader software continues to run for 20 milliseconds and checks whether it has received the UDS diagnostic service during this 20 milliseconds. If a UDS diagnostic extended session request is received, it is considered to have received the bootloader flash request and the process proceeds to step S11. Otherwise, it is considered to have not received the bootloader flash request and after 20 milliseconds, the process proceeds to step S9.

[0021] S9. Jump from Bootloader to application software: The controller jumps from the Bootloader software to the starting address of the application software and starts running the application software.

[0022] S10. Continue running the Bootloader software: Jumping to this step indicates that there is no valid application software in the current controller. Therefore, the controller continues to run the bootloader software and waits for a bootloader flash request from the CAN bus. In this case, the controller continues to run the bootloader software until the operator starts the bootloader flash process from the host computer or until the operator disconnects the controller power.

[0023] S11. Start the Bootloader flashing process: The bootloader software continues to run, begins the bootloader flash process, and waits for the next UDS diagnostic service request. If the next UDS diagnostic service request is not received within the S3 timer, the bootloader software will reboot and then jump to step S1. The S3 timer here refers to the S3server timer specified in the UDS protocol.

[0024] Preferably, when the controller executes the bootloader flash process, the bootloader software will perform a double check in the integrity check routine of the bootloader process. The specific bootloader flash process should be determined by the software developer according to the needs. The double check described in the present invention is only applied to the integrity check routine of the bootloader process. The double check mechanism of the bootloader software includes the following steps: S1. Execute the pre-sequence operation of the integrity check routine in the Bootloader process: Using the UDS diagnostic service, the bootloader application software flashing process, before the integrity check routine, is executed. This includes, but is not limited to, downloading the FlashDriver, verifying the FlashDriver, erasing the application software, and downloading the application software. Before erasing the application software, the bootloader writes the application software validity flag to non-volatile memory with a value equal to FLAG_APP_INVALID. After the application software download is complete, step S2 is executed.

[0025] S2. Start integrity check routine: Start executing the integrity check routine in the Bootloader process, receive the UDS 31 service diagnostic request message sent from the host computer, and obtain the integrity check code in it according to the specified format.

[0026] S3. Perform the first level of integrity check: The bootloader calculates a first-level integrity check code based on the data downloaded in the previous operation, including the application software and application software verification information, using a specified verification algorithm. The bootloader then compares this first-level integrity check code with the integrity check code sent by the host computer. If the first-level integrity check code is equal to the integrity check code sent by the host computer, the process proceeds to step S4; otherwise, the process proceeds to step S10.

[0027] Taking the CRC32 cyclic redundancy check algorithm as an example, the calculation process of the first integrity check code is as follows: Assume that the downloaded data has a total of Bytes, this Byte data is connected end to end to form a bit binary number, this The first bit of the binary number Bit as variable of The coefficient of the power can be regarded as a binary number with the highest power being Binary polynomial of , which is of the following form, where for The first bit of a binary number Bit value: ; Use the specified generator polynomial , its hexadecimal representation is 0x04C11DB7: ; ; According to the following formula, perform modulo-2 division, ignoring carries and borrows during addition and subtraction, to calculate the CRC32 checksum: ; Perform modulo-2 division according to formula (3) and calculate the binary number corresponding to the remainder polynomial This is the first level of integrity check code.

[0028] Preferably, in the Bootloader software, the CRC32 check code is not calculated from scratch using the above method, but a CRC32 table pre-stored in the code is used to speed up the calculation of the integrity check code. The specific calculation process is as follows: When using the table lookup method, the calculation is not performed one by one, but every 8 bits. Bytes, each byte can be regarded as a binary polynomial with the highest power of 7. The polynomial of the byte is , which can be written as follows: ; At this time, the binary polynomial Can be divided into The sum of binary polynomials can be written as follows: ; At this point, formula (3) can be written as follows: ; Just follow formula (6) to calculate one by one from left to right. The remainder of each calculation is used in the next calculation. The final remainder is the CRC32 check code. , the detailed calculation process is as follows: Assume modulo 2 division The remainder polynomial of , split it into two polynomials and The sum of , then: ; ; ; make , according to formula (7), The remainder of the modulo-2 division is 0.

[0029] For the bytes, assuming modulo 2 division The remainder polynomial of , will remainder of byte calculation With the Polynomial calculated from bytes Add and divide the result into 2 polynomials and , then: ; ; ; make ,because The remainder is equal to 0. According to formula (10), the modulo 2 division can be derived The remainder is also equal to 0, then formula (6) can be written as: ; In formula (13), the front n The remainders of the terms are all 0, so It's modulo 2 division Therefore, we only need to calculate the remainder from Start calculating, each time calculating the modulo 2 division remainder , plus After getting a new and ,use and Participate in the next calculation, a total of times, the last calculated The corresponding binary number is the CRC32 check code .

[0030] In calculation When , only 8 bits of data are involved in the calculation each time, so the remainder obtained is at most Possibility, use an array of length 256 in the code to store all possible remainders in advance, each calculation When , the remainder of the calculation can be directly obtained by looking up the table, and then the next calculation can be performed. The first level of integrity check code can be obtained by looking up the table .

[0031] S4. Obtain application software verification information: The bootloader software obtains the verification information of the application software from the specified address, including the starting address, ending address, length, integrity check code, and compatibility check code of the application software. Then, step S5 is executed.

[0032] S5. Perform compatibility check: Compare the compatibility check code value of the application software to see if it is equal to the specified compatibility identifier. If the compatibility check code value is equal to the specified compatibility identifier, execute step S6; otherwise, execute step S10.

[0033] S6. Compare application software length information: Add the length to the application software start address in the application software verification information and subtract 1, and compare whether the calculated result is equal to the application software end address. If the calculated result is equal to the end address, execute step S7; otherwise, execute step S10.

[0034] S7. Perform the second level of integrity check: Based on the data between the start address and the end address in the controller chip's Code Flash address space, a checksum is calculated using a specified checksum algorithm. This checksum is then compared with the integrity checksum in the application software's verification information. If the two are identical, step S8 is executed; otherwise, step S10 is executed.

[0035] The specific algorithm of the second integrity check code should also be determined according to the needs of the software developer. It can use the same verification algorithm as the first integrity check, or a different verification algorithm from the first integrity check.

[0036] Preferably, the second integrity check algorithm uses a fixed algorithm as the internal algorithm of the controller supplier, and the first integrity check algorithm changes with customer needs, which can meet the security needs of different customers without reducing development efficiency.

[0037] S8. Write application software validity flag: The application software validity flag is written into the non-volatile memory of the controller, and the written value is equal to FLAG_APP_VALID. Then, step S9 is executed.

[0038] S9. End the integrity check routine and make a positive response: A positive response to the integrity check routine using the specified format indicates a successful integrity check and continues the bootloader flash process, waiting for the next UDS diagnostic service request. If the next UDS diagnostic service request is not received within the S3 timer, the bootloader software will reset. The S3 timer here refers to the S3server timer specified in the UDS protocol.

[0039] S10. End the integrity check routine and make a negative response: A negative response to the integrity check routine, or a positive response to the integrity check routine using the specified format as required, indicates that the integrity check has failed, aborts the bootloader flash process, and waits for the S3 timer to expire before the bootloader performs a reset.

[0040] Preferably, after the application software is compiled, a compilation script is used to automatically generate verification information and fill it into the flashable file, thereby generating a new flashable file. The format of the flashable file should be specified by the software developer according to their own needs, and can be selected in hex format, s19 format or bin format. Regarding the use of the compilation script to generate verification information and flashable files, the script should perform the following steps in order: S1. Calculate the start address, end address, and length information: Read the flashable file generated after compilation is completed. For easy distinction, this file is called a Raw file.

[0041] Preferably, a padding operation is performed on the Raw file, and the padding character is 0xFF.

[0042] Get the starting address and length information of the Raw file, and calculate the ending address of the Raw file based on it.

[0043] S2. Calculate the integrity check code of the application software: Based on the data between the start address and the end address of the Raw file, the integrity check code of the application software is calculated using the specified verification algorithm.

[0044] The specific algorithm for generating this checksum is determined by the software developer's needs, and may include CRC32 or the MD5 hash algorithm. The integrity checksum is calculated based only on the contents of the compiled, flashable file; the checksum itself is not used in the calculation of the integrity checksum.

[0045] Taking the CRC32 algorithm as an example, the calculation process of the integrity check code in the verification information is as follows: After the application software is compiled, a flashable file in hex format is generated. After the flashable file is filled with the character 0xFF, the CRC32 check code is calculated using the data of the flashable file, and the file data is written as a binary polynomial. , using the specified generator polynomial , which is represented in hexadecimal as 0x04C11DB7, and calculates the modulo 2 division , the binary number corresponding to the remainder polynomial is This is the integrity check code for the verification information, and the detailed calculation process is the same as the CRC32 check algorithm calculation process described above when explaining the first integrity check code.

[0046] S3. Obtain the compatibility check code of the application software: Obtain the compatibility check code of the application software based on the configuration information of the script.

[0047] The compatibility check code is a software compatibility identifier stored at a specific address on the controller chip's Code Flash, specified by the software developer. The specific value of this compatibility check code should be specified by the software developer and can include software project information such as the product name, project name, part number, and vendor code.

[0048] For example, the product name is "ONEBOX", the project name is "BCM5", and the vehicle model code is "AB01". The compatibility check code composed of these three pieces of information is "ONEBOX_BCM5_AB01", which is stored in the check information in the form of ASCII code and occupies 16 bytes of storage space. After the application software is downloaded, the Bootloader can judge the compatibility of the downloaded application software based on the product name, project name, and vehicle model code information in the compatibility check code.

[0049] S4. Fill in the verification information into the flashable file: Combine the application software start address, end address, length information, integrity check code and compatibility check code calculated by the script into a piece of verification information, and fill the verification information into the specified address space of the Raw file. The address space occupied by the verification information must not overlap with the address space of the original data of the Raw file. After filling, save it as a new flashable file, and fill the date and time of script execution and the automatically generated version number information in the file name. The new flashable file generated by the script is called a Customer file. If the generated Customer file is in bin format, the script should fill the specified bin file header information in the Customer file using the specified format according to the configuration information, such as: application software start address, length, part number, software version number.

[0050] S5. Merge the Customer file with the Bootloader's flashable file to generate a new flashable file: Based on the script's configuration information, the controller's bootloader software's flashable file is retrieved and its contents are inserted into the address space of the Customer file to generate a new flashable file. The file name is filled with the script execution date and time, as well as the automatically generated version number. This merged flashable file is called the ProductionLine file. In the ProductionLine file, the address space of the bootloader software, the address space of the application software, and the address space of the application software's verification information must not overlap.

[0051] The Customer file generated by the script contains the application software and its verification information. When executing the bootloader flash process, the Customer file should be used to flash the application software. During the integrity check routine in the bootloader process, the bootloader performs a double check using the integrity check code sent by the host computer and the verification information in the Customer file.

[0052] The script generates a "ProductionLine" file containing the bootloader software, application software, and verification information for the application software. The "ProductionLine" file should be flashed on the controller production line. This method allows both the bootloader and application software to be flashed to the controller chip simultaneously. After the controller is powered on, the bootloader software performs a self-verification based on the verification information from the application software and automatically jumps to the application software, eliminating the need for a second bootloader flash on the controller production line.

[0053] Therefore, the present invention adopts the above-mentioned application software validity verification method based on double verification and self-verification in a bootloader, and the beneficial technical effects are as follows: (1) Improve the security of the automotive controller bootloader flashing: Using a double check method can avoid the failure state of the controller crashing after flashing due to the error of the bootloader host computer in parsing the application software flashable file, which greatly improves the security of the bootloader software flashing.

[0054] (2) Improve the production efficiency of controllers: Using the self-checking method, when the Bootloader confirms that the integrity and compatibility of the application software are valid, the Bootloader will automatically write the valid flag of the application software and jump to the application software. This mechanism allows the controller production line to directly burn the Bootloader software and application software into the controller chip at one time, avoiding the secondary download process and improving the production efficiency of the controller.

[0055] (3) Improve software development efficiency: Use compiled scripts to automatically generate flashable files in a specified format, and automatically update the date, time, and version number information in the file name, thereby improving version traceability and software development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 This is a workflow diagram for using the Bootloader software; Figure 2 This is a workflow diagram for executing the self-check process using the Bootloader software; Figure 3 A workflow diagram for performing a double verification process using the Bootloader software; Figure 4 A flowchart for the script used to generate flashable files. DETAILED DESCRIPTION

[0057] The technical solution of the present invention is further described below with reference to the accompanying drawings and embodiments.

[0058] Unless otherwise defined, technical or scientific terms used in the present invention shall have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs.

[0059] Example 1 A fixed address space is allocated in the controller chip's Code Flash to store verification information for the application software. This address space does not overlap with the address space of the bootloader software or the application software.

[0060] In this embodiment, the Code Flash memory of the controller chip is divided into three parts, which are used to store the Bootloader software, the application software, and the verification information of the application software.

[0061] Table 1 Code Flash address space allocation table ;

[0062] The storage format of the application software verification information is also fixed.

[0063] Table 2 Application software verification information storage format ;

[0064] The bootloader software can read this verification information based on the specified address and parsing format to verify the validity and compatibility of the application software. In this embodiment, the integrity check code of the application software verification information uses the CRC32 checksum algorithm. The compatibility check code contains information such as the product name, project name, and vehicle model code. The correct value of the compatibility check code is "ONEBOX_BCM5_AB01".

[0065] When the Bootloader software uses the verification method provided by the present invention, its workflow is as follows: Figure 1 shown.

[0066] In this embodiment, the characters 0x55DD55DD are used to indicate that the application software is valid, and its macro definition is FLAG_APP_VALID; the characters 0x44EE44EE are used to indicate that the application software is invalid, and its macro definition is FLAG_APP_INVALID.

[0067] After the controller is initialized, it starts to execute the Bootloader software. In this embodiment, the non-volatile memory of the controller is an external EepRom chip. When the Bootloader software is initialized, it first reads the validity flag of the application software from the external EepRom chip. If the application software validity flag is successfully read from the external EepRom chip and its value is equal to 0x55DD55DD, the application software is considered valid. If the Bootloader flash request is not received in the next 20 milliseconds, the Bootloader software will execute a jump to the application software. Using this method, you can quickly jump to the application software when the application software is confirmed to be valid, without having to re-check the validity of the application software every time the controller is started, which speeds up the initialization speed of the controller.

[0068] When the Bootloader software reads the validity flag of the application software from the external EepRom chip, if the reading of the EepRom data fails, the application software is considered invalid. At this time, the Bootloader software will perform a self-check operation and use the check information in address 0x0040000-0x004001F to verify the validity of the application software.

[0069] When the Bootloader software reads the validity flag of the application software from the external EepRom chip, if the validity flag of the application software is successfully read from the external EepRom chip, but its value is not equal to 0x55DD55DD, the application software is also considered invalid. At this time, the Bootloader software will perform a self-check operation and use the check information in address 0x0040000-0x004001F to verify the validity of the application software.

[0070] The bootloader software determines whether to allow a jump to the application software based on the self-check result. If the self-check succeeds, the application software currently in the controller chip is valid, and the jump to the application software is allowed. If no new bootloader flash request is received within 20 milliseconds, the bootloader software executes the jump to the application software. If the self-check fails, the jump to the application software is not allowed, and the controller remains in the bootloader software, waiting for a flash request.

[0071] When the Bootloader software receives the flash request, it will start the Bootloader flash process. In this embodiment, the Bootloader will erase the current application software before starting to download the application software, and write the application software validity flag to the external EepRom, with the written value equal to 0x44EE44EE.

[0072] After the application software is downloaded, the Bootloader will perform a double check in the integrity check routine, and determine whether to allow the jump to the application software based on the result of the double check. If the double check is successful, the Bootloader will write the application software validity flag to the external EepRom, and the written value is equal to 0x55DD55DD. Then the Bootloader will perform a reset after the flash process is completed, and then follow the Figure 1 The process shown in the figure starts from the beginning; if the double check fails, the jump to the application software is not allowed. The Bootloader will abort the flash process according to the instructions of the host computer, perform a reset, and then follow the instructions of the host computer. Figure 1 The process shown is executed from the beginning.

[0073] When the Bootloader software performs self-checking according to the method provided by the present invention, the detailed execution process is as follows: Figure 2 shown.

[0074] When the bootloader performs self-check, it first reads the compatibility check code in the application software verification information from Code Flash addresses 0x0040010-0x004001F. If the compatibility check code value is equal to the ASCII code "ONEBOX_BCM5_AB01", the compatibility check is considered successful. Otherwise, the self-check is considered to have failed and the self-check is aborted.

[0075] Next, the start address, end address, and length information in the verification information are read from Code Flash addresses 0x0040000-0x004000B. The start address and length are added together and then subtracted by one. The calculated result is compared to see if it matches the end address. If the two match, the length information is considered correct; otherwise, the self-verification is determined to have failed and the self-verification is aborted.

[0076] Next, read the data from the start address to the end address in the controller chip Code Flash and use the CRC32 algorithm to calculate the integrity check code: write the data into a binary polynomial , using the specified generator polynomial , its hexadecimal representation is 0x04C11DB7, and the modulo-2 division is calculated using the table lookup method. , the binary number corresponding to the calculated remainder polynomial This is the integrity check code.

[0077] The calculated result is compared with the integrity check code stored at Code Flash address 0x004000C. If the two are equal, the integrity check is considered successful and the self-check is considered successful. If the two are not equal, the self-check is considered to have failed and the self-check is stopped.

[0078] After determining that the self-check is successful, the Bootloader will write the application software validity flag to the external EepRom with a value equal to 0x55DD55DD. If no new Bootloader flash request is received within the next 20 milliseconds, the Bootloader software will jump to the application software.

[0079] After determining that the self-check has failed, the controller is not allowed to jump to the application software. The controller will continue to run the Bootloader software until the flash process starts or until the controller is powered off.

[0080] When the Bootloader software performs double verification according to the method provided by the present invention, the detailed execution process is as follows: Figure 3shown.

[0081] In this embodiment, the CRC32 check algorithm is used when performing the first and second integrity checks. The integrity checks in the second and self-checks use the same integrity check code in the check information, which is the integrity check code stored at code flash address 0x004000C.

[0082] In this embodiment, when executing the flash process, the bootloader software writes the application software validity flag to the external EepRom before erasing the application software. The written value is equal to 0x44EE44EE. After the application software is downloaded, the host computer sends a UDS 31 service request to the bootloader to start the integrity check routine. The bootloader software performs a double check in the integrity check routine.

[0083] When the bootloader performs double verification, it first obtains the integrity check code of the first check from the UDS 31 service request message sent by the host computer. Then, based on the data downloaded in the flash process, the CRC32 check algorithm is used to calculate the first integrity check code: Write the downloaded data into a binary polynomial , using the specified generator polynomial , its hexadecimal representation is 0x04C11DB7, and the modulo-2 division is calculated using the table lookup method. , the binary number corresponding to the calculated remainder polynomial This is the first level of integrity check code.

[0084] In this embodiment, the downloaded data includes the application software and application software verification information. Therefore, both the application software and the application software verification information participate in the calculation of the first-level integrity check code. The calculated first-level integrity check code is compared with the integrity check code sent by the host computer. If the two are equal, the first-level verification is considered successful. If they are not equal, the double check is determined to have failed and the double check is aborted.

[0085] Next, the compatibility check code in the application software verification information is read from Code Flash address 0x0040010-0x004001F. If the value of the compatibility check code is equal to the ASCII code of "ONEBOX_BCM5_AB01", the compatibility check is considered successful; otherwise, the double check is determined to have failed and the double check is aborted.

[0086] Next, the start address, end address, and length information in the verification information are read from Code Flash addresses 0x0040000-0x004000B. The start address and length are added together and then subtracted by one. The result of the calculation is compared to see if it matches the end address. If the two match, the length information is considered correct; otherwise, the double verification is determined to have failed and the double verification is terminated.

[0087] Next, read the data from the start address to the end address in the controller chip Code Flash, and use the CRC32 algorithm to calculate the second integrity check code: write this data into a binary polynomial , using the specified generator polynomial , its hexadecimal representation is 0x04C11DB7, and the modulo-2 division is calculated using the table lookup method. , the binary number corresponding to the calculated remainder polynomial This is the second integrity check code.

[0088] In this embodiment, only the application software participates in the calculation of the second-level integrity check code; the application software verification information does not. The calculated second-level integrity check code is compared with the integrity check code stored at Code Flash address 0x004000C. If the two are equal, the second-level integrity check is considered successful, and the double check is considered successful. If the two are not equal, the double check is considered to have failed, and the double check is terminated.

[0089] After determining that the double check is successful, the Bootloader will write the application software validity flag to the external EepRom, and the written value is equal to 0x55DD55DD. Then the Bootloader responds positively to the UDS 31 service request of the host computer, indicating that the integrity check routine is executed successfully. After receiving the positive response, the host computer will continue to execute the flashing process, and perform a reset after the flashing process is completed, and then follow the Figure 1 The process shown is executed from the beginning.

[0090] After determining that the double check fails, Bootoader will respond negatively to the UDS 31 service request of the host computer, indicating that the integrity check routine execution failed. After receiving the negative response, the host computer will abort the flash process, wait for the S3 timer to time out, and then the Bootloader will perform a reset, and then follow Figure 1 The process shown is executed from the beginning.

[0091] In this embodiment, the script of the present invention is integrated into the compilation script, and the script will be automatically executed after the application software is compiled successfully. Figure 4 shown.

[0092] In this embodiment, after the application software is successfully compiled, a raw file in hex format will be generated. The script will first fill the raw file with the character 0xFF and calculate the starting address, ending address and length information after filling.

[0093] Next, the script will use the CRC32 checksum algorithm to calculate the integrity checksum based on the padded data: Write the data in the Raw file into a binary polynomial , using the specified generator polynomial , which is represented in hexadecimal as 0x04C11DB7, and calculates the modulo 2 division , the binary number corresponding to the remainder polynomial is This is the integrity check code. The integrity check code calculated by the script is compared with the integrity check code calculated by the bootloader when the bootloader performs the second check of the self-check and double check.

[0094] Next, the script will obtain the vehicle model code "AB01", product name "ONEBOX", and project name "BCM5" based on its own configuration information, and splice them into an ASCII code "ONEBOX_BCM5_AB01" as the compatibility check code for the application software.

[0095] The script then concatenates the application's starting address, ending address, length, integrity check code, and compatibility check code according to the specified format shown in Table 2. This information is then inserted into the Raw file's addresses 0x0040000-0x004001F as verification information. This creates a new Customer file and adds the current system date, time, and version number to the filename. The version number added this time is the version number from the last script execution plus one. In this embodiment, the Customer file is in hex format and named "ONEBOX_BCM5_Customer_AAA_BBB_CCC.hex," where "AAA" is the system date at the time of script execution, "BBB" is the version number, and "CCC" is the system time at the time of script execution.

[0096] Next, the script will obtain the flashable file of the Bootloader software based on its own configuration information. In this embodiment, the flashable file of the Bootloader software is in hex format. The script will fill the data in the Bootloader hex file into the address space 0x00000000-0x0003FFFF of the Customer file, generate a new ProductionLine file, and fill the current system date, time, and version number information into the file name of the ProductionLine file. The version number filled in this time is the version number when this script was last executed plus one. In this embodiment, the ProductionLine file is in hex format and the file name is "ONEBOX_BCM5_ProductLine_AAA_BBB_CCC.hex", where "AAA" is the system date when the script is executed, "BBB" is the version number, and "CCC" is the system time when the script is executed.

[0097] In this embodiment, when programming software on the controller production line, the flashable file ONEBOX_BCM5_ProductLine_AAA_BBB_CCC.hex is programmed into the controller chip via the Jtag port. This method allows both the bootloader software and application software to be programmed into the controller chip simultaneously. When the bootloader flash process is required, the flashable file ONEBOX_BCM5_Customer_AAA_BBB_CCC.hex is used for flashing on the bootloader host computer or diagnostic instrument.

[0098] It is worth noting that the contents not elaborated in detail in the present invention are all prior art and are well known to those skilled in the art.

[0099] Therefore, the present invention adopts the aforementioned dual-verification and self-verification method for application software validity verification in a bootloader, improving the security of bootloader software flashing. This method also allows the production line to flash the bootloader and application software into the controller chip at the same time, avoiding the secondary flashing step and improving production efficiency. Furthermore, the use of a compiled script to automatically generate flashable files in a specified format improves version traceability and software development efficiency.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the same. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solutions of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for verifying the validity of application software based on double verification and self-verification in a Bootloader, characterized in that: The bootloader software, application software and verification information of the application software are stored in the Code Flash of the controller chip; the validity flag of the application software is stored in the internal or external non-volatile memory of the controller chip; a specified value is used to indicate that the application software is valid, and the macro definition of this value in the bootloader software code is FLAG_APP_VALID; another specified value is used to indicate that the application software is invalid, and the macro definition of this value in the bootloader software code is FLAG_APP_INVALID; When the Bootloader software is running, when the application software validity flag value read from the non-volatile memory is equal to FLAG_APP_VALID, it is allowed to jump from the Bootloader software to the application software; The Bootloader software verifies the integrity and compatibility of the application software through self-verification or double verification. When it is confirmed that the integrity and compatibility of the application software are valid, the Bootloader writes the validity flag of the application software to the non-volatile memory, and the written validity flag value is equal to FLAG_APP_VALID.

2. According to claim 1, a method for verifying the validity of application software based on double verification and self-verification in a Bootloader, characterized in that: After the Bootloader software is initialized, the validity flag of the application software is first read from the non-volatile memory. When the validity flag of the application software is successfully read and the validity flag value is equal to FLAG_APP_VALID, the Bootloader software does not perform the self-checking step; When the Bootloader software fails to read the validity flag of the application software, or successfully reads the validity flag of the application software but its value is not equal to FLAG_APP_VALID, the Bootloader software performs a self-checking step to check the integrity and compatibility of the application software; The self-checking steps of the Bootloader software are as follows: By reading the content of the Code Flash specified address of the controller chip, the integrity and compatibility of the entire application software are verified according to the application software verification information of the address; the application software verification information includes: software start address, software end address, length, integrity check code and compatibility check code; In the Bootloader flashing process, the application software verification information is downloaded to the Code Flash together with the application software.

3. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 2, characterized in that: The Bootloader software double verification method includes the first verification and the second verification; In the Bootloader flash process, the Bootloader software writes the application software validity flag to the non-volatile memory before erasing the application software, and the written value is equal to FLAG_APP_INVALID; after the application software data is successfully downloaded to CodeFlash, the Bootloader software executes the integrity check routine. After confirming that the integrity check routine is successful, the Bootloader software writes the application software validity flag to the non-volatile memory, and the written value is equal to FLAG_APP_VALID; In the integrity check routine, the Bootloader software receives the integrity check code sent by the host computer, and then calculates the first integrity check code based on the data downloaded in the flash process, and compares it with the integrity check code sent by the host computer to verify the integrity of the downloaded data, which is the first level of verification; The first integrity check code is calculated based on the data downloaded in the Bootloader process, which includes the application software and the verification information of the application software; In the integrity check routine, the Bootloader software checks the integrity and compatibility of the application software again according to the check information of the Code Flash address specified by the controller chip, which is the second check. When both the first check and the second check are successful, the Bootloader software writes the value of the validity flag of the application software to the non-volatile memory as FLAG_APP_VALID.

4. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 3, characterized in that: A space is allocated at the specified address of the Code Flash of the controller chip, and the verification information of the integrity and compatibility of the application software is stored in a fixed format. The verification information should include the starting address, end address, length, integrity check code and compatibility check code of the application software. The storage format of these verification information in the Code Flash should be determined by the software developer. The length and storage format of the verification information jointly determine the size of the address space. The address space occupied by the verification information of the integrity and compatibility of the application software shall not overlap with the Bootloader software or the application software; the verification information of the integrity and compatibility of the application software is regarded as a part of the application software data, and is downloaded to the Code Flash of the controller chip together with the application software during production or when the Bootloader is flashed; the verification information of the integrity and compatibility of the application software is used to describe the verification information of the application software data that needs to be downloaded in the Bootloader flashing process, including the application software starting address, application software ending address, application software length, application software data integrity check code, and application software compatibility identifier; the verification information of the integrity and compatibility of the application software is a piece of verification information automatically calculated by a script based on the flashable file generated by the compilation after the application software is successfully compiled.

5. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 4, characterized in that: The integrity check code is calculated based on the data in the compiled flashable file.

6. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 5, characterized in that: The compatibility check code is a software compatibility identifier stored at a specified address of the CodeFlash of the controller chip specified by the software developer.

7. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 6, characterized in that: When performing self-calibration and secondary calibration, follow the steps below to perform the calibration: First, obtain the verification information from the fixed address of the Code Flash, and parse it according to the storage format of the verification information in the Code Flash to obtain the starting address, end address, length, integrity check code and compatibility check code of the application software; Next, a compatibility check is performed, the information in the compatibility check code is read, and the compatibility of the application software is checked; Next, the length information is confirmed by adding the start address to the length and then subtracting one. The result is compared to see if it is equal to the end address. If they are equal, the length of the application software is correct. Next, perform integrity check, read the data from the start address to the end address of the application software in the Code Flash, calculate the integrity check code based on this data, and compare it with the integrity check code in the verification information. If the two are equal, the integrity check is successful; After all the above verification steps are successfully executed, the Bootloader software writes the application software validity flag to the non-volatile memory, and the written value is equal to FLAG_APP_VALID.

8. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 7, characterized in that: The script is integrated into the compilation script. When the application software project is compiled successfully, the script that generates the verification information is automatically executed. When executing the script for generating verification information, the script first reads the starting address, ending address and length information of the application software data according to the compiled and generated flashable file; then generates the application software integrity check code according to the data between the starting address and the ending address. The encryption algorithm used should be selected according to the needs of the software developer; after the calculation is completed, the script fills the starting address, ending address, length, integrity check code and compatibility check code information of the application software into the specified address of the flashable file of the application software to generate a new flashable file; The flashable file generated by compilation is recorded as Raw file, and the flashable file newly generated by this script is recorded as Customer file; when this script generates Customer file, the date, time and version number information are automatically filled in the file name; After this script generates the Customer file, this script merges the flashable file of the Bootloader software with the Customer file to generate a new flashable file, which is recorded as the ProductionLine file; When this script generates a ProductionLine file, it automatically fills in the date, time, and version number information in the file name.

9. The method for verifying the validity of application software based on double verification and self-verification in a Bootloader according to claim 8, characterized in that: The Customer file contains the application software data and verification information of the application software. When executing the Bootloader flashing process, the Customer file is used to flash the application software; The ProductionLine file contains Bootloader software data, application software data, and application software verification information; The ProductionLine file is burned on the controller production line, and the Bootloader software and application software are burned into the controller chip at the same time. After the Bootloader software is started, the Bootloader software performs self-checking according to the check information of the application software and jumps to the application software by itself.

Images