Vehicle firmware upgrading method, vehicle machine system and vehicle

Abstract

The invention provides a vehicle firmware upgrading method, a vehicle machine system and a vehicle, and relates to the technical field of vehicles. And comparing the actual hash value of each module in the target partition with the expected hash value of each module in the new version firmware upgrade package, generating a to-be-updated list, determining a target flashing mode according to the number of the to-be-updated modules in the to-be-updated list, namely, deciding to adopt a differential flashing mode or a full flashing mode, and updating the to-be-updated module in the to-be-updated list according to the determined target flashing mode. The problem that the time consumption problem is relatively prominent when an A / B partition mechanism is adopted for overall flashing for a large firmware package is solved; firmware upgrading of the target partition is executed according to the target flashing mode, and after writing is verified successfully and the vehicle-mounted machine system is triggered to be started next time, the vehicle-mounted machine system is started from the target partition, so that the reliability and safety of the firmware upgrading process are ensured.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a vehicle firmware upgrade method, a vehicle computer system, and a vehicle. Background Art

[0002] Vehicle firmware upgrade refers to the process of updating vehicle system software or hardware firmware wirelessly or physically. It is one of the important technologies for the development of modern intelligent automobiles. By upgrading the vehicle system, performance can be optimized, vulnerabilities can be fixed, and safety and user experience can be improved.

[0003] Among the related technologies, the current mainstream firmware upgrade technology solution is mainly the A / B partition mechanism. This solution ensures the reliability and rollback capability of the upgrade process by performing the upgrade operation in an inactive partition (such as partition B) and switching to the boot partition after successful verification.

[0004] However, for large firmware packages, the overall flashing time of the A / B partition mechanism is more prominent. Summary of the Invention

[0005] The purpose of the present invention is to provide a vehicle firmware upgrade method, a vehicle system and a vehicle in order to solve the technical problems existing in the prior art in view of the above-mentioned deficiencies in the prior art.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of the present application are as follows: In a first aspect, an embodiment of the present application provides a vehicle firmware upgrade method, which is applied to a vehicle system, wherein the vehicle system includes: a microcontroller and a main controller, wherein the microcontroller and the main controller communicate using a serial peripheral interface, and the method includes: The microcontroller receives a new version firmware upgrade package issued by the main controller, wherein the new version firmware upgrade package includes: the new version firmware and the expected hash value of each module; If the new version firmware upgrade package passes the pre-verification, the microcontroller obtains the actual hash value of each module of the target partition on the microcontroller, generates a to-be-updated list according to the actual hash value of each module of the target partition and the expected hash value of each module in the new version firmware upgrade package, and filters out the firmware upgrade package of each to-be-updated module in the to-be-updated list from the new version firmware, wherein the to-be-updated list includes: at least one to-be-updated module; The microcontroller determines a target flashing mode according to the number of modules to be updated in the to-be-updated list; The microcontroller executes the firmware upgrade of the target partition according to the target flashing mode; The microcontroller performs module verification on the target partition. If the verification passes, it is determined that the writing is successful, and the vehicle system is started from the target partition when the vehicle system is triggered to start next time.

[0007] Optionally, generating a to-be-updated list according to actual hash values of modules of the target partition and expected hash values of modules in the new version firmware upgrade package includes: Traverse each module of the target partition and compare the actual hash value of the current module with the expected hash value of the corresponding module in the new version firmware upgrade package. If the comparison results are inconsistent, add the current module to the to-be-updated list until all modules of the target partition are traversed.

[0008] Optionally, determining the target flashing mode according to the number of modules to be updated in the update list includes: If the number of modules to be updated is equal to a preset threshold, determining the target flashing mode to be a full flashing mode; If the number of modules to be updated is less than a preset threshold, it is determined that the target flashing mode is a differential flashing mode.

[0009] Optionally, the microcontroller executes the firmware upgrade of the target partition according to the target flashing method, including: If the target flashing mode is the differential flashing mode, the area to be updated in the target partition is erased, and the firmware upgrade package of each module to be updated is written to the area to be updated, where the area to be updated is where the at least one module to be updated is located.

[0010] Optionally, performing module verification on the target partition includes: Perform module verification on each module written into the area to be updated.

[0011] Optionally, verifying each module written into the area to be updated includes: Determine the actual hash value of each module written into the area to be updated; Obtaining an expected hash value of each module in the new version firmware upgrade package pre-stored in a secure storage partition on the microcontroller; The actual hash value of each module written in the to-be-updated area is compared with the expected hash value of the corresponding module in the new version firmware upgrade package of the secure storage partition. If the comparison results are consistent, it is determined that the verification has passed.

[0012] Optionally, the microcontroller executes the firmware upgrade of the target partition according to the target flashing method, including: If the target flashing mode is a full flashing mode, the target partition is erased and the new version firmware upgrade package is written to the target partition.

[0013] Optionally, performing module verification on the target partition includes: Perform module verification on each module of the target partition.

[0014] Optionally, the pre-verification includes: digital signature verification and integrity verification; The pre-verification process includes: Obtaining a digital signature in the new version firmware upgrade package, where the digital signature is generated by encrypting a hash value of the new version firmware upgrade package using a private key by the publisher of the new version firmware upgrade package; Verify the digital signature in the new version of the firmware upgrade package. If the verification passes, determine the hash value of the new version of the firmware upgrade package, and compare the hash value of the new version of the firmware upgrade package with the accompanying hash value included in the new version of the firmware upgrade package. If the comparison results are consistent, determine that the new version of the firmware upgrade package passes the integrity verification.

[0015] Optionally, before the microcontroller receives the new version firmware upgrade package sent by the main controller, the process further includes: The microcontroller establishes a serial peripheral interface communication connection with the main controller; The main controller determines the transmission parameters between the microcontroller and the main controller by interacting with the microcontroller.

[0016] Optionally, the main controller determines the transmission parameters between the microcontroller and the main controller by interacting with the microcontroller, including: The main controller configures the initial transmission parameters of the serial peripheral interface; The main controller sends the initial transmission parameters to the microcontroller; The microcontroller sends data processing capability parameters of the microcontroller to the main controller, wherein the data processing capability parameters include at least: data processing speed, available bandwidth and current load status, and the transmission parameters include: data packet size and communication interval; The main controller adjusts the initial transmission parameters according to the data processing capability parameters to obtain the transmission parameters between the microcontroller and the main controller.

[0017] In a second aspect, an embodiment of the present application further provides a vehicle system, comprising: a microcontroller and a main controller; The vehicle system is used to execute the steps of the vehicle firmware upgrade method provided in the first aspect above.

[0018] In a third aspect, an embodiment of the present application further provides a vehicle, comprising the vehicle-mounted system provided in the second aspect above.

[0019] The beneficial effects of this application are: The present application provides a vehicle firmware upgrade method, a vehicle system, and a vehicle. The present application compares the actual hash value of each module of the target partition with the expected hash value of each module in the new version of the firmware upgrade package to generate a list to be updated. Then, based on the number of modules to be updated in the list to be updated, the target flashing method is determined, that is, whether to use the differential flashing method or the full flashing method is intelligently decided. This solves the problem that the overall flashing of a large firmware package using the A / B partition mechanism is time-consuming and has a prominent problem. This achieves the purpose of taking into account both efficiency and specific scenario requirements. The firmware upgrade of the target partition is performed according to the target flashing method. After the writing is completed, the module verification of the target partition is performed. If the verification is successful, it is determined that the writing is successful. The vehicle system is started from the target partition the next time the vehicle system is triggered to start, ensuring the reliability and security of the firmware upgrade process, preventing malicious tampering or flashing errors, and ensuring the stability and security of the vehicle system. Therefore, the vehicle firmware upgrade method provided by the present application solves the problems of low efficiency and poor security in traditional upgrade methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 A schematic structural diagram of a vehicle system provided in an embodiment of the present application; Figure 2 A flowchart of a vehicle firmware upgrade method provided in an embodiment of the present application; Figure 3 A flowchart of another vehicle firmware upgrade method provided in an embodiment of the present application; Figure 4 A flowchart of another vehicle firmware upgrade method provided in an embodiment of the present application; Figure 5 A flowchart of another vehicle firmware upgrade method provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application; Figure 7 A schematic structural diagram of a vehicle provided in an embodiment of the present application.

[0022] Icon: 100-vehicle system; 1-microcontroller; 2-main controller; 200-vehicle. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of illustration and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowcharts can be implemented out of sequence, and steps without logical context can be reversed or implemented simultaneously. In addition, those skilled in the art, under the guidance of the contents of this application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0024] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0025] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0026] First, before providing a detailed description of the technical solution provided in this application, a brief description of the relevant background involved in this application is given.

[0027] Among the related technologies, the current mainstream firmware upgrade technology solution is mainly the A / B partition mechanism. This solution ensures the reliability and rollback capability of the upgrade process by performing the upgrade operation in an inactive partition (such as partition B) and switching to the boot partition after successful verification.

[0028] However, for large firmware packages, the time-consuming problem of overall flashing using the A / B partition mechanism is more prominent. Both of the above update methods have certain limitations. For large firmware packages, the time-consuming problem of overall flashing using the A / B partition mechanism is more prominent. If the differential update method has a weak security mechanism and lacks redundancy, the system may become unstable or even unable to start when the upgrade fails or suffers a malicious attack.

[0029] In response to the technical problems existing in the relevant technologies, this application proposes a vehicle firmware upgrade method, which compares the actual hash value of each module of the target partition with the expected hash value of each module in the new version of the firmware upgrade package to generate a list to be updated. Then, based on the number of modules to be updated in the list to be updated, the target flashing method is determined, that is, an intelligent decision is made whether to use a differential flashing method or a full flashing method, which solves the problem that the overall flashing of a large firmware package using the A / B partition mechanism is time-consuming and achieves the purpose of taking into account both efficiency and specific scenario requirements; the firmware upgrade of the target partition is executed according to the target flashing method, and after the writing is completed, the module verification is performed on the target partition. If the verification is successful, it is determined that the writing is successful, and the next time the vehicle system is triggered to start, the vehicle system is started from the target partition, ensuring the reliability and security of the firmware upgrade process, preventing malicious tampering or flashing errors, and ensuring the stability and security of the vehicle system. Therefore, the vehicle firmware upgrade method provided by this application solves the problems of low efficiency and poor security in traditional upgrade methods.

[0030] Figure 1 This is a structural diagram of a vehicle system provided in an embodiment of the present application; the vehicle system includes: a microcontroller 1 and a main controller 2, wherein the microcontroller 1 and the main controller 2 are both processing devices with data processing functions.

[0031] A serial peripheral interface (SPI) communication connection is established between the microcontroller 1 and the main controller 2 .

[0032] Alternatively, in existing technologies, most vehicle microcontrollers and main controllers use CAN bus communication. However, these communication methods suffer from low transmission rates and small data packet capacity, resulting in a time-consuming and inefficient upgrade process. Although some vehicle systems are beginning to adopt SPI as a transmission medium, existing SPI transmission solutions mostly use fixed parameter settings and cannot adaptively adjust data packet size based on the actual communication environment and MCU processing capabilities. This can easily lead to transmission errors and long upgrade times in complex operating environments.

[0033] Therefore, to address this problem, the present application proposes that the main controller 2 can dynamically adjust the data packet size and transmission rate according to the data processing capability and real-time status parameters of the microcontroller 1. That is, the dynamic adjustment mechanism proposed in the present application can significantly improve the adaptability and stability of the vehicle system, while also speeding up the data transmission rate and improving the efficiency of vehicle firmware upgrades.

[0034] I understand. Figure 1The structure shown is for illustration only. The vehicle system terminal device may also include Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown. Figure 1 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0035] The vehicle firmware upgrade method provided by this application is applied to the above-mentioned Figure 1 The implementation principle of the vehicle system shown in the figure and the corresponding beneficial effects are explained.

[0036] Figure 2 A flow chart of a vehicle firmware upgrade method provided in an embodiment of the present application; optionally, the execution subject of the method may be the above Figure 1 It should be understood that in other embodiments, the order of some steps in the vehicle firmware upgrade method can be interchanged according to actual needs, or some steps can be omitted or deleted. Figure 2 As shown, the method includes: S201: The microcontroller receives a new version firmware upgrade package sent by the main controller.

[0037] The new version firmware upgrade package includes: the new version firmware and the expected hash value of each module.

[0038] The new version firmware is the new version firmware data that needs to be updated to the vehicle system. The new version firmware can be a set of sub-files divided according to the modules included in the vehicle system, and can be an operating system kernel, driver, application, etc.

[0039] The expected hash value of each module is used to uniquely identify the file content. By comparing the actual hash value of each module with the expected hash value, it is possible to verify whether each module is the module to be updated.

[0040] Optionally, the microcontroller can be divided into area A, area B and a secure storage area, that is, the expected hash value of each module can be encrypted (for example, using an AES algorithm), and the encrypted expected hash information can be stored in the secure storage partition.

[0041] In one feasible method, the vehicle system enters the Over-the-Air Upgrade (OTA) update process, and the main controller obtains the new version firmware upgrade package required for the vehicle system upgrade from the cloud and sends the new version firmware upgrade package to the microcontroller.

[0042] S202. If the new version firmware upgrade package passes the pre-verification, the microcontroller obtains the actual hash value of each module of the target partition on the microcontroller, generates a list to be updated based on the actual hash value of each module of the target partition and the expected hash value of each module in the new version firmware upgrade package, and filters out the firmware upgrade package of each module to be updated in the list to be updated from the new version firmware.

[0043] The to-be-updated list includes: at least one to-be-updated module.

[0044] Exemplarily, the target partition can be area A or area B. For example, when area A is the current active area and area B is the inactive area, area B can be used as the target partition. For another example, when area A is the inactive area and area B is the current active area, area A can be used as the target partition.

[0045] The pre-verification includes: digital signature verification and integrity verification, that is, verifying the new version of the firmware upgrade package to verify whether the downloaded new version of the firmware upgrade package is complete and has not been tampered with.

[0046] The specific process of pre-verification is as follows: obtaining the digital signature in the new version of the firmware upgrade package. The digital signature is generated by encrypting the hash value of the new version of the firmware upgrade package using the private key of the publisher of the new version of the firmware upgrade package; verifying the digital signature in the new version of the firmware upgrade package. If the signature is valid, it is determined that the new version of the firmware upgrade package was issued by a trusted source (such as the manufacturer's signature). Then, the integrity of the new version of the firmware upgrade package is verified, the hash value of the new version of the firmware upgrade package is calculated, and the hash value of the new version of the firmware upgrade package is compared with the accompanying hash value included in the new version of the firmware upgrade package. If the comparison results are consistent, it is determined that the new version of the firmware upgrade package is not lost or damaged.

[0047] In this embodiment, the microcontroller obtains the actual hash value of each module of the target partition on the microcontroller, obtains at least one module to be updated based on the actual hash value of each module of the target partition and the expected hash value of each module in the new version of the firmware upgrade package, and filters out the firmware upgrade package of each module to be updated from the new version of the firmware, that is, using the differential method, obtains at least one module to be updated in the target partition, avoids updating all modules in the target partition, and improves the efficiency of the firmware upgrade.

[0048] S203: The microcontroller determines a target flashing mode according to the number of modules to be updated in the to-be-updated list.

[0049] Optionally, in order to improve the efficiency of firmware upgrades, this application proposes that the target flashing method, that is, whether to use differential flashing or full flashing, can be intelligently determined based on the number of modules to be updated in the to-be-updated list. For example, if the number of modules to be updated is too large, a full flashing is used; if the number of modules to be updated is too small, a differential flashing is used. This significantly reduces the amount of data and time required for the upgrade, and solves the problem that the overall flashing of large firmware packages using the A / B partition mechanism is time-consuming, achieving the goal of balancing efficiency and specific scenario requirements. S204: The microcontroller executes the firmware upgrade of the target partition according to the target flashing method.

[0050] S205. The microcontroller performs module verification on the target partition. If the verification passes, it is determined that the writing is successful, and the vehicle system is started from the target partition the next time the vehicle system is triggered to start.

[0051] In one achievable approach, the microcontroller directly executes a firmware upgrade of the target partition according to the target flashing method, upgrading each module to be updated. After the update is complete, the target partition is verified. The verification process involves recalculating the actual hash value for each flashed submodule in the target partition, for example using the SHA256 algorithm. The encrypted expected hash value of each module is read from a secure storage partition and decrypted to obtain the expected hash value of each module. The expected hash value of each submodule is then compared with the calculated actual hash value one by one. If all the compared hash values are consistent, the target partition is deemed successfully flashed. The system then enters the system switching phase, atomically updating the bootloader's boot pointer information to point to the newly flashed target partition. This update operation must be atomic to prevent an update failure midway, preventing the system from being unable to select a boot partition. The successful upgrade status and new version information can also be recorded in the secure storage partition. The next time the vehicle system is triggered to boot, the vehicle system is booted from the target partition, completing the upgrade.

[0052] In another feasible method, if the actual hash value of a module is inconsistent with the expected hash value, the verification is determined to have failed, that is, the upgrade is determined to have failed. At this time, the Boot information of the vehicle system remains unchanged, and the vehicle system still starts from the original active partition (area A), and the upgrade failure status and cause are recorded in the secure storage partition to ensure the reliability and rollback capability of the upgrade process.

[0053] In summary, the embodiment of the present application provides a vehicle firmware upgrade method, which compares the actual hash value of each module of the target partition with the expected hash value of each module in the new version of the firmware upgrade package to generate a list to be updated. Then, based on the number of modules to be updated in the list to be updated, the target flashing method is determined, that is, whether to use the differential flashing method or the full flashing method is intelligently decided, which solves the problem that the overall flashing of a large firmware package using the A / B partition mechanism is time-consuming and has a prominent problem, thereby achieving the purpose of taking into account both efficiency and specific scenario requirements; the firmware upgrade of the target partition is executed according to the target flashing method, and after the writing is completed, the module verification is performed on the target partition. If the verification is successful, it is determined that the writing is successful, and the next time the vehicle system is triggered to start, the vehicle system is started from the target partition, ensuring the reliability and security of the firmware upgrade process, preventing malicious tampering or flashing errors, and ensuring the stability and security of the vehicle system. Therefore, the vehicle firmware upgrade method provided by the present application solves the problems of low efficiency and poor security in traditional upgrade methods.

[0054] Optionally, the following embodiments will be used to explain in detail how to use a differential method to determine at least one module to be updated.

[0055] Optionally, the above step S202 includes: Traverse each module of the target partition and compare the actual hash value of the current module with the expected hash value of the corresponding module in the new version of the firmware upgrade package. If the comparison results are inconsistent, add the current module to the list to be updated until all modules of the target partition are traversed.

[0056] In one feasible method, all modules of the target partition are traversed. For example, the current module traversed is module 3. The expected hash value of module 3 is found from the new version of the firmware upgrade package. Then, the actual hash value of module 3 is compared with the expected hash value. If the comparison result is consistent, the function of module 3 has not changed, that is, module 3 does not need to be upgraded; if the comparison result is inconsistent, the function of module 3 has changed, and module 3 needs to be upgraded, that is, module 3 is treated as a module to be updated and added to the list to be updated. Until all modules of the target partition are traversed, a list to be updated is generated.

[0057] Optionally, the above step S203 includes: If the number of modules to be updated is equal to the preset threshold, the target flashing mode is determined to be a full flashing mode; If the number of modules to be updated is less than a preset threshold, the target flashing mode is determined to be a differential flashing mode.

[0058] For example, the preset threshold is the number of all modules in the target partition. For example, if the number of all modules in the target partition is 10, the preset threshold is also 10.

[0059] In one feasible method, if the number of modules to be updated is equal to a preset threshold, that is, all modules in the target partition are modules to be updated, then the target flashing method is determined to be a full flashing method; if the number of modules to be updated is equal to a preset threshold, that is, some modules in the target partition are modules to be updated, then the target flashing method is determined to be a differential flashing method, that is, only some modules in the target partition need to be updated, thereby improving the firmware upgrade efficiency of the target partition and greatly reducing the time required for the upgrade, especially when the firmware changes are small.

[0060] Therefore, in this embodiment, by comparing the differences between the current firmware and the new version, a list of modules to be updated is generated. If the number of modules to be updated in the list is small, a differential flashing method is used; if the number of modules to be updated in the list is large, a direct full replacement is performed. This allows for a balance between efficiency and specific scenario requirements.

[0061] Optionally, the above step S204 includes: If the target flashing method is the differential flashing method, the area to be updated in the target partition is erased, that is, the target partition is partially erased, and the firmware upgrade package of each module to be updated is written to the area to be updated. The area to be updated is the area where at least one module to be updated is located.

[0062] In one feasible method, if the target flashing method is a differential flashing method, it is only necessary to erase the area to be updated in the target partition, wherein the area where each module to be updated is located is the area to be updated, and the firmware upgrade package of each module to be updated is written to the area to be updated, thereby improving the efficiency of the target partition firmware upgrade.

[0063] Optionally, the above step S205 includes: Perform module verification on each module written to the update area.

[0064] In this embodiment, it is only necessary to perform module verification on each module written to the area to be updated in the target partition, thereby improving the verification efficiency after flashing.

[0065] Optionally, refer to Figure 3 As shown, the above steps verify each module written to the update area, including: S301: Determine the actual hash value of each module written into the area to be updated.

[0066] Exemplarily, the SHA256 algorithm may be used to calculate the actual hash value of each module.

[0067] S302: Obtain the expected hash value of each module in the new version firmware upgrade package pre-stored in the secure storage partition on the microcontroller.

[0068] S303: Compare the actual hash value of each module written into the area to be updated with the expected hash value of the corresponding module in the new version firmware upgrade package of the secure storage partition. If the comparison results are consistent, it is determined that the verification is passed.

[0069] In this embodiment, only the modules written to the to-be-updated area of the target partition need to be verified. Specifically, the actual hash value of each module written to the to-be-updated area is recalculated, and the encrypted expected hash value of each module previously stored is read from the secure storage partition. The encrypted expected hash value of each module is decrypted to obtain the expected hash value of each module. The expected hash value of each module is then compared with the actual hash value one by one. If the comparison results of each module are consistent, it is determined that all modules written to the to-be-updated area have passed verification.

[0070] Optionally, the above step S204 includes: If the target flash mode is full flash mode, the target partition will be erased and the new version firmware upgrade package will be written to the target partition.

[0071] In one feasible method, if the target flash mode is the full flash mode, the target partition needs to be completely erased and the entire new version firmware upgrade package is directly written to the target partition, ensuring the reliability of the target partition firmware upgrade.

[0072] Optionally, perform module verification on the target partition, including: Perform module verification on each module of the target partition.

[0073] In this embodiment, since a full flashing method is used to upgrade the firmware of the target partition, it is necessary to perform module verification on all modules of the target partition. In this way, the accuracy of the verification result after the flashing can be ensured.

[0074] The following examples will explain in detail how to establish a serial peripheral interface communication connection between the microcontroller and the main controller.

[0075] Optionally, refer to Figure 4 As shown, before the above step S201, the following steps are also included: S401: The microcontroller establishes a serial peripheral interface communication connection with the main controller.

[0076] S402: The main controller determines the transmission parameters between the microcontroller and the main controller by interacting with the microcontroller.

[0077] In one feasible manner, in order to solve the problem that the CAN bus communication method is used between the microcontroller and the main controller on most vehicles in the existing technology, which has problems such as low transmission rate and small data packet capacity, resulting in a long and inefficient upgrade process, the present application proposes to establish a serial peripheral interface communication connection between the microcontroller and the main controller, and the main controller dynamically adjusts the transmission parameters between the microcontroller and the main controller, namely the data packet size and transmission rate, based on the real-time monitoring of the microcontroller's data processing capabilities and real-time status parameters (such as load fluctuations, network status changes), thereby improving the adaptability and stability of the vehicle system, avoiding transmission errors or inefficiencies caused by fixed parameters in complex working environments, and improving the efficiency of vehicle firmware upgrades.

[0078] The following embodiments will explain in detail how to dynamically adjust the transmission parameters between the microcontroller and the main controller.

[0079] Optionally, refer to Figure 5 As shown, the above step S402 includes: S501: The main controller configures initial transmission parameters of the serial peripheral interface.

[0080] Exemplarily, an SPI communication connection is established between the main controller and the microprocessor, and initial transmission parameters of the SPI are configured, such as a baud rate fixed at 9.6 MHz, a mode of CPOL=0, CPHA=0, and a data bit of 8 bits.

[0081] S502: The main controller sends initial transmission parameters to the microcontroller.

[0082] Optionally, the master controller confirms the ready state of the microprocessor through an SPI synchronization frame, and the microprocessor returns current state information through a status byte; then, the master controller determines initial transmission parameters based on the current state information returned by the microprocessor, such as the data packet size (maximum 4096 bytes) and the communication interval (at least greater than or equal to 1ms).

[0083] The synchronization frame format is as follows: HeadCode: 0xA5 (1 byte), Cmd: 0xFFFF (2 bytes), Length: 0x0000 (2 bytes).

[0084] The microprocessor returns the current status information through the status byte, including: Status: Contains status bits such as READY, ERR, and STATUS; Flag: contains flags such as MCUOTA; Response: single-byte reply; Deal_Length: The length of data that the slave needs to process; Checksum: Checksum.

[0085] S503: The microcontroller sends the data processing capability parameter of the microcontroller to the main controller.

[0086] The data processing capability parameters include at least: data processing speed, available bandwidth and current load status; the transmission parameters include: data packet size and communication interval.

[0087] S504: The main controller adjusts the initial transmission parameters according to the data processing capability parameters to obtain the transmission parameters between the microcontroller and the main controller.

[0088] In one feasible approach, the master controller divides the new version firmware upgrade package into multiple logical segments, each containing multiple data packets. The master controller sends the data packet of the first logical segment through the SPI instruction frame according to the determined initial transmission parameters. The master controller monitors the data processing capability parameters for each data packet returned by the microcontroller, and dynamically adjusts the size (in the range of 256-4096 bytes) and communication interval of subsequent data packets. At the same time, the SPI baud rate remains fixed. After each logical segment is transmitted, segment-level data integrity verification is performed. After the verification is passed, a rollback point is set at the key node, and the next logical segment is transmitted. If the verification fails, the master controller rolls back to the last successful rollback point and retransmits.

[0089] Therefore, in this embodiment, since the processing capability of the microcontroller may change over time (such as load fluctuations, changes in network conditions, etc.), the main controller needs to periodically re-evaluate the data processing capability of the microcontroller and adjust the transmission parameters accordingly. This dynamic adjustment mechanism can significantly improve the adaptability and stability of the vehicle system.

[0090] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present application, which may be integrated with the above Figure 1 The main controller or microprocessor in the vehicle system shown in FIG. 1 may be a computing device with data processing capabilities.

[0091] The electronic device includes: a processor 601 and a memory 602 .

[0092] The memory 602 is used to store programs, and the processor 601 calls the programs stored in the memory 602 to execute the above method embodiment. The specific implementation method and technical effects are similar and will not be repeated here.

[0093] Optionally, Figure 7 This is a structural diagram of a vehicle provided in an embodiment of the present application. The vehicle 200 includes: the vehicle system 100 provided in the above embodiment.

[0094] Optionally, the present invention further provides a program product, such as a computer-readable storage medium, comprising a program, which is used to perform the above method embodiment when executed by a processor.

[0095] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0096] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0097] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional units.

[0098] The aforementioned integrated unit implemented as a software functional unit can be stored in a computer-readable storage medium. The software functional unit, stored in a storage medium, includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) or a processor to execute portions of the method steps described in various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a removable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

Claims

1. A vehicle firmware upgrade method, characterized in that: Applied to a vehicle system, the vehicle system includes: a microcontroller and a main controller, the microcontroller and the main controller communicate using a serial peripheral interface, and the method includes: The microcontroller receives a new version firmware upgrade package issued by the main controller, wherein the new version firmware upgrade package includes: the new version firmware and the expected hash value of each module; If the new version firmware upgrade package passes the pre-verification, the microcontroller obtains the actual hash value of each module of the target partition on the microcontroller, generates a to-be-updated list according to the actual hash value of each module of the target partition and the expected hash value of each module in the new version firmware upgrade package, and filters out the firmware upgrade package of each to-be-updated module in the to-be-updated list from the new version firmware, wherein the to-be-updated list includes: at least one to-be-updated module; The microcontroller determines a target flashing mode according to the number of modules to be updated in the to-be-updated list; The microcontroller executes the firmware upgrade of the target partition according to the target flashing mode; The microcontroller performs module verification on the target partition. If the verification passes, it is determined that the writing is successful, and the vehicle system is started from the target partition when the vehicle system is triggered to start next time.

2. The method according to claim 1, characterized in that The step of generating a to-be-updated list according to the actual hash value of each module of the target partition and the expected hash value of each module in the new version firmware upgrade package includes: Traverse each module of the target partition and compare the actual hash value of the current module with the expected hash value of the corresponding module in the new version firmware upgrade package. If the comparison results are inconsistent, add the current module to the to-be-updated list until all modules of the target partition are traversed.

3. The method according to claim 1, characterized in that The step of determining a target flashing mode according to the number of modules to be updated in the update list includes: If the number of modules to be updated is equal to a preset threshold, determining the target flashing mode to be a full flashing mode; If the number of modules to be updated is less than a preset threshold, it is determined that the target flashing mode is a differential flashing mode.

4. The method according to claim 3, characterized in that The microcontroller executes the firmware upgrade of the target partition according to the target flashing mode, including: If the target flashing mode is the differential flashing mode, the area to be updated in the target partition is erased, and the firmware upgrade package of each module to be updated is written to the area to be updated, where the area to be updated is where the at least one module to be updated is located.

5. The method according to claim 4, characterized in that The performing module verification on the target partition includes: Perform module verification on each module written into the area to be updated.

6. The method according to claim 5, characterized in that The verifying of each module written in the area to be updated includes: Determine the actual hash value of each module written into the area to be updated; Obtaining an expected hash value of each module in the new version firmware upgrade package pre-stored in a secure storage partition on the microcontroller; The actual hash value of each module written in the to-be-updated area is compared with the expected hash value of the corresponding module in the new version firmware upgrade package of the secure storage partition. If the comparison results are consistent, it is determined that the verification has passed.

7. The method according to any one of claims 1 to 6, characterized in that Before the microcontroller receives the new version firmware upgrade package issued by the main controller, the method further includes: The microcontroller establishes a serial peripheral interface communication connection with the main controller; The main controller determines the transmission parameters between the microcontroller and the main controller by interacting with the microcontroller.

8. The method according to claim 7, characterized in that The main controller determines the transmission parameters between the microcontroller and the main controller by interacting with the microcontroller, including: The main controller configures the initial transmission parameters of the serial peripheral interface; The main controller sends the initial transmission parameters to the microcontroller; The microcontroller sends data processing capability parameters of the microcontroller to the main controller, wherein the data processing capability parameters include at least: data processing speed, available bandwidth and current load status, and the transmission parameters include: data packet size and communication interval; The main controller adjusts the initial transmission parameters according to the data processing capability parameters to obtain the transmission parameters between the microcontroller and the main controller.

9. A vehicle computer system, characterized in that: include: Microcontroller and main controller; The vehicle system is used to execute the vehicle firmware upgrade method steps described in any one of claims 1 to 8 above.

10. A vehicle, characterized in that: Including the vehicle system according to claim 9.

Images