A method for instrument software upgrade

Abstract

The present invention relates to a method for upgrading instrument software. The control chip of the instrument is a dual-core architecture chip, and the dual-core architecture chip includes a first core and a second core. The first core communicates with the outside through the second core. In this method, an upgrade tool obtains a programming image of the new version software and processes the programming image data to obtain an upgrade package file; the second core establishes a communication connection with the upgrade tool and receives the upgrade package file; after the first core receives the data packets in segments and performs two verifications, after the verification is completed, the first core executes an upgrade task to upgrade the instrument software. Through this method, as long as the user establishes a communication connection between the vehicle instrument and the upgrade tool in a wired or wireless manner, the software update can be completed while greatly ensuring the safety and stability of the vehicle instrument, thereby protecting the property safety of the user.

Description

Technical Field

[0001] The present invention relates to the technical field of software upgrading, and particularly to a method for upgrading instrument software. Background Art

[0002] With the rapid development of current technologies, users have higher and higher requirements for the display of instrument systems. Before the vehicle leaves the factory, the software of the automotive instrument is stored in the storage chip in a solidified form, and it is impossible to update the data in the storage chip before disassembling the instrument. Therefore, it is very difficult to update the software on the sold vehicles, and the vehicle needs to be recalled, and after going through layers of operations to the factory for disassembly, then flashing or replacement can be carried out. Currently, there is a need for a simple operation that only requires the user to go to a designated point to complete the software update. However, there are many unsafe factors in this update method, and in the current environment, the data transmission method of some currently used upgrade systems uses plaintext transmission. The intercepted data packets can still be used after being modified by a third party, or the upgrade package is damaged after being cracked or accidentally modified by a third party, resulting in upgrade failure or abnormality. Summary of the Invention

[0003] In view of the technical problems existing in the prior art, the present invention provides a method for upgrading instrument software, which can safely update the data in the storage chip of the instrument.

[0004] The technical solution for the present invention to solve the above technical problems is as follows: A method for upgrading instrument software, the control chip of the instrument is a dual-core architecture chip, the dual-core architecture chip includes a first core and a second core, and the first core communicates with the outside through the second core. The method includes:

[0005] The upgrade tool obtains the burn image of the new version software and processes the burn image data to obtain an upgrade package file;

[0006] The second core establishes a communication connection with the upgrade tool and receives the upgrade package file; the second core includes a first buffer and a second buffer. The second core first stores the received upgrade package file in the first buffer area. When the first buffer area is full, the data in the first buffer area is transferred to the second buffer area, and at the same time, the first core is requested to receive the data stored in the second buffer area;

[0007] The first core includes a third buffer, a fourth buffer, and a fifth buffer. After the first core receives a data reception request sent by the second core, it receives the data stored in the second buffer and stores it in the third buffer. When the third buffer is full, the data is copied to the fourth buffer. The size of the fourth buffer is the size of the upgrade package segment. When the fourth buffer is full, the data is verified. After the data passes the verification, it is stored in the fifth buffer. After the complete data packet is stored in the fifth buffer, the data packet is verified again. After the verification is completed, the first core executes an upgrade task to upgrade the meter software.

[0008] Further, the first buffer is set in the memory of the second core, the second buffer is set in the shared memory of the first core and the second core, the third buffer and the fourth buffer are set in the memory of the first core, and the fifth buffer is set in the storage device.

[0009] Further, after the first core receives a data reception request sent by the second core, it extracts data with a specified offset and a specified size in the communication protocol from the second buffer and copies it to the third buffer.

[0010] Further, the method further includes that before the first core executes the upgrade task, the meter management program determines whether the current meter is in a safe state by detecting the current meter event. If it is in a safe state, the first core is allowed to execute the upgrade task; otherwise, this upgrade is rejected.

[0011] Further, when the first core performs two verifications on the upgrade package data, if any verification result is abnormal, the current upgrade task is interrupted.

[0012] Further, after the second verification is completed, the first core sends a message indicating that the data reception is completed to the upgrade tool through the second core to end the data transmission task.

[0013] Further, the first core executes the upgrade task, including:

[0014] Dividing the storage device into the form of A / B slots by means of software isolation, where one is the active slot and the other is the inactive slot;

[0015] Copying the currently running slot to the inactive slot, reading the complete upgrade package stored in the fifth buffer, obtaining the number of modules to be upgraded in the upgrade package through the file protocol of the upgrade package, and decompressing the data of each module in turn. After decompression, the data is verified and compared with the verification code stored in the file protocol. If the data is correct, the upgrade data is written to the specified offset of the backup slot to overwrite the old version data.

[0016] Further, after the upgrade task is completed, by modifying the flag bit in the boot area, the currently activated slot is set to an inactive slot, and the inactive slot is set to an active slot.

[0017] Further, the control chip of the instrument further includes an MCU core. The MCU is responsible for CAN communication, establishes communication with the upgrade tool through GTS, receives the data sent by the upgrade tool, decrypts and verifies the data, and interacts with the second core through a dual-channel SPI protocol.

[0018] Further, processing the burned image data to obtain an upgrade package file includes:

[0019] Performing heterogeneous arrangement on the burned image data according to the upgrade package file format to generate a binary file;

[0020] Converting the generated binary file into multiple S-Record format files;

[0021] Encrypting the multiple S-Record format files to obtain an upgrade package file containing multiple encrypted S-Record format files.

[0022] The beneficial effects of the present invention are as follows: 1. Through this method, there is no need to recall, disassemble, rewrite, or replace the vehicle to be upgraded. As long as the user establishes a communication connection between the vehicle instrument and the upgrade tool through a wired or wireless method, the software update can be completed.

[0023] 2. This upgrade method performs a verification operation on the key data every time the data is operated, greatly ensuring the security and stability of the vehicle instrument, and thus protecting the property safety of the user.

[0024] 3. When the upgrade package file is made, multiple encrypted S-Record format files are generated. On the one hand, it improves data security, and on the other hand, when multiple files are generated, strategies such as breakpoint resumption can be adopted during data transmission to improve data transmission efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a schematic diagram of an instrument software upgrade method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0026] The principles and features of the present invention are described below in conjunction with the accompanying drawings. The examples given are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0027] As Figure 1 shown, an embodiment of the present invention provides an instrument software upgrade method, including the following steps:

[0028] Step S101: After the software publisher releases a version, it will provide the burning image of the storage medium to the outside world, and a certificate group under optional conditions.

[0029] The image should include the 2D display program, 3D display program, instrument management program, instrument performance control program, etc. of the vehicle instrument.

[0030] Step S102: The burning image is internally parsed, reorganized, compressed, and packaged in the form of a configuration file. The data is heterogeneously arranged according to the upgrade package file format to form a new file with a new suffix name. This program will be loaded into the automated integration system, and through the configuration information generated in each integration and the required program configuration, the required binary upgrade package file will be centrally produced at the system level. It will include information such as the model of the vehicle instrument, the software version of the upgrade package, the updated software version information, the hardware version, and the integration time.

[0031] Among them, the model is the instrument of the specified vehicle model targeted by the upgrade package; the software version of the upgrade package is the version information of the upgrade package production software currently used, which will be recognized inside the instrument upgrade program; the updated software version information refers to the version information of the vehicle instrument, which is used to identify whether it is an upgradable version and record upgrade information, etc. inside the instrument upgrade program.

[0032] In specific implementation, due to the large amount of data, in order to reduce the time-consuming of the transmission process, the data will be compressed by the LZMA (Lempel-Ziv-Markov chain-Algiorithm) compression technology. The volume of the upgrade package can be compressed by 75%.

[0033] Finally, the generated binary file will be converted into an S-Record format file.

[0034] The basic characters of S-Record data are special ASCII characters, which are used to represent the corresponding hexadecimal data.

[0035] Step S103: After a series of processing procedures in the previous step, n S-Record format files will be generated according to the size. This file group will be archived in the server for recording and filing.

[0036] Step S104: To prevent the upgrade package from being cracked by a third party or damaged due to accidental modification, resulting in upgrade failure or abnormality, the S-Record file will be encrypted by technical means through this tool. The generated encrypted file will be submitted to the users who need to upgrade in the form of release.

[0037] Steps S105, S106: Before the user needs to perform an upgrade, the following preparations are required: the vehicle to be upgraded, a PC for automotive diagnosis, a specified upgrade tool (PC), an encrypted software upgrade package, a GTS vehicle diagnostic tool, etc. When the above tools are ready, connect the vehicle OBD and the PC interface through the GTS tool, load the encrypted upgrade package file group through the upgrade tool (PC), and click the Download button for transmission.

[0038] Step S107: The MCU is responsible for CAN communication, establishes communication with the PC upgrade tool through the GTS, receives the data sent by the upgrade tool, decrypts and verifies the data; acts as the host in the in-vehicle instrument, controls the interaction with the user (PC), and sends the instructions to the next-level chip through the SPI protocol.

[0039] Step S108: The MCU connects to the RCAR-E3 chip through the dual-channel SPI protocol and interacts with the Cotex-R7 core in the secure island.

[0040] Step S109: The CR7 core performs a pass-through operation in the in-vehicle instrument upgrade system. Two buffer areas are built in the CR7 core. The first buffer area is built in the memory and is used to store the data sent by the MCU core. When the buffer area is full, the data will be moved to the second buffer area; the second buffer area is built in the shared memory that interacts with the CA53 core, and the data stored through the built-in offset management will be sent to the CA53 core to request data reception when the second buffer area is full.

[0041] The RCAR-E3 chip internally contains a secure island Cotex-R7 core and two high-performance cores Cotex-A53 cores. To ensure the secure transmission and stable performance of data, the communication of the MCU will only interact with the CR7 core.

[0042] Step S110: The CA53 core serves as an executing job in the internal upgrade system. When the CA53 core receives a data reception request from CR7, it will retrieve data with a specified offset and size in the communication protocol from the shared memory with CR7 and copy it into the cache. Three buffer areas are built inside the CA53. The first buffer area is built in the memory (DDR) and will store the data transmitted by the CR7 core. When the first buffer area is full, the data will be copied to the second buffer area. The second buffer area is also built in the memory (DDR). The size of the second buffer area is the specified size of the upgrade package segment. By continuously obtaining data from the first buffer area until the complete size of the upgrade package segment is received, after verification, the valid data will be stored in the third buffer area according to the offset and size in the file protocol of the upgrade package segment. The third buffer area is built in the storage device (NAND FLASH). When the complete upgrade package data is stored, the complete upgrade package will be verified, and the result will be sent to the MCU through CR7, indicating the end of the data transmission task.

[0043] Step S111: The instrument management program determines whether the current instrument is in a safe state by detecting the current instrument event. In the case of a safe state, if an upgrade task is initiated, it will allow the upgrade control program to perform the next operation. In the case of an abnormal state of the instrument, if an upgrade task is initiated by the superior, this upgrade will be rejected.

[0044] Step S112: For the reception task of the CA53 core, when receiving data sent by the CR7 core, each segment of the received data will be verified, and the complete data will also be verified when the data is merged. If an exception occurs, it will enter the NG state and interrupt the current upgrade task.

[0045] Step S113: For the installation task of the CA53 core, after the data transmission task is completed, the installation process starts. First, the currently running slot will be copied to the backup slot. It will read the complete upgrade package in the third cache of the reception task, that is, in the NAND FLASH, obtain the number of modules to be upgraded in the upgrade package through the file protocol of the upgrade package, and decompress the data of each module in turn. After decompression, data verification will be performed and compared with the check code stored in the file protocol. If the data is correct, the upgrade data will be written to the specified offset of the backup slot, overwriting the old version data. After all modules are written, the result will be sent to the MCU through CR7, and then the MCU will notify the upgrade tool (PC), and thus the upgrade task is completed.

[0046] The NAND flash adopts the eMMC 5.0 protocol and divides the MMC UDA (USER DATA AREA) into the form of slots A / B through software isolation. Each slot will be planned by each module, and the data of the non-current startup slot will be updated in the form of data writing, which will not affect the currently running slot. After the upgrade program runs to completion, by modifying the flag bit in the boot area, the currently startup slot is set as the inactive slot, and the inactive slot is set as the active slot. When the vehicle instrument is reset next time, it will automatically switch to the updated slot.

[0047] Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic inventive concept. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0048] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.

Claims

1. A method for instrument software upgrade, wherein the control chip of the instrument is a dual-core architecture chip, the dual-core architecture chip includes a first core and a second core, and the first core communicates with the outside through the second core, characterized in that, The method includes: The upgrade tool obtains the flashing image of the new version software and processes the flashing image data to obtain an upgrade package file; The second core establishes a communication connection with the upgrade tool and receives the upgrade package file; the second core includes a first buffer and a second buffer. The second core first stores the received upgrade package file in the first buffer. When the first buffer is full, the data in the first buffer is transferred to the second buffer, and at the same time, the first core is requested to receive the data stored in the second buffer; The first core includes a third buffer, a fourth buffer, and a fifth buffer. After receiving the data reception request sent by the second core, the first core receives the data stored in the second buffer and stores it in the third buffer; when the third buffer is full of data, the data is copied to the fourth buffer. The size of the fourth buffer is the upgrade package segment size. When the fourth buffer is full, the data is verified. After the data passes the verification, it is stored in the fifth buffer. After the complete data packet is stored in the fifth buffer, the data packet is verified again. After the verification is completed, the first core executes the upgrade task to upgrade the instrument software.

2. The method according to claim 1, characterized in that, The first buffer is set in the memory of the second core, the second buffer is set in the shared memory of the first core and the second core, the third buffer and the fourth buffer are set in the memory of the first core, and the fifth buffer is set in the storage device.

3. The method according to claim 1, characterized in that After receiving the data reception request sent by the second core, the first core copies the data with the specified offset and specified size in the communication protocol from the second buffer to the third buffer.

4. The method according to claim 1, wherein It also includes that before the first core executes the upgrade task, the instrument management program judges whether the current instrument is in a safe state by detecting the current instrument event. If it is in a safe state, the first core is allowed to execute the upgrade task, otherwise this upgrade is rejected.

5. The method according to claim 1, wherein When the first core performs two verifications on the upgrade package data, if any verification result is abnormal, the current upgrade task is interrupted.

6. The method according to claim 1, wherein After the secondary verification is completed, the first core sends a message indicating that the data reception is completed to the upgrade tool through the second core to end the data transmission task.

7. The method according to claim 1, wherein The first core executes the upgrade task, including: Dividing the storage device into the form of A / B slots by means of software isolation, where one is the active slot and the other is the inactive slot; Copying the currently running slot to the inactive slot, reading the complete upgrade package stored in the fifth buffer, obtaining the number of modules to be upgraded in the upgrade package through the file protocol of the upgrade package, and decompressing the data of each module in turn. After decompression, the data is verified and compared with the verification code stored in the file protocol. If the data is correct, the upgrade data is written to the specified offset of the backup slot to overwrite the old version data.

8. The method according to claim 7, wherein After the upgrade task is completed, by modifying the flag bit in the boot area, the currently started slot is set to the inactive slot, and the inactive slot is set to the active slot.

9. The method according to claim 1, characterized in that, The control chip of the instrument further includes an MCU core, which is responsible for CAN communication, establishes communication with the upgrade tool through GTS, receives the data sent by the upgrade tool, decrypts and verifies the data, and interacts with the second core through a dual-channel SPI protocol.

10. The method according to claim 1, wherein Processing the burned image data to obtain an upgrade package file, including: Performing heterogeneous arrangement on the burned image data according to the upgrade package file format to generate a binary file; Converting the generated binary file into multiple S-Record format files; Encrypting the multiple S-Record format files to obtain an upgrade package file containing multiple encrypted S-Record format files.

Images