A vehicle-mounted controller firmware upgrading method, vehicle-mounted controller and system

Abstract

The application provides a vehicle-mounted controller firmware upgrading method, a vehicle-mounted controller and a system. The method comprises the following steps: in the process of receiving a compressed firmware data packet, performing first device matching verification on the compressed firmware data packet; if the first device matching verification is passed, receiving the compressed firmware data packet and storing the compressed firmware data packet into a target storage partition, and performing first compressed integrity verification on the compressed firmware data packet; if the first compressed integrity verification is passed, restarting and performing second device matching verification on the compressed firmware data packet in the target storage partition by using a Bootloader; if the second device matching verification is passed, performing second compressed integrity verification on the compressed firmware data packet by using the Bootloader; if the second compressed integrity verification is passed, decompressing the compressed firmware data into an App storage partition by using the Bootloader to obtain decompressed firmware data, and performing decompressed integrity verification on the decompressed firmware data; and if the decompressed integrity verification is passed, running the firmware to be upgraded in the App storage partition.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automotive electronics, in particular to a vehicle-mounted controller firmware upgrading method, vehicle-mounted controller and system. BACKGROUND

[0002] When the firmware of a vehicle device needs to be upgraded, the device manufacturer does not need to update the firmware of the vehicle device through after-sales, on-site service, etc., but pushes the firmware update to the vehicle to be upgraded through the OTA (Over the Air, remote wireless upgrade) technology. The OTA technology simplifies the vehicle after-sales maintenance cost, and is safe, reliable, convenient, low in cost, reduces manual intervention, and has become an indispensable technology.

[0003] The existing vehicle-mounted controller firmware upgrading scheme corresponds to four storage modes. Scheme 1 is ordinary single-partition storage, that is, on-chip storage and only includes an application program App storage partition and a boot loader Bootloader storage partition. Although this scheme occupies a small on-chip space, the firmware cannot be used when firmware upgrading is needed and rollback is not supported. Scheme 2, scheme 3 and scheme 4 are ordinary dual-partition storage. Scheme 2 has dual Bootloader storage partitions and dual App storage partitions, scheme 3 has single Bootloader storage partition and dual App storage partitions, and scheme 2 and scheme 3 both need to occupy a large amount of space of the vehicle-mounted controller chip. However, the internal space of the chip is usually scarce, so the cost during chip manufacturing process will be very high. Scheme 4 has on-chip storage area and off-chip storage area. Although scheme 4 occupies a small on-chip space, the off-chip flash has poor security and is easy to be stolen and maliciously damaged, and has poor security and reliability.

[0004] In view of this, the present application is proposed. SUMMARY

[0005] In view of the above defects or deficiencies in the prior art, the present application aims to provide a vehicle-mounted controller firmware upgrading method, vehicle-mounted controller and system, which reduces the occupation of internal storage space of the vehicle-mounted controller chip and also reduces the occupation of external storage space of the vehicle-mounted chip, and improves the security and reliability of the external storage space of the vehicle-mounted chip.

[0006] In a first aspect, the embodiments of the present application provide a vehicle-mounted controller firmware upgrading method, the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program App storage partition and a boot loader Bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition, and the method comprises the following steps.

[0007] In the process of receiving the compressed firmware data packet corresponding to the to-be-upgraded firmware, a first device matching check is performed on the compressed firmware data packet based on firmware header information, the compressed firmware data packet is generated based on the vehicle-mounted controller chip identification code ChipId, and the compressed firmware data packet includes the firmware header information corresponding to the to-be-upgraded firmware and compressed firmware data;

[0008] If the first device matching check passes, the compressed firmware data packet is received and stored in a target storage partition, and a first compressed integrity check is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, where the target storage partition is the first storage partition or the second storage partition.

[0009] If the first compressed integrity check passes, a second device matching check is performed on the compressed firmware data packet in the target storage partition based on the firmware header information by using a Bootloader storage partition;

[0010] If the second device matching check passes, a second compressed integrity check is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data by using the Bootloader storage partition;

[0011] If the second compressed integrity check passes, the compressed firmware data is decompressed to an App storage partition by using the Bootloader storage partition, to obtain decompressed firmware data, and a decompressed integrity check is performed on the decompressed firmware data based on the firmware header information;

[0012] If the decompressed integrity check passes, the to-be-upgraded firmware is run in the App storage partition.

[0013] According to the technical scheme provided in the embodiments of the present application, the vehicle-mounted controller firmware upgrading method further includes:

[0014] If the first device matching check fails, an upgrade invalid information is fed back, and subsequent operation steps are no longer performed.

[0015] Alternatively, if the first compressed integrity check fails, an upgrade invalid information is fed back, and subsequent operation steps are no longer performed.

[0016] Alternatively, if the second device matching check fails, an upgrade invalid information is fed back, and subsequent operation steps are no longer performed.

[0017] Alternatively, if the second compressed integrity check fails, an upgrade invalid information is fed back, and subsequent operation steps are no longer performed.

[0018] If the decompressed integrity check fails, a decompression failure is performed, and a firmware version rollback operation is performed.

[0019] According to the technical scheme provided in the embodiment of the application, the firmware header information comprises a device type, a vehicle-mounted controller chip identification code ChipId and a preset matching value, and correspondingly, the first device matching check on the compressed firmware data packet based on the firmware header information comprises:

[0020] matching check on the device type, the ChipId and the preset matching value;

[0021] If the device type, the ChipId and the preset matching value all pass the check, the first device matching check passes;

[0022] Correspondingly, the second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information by the Bootloader storage partition comprises:

[0023] matching check on the device type, the ChipId and the preset matching value by the Bootloader storage partition;

[0024] If the device type, the ChipId and the preset matching value all pass the check, the second device matching check passes.

[0025] According to the technical scheme provided in the embodiment of the application, the firmware header information further comprises an original compressed firmware cyclic redundancy check value, and correspondingly, the first compressed integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data comprises:

[0026] calculating a first compressed firmware cyclic redundancy check value corresponding to the compressed firmware data by using a cyclic redundancy check algorithm and the ChipId;

[0027] comparing the first compressed firmware cyclic redundancy check value with the original compressed firmware cyclic redundancy check value;

[0028] If the comparison result is consistent, the first compressed integrity check passes;

[0029] Correspondingly, the second compressed integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data by the Bootloader storage partition comprises:

[0030] calculating a second compressed firmware cyclic redundancy check value corresponding to the compressed firmware data by the Bootloader storage partition based on a cyclic redundancy check algorithm and the ChipId;

[0031] comparing the second compressed firmware cyclic redundancy check value with the original compressed firmware cyclic redundancy check value;

[0032] If the comparison result is consistent, the second compressed integrity check passes.

[0033] According to the technical scheme provided in the embodiment of the application, the firmware header information further comprises an original firmware cyclic redundancy check value, and correspondingly, the decompressed firmware data is subjected to decompressed integrity check, comprising:

[0034] calculating a decompressed firmware cyclic redundancy check value corresponding to the decompressed firmware data by using the cyclic redundancy check algorithm and the ChipId;

[0035] comparing the decompressed firmware cyclic redundancy check value with the original firmware cyclic redundancy check value;

[0036] If the comparison result is consistent, the decompressed integrity check passes.

[0037] According to the technical scheme provided in the embodiment of the application, the on-chip storage area further comprises a non-loss storage partition, which is used for storing an off-chip storage partition flag and an upgrade flag, and correspondingly, before the compressed firmware data packet is stored into the target storage partition, the method further comprises:

[0038] determining the target storage partition according to the off-chip storage partition flag;

[0039] Correspondingly, if the first compressed integrity check passes, the upgrade flag is set to mark to be upgraded, and the off-chip storage partition flag is set to mark a non-target storage partition.

[0040] According to the technical scheme provided in the embodiment of the application, before the compressed firmware data packet corresponding to the firmware to be upgraded is received, the method further comprises:

[0041] read-protecting the App storage partition and the Bootloader storage partition;

[0042] and starting or stopping the JTAG interface by using the Bootloader storage partition through the UDS.

[0043] According to the technical scheme provided in the embodiment of the application, the vehicle-mounted controller firmware upgrade method further comprises:

[0044] After the first time of burning power on, if it is detected that there is no firmware in the App storage partition and there is also no firmware in the off-chip storage area, initial compressed firmware data is received by using the Bootloader storage partition, and a third compressed integrity check is performed on the initial compressed firmware data, wherein the initial compressed firmware data is compressed data corresponding to initial firmware;

[0045] If the third compressed integrity check passes, the initial compressed firmware data is stored into an initial storage partition by using the Bootloader storage partition, and the initial storage partition is the first storage partition or the second storage partition.

[0046] In a second aspect, an embodiment of the present application provides a vehicle-mounted controller, including an on-chip storage area and an off-chip storage area, the on-chip storage area including an application program (App) storage partition and a boot loader (Bootloader) storage partition, and the off-chip storage area including a first storage partition and a second storage partition, and the vehicle-mounted controller is used to execute the vehicle-mounted controller firmware upgrading method according to any one of the above.

[0047] In a third aspect, an embodiment of the present application provides a vehicle-mounted controller firmware upgrading system, including the vehicle-mounted controller according to the second aspect and a server, and the system is used to:

[0048] The server acquires a vehicle-mounted controller firmware version, detects whether there is firmware to be upgraded, determines whether to upgrade the firmware, and if it is determined to upgrade, sends firmware upgradable information to the vehicle-mounted controller.

[0049] The vehicle-mounted controller receives the firmware upgradable information, and sends a ChipId corresponding to the vehicle-mounted controller to the server.

[0050] The server generates a compressed firmware data packet corresponding to the firmware to be upgraded based on the ChipId, and sends the compressed firmware data packet to the vehicle-mounted controller, wherein the compressed firmware data packet includes the firmware header information and compressed firmware data corresponding to the firmware to be upgraded.

[0051] In the process of receiving the compressed firmware data packet, the vehicle-mounted controller performs a first device matching check on the compressed firmware data packet based on the firmware header information.

[0052] If the first device matching check passes, the compressed firmware data packet is received and stored into a target storage partition, and a first compressed integrity check is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition.

[0053] if the first compression integrity check passes, restarting and using the Bootloader storage partition to perform a second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information;

[0054] if the second device matching check passes, using the Bootloader storage partition to perform a second compression integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data;

[0055] if the second compression integrity check passes, using the Bootloader storage partition to decompress the compressed firmware data to an App storage partition to obtain decompressed firmware data, and performing a decompression integrity check on the decompressed firmware data based on the firmware header information;

[0056] if the decompression integrity check passes, running the firmware to be upgraded in the App storage partition.

[0057] In summary, the application provides a vehicle-mounted controller firmware upgrading method, the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program App storage partition and a bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition, which comprises the following steps: in the process of receiving a compressed firmware data packet corresponding to the firmware to be upgraded, performing first device matching verification on the compressed firmware data packet based on firmware header information, the compressed firmware data packet is generated based on the vehicle-mounted controller chip identification code ChipId and includes the firmware header information and compressed firmware data corresponding to the firmware to be upgraded; if the first device matching verification passes, the compressed firmware data packet is received and stored in a target storage partition, and first compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition; if the first compressed integrity verification passes, the target storage partition is restarted and the compressed firmware data packet in the target storage partition is subjected to second device matching verification based on the firmware header information by using the bootloader storage partition; if the second device matching verification passes, the bootloader storage partition is used to perform second compressed integrity verification on the compressed firmware data packet based on the firmware header information and the compressed firmware data; if the second compressed integrity verification passes, the bootloader storage partition is used to decompress the compressed firmware data to the App storage partition to obtain decompressed firmware data, and decompressed integrity verification is performed on the decompressed firmware data based on the firmware header information; if the decompressed integrity verification passes, the firmware to be upgraded is run in the App storage partition. By compressing the firmware to be upgraded and storing it in the off-chip storage area of the vehicle-mounted controller, the network transmission traffic is reduced and the space occupation of the off-chip storage area is reduced. In addition, the compressed firmware data packet is generated based on the vehicle-mounted controller chip identification code, which is equivalent to encrypting the firmware to be upgraded, and the security and integrity of the firmware to be upgraded in the upgrading process are ensured through subsequent device uniqueness verification and integrity verification. BRIEF DESCRIPTION OF DRAWINGS

[0058] Figure 1 A storage area structure diagram for firmware upgrading in a vehicle-mounted controller is provided for the embodiments of the application.

[0059] Figure 2 A flowchart of a vehicle-mounted controller firmware upgrading method is provided for the embodiments of the application.

[0060] Figure 3 A flowchart of another vehicle-mounted controller firmware upgrading method is provided for the embodiments of the application.

[0061] Figure 4 A flowchart of a method for opening read protection of a vehicle-mounted controller according to an embodiment of the present application is provided.

[0062] Figure 5 A flowchart of a method for controlling opening and closing of JTAG by Bootloader through UDS protocol according to an embodiment of the present application is provided.

[0063] Figure 6 A flowchart of a method for loading firmware of a vehicle-mounted controller after first-time programming power-on according to an embodiment of the present application is provided.

[0064] Figure 7 A structural diagram of a vehicle-mounted controller firmware upgrade device according to an embodiment of the present application is provided.

[0065] Figure 8 A structural diagram of a vehicle-mounted controller according to an embodiment of the present application is provided.

[0066] Figure 9 A structural diagram of a vehicle-mounted controller firmware upgrade system according to an embodiment of the present application is provided.

[0067] Figure 10 A flowchart of another vehicle-mounted controller firmware upgrade method according to an embodiment of the present application is provided. DETAILED DESCRIPTION

[0068] The present application will be further described below in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related application, and not to limit the application. In addition, it should be noted that only the parts related to the application are shown in the drawings for ease of description.

[0069] It should be noted that the embodiments and features in the embodiments in the present application can be combined with each other without conflict. The present application will be described in detail below with reference to the accompanying drawings and embodiments.

[0070] As mentioned in the background, in order to solve the problems in the prior art, the present application provides a vehicle-mounted controller firmware upgrade method. The embodiment can be applied to the case where the firmware of the vehicle-mounted controller needs to be upgraded. The method can be executed by a vehicle-mounted controller firmware upgrade device, which can be realized in software and / or hardware, and can be configured in the vehicle-mounted controller, Figure 1 A structural diagram of a storage area for performing firmware upgrade in a vehicle-mounted controller according to an embodiment of the present application is provided. See Figure 1The vehicle-mounted controller is provided with an on-chip storage area 11 and an off-chip storage area 12. The on-chip storage area 11 includes an application program App storage partition 111 and a bootloader Bootloader storage partition 112. The off-chip storage area 12 includes a first storage partition 121 and a second storage partition 122. Figure 2 A flowchart of a vehicle-mounted controller firmware upgrading method provided by an embodiment of the present application is shown in FIG. 2. As shown in FIG. 2, the method includes the following steps. Figure 2

[0071] In S210, in the process of receiving a compressed firmware data packet corresponding to the firmware to be upgraded, a first device matching check is performed on the compressed firmware data packet based on firmware header information. The compressed firmware data packet is generated based on the vehicle-mounted controller chip identification code ChipId and includes the firmware header information corresponding to the firmware to be upgraded and compressed firmware data.

[0072] In this embodiment, the vehicle-mounted controller is a control unit of in-vehicle related electronic devices. Optionally, the vehicle-mounted controller can be various electronic control units (ECU), transmission control units (TCU), body control management (BCM), etc. The on-chip storage area 11 and the off-chip storage area 12 are preferably storage devices that will not lose data after power failure. For example, the on-chip storage area 11 and the off-chip storage area 12 can both be flash memories. The space of the application program App storage partition 111 in the on-chip storage area 11 is usually about 1.5 times that of the off-chip storage partition. Specifically, the application program App storage partition 111 is used to store decompressed firmware, and the off-chip storage area 12 is used to store compressed firmware data packets of firmware before upgrading and compressed firmware data packets of the current firmware to be upgraded.

[0073] ​Preferably, the compressed firmware data packet is generated by the server based on the chip identification ChipId of the vehicle-mounted controller, that is, the compressed firmware data packet corresponds to the vehicle-mounted controller one by one. The compressed firmware data packet comprises firmware header information and compressed firmware data. The firmware header information can be set to 64 bytes, wherein the firmware type ImgType of the firmware to be upgraded, the firmware size ImgSize, the running address ImgRunAddr, the original firmware cyclic redundancy check value ImgCRC, the firmware size FwSize corresponding to the compressed firmware (compressed firmware to be upgraded), the original compressed firmware cyclic redundancy check value FwCRC corresponding to the compressed firmware, the firmware version type HdrVer, the device type DevType, the chip identification ChipId of the vehicle-mounted controller, and the preset matching value Pattern can be stored. The original firmware cyclic redundancy check value ImgCRC is calculated by the server using the cyclic redundancy check (CRC) algorithm, taking ChipId as the initial value or part of the algorithm polynomial, and according to the firmware data to be upgraded (i.e. the content of the firmware to be upgraded); the original compressed firmware cyclic redundancy check value FwCRC is calculated by the server using the cyclic redundancy check algorithm, taking ChipId as the initial value or part of the algorithm polynomial, and according to the compressed firmware data (i.e. the content of the compressed firmware); for example, the cyclic redundancy check algorithm can be a CRC32 check algorithm; the preset matching value Pattern is used to indicate the fixed value at the preset position of the firmware header. The compressed firmware data is the data obtained by compressing the firmware to be upgraded. Table 1 is the comparison data before and after the firmware to be upgraded is compressed. As shown in Table 1, the data amount of the compressed firmware to be upgraded is significantly smaller. It can be understood that the decompression time corresponding to different processors will be different. After determining the firmware header information and the compressed firmware data, the server packs the firmware header information and the compressed firmware data into a compressed firmware data packet, and sends it to the vehicle-mounted controller through remote OTA technology. Table 2 is the content of the compressed firmware data packet. As shown in Table 2, the compressed firmware data packet comprises firmware header information and compressed firmware data. Alternatively, the compressed firmware data packet can be directly issued by the server to the vehicle-mounted controller through remote OTA technology, or can be issued by the server to the vehicle-mounted communication device through remote OTA technology, and then forwarded to the vehicle-mounted controller by the vehicle-mounted communication device. In this embodiment, the vehicle-mounted controller can perform the first device matching check after receiving the firmware header information in the compressed firmware data packet sent by the server, without waiting for the compressed firmware data packet to be completely received.

[0074] Table 1

[0075]

[0076] Table 2

[0077]

[0078] Since the related information of the vehicle-mounted controller corresponding to the firmware to be upgraded is stored in the firmware header information, the compressed firmware data packet can be preferably subjected to first device matching verification based on the firmware header information to determine whether the vehicle-mounted controller receiving the compressed firmware data packet is the vehicle-mounted controller corresponding to the firmware to be upgraded.

[0079] S220, if the first device matching verification passes, the compressed firmware data packet is received and stored into a target storage partition, and first compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition 121 or the second storage partition 122.

[0080] If the first device matching verification passes, it indicates that the vehicle-mounted controller receiving the compressed firmware data packet is the vehicle-mounted controller corresponding to the firmware to be upgraded. At this time, the complete compressed firmware data packet can be received and stored into the first storage partition 121 or the second storage partition 122, and the specific storage partition can be determined according to the last storage partition. If the last storage partition is the first storage partition 121, the current storage partition is the second storage partition 122, and if the last storage partition is the second storage partition 122, the current storage partition is the first storage partition 121, that is, the storage partitions corresponding to adjacent two times of storage are different.

[0081] Preferably, referring to Figure 1 , the on-chip storage area 11 can further include a non-loss storage partition Nvs 113 for storing an off-chip storage partition flag and an upgrade flag, and can further store other variables such as firmware parameters. The on-chip storage area 11 can further include a reserved partition Partion (not shown in Figure 1 ), for storing the specific path corresponding to the first storage partition 121 or the second storage partition 122 in the off-chip storage area 12. Correspondingly, before storing the compressed firmware data packet into the target storage partition, it further includes: determining the target storage partition according to the off-chip storage partition flag. By setting the non-loss storage partition, it can be ensured that the data will not disappear even in the case of power failure. By setting the off-chip storage partition flag and the upgrade flag, the vehicle-mounted controller can accurately locate the target storage partition and determine whether there is firmware to be upgraded.

[0082] The out-of-chip storage partition flag is used to mark the out-of-chip storage partition corresponding to the compressed firmware data packet before the compressed firmware data packet is stored in the target storage partition. For example, the out-of-chip storage partition flag can be represented by 1 or 0. If the out-of-chip storage partition flag is 1, the compressed firmware data packet can be stored in the first storage partition 121. If the out-of-chip storage partition flag is 0, the compressed firmware data packet can be stored in the second storage partition 122. For another example, the out-of-chip storage partition flag can be represented by A or B. If the out-of-chip storage partition flag is A, the compressed firmware data packet can be stored in the first storage partition 121. If the out-of-chip storage partition flag is B, the compressed firmware data packet can be stored in the second storage partition 122. Therefore, the target storage partition can be determined according to the out-of-chip storage partition flag in the embodiment. The upgrade flag is used to indicate whether there is firmware to be upgraded. For example, the upgrade flag can be represented by 1 or 0. If the upgrade flag is 1, there is firmware to be upgraded. If the upgrade flag is 0, there is no firmware to be upgraded.

[0083] Since the original compressed firmware cyclic redundancy check value FwCRC is stored in the firmware header information, and since the compressed firmware cyclic redundancy check value corresponding to the compressed firmware data needs to be calculated using the compressed firmware data, in order to determine whether the received compressed firmware data packet is complete, a first compressed integrity check can be performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data.

[0084] S230, if the first compressed integrity check passes, restarting and using the Bootloader storage partition to perform a second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information.

[0085] If the first compressed integrity check passes, it can be determined that the compressed firmware data packet has integrity. Preferably, if the first compressed integrity check passes, the upgrade flag is set to mark the firmware to be upgraded, and the out-of-chip storage partition flag is set to mark the non-target storage partition. In the embodiment, the upgrade flag is set to be upgraded, so that the Bootloader storage partition can know that there is firmware to be upgraded. The out-of-chip storage partition flag is set to mark the non-target storage partition, so that the vehicle-mounted controller can know the corresponding storage partition to be stored next time, and the Bootloader storage partition can know the partition to be decompressed next time.

[0086] After the first compression integrity check passes, the vehicle-mounted controller is restarted and switched to run in the Bootloader storage partition. To ensure the safety of the firmware upgrade process, the Bootloader preferably performs a second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information. The second device matching check is the same as the first device matching check, which will not be described again here.

[0087] S240, if the second device matching check passes, the Bootloader storage partition performs a second compression integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data.

[0088] The second compression integrity check in this embodiment is the same as the first compression integrity check, which will not be described again here.

[0089] S250, if the second compression integrity check passes, the Bootloader storage partition decompresses the compressed firmware data to the App storage partition to obtain decompressed firmware data, and performs a decompression integrity check on the decompressed firmware data based on the firmware header information.

[0090] For example, the decompression algorithm can be the LZMA algorithm, which has the advantages of small code size, easy porting, high compression ratio, fast compression speed, and stream operation. When using the LZMA algorithm for decompression, only 64K of running RAM (Random Access Memory) and 20K of code space are required, which requires less resources for the vehicle-mounted controller.

[0091] The decompressed firmware data is the data corresponding to the firmware to be upgraded. Since the original firmware cyclic redundancy check value ImgCRC corresponding to the firmware to be upgraded is stored in the firmware header information, and the decompressed firmware cyclic redundancy check value is calculated using the decompressed firmware data, to determine whether the decompressed firmware data is complete, the decompressed firmware data is preferably checked for decompression integrity based on the firmware header information and the decompressed firmware data.

[0092] S260, if the decompression integrity check passes, run the firmware to be upgraded in the App storage partition.

[0093] If the decompression integrity check passes, it can be determined that the decompression is successful, and the firmware to be upgraded can be run.

[0094] The vehicle-mounted controller firmware upgrading method provided in the embodiment, the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program App storage partition and a bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition, and the method comprises the following steps: in the process of receiving a compressed firmware data packet corresponding to the firmware to be upgraded, performing first device matching verification on the compressed firmware data packet based on firmware header information, the compressed firmware data packet is generated based on the chip identification code ChipId of the vehicle-mounted controller, and the compressed firmware data packet includes the firmware header information and compressed firmware data corresponding to the firmware to be upgraded; if the first device matching verification is passed, the compressed firmware data packet is received and stored in a target storage partition, and first compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition; if the first compressed integrity verification is passed, the vehicle-mounted controller is restarted, and second device matching verification is performed on the compressed firmware data packet in the target storage partition based on the firmware header information by using the bootloader storage partition; if the second device matching verification is passed, second compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data by using the bootloader storage partition; if the second compressed integrity verification is passed, the compressed firmware data is decompressed to the App storage partition by using the bootloader storage partition, to obtain decompressed firmware data, and decompressed integrity verification is performed on the decompressed firmware data based on the firmware header information; and if the decompressed integrity verification is passed, the firmware to be upgraded is run in the App storage partition. By compressing the firmware to be upgraded and storing it in the off-chip storage area of the vehicle-mounted controller, the network transmission traffic is reduced, and the space occupation of the internal storage area and the external storage area is reduced. In addition, the compressed firmware data packet is generated based on the chip identification code of the vehicle-mounted controller, the firmware is bound one-to-one with the vehicle-mounted controller, which is equivalent to encrypting the firmware to be upgraded, and the safety and integrity of the firmware to be upgraded in the upgrading process are ensured through subsequent device uniqueness verification and integrity verification.

[0095] Figure 3 The flowchart of another vehicle-mounted controller firmware upgrading method provided by the embodiment of the application is shown in FIG. 4. Figure 3 As shown in FIG. 4, the flowchart of the vehicle-mounted controller firmware upgrading method provided by the embodiment of the application not only includes the flowchart of the vehicle-mounted controller firmware upgrading method provided by each of the above embodiments, but also includes the flowchart of the vehicle-mounted controller firmware upgrading method further provided by the following embodiment. On the basis of each of the above embodiments, further, the vehicle-mounted controller firmware upgrading method further comprises the following steps:

[0096] If the first device matching verification is not passed, the upgrading invalid information is fed back, and the subsequent operation steps are not performed.

[0097] Or, if the first compression integrity check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps;

[0098] Or, if the second device matching check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps;

[0099] Or, if the second compression integrity check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps;

[0100] If the decompression integrity check fails, the decompression fails, and a firmware version rollback operation is performed.

[0101] If the first device matching check fails, it means that the vehicle-mounted controller receiving the compressed firmware data packet is not the vehicle-mounted controller corresponding to the firmware to be upgraded, that is, the firmware to be upgraded is received incorrectly. At this time, upgrade invalid information can be fed back, and subsequent operations are stopped. The vehicle-mounted controller can still run the current version of the firmware, without affecting its performance. If the first compression integrity check fails, it can be determined that the compressed firmware data packet is not complete, which will cause errors in subsequent firmware upgrades. At this time, upgrade invalid information can be fed back, and subsequent operations are stopped. The vehicle-mounted controller can still run the current version of the firmware, without affecting its performance. If the second device matching check fails, it means that the first device matching check may have errors or the compressed firmware data packet has errors. At this time, upgrade invalid information can be fed back, and subsequent operations are stopped. The vehicle-mounted controller can still run the current version of the firmware, without affecting its performance. If the second compression integrity check fails, it can be determined that the first compression integrity check has errors or the compressed firmware data packet has integrity problems. At this time, upgrade invalid information can be fed back, and subsequent operations are stopped. The vehicle-mounted controller can still run the current version of the firmware, without affecting its performance. If the decompression integrity check fails for the first time, the decompression operation can be repeated a predetermined number of times. If it is finally determined that the decompression integrity check fails, the decompression fails, and a firmware version rollback operation is performed. The above technical solution can avoid the problem of still performing subsequent operations when problems occur during the upgrade process, saving time and cost.

[0102] On the basis of the above embodiments, further, the firmware header information includes a device type, a vehicle-mounted controller chip identification code ChipId and a preset matching value. Correspondingly, the first device matching check on the compressed firmware data packet based on the firmware header information includes:

[0103] Matching check is performed on the device type, the ChipId and the preset matching value;

[0104] If the device type, the ChipId and the preset matching value are all verified, the first device matching verification is passed;

[0105] Correspondingly, the Bootloader storage partition performs a second device matching verification on the compressed firmware data packet in the target storage partition based on the firmware header information, including:

[0106] The Bootloader storage partition performs matching verification on the device type, the ChipId and the preset matching value;

[0107] If the device type, the ChipId and the preset matching value are all verified, the second device matching verification is passed.

[0108] The embodiment places the unique ChipId of the vehicle-mounted controller in the firmware header information, so that the vehicle-mounted controller is uniquely bound with the firmware to be upgraded, and the safety of the firmware upgrading process can be ensured.

[0109] Specifically, the first device matching verification can include that the vehicle-mounted controller compares the local device type and the ChipId with the device type and the ChipId in the firmware header information, and if the comparison result is consistent, it indicates that the vehicle-mounted controller is the vehicle-mounted controller corresponding to the compressed firmware data packet. In addition, the vehicle-mounted controller can also verify the data at the corresponding position of the firmware header according to the preset matching value, and if they are consistent, it can be determined that the first device matching verification is passed. The second device matching verification can include that the Bootloader storage partition compares the local device type and the ChipId with the device type and the ChipId in the firmware header information, and if the comparison result is consistent, it indicates that the vehicle-mounted controller is the vehicle-mounted controller corresponding to the compressed firmware data packet. In addition, the Bootloader storage partition can also verify the data at the corresponding position of the firmware header according to the preset matching value, and if they are consistent, it can be determined that the second device matching verification is passed.

[0110] On the basis of the above embodiments, further, the firmware header information further includes an original compressed firmware cyclic redundancy check value, and correspondingly, the first compressed integrity verification on the compressed firmware data packet based on the firmware header information and the compressed firmware data includes:

[0111] The first compressed firmware cyclic redundancy check value is compared with the original compressed firmware cyclic redundancy check value;

[0112] The first compressed firmware cyclic redundancy check value is compared with the original compressed firmware cyclic redundancy check value;

[0113] If the comparison result is consistent, the first compression integrity check passes;

[0114] Correspondingly, the Bootloader storage partition performs a second compression integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data, including:

[0115] The Bootloader storage partition calculates a second compressed firmware cyclic redundancy check value corresponding to the compressed firmware data based on a cyclic redundancy check algorithm and the ChipId;

[0116] The second compressed firmware cyclic redundancy check value is compared with an original compressed firmware cyclic redundancy check value;

[0117] If the comparison result is consistent, the second compression integrity check passes.

[0118] The embodiment can guarantee the security of the firmware upgrade process by performing integrity verification on the compressed firmware data packet through the cyclic redundancy check algorithm.

[0119] On the basis of the above embodiments, further, the firmware header information further includes an original firmware cyclic redundancy check value, and correspondingly, the decompressed firmware data is subjected to decompression integrity check, including:

[0120] A decompressed firmware cyclic redundancy check value corresponding to the decompressed firmware data is calculated based on a cyclic redundancy check algorithm and the ChipId;

[0121] The decompressed firmware cyclic redundancy check value is compared with the original firmware cyclic redundancy check value;

[0122] If the comparison result is consistent, the decompression integrity check passes.

[0123] The embodiment can guarantee the security of the firmware upgrade process by performing integrity verification on the decompressed firmware data packet through the cyclic redundancy check algorithm.

[0124] On the basis of the above embodiments, further, before receiving the compressed firmware data packet corresponding to the firmware to be upgraded, the method further includes:

[0125] The App storage partition and the Bootloader storage partition are subjected to read protection;

[0126] And the Bootloader storage partition starts or stops a Joint Test Action Group (JTAG) interface through a Unified Diagnostic Services (UDS) protocol.

[0127] The technical scheme of the embodiment can prevent external devices from illegally obtaining the content in the App storage partition and the Bootloader storage partition through a JTAG interface or other ways by performing read protection on the App storage partition and the Bootloader storage partition, and ensure the safety of the running of the firmware of the vehicle-mounted controller. The safety of the vehicle-mounted controller can be further enhanced by controlling the opening and closing of the JTAG interface through the UDS protocol.

[0128] Figure 4 A flowchart of a vehicle-mounted controller read protection opening method provided by the embodiment of the application is shown in FIG. 1. Figure 4 The vehicle-mounted controller is powered on to enter the Bootloader, and it is determined whether the read protection of the App storage partition and the Bootloader storage partition is opened. If the read protection is opened, even if external devices read the content in the App storage partition and the Bootloader storage partition through a JTAG interface or other ways, the read content is invalid. If the read protection is not opened, the read protection of the App storage partition and the Bootloader storage partition is opened.

[0129] Figure 5 A flowchart of a Bootloader JTAG opening and closing method through a UDS protocol provided by the embodiment of the application is shown in FIG. 2. Figure 5 The vehicle-mounted controller is powered on to enter the Bootloader, and the UDS sends a JTAG interface switch command through can communication to determine whether the JTAG interface debugging is opened. If the JTAG interface debugging is opened, the firmware can be debugged or programmed in the vehicle-mounted controller (except the read protection area) through the JTAG interface. If the JTAG interface debugging is closed, the firmware is prohibited from being debugged or programmed in the vehicle-mounted controller through the JTAG interface.

[0130] On the basis of the above-mentioned embodiments, further, the vehicle-mounted controller firmware upgrading method further comprises:

[0131] After the first programming power-on, if it is detected that the firmware does not exist in the App storage partition and the firmware does not exist in the off-chip storage area, the Bootloader storage partition is used to receive initial compressed firmware data, and the initial compressed firmware data is subjected to third compressed integrity verification, wherein the initial compressed firmware data is compressed data corresponding to the initial firmware.

[0132] If the third compressed integrity verification passes, the Bootloader storage partition is used to store the initial compressed firmware data into an initial storage partition, and the initial storage partition is the first storage partition or the second storage partition.

[0133] In this embodiment, the first time burning needs to burn the Bootloader storage partition, which has the functions of reading and writing the off-chip storage area, UDS protocol communication, JTAG interface control, application program App storage partition and boot loader Bootloader storage partition read protection, and decompressing firmware. Figure 6 A flowchart of a first-time burning power-on firmware loading method for a vehicle-mounted controller according to an embodiment of the present application is shown in FIG. 8. After the first-time burning power-on, if it is detected that there is no firmware in the App storage partition and there is also no firmware in the off-chip storage area, the Bootloader storage partition is waited for and receives the initial compressed firmware data sent by the server, the initial compressed firmware data is subjected to third compression integrity verification, the verification is passed, the initial compressed firmware data is stored in the initial storage partition in the off-chip storage area, and then the vehicle-mounted controller is restarted. If it is detected that there is firmware in the App storage partition, the firmware is directly run, and if it is detected that there is no firmware in the App storage partition but there is firmware in the off-chip storage area, the compressed firmware data in the off-chip storage area is decompressed to the App storage partition, and the new firmware is run. Figure 6

[0134] Figure 7 A structure diagram of a vehicle-mounted controller firmware upgrading device according to an embodiment of the present application is shown in FIG. 9. The device is arranged in a vehicle-mounted controller, the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program App storage partition and a boot loader Bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition. As shown in FIG. 9, the device includes: Figure 7

[0135] A first device matching verification module 710 is configured to, in the process of receiving a compressed firmware data packet corresponding to a to-be-upgraded firmware, perform first device matching verification on the compressed firmware data packet based on firmware header information, the compressed firmware data packet is generated based on a vehicle-mounted controller chip identification code ChipId and includes the firmware header information and compressed firmware data corresponding to the to-be-upgraded firmware.

[0136] A first compression integrity verification module 720 is configured to, if the first device matching verification is passed, receive the compressed firmware data packet and store it in a target storage partition, and perform first compression integrity verification on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition.

[0137] ​​The second device matching verification module 730 is configured to restart and perform, based on the firmware header information, second device matching verification on the compressed firmware data packet in the target storage partition by using the Bootloader storage partition if the first compressed integrity verification passes.

[0138] The second compressed integrity verification module 740 is configured to perform, based on the firmware header information and the compressed firmware data, second compressed integrity verification on the compressed firmware data packet by using the Bootloader storage partition if the second device matching verification passes.

[0139] The decompression integrity verification module 750 is configured to decompress, by using the Bootloader storage partition, the compressed firmware data to an App storage partition to obtain decompressed firmware data, and perform decompression integrity verification on the decompressed firmware data based on the firmware header information if the second compressed integrity verification passes.

[0140] The to-be-upgraded firmware running module 760 is configured to run the to-be-upgraded firmware in the App storage partition if the decompression integrity verification passes.

[0141] The vehicle-mounted controller firmware upgrading device provided by the embodiment is arranged in a vehicle-mounted controller, the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program (App) storage partition and a boot loader (Bootloader) storage partition, the off-chip storage area includes a first storage partition and a second storage partition, the device includes a first device matching verification module, configured to perform first device matching verification on a compressed firmware data packet corresponding to a to-be-upgraded firmware based on firmware header information in a process of receiving the compressed firmware data packet, the compressed firmware data packet is generated based on a chip identification code (ChipId) of the vehicle-mounted controller and includes the firmware header information and compressed firmware data corresponding to the to-be-upgraded firmware, a first compressed integrity verification module, configured to, if the first device matching verification passes, receive the compressed firmware data packet and store the compressed firmware data packet into a target storage partition, and perform first compressed integrity verification on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition, a second device matching verification module, configured to, if the first compressed integrity verification passes, restart and perform second device matching verification on the compressed firmware data packet in the target storage partition based on the firmware header information by using the Bootloader storage partition, a second compressed integrity verification module, configured to, if the second device matching verification passes, perform second compressed integrity verification on the compressed firmware data packet based on the firmware header information and the compressed firmware data by using the Bootloader storage partition, a decompression integrity verification module, configured to, if the second compressed integrity verification passes, decompress the compressed firmware data into an App storage partition by using the Bootloader storage partition to obtain decompressed firmware data, and perform decompression integrity verification on the decompressed firmware data based on the firmware header information, and a to-be-upgraded firmware running module, configured to, if the decompression integrity verification passes, run the to-be-upgraded firmware in the App storage partition. By compressing the to-be-upgraded firmware and storing the to-be-upgraded firmware into the off-chip storage area of the vehicle-mounted controller, network transmission traffic is reduced, and the space occupation of the internal storage area and the external storage area is reduced. In addition, the compressed firmware data packet is generated based on the chip identification code of the vehicle-mounted controller, the firmware is bound to the vehicle-mounted controller chip one by one, which is equivalent to encrypting the to-be-upgraded firmware, and the safety and integrity of the to-be-upgraded firmware in the upgrading process are ensured through subsequent device uniqueness verification and integrity verification.

[0142] On the basis of the above technical solutions, further, the vehicle-mounted controller firmware upgrading device can be used for:

[0143] If the first device matching verification does not pass, feedback upgrading invalid information, and no subsequent operation steps are performed.

[0144] Or, if the first compression integrity check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps.

[0145] Or, if the second device matching check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps.

[0146] Or, if the second compression integrity check fails, feedback upgrade invalid information, and no longer perform subsequent operation steps.

[0147] If the decompression integrity check fails, the decompression fails, and a firmware version rollback operation is performed.

[0148] On the basis of each of the above technical solutions, further, the firmware header information includes a device type, a vehicle-mounted controller chip identification code ChipId, and a preset matching value. Correspondingly, the first device matching check module 710 can be specifically configured to perform matching check on the device type, the ChipId, and the preset matching value. If the device type, the ChipId, and the preset matching value all pass the check, the first device matching check passes. Correspondingly, the second device matching check module 730 can be specifically configured to perform matching check on the device type, the ChipId, and the preset matching value by using the Bootloader storage partition. If the device type, the ChipId, and the preset matching value all pass the check, the second device matching check passes.

[0149] On the basis of each of the above technical solutions, further, the firmware header information further includes an original compressed firmware cyclic redundancy check value. Correspondingly, the first compression integrity check module 720 can be specifically configured to calculate a first compressed firmware cyclic redundancy check value corresponding to the compressed firmware data by using a cyclic redundancy check algorithm and the ChipId, compare the first compressed firmware cyclic redundancy check value with the original compressed firmware cyclic redundancy check value, and if the comparison result is consistent, the first compression integrity check passes. Correspondingly, the second compression integrity check module 740 can be specifically configured to calculate a second compressed firmware cyclic redundancy check value corresponding to the compressed firmware data by using the Bootloader storage partition based on a cyclic redundancy check algorithm and the ChipId, compare the second compressed firmware cyclic redundancy check value with the original compressed firmware cyclic redundancy check value, and if the comparison result is consistent, the second compression integrity check passes.

[0150] On the basis of each of the technical solutions above, further, the firmware header information further comprises an original firmware cyclic redundancy check value, and correspondingly, the decompression integrity check module 750 can be specifically configured to: calculate a decompression firmware cyclic redundancy check value corresponding to the decompressed firmware data by using a cyclic redundancy check algorithm and the ChipId; compare the decompression firmware cyclic redundancy check value with the original firmware cyclic redundancy check value; and if the comparison result is consistent, the decompression integrity check passes.

[0151] On the basis of each of the technical solutions above, further, the on-chip storage area further comprises a non-lost storage partition, the non-lost storage partition is configured to store an off-chip storage partition flag and an upgrade flag, and correspondingly, the vehicle-mounted controller firmware upgrade device can further comprise a flag setting module, configured to determine the target storage partition according to the off-chip storage partition flag before storing the compressed firmware data packet into the target storage partition; and correspondingly, if the first compression integrity check passes, set the upgrade flag to mark that the upgrade is to be performed, and set the off-chip storage partition flag to mark that the target storage partition is not the target storage partition.

[0152] On the basis of each of the technical solutions above, further, the vehicle-mounted controller firmware upgrade device can further comprise a security setting module, configured to: perform read protection on the App storage partition and the Bootloader storage partition before receiving the compressed firmware data packet corresponding to the firmware to be upgraded; and enable or disable a Joint Test Action Group (JTAG) interface by using the Bootloader storage partition through a Unified Diagnostic Services (UDS) protocol.

[0153] On the basis of each of the technical solutions above, further, the vehicle-mounted controller firmware upgrade device can further comprise an initial firmware receiving and storing module, configured to: after first-time power-on, if it is detected that there is no firmware in the App storage partition and there is no firmware in the off-chip storage area, receive initial compressed firmware data by using the Bootloader storage partition, and perform third compression integrity check on the initial compressed firmware data, wherein the initial compressed firmware data is compressed data corresponding to an initial firmware; and if the third compression integrity check passes, store the initial compressed firmware data into an initial storage partition by using the Bootloader storage partition, the initial storage partition being the first storage partition or the second storage partition.

[0154] The vehicle-mounted controller firmware upgrade device provided by the embodiment of the application can execute the steps in the vehicle-mounted controller firmware upgrade method provided by the method embodiment of the application, and has the execution steps and beneficial effects which will not be repeated here.

[0155] Figure 8A structural schematic diagram of a vehicle controller is provided in the embodiments of the present application. As shown in Figure 8 The vehicle controller 300 includes a processor 331 and a memory 332, wherein the memory includes an on-chip storage area and an off-chip storage area (not shown in the figure), the on-chip storage area includes an application program App storage partition and a bootloader Bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition; the processor 331 invokes programs or instructions stored in the memory 332 to execute the vehicle controller firmware upgrading method as described in the embodiments of the present application.

[0156] In the embodiments, the processor 331 can be one or multiple. The processor 331 can be a central processing unit (CPU) or other forms of processing units with data processing capability and / or instruction execution capability, and can control other components in the vehicle controller 300 to perform desired functions.

[0157] The memory 332 can include one or more computer program products, which can include various forms of computer readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory can include, for example, random access memory (RAM), cache memory and / or the like. The non-volatile memory can include, for example, read-only memory (ROM), hard disk, flash memory and / or the like. One or more computer programs or instructions can be stored in the computer readable storage media, and the processor 331 can invoke the programs or instructions to implement the vehicle controller firmware upgrading method of any of the embodiments of the present application and / or other desired functions. Various contents such as initial extrinsic parameters, threshold values and the like can also be stored in the computer readable storage media.

[0158] In one example, the vehicle controller 300 can further include an input device 333 and an output device 334, which are interconnected through a bus system and / or other forms of connection mechanism (not shown). The input device 333 can include, for example, a keyboard, a mouse and / or the like. The output device 334 can output various information to the outside, including pre-warning prompt information, braking force and the like. The output device 334 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and / or the like.

[0159] Of course, in order to simplify, Figure 8 In the embodiments, only some of the components in the vehicle controller 300 related to the present application are shown, and components such as buses, input / output interfaces and the like are omitted. In addition, the vehicle controller 300 can also include any other appropriate components according to specific application conditions.

[0160] Besides the method and the device, the embodiment of the present application can also be a computer program product, which comprises computer program instructions, and the computer program instructions make the processor execute the steps of the vehicle controller firmware upgrading method provided by any embodiment of the present application when the processor runs.

[0161] The computer program product can be written in any combination of one or more programming languages to perform the operations of the embodiments of the present application, including an object-oriented programming language, such as Java, C++, and the like, and a conventional procedural programming language, such as the "C" programming language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0162] In addition, the embodiment of the present application can also be a computer readable storage medium, which stores programs or instructions, and the programs or instructions make the computer execute the steps of the vehicle controller firmware upgrading method provided by any embodiment of the present application.

[0163] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples (non-exhaustive list) of readable storage medium include: electrical connection with one or more conductive wires, portable disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.

[0164] Figure 9 A structural schematic diagram of a vehicle controller firmware upgrading system provided by the embodiment of the present application, Figure 10 A structural schematic diagram of another vehicle controller firmware upgrading method provided by the embodiment of the present application, which is executed by a vehicle controller firmware upgrading system. Referring to Figure 9 and Figure 10 The embodiment of the present application also provides a vehicle controller firmware upgrading system, which comprises a vehicle controller 910 and a server 920 executing the vehicle controller firmware upgrading method provided by any embodiment of the present application, and the system is used for:

[0165] The server 920 acquires the firmware version of the vehicle-mounted controller 910, determines whether to upgrade the firmware if it is detected that there is firmware to be upgraded, and sends firmware upgradable information to the vehicle-mounted controller 910 if it is determined to upgrade;

[0166] The vehicle-mounted controller 910 receives the firmware upgradable information and sends a ChipId corresponding to the vehicle-mounted controller 910 to the server 920;

[0167] The server 920 generates a compressed firmware data packet corresponding to the firmware to be upgraded based on the ChipId and sends the compressed firmware data packet to the vehicle-mounted controller 910, wherein the compressed firmware data packet includes the firmware header information and compressed firmware data corresponding to the firmware to be upgraded;

[0168] The vehicle-mounted controller 910 receives the compressed firmware data packet and performs first device matching verification on the compressed firmware data packet based on the firmware header information;

[0169] If the first device matching verification passes, the compressed firmware data packet is stored in a target storage partition, and first compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition;

[0170] If the first compressed integrity verification passes, the vehicle-mounted controller 910 is restarted and performs second device matching verification on the compressed firmware data packet in the target storage partition based on the firmware header information using a Bootloader storage partition;

[0171] If the second device matching verification passes, second compressed integrity verification is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data using the Bootloader storage partition;

[0172] If the second compressed integrity verification passes, the compressed firmware data is decompressed to an App storage partition using the Bootloader storage partition to obtain decompressed firmware data, and decompressed integrity verification is performed on the decompressed firmware data based on the firmware header information;

[0173] If the decompressed integrity verification passes, the vehicle-mounted controller 910 runs the firmware to be upgraded in the App storage partition.

[0174] In this embodiment, the server can automatically determine whether to perform firmware upgrade, or the user can trigger a firmware upgrade instruction.

[0175] On the basis of the above embodiments, further, if it is determined not to upgrade the firmware, the server 920 runs other functions.

[0176] On the basis of the above embodiments, further, the vehicle-mounted controller 910 in the system is further used for:

[0177] If the first device matching check fails, feedback is given that the upgrade is invalid, and no subsequent operation steps are performed.

[0178] Alternatively, if the first compression integrity check fails, feedback is given that the upgrade is invalid, and no subsequent operation steps are performed.

[0179] Alternatively, if the second device matching check fails, feedback is given that the upgrade is invalid, and no subsequent operation steps are performed.

[0180] Alternatively, if the second compression integrity check fails, feedback is given that the upgrade is invalid, and no subsequent operation steps are performed.

[0181] If the decompression integrity check fails, the decompression fails, and a firmware version rollback operation is performed.

[0182] It should be noted that the terms used in the present application are only for the purpose of describing specific embodiments, and are not intended to limit the scope of the present application. As shown in the specification and claims of the present application, unless the context clearly indicates otherwise, "one", "a", "an", and / or "the" do not specifically refer to the singular, but can also include the plural. The terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method or device. Without further limitation, the element defined by the statement "including one" does not exclude the presence of other identical elements in the process, method or device including the element.

[0183] It should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", and the like, indicate relative positions or orientations based on the positions or orientations shown in the drawings, and are used only to facilitate the description of the present application and simplify the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. Unless otherwise expressly specified and limited, the terms "mounting", "connecting", "connecting" and the like should be broadly understood, for example, can be fixedly connected, can also be detachably connected, or integrally connected; can be mechanically connected, can also be electrically connected; can be directly connected, can also be indirectly connected through an intermediate medium, can be internal communication of two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to the specific circumstances.

[0184] The principles and implementation modes of the present application are described herein by applying specific examples, and the above example descriptions are only used to help understand the method of the present application and its core idea. The above description is only the preferred embodiment of the present application. It should be pointed out that due to the limitation of language expression, there are objectively infinite specific structures, and for those skilled in the art, without departing from the principles of the present application, a number of improvements, refinements or changes can be made, and the above technical features can be combined in an appropriate manner; these improvements, refinements, changes or combinations, or the direct application of the inventive concept and technical solution to other occasions without improvement, shall be regarded as the protection scope of the present application.

Claims

1. An in-vehicle controller firmware upgrade method characterized by, The vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the on-chip storage area includes an application program (App) storage partition and a bootloader storage partition, and the off-chip storage area includes a first storage partition and a second storage partition, comprising: In the process of receiving the compressed firmware data packet corresponding to the firmware to be upgraded, the first device matching check is performed on the compressed firmware data packet based on the firmware header information, the compressed firmware data packet is generated based on the vehicle-mounted controller chip identification code (ChipId), and the compressed firmware data packet includes the firmware header information and the compressed firmware data corresponding to the firmware to be upgraded; If the first device matching check passes, the compressed firmware data packet is received, the target storage partition is determined according to the off-chip storage partition flag, the compressed firmware data packet is stored in the target storage partition, and the first compressed integrity check is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the target storage partition is the first storage partition or the second storage partition; the off-chip storage partitions corresponding to adjacent two times of storage are different; the on-chip storage area further includes a non-loss storage partition, and the non-loss storage partition is used to store the off-chip storage partition flag and an upgrade flag; If the first compressed integrity check passes, the upgrade flag is set to mark the firmware to be upgraded, the off-chip storage partition flag is set to mark the non-target storage partition, and the target storage partition is restarted and the bootloader storage partition is used to perform the second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information; If the second device matching check passes, the bootloader storage partition is used to perform the second compressed integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data; If the second compressed integrity check passes, the bootloader storage partition is used to decompress the compressed firmware data to the App storage partition to obtain decompressed firmware data, and the decompressed firmware data is subjected to decompressed integrity check based on the firmware header information; If the decompressed integrity check passes, the firmware to be upgraded is run in the App storage partition.

2. The method of claim 1, wherein, Further comprising: If the first device matching check does not pass, the upgrade invalid information is fed back, and the subsequent operation steps are no longer performed; Or, if the first compressed integrity check does not pass, the upgrade invalid information is fed back, and the subsequent operation steps are no longer performed; Or, if the second device matching check does not pass, the upgrade invalid information is fed back, and the subsequent operation steps are no longer performed; Or, if the second compressed integrity check does not pass, the upgrade invalid information is fed back, and the subsequent operation steps are no longer performed; If the decompressed integrity check does not pass, the decompression fails, and the firmware version rollback operation is performed.

3. The method according to claim 1 or 2, characterized in that, The firmware header information includes device type, vehicle-mounted controller chip identification code (ChipId) and a preset matching value, and correspondingly, the first device matching check on the compressed firmware data packet based on the firmware header information includes: The device type, the ChipId and the preset matching value are matched and checked; If the device type, the ChipId and the preset matching value are all checked, the first device matching check is passed; Correspondingly, the Bootloader storage partition performs second device matching check on the compressed firmware data packet in the target storage partition based on the firmware header information, including: The Bootloader storage partition performs matching check on the device type, the ChipId and the preset matching value; If the device type, the ChipId and the preset matching value are all checked, the second device matching check is passed.

4. The method of claim 3, wherein, The firmware header information also includes an original compressed firmware cyclic redundancy check value, and correspondingly, the first compressed integrity check is performed on the compressed firmware data packet based on the firmware header information and the compressed firmware data, including: The first compressed firmware cyclic redundancy check value is compared with the original compressed firmware cyclic redundancy check value; If the comparison result is consistent, the first compressed integrity check is passed; Correspondingly, the Bootloader storage partition performs second compressed integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data, including: The Bootloader storage partition calculates the second compressed firmware cyclic redundancy check value corresponding to the compressed firmware data based on the cyclic redundancy check algorithm and the ChipId; The second compressed firmware cyclic redundancy check value is compared with the original compressed firmware cyclic redundancy check value; If the comparison result is consistent, the second compressed integrity check is passed. The firmware header information also includes an original firmware cyclic redundancy check value, and correspondingly, the decompressed integrity check is performed on the decompressed firmware data, including:

5. The method of claim 4, wherein, The decompressed firmware cyclic redundancy check value is compared with the original firmware cyclic redundancy check value; If the comparison result is consistent, the decompressed integrity check is passed. Before receiving the compressed firmware data packet corresponding to the firmware to be upgraded, it further includes: The App storage partition and the Bootloader storage partition are read-protected; 6. The method of claim 1 or 2, wherein, And the Bootloader storage partition starts or stops the Joint Test Action Group (JTAG) interface through the Unified Diagnostic Services (UDS) protocol. It further includes: After the first time of programming power-on, if it is detected that there is no firmware in the App storage partition and no firmware in the off-chip storage area, the Bootloader storage partition receives initial compressed firmware data, and performs third compressed integrity check on the initial compressed firmware data, wherein the initial compressed firmware data is the compressed data corresponding to the initial firmware; 7. The method according to claim 1 or 2, characterized in that, ​ ​ If the third compression integrity check passes, the initial compressed firmware data is stored into an initial storage partition by using the Bootloader storage partition, and the initial storage partition is the first storage partition or the second storage partition.

8. An in-vehicle controller characterized by comprising: The vehicle-mounted controller comprises a processor and a memory, wherein the memory comprises an on-chip storage area and an off-chip storage area, the on-chip storage area comprises an application program (App) storage partition and a Bootloader storage partition, and the off-chip storage area comprises a first storage partition and a second storage partition; the processor is configured to execute the vehicle-mounted controller firmware upgrading method according to any one of claims 1-7 by invoking programs or instructions stored in the memory.

9. An in-vehicle controller firmware upgrade system, comprising: The system comprises the vehicle-mounted controller according to claim 8 and a server, and the system is configured to: The server acquires a vehicle-mounted controller firmware version, detects whether there is firmware to be upgraded, determines whether to upgrade the firmware, and sends firmware upgradable information to the vehicle-mounted controller if it is determined to upgrade the firmware; The vehicle-mounted controller receives the firmware upgradable information, sends a ChipId corresponding to the vehicle-mounted controller to the server; The server generates a compressed firmware data packet corresponding to the firmware to be upgraded based on the ChipId, and sends the compressed firmware data packet to the vehicle-mounted controller, wherein the compressed firmware data packet comprises firmware header information and compressed firmware data corresponding to the firmware to be upgraded; The vehicle-mounted controller performs a first device matching check on the compressed firmware data packet based on the firmware header information during the process of receiving the compressed firmware data packet; If the first device matching check passes, the vehicle-mounted controller receives the compressed firmware data packet, determines a target storage partition according to an off-chip storage partition flag, stores the compressed firmware data packet into the target storage partition, and performs a first compression integrity check on the compressed firmware data packet based on the firmware header information and the compressed firmware data, wherein the vehicle-mounted controller is provided with an on-chip storage area and an off-chip storage area, the target storage partition is the first storage partition or the second storage partition, the off-chip storage partitions corresponding to adjacent two storages are different, and the on-chip storage area further comprises a non-loss storage partition, which is configured to store an off-chip storage partition flag and an upgrading flag; If the first compression integrity check passes, the upgrading flag is set to mark that the firmware is to be upgraded, the off-chip storage partition flag is set to mark that the storage partition is not the target storage partition, the vehicle-mounted controller is restarted, and a second device matching check on the compressed firmware data packet in the target storage partition is performed based on the firmware header information by using the Bootloader storage partition; If the second device matching check passes, a second compression integrity check on the compressed firmware data packet is performed based on the firmware header information and the compressed firmware data by using the Bootloader storage partition; If the second compression integrity check passes, the initial compressed firmware data is stored into an initial storage partition by using the Bootloader storage partition, and the initial storage partition is the first storage partition or the second storage partition. If the second compression integrity check passes, the compressed firmware data is decompressed to an App storage partition by using the Bootloader storage partition to obtain decompressed firmware data, and the decompressed firmware data is subjected to decompression integrity check based on the firmware header information; If the decompression integrity check passes, the to-be-upgraded firmware is run in the App storage partition.

Images