A method and system for coordinated upgrade

Abstract

The application relates to the technical field of firmware upgrading, and discloses a cooperative upgrading method and system, the method is applied to a coprocessor, the coprocessor comprises a microcontroller and a system on chip, and the method comprises the following steps: receiving an initial composite upgrading package; performing first verification processing on the initial composite upgrading package to obtain a first target composite upgrading package; after performing version upgrading on the system on chip based on first upgrading data in the first target composite upgrading package, sending the first target composite upgrading package to the microcontroller; performing second verification processing on the first target composite upgrading package to obtain a second target composite upgrading package; and performing version upgrading on the microcontroller based on second upgrading data in the second target composite upgrading package. The cooperative upgrading method realizes strong binding of firmware upgrading versions of the system on chip and the microcontroller by constructing a composite upgrading package, eliminates the risk of software mismatch caused by asynchronous package, greatly improves upgrading efficiency, and simultaneously considers safety and reliability.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, and in particular to a collaborative upgrade method and system. Background Technology

[0002] In existing coprocessors, the System-on-Chip (SOC) and the Microcontroller Unit (MCU) typically handle different levels of functional division. Current mainstream upgrade solutions employ a decoupled dual-package upgrade approach, which involves building separate firmware packages for the SOC and MCU, and distributing and flashing them through independent channels in a time-sharing and step-by-step manner. This approach has significant drawbacks: the two firmware packages lack a strong version correlation mechanism, making them susceptible to human error, oversights in the release process, or inconsistent gray-scale strategies. This can result in the MCU running version 2.1 while the SOC has already been upgraded to version 3.0, failing to guarantee software compatibility between the MCU and SOC, and also leading to slow upgrade efficiency. Summary of the Invention

[0003] In view of this, embodiments of this application provide a collaborative upgrade method and system, which can effectively improve the problems of easy software compatibility errors and slow efficiency in coprocessor upgrades.

[0004] In a first aspect, embodiments of this application provide a collaborative upgrade method applied to a coprocessor, the coprocessor including a microcontroller and a system-on-a-chip, the method comprising: Receive an initial composite upgrade package, the initial composite upgrade package including first upgrade data and second upgrade data; The initial composite upgrade package is subjected to a first verification process to obtain a first target composite upgrade package that has passed verification. After upgrading the system-on-a-chip based on the first upgrade data in the first target composite upgrade package, the first target composite upgrade package is sent to the microcontroller. The first target composite upgrade package is subjected to a second verification process to obtain a second target composite upgrade package that has passed verification. The microcontroller is upgraded based on the second upgrade data in the second target composite upgrade package.

[0005] In a first possible embodiment of the first aspect, the initial composite upgrade package further includes an overall verification field, the first upgrade data includes a first data type field and a first verification code, and the first verification process of the initial composite upgrade package includes: The initial composite upgrade package is subjected to overall verification based on the overall verification field to obtain an initial composite upgrade package that passes the overall verification. Based on the first data type field, the initial composite upgrade package that has passed the overall verification is validated for data type to obtain an initial composite upgrade package that conforms to the first preset data type. Based on the first verification code, the initial composite upgrade package conforming to the first preset data type is subjected to redundancy verification to obtain the first target composite upgrade package that passes the redundancy verification.

[0006] In a second possible embodiment of the first aspect, the overall verification field includes an overall signature field and an overall verification code field, and the overall verification of the initial composite upgrade package based on the overall verification field includes: Compare the overall signature field with the calculated initial composite upgrade package signature; Compare the overall checksum field with the calculated initial composite upgrade package checksum; If the overall signature field is the same as the initial composite upgrade package signature, and the overall verification code field is the same as the initial composite upgrade package verification code, then the initial composite upgrade package is determined to have passed the overall verification.

[0007] In a third possible embodiment of the first aspect, the second upgrade data includes a second data type field and a second verification code, and the second verification process for the first target composite upgrade package includes: Based on the second data type field, the data type of the first target composite upgrade package is validated to obtain a first target composite upgrade package that conforms to the second preset data type. Based on the second check code, the first target composite upgrade package that conforms to the second preset data type is subjected to redundancy verification to obtain the second target composite upgrade package that passes the redundancy verification.

[0008] In a fourth possible embodiment of the first aspect, the redundancy check of the initial composite upgrade package conforming to the first preset data type based on the first check code includes: The first check code is compared with the calculated first upgrade data check code. If the first check code and the first upgrade data check code are the same, the initial composite upgrade package is determined to have passed the redundancy check. If the first check code is different from the first upgrade data check code, it is determined that the initial composite upgrade package has failed the redundancy check. The redundancy check of the first target composite upgrade package conforming to the second preset data type based on the second check code includes: The second check code is compared with the calculated second upgrade data check code. If the second check code and the second upgrade data check code are the same, the first target composite upgrade package is determined to have passed the redundancy check. If the second check code is different from the second upgrade data check code, it is determined that the first target composite upgrade package has failed the redundancy check.

[0009] In a fifth possible embodiment of the first aspect, the system-on-chip is connected to a first memory, and the version upgrade of the system-on-chip based on the first upgrade data in the first target composite upgrade package includes: Delete the original upgrade data stored in the first memory, write the first upgrade data into the first memory, and enable the on-chip system to run based on the first upgrade data; The microcontroller is connected to a second memory, and the version upgrade of the microcontroller based on the second upgrade data in the second target composite upgrade package includes: The original upgrade data stored in the second memory is deleted, and the second upgrade data is written into the second memory, so that the microcontroller runs based on the second upgrade data.

[0010] In a sixth possible embodiment of the first aspect, it further includes: If the initial composite upgrade package fails the first verification process, or if the first target composite upgrade package fails the second verification process, an upgrade failure message is output. Once the microcontroller has completed the version upgrade, it will output an upgrade success message.

[0011] Secondly, embodiments of this application provide a collaborative upgrade system, including: a coprocessor, the coprocessor including a microcontroller and a system-on-a-chip; The coprocessor is used to perform the above-described collaborative upgrade method to upgrade the microcontroller and the system-on-a-chip.

[0012] In a first possible embodiment of the second aspect, it further includes: an upgrade tool, wherein the coprocessor is connected to the upgrade tool; The upgrade tool is used to send an initial composite upgrade package to the coprocessor.

[0013] In a second possible embodiment of the second aspect, the system-on-chip is connected to a first memory, and the microcontroller is connected to a second memory; The first memory is used to store the first upgrade data of the on-chip system; The second memory is used to store the second upgrade data of the microcontroller.

[0014] The embodiments of this application have the following beneficial effects: This embodiment presents a collaborative upgrade method applied to a coprocessor, which includes a microcontroller and a system-on-a-chip (SoC). The method includes: sending an initial composite upgrade package to the SoC, the initial composite upgrade package including first upgrade data and second upgrade data; performing a first verification process on the initial composite upgrade package to obtain a verified first target composite upgrade package; upgrading the SoC based on the first upgrade data in the first target composite upgrade package, and then sending the first target composite upgrade package to the microcontroller; performing a second verification process on the first target composite upgrade package to obtain a verified second target composite upgrade package; and upgrading the microcontroller based on the second upgrade data in the second target composite upgrade package. Based on the above scheme, this collaborative upgrade method, by constructing a composite upgrade package, achieves strong binding between the firmware upgrade versions of the SoC and the MCU, fundamentally eliminating the risk of software incompatibility caused by asynchronous package splitting. Furthermore, it enables the SoC and MCU to be upgraded synchronously to the same version, greatly improving upgrade efficiency. Before upgrading the SoC and MCU, the composite upgrade package is verified to ensure that each stage of the upgrade is based on a reliable composite upgrade package, balancing security and reliability. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of a first structural embodiment of the collaborative upgrade system of this application is shown; Figure 2 A second structural schematic diagram of the collaborative upgrade system according to an embodiment of this application is shown; Figure 3 This paper illustrates a first flowchart of the collaborative upgrade method according to an embodiment of the present application. Figure 4 A second flowchart of the collaborative upgrade method according to an embodiment of this application is shown; Figure 5 A timing diagram illustrating the collaborative upgrade of the system-on-a-chip and the microcontroller according to an embodiment of this application is shown.

[0017] Explanation of key component symbols: 100 - Collaborative upgrade system; 110 - Coprocessor; 111 - Microcontroller; 1111 - Secondary memory; 112 - System-on-a-chip; 1121 - Primary memory; 120 - Upgrade tool. Detailed Implementation

[0018] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0023] First, this application provides a collaborative upgrade system 100. Please refer to... Figure 1 This is a structural block diagram of the collaborative upgrade system 100 provided in this application embodiment. The collaborative upgrade system 100 may include a coprocessor 110, which includes a microcontroller 111 and a system-on-a-chip 112.

[0024] Exemplarily, the coprocessor 110 includes, but is not limited to, a computing power coprocessor, an in-vehicle dedicated coprocessor, an audio / video coprocessor, etc. In one embodiment, the coprocessor 110 can process information and / or data related to the collaborative upgrade method to perform one or more functions described in this application. For example, the coprocessor 110 can send an initial composite upgrade package to the system-on-a-chip 112, the initial composite upgrade package including first upgrade data and second upgrade data; perform a first verification process on the initial composite upgrade package to obtain a verified first target composite upgrade package; upgrade the system-on-a-chip 112 based on the first upgrade data in the first target composite upgrade package, and then send the first target composite upgrade package to the microcontroller 111; perform a second verification process on the first target composite upgrade package to obtain a verified second target composite upgrade package; and upgrade the microcontroller 111 based on the second upgrade data in the second target composite upgrade package. This enables the microcontroller 111 and the system-on-a-chip 112 to be upgraded to the same version synchronously, making the software versions of the microcontroller 111 and the system-on-a-chip 112 compatible and greatly improving upgrade efficiency.

[0025] In one embodiment, the microcontroller 111 is connected to the system-on-a-chip 112 via an SPI communication interface, which enables the system-on-a-chip 112 to forward the first target composite upgrade package to the microcontroller 111 via the SPI communication interface after performing a version upgrade based on the first upgrade data.

[0026] In this embodiment, traditional upgrade schemes require sending upgrade packages corresponding to microcontroller 111 and system-on-a-chip 112 separately via the CAN bus. Since the algorithm software on the microcontroller 111 requires a higher speed for upgrades, the CAN bus communication speed is limited, easily leading to upgrade failure. Because the SPI interface has hardware chip select and synchronous clock mechanisms, it offers strong deterministic transmission and a low error rate, ensuring the integrity and reliability of the upgrade package and providing a highly reliable physical channel for the secure upgrade of the microcontroller 111.

[0027] In one embodiment, such as Figure 2 As shown, the collaborative upgrade system 100 further includes an upgrade tool 120. A coprocessor 110 is connected to the upgrade tool 120, and the upgrade tool 120 is used to send an initial composite upgrade package to the coprocessor 110. In this embodiment, the upgrade tool 120 generates the initial composite upgrade package and sends it to the system-on-a-chip 112 in the coprocessor 110, thereby enabling the system-on-a-chip 112 to perform a version upgrade based on the first upgrade data in the composite upgrade package.

[0028] As an example, the upgrade tool 120 communicates with the system-on-a-chip 112 via Ethernet. When the coprocessor 110 is deployed on an automotive-grade ECU (Electronic Control Unit) with an Ethernet interface, the upgrade tool 120 establishes a reliable connection with the system-on-a-chip 112 via 100 Mbps or 1 Gbps Ethernet to complete the transmission of the initial composite upgrade package, saving transmission time.

[0029] In another embodiment, the system-on-chip 112 is connected to a first memory 1121, and the microcontroller 111 is connected to a second memory 1111; the first memory 1121 is used to store first upgrade data of the system-on-chip 112; and the second memory 1111 is used to store second upgrade data of the microcontroller 111.

[0030] In this embodiment, the first memory 1121 connected to the system-on-a-chip 112 is used to store the first upgrade data, supports high-speed random read and write of the first upgrade data, and ensures that the system-on-a-chip 112 subsequently runs based on the first upgrade data, thereby completing the version upgrade of the system-on-a-chip 112. The second memory 1111 connected to the microcontroller 111 is used to store the second upgrade data, supports high-speed random read and write of the second upgrade data, and ensures that the microcontroller 111 subsequently runs based on the second upgrade data, thereby completing the version upgrade of the microcontroller 111.

[0031] For example, the first memory 1121 can be an internal or external storage medium of the system-on-chip 112, and the second memory 1111 can be an internal or external storage medium of the microcontroller 111. For example, the memory can be set as non-volatile memory (Flash). Storing upgrade data in the memory can prevent accidental flashing or malicious tampering and ensure the reliability of version upgrades for the system-on-chip 112 and the microcontroller 111.

[0032] For ease of understanding, the following embodiments of this application will be described in terms of... Figure 1 and Figure 2 Taking the collaborative upgrade system 100 shown as an example, and in conjunction with the accompanying drawings, the collaborative upgrade method provided in this application embodiment will be described.

[0033] The following examples illustrate the collaborative upgrade method.

[0034] Figure 3 A flowchart of a collaborative upgrade method according to an embodiment of this application is shown. Exemplarily, this collaborative upgrade method is applied to a coprocessor 110 and includes the following steps: S210, Receive the initial composite upgrade package, which includes first upgrade data and second upgrade data.

[0035] Exemplarily, the initial composite upgrade package includes system firmware, application programs, and configuration data for upgraded versions of the system-on-chip 112 and the microcontroller 111. The first upgrade data is the system firmware, application programs, and configuration data specifically for the upgraded version of the system-on-chip 112 in the initial composite upgrade package, and the second upgrade data is the system firmware, application programs, and configuration data specifically for the upgraded version of the microcontroller 111 in the initial composite upgrade package.

[0036] In this embodiment, by uniformly encapsulating the upgrade data of the same version of the system-on-chip 112 and the microcontroller 111 into an initial composite upgrade package, the risk of version mismatch caused by package upgrade is completely eliminated, the transmission and execution efficiency is improved, and the protocol mismatch or function degradation caused by asynchronous upgrade is avoided.

[0037] S220, the initial composite upgrade package is subjected to the first verification process to obtain the first target composite upgrade package that has passed the verification.

[0038] Exemplary, the initial composite upgrade package also includes an overall verification field. In addition to valid data specifically for the System-on-Chip 112 upgrade, the first upgrade data also includes a first data type field and a first checksum. The overall verification field is a structured security verification field embedded in the header or footer of the initial composite upgrade package. The first data type field identifies the format or type of the first upgrade data, helping to quickly determine whether the first upgrade data is in a valid and expected format. The first checksum is a pre-calculated check value for the first upgrade data using a cyclic redundancy check algorithm.

[0039] In one embodiment, such as Figure 4 As shown, the first verification process includes the following steps: S221, Perform overall verification on the initial composite upgrade package based on the overall verification field to obtain an initial composite upgrade package that passes the overall verification.

[0040] For example, the overall verification field includes an overall signature field and an overall checksum field. The overall signature field is a digital signature value calculated from the entire binary content of the initial composite upgrade package using an asymmetric cryptographic algorithm (such as ECDSA-secp256r1 or RSA-PSS), generated by the private key in the trusted key pair. The overall checksum field is a hash value calculated from the original byte stream of the initial composite upgrade package using a Cyclic Redundancy Check (CRC) algorithm.

[0041] In one embodiment, the overall signature field is compared with the calculated initial composite upgrade package signature, and the overall verification code field is compared with the calculated initial composite upgrade package verification code. If both the overall signature field and the initial composite upgrade package signature are identical, and both the overall verification code field and the initial composite upgrade package verification code are identical, the initial composite upgrade package is determined to have passed the overall verification.

[0042] In this embodiment, after receiving the initial composite upgrade packet, its embedded overall verification field is first parsed to separate the overall signature field and the overall checksum field. Then, two independent verifications are performed: The initial composite upgrade packet signature is recalculated using an asymmetric cryptographic algorithm, and the consistency between the initial composite upgrade packet signature and the overall signature field is compared. If they match, the initial composite upgrade packet has not been tampered with. Simultaneously, the initial composite upgrade packet checksum is recalculated using a cyclic redundancy check algorithm, and the consistency between the initial composite upgrade packet checksum and the overall checksum field is compared. If they match, the initial composite upgrade packet has not been damaged during storage or transmission. Verification is considered successful only when both results are consistent.

[0043] In another embodiment, if the overall signature field is different from the initial composite upgrade package signature, or if the overall verification code field is different from the initial composite upgrade package verification code, it is determined that the initial composite upgrade package has failed the overall verification.

[0044] In this embodiment, verification based on the overall signature field ensures that the initial composite upgrade package has not been tampered with and originates from a trusted party, while verification based on the overall checksum field ensures the data integrity during the transmission / storage of the initial composite upgrade package. The two methods work together to complete a global trust determination of the initial composite upgrade package before the upgrade, significantly improving the security of firmware upgrades and preventing upgrade anomalies caused by malicious injection or corrupted packages.

[0045] S222, perform data type verification on the initial composite upgrade package that has passed the overall verification based on the first data type field to obtain an initial composite upgrade package that conforms to the first preset data type.

[0046] In this embodiment, the first preset data type is a legally valid upgrade data type that is strictly limited for the upgrade of the on-chip system 112. By comparing whether the first preset data type is the same as the first data type field, it is determined whether the first upgrade data meets the type data required for the upgrade of the on-chip system 112. If the first preset data type is not the same as the first data type field, the first upgrade data does not meet the data type required by the on-chip system 112, and the on-chip system 112 is not upgraded. If the first preset data type is the same as the first data type field, the first upgrade data meets the data type required by the on-chip system 112, and the on-chip system 112 can be upgraded based on the first upgrade data. This ensures that only upgrade data matching the first preset data type can enter the upgrade process, which can resist logical vulnerabilities where attackers forge type fields to bypass verification, and significantly improve upgrade compatibility and security.

[0047] S223, Based on the first check code, perform redundancy verification on the initial composite upgrade package that conforms to the first preset data type to obtain the first target composite upgrade package that passes the redundancy verification.

[0048] In one embodiment, the first check code is compared with the calculated first upgrade data check code. If the first check code and the first upgrade data check code are the same, the initial composite upgrade package is determined to have passed the redundancy check; if the first check code and the first upgrade data check code are different, the initial composite upgrade package is determined to have failed the redundancy check.

[0049] In this embodiment, the received first upgrade data is calculated using the same method as the first checksum calculation to obtain the first upgrade data checksum, which is then compared with the first checksum in real time. If they match, it is confirmed that the first upgrade data has not been tampered with or damaged, and a reliable first target composite upgrade package is generated. This significantly improves the integrity assurance capability of critical data segments in the firmware upgrade of the System-on-Chip 112, preventing transmission errors and tampering.

[0050] S230: After upgrading the system-on-chip 112 based on the first upgrade data in the first target composite upgrade package, the first target composite upgrade package is sent to the microcontroller 111.

[0051] As an example, the system-on-a-chip 112 is connected to a first memory 1121, which is the final destination for writing the first upgrade data, which is the upgrade data for a new version of the system-on-a-chip 112. The system-on-a-chip 112 only retrieves the first upgrade data from the first memory 1121 after the upgrade is completed, and operates based on the first upgrade data, thereby improving the upgrade efficiency of the system-on-a-chip 112.

[0052] In one embodiment, the original upgrade data stored in the first memory 1121 is deleted, and the first upgrade data is written into the first memory 1121, enabling the system-on-chip 112 to run based on the first upgrade data. In this embodiment, the upgrade is completed by erasing the old version data and writing the new version upgrade data. The first upgrade data in the first target composite upgrade package is directly written into the first memory 1121 directly connected to the system-on-chip 112, and the old version data is completely erased before writing. The system-on-chip 112 only loads and runs the new version from the first memory 1121 after the verification is passed and the first upgrade data is written, avoiding upgrade interruption that would cause the system-on-chip 112 to become unbootable, and significantly improving the upgrade reliability, real-time performance, and storage resource utilization of the system-on-chip 112.

[0053] In another implementation, the upgrade is performed in a queuing manner, upgrading the system-on-chip 112 first and then the microcontroller 111. If the upgrade of the system-on-chip 112 fails, the microcontroller 111 remains unchanged, and the coprocessor 110 continues to run its current version. Conversely, if the upgrade fails, the coprocessor 110 may become unavailable, significantly enhancing the reliability of multi-chip collaborative upgrades. After the system-on-chip 112 completes its upgrade, it can forward the first target composite upgrade package to the microcontroller 111, enabling the microcontroller 111 to perform a version upgrade using the first target composite upgrade package.

[0054] S240, the first target composite upgrade package is subjected to a second verification process to obtain a verified second target composite upgrade package.

[0055] Exemplary, the second upgrade data includes a second data type field and a second check code. In one embodiment, the data type of the first target composite upgrade package is checked based on the second data type field to obtain a first target composite upgrade package that conforms to the second preset data type.

[0056] For example, the second data type field is used to identify the format or type of the second upgrade data, helping to quickly identify whether the second upgrade data is in a legal and expected format. The second preset data type is a legal upgrade data type that is strictly limited by the microcontroller 111 upgrade.

[0057] In this embodiment, by comparing whether the second preset data type is the same as the second data type field, it is determined whether the second upgrade data meets the type data required for the microcontroller 111 upgrade. If the second preset data type is different from the second data type field, the upgrade data does not meet the data type required by the microcontroller 111, and the microcontroller 111 is not upgraded. If the second preset data type is the same as the second data type field, the second upgrade data meets the data type required by the microcontroller 111, and the microcontroller 111 can be upgraded based on the second upgrade data. This ensures that only upgrade data matching the second preset data type can enter the microcontroller 111 upgrade process, resisting logical vulnerabilities where attackers forge type fields to bypass verification, and significantly improving upgrade compatibility, security, and system stability.

[0058] In another embodiment, a redundancy check is performed on the first target composite upgrade package conforming to a second preset data type based on a second check code, resulting in a second target composite upgrade package that passes the redundancy check. In this embodiment, the second check code is a check value pre-calculated on the second upgrade data using a cyclic redundancy check algorithm. By introducing a second check code to perform redundancy check on the first target composite upgrade package, accurate integrity verification at the data semantic level is achieved, improving verification efficiency and upgrade reliability.

[0059] In one embodiment, the second check code is compared with the calculated second upgrade field check code. If the second check code and the second upgrade field check code are the same, the first target composite upgrade package is determined to have passed the redundancy check; if the second check code field and the second upgrade data check code are different, the first target composite upgrade package is determined to have failed the redundancy check.

[0060] In this embodiment, the received second upgrade data is calculated using the same method as the second checksum, resulting in a second upgrade data checksum. This checksum is then compared with the second checksum in real time. If they match, it confirms that the second upgrade data has not been tampered with or corrupted, generating a reliable second target composite upgrade package. This significantly improves the integrity assurance capability of critical data segments during microcontroller 111 firmware upgrades, preventing transmission errors and selective tampering.

[0061] S250, performs a version upgrade on microcontroller 111 based on the second upgrade data in the second target composite upgrade package.

[0062] As an example, microcontroller 111 is connected to a second memory 1111, which serves as the final destination for writing the second upgrade data, which is the upgrade data for a new version of microcontroller 111. Microcontroller 111 only retrieves the second upgrade data from the second memory 1111 after the upgrade is complete and operates based on the second upgrade data, thereby improving the upgrade efficiency of microcontroller 111.

[0063] In one embodiment, the original upgrade data stored in the second memory 1111 is deleted, and the second upgrade data is written into the second memory 1111, enabling the microcontroller 111 to run based on the second upgrade data. In this embodiment, the microcontroller 111 upgrade is completed by erasing the old version data and writing the new version upgrade data. The second upgrade data in the second target composite upgrade package is directly written into the second memory 1111 directly connected to the microcontroller 111, and the old version data is completely erased before writing. The microcontroller 111 only loads and runs the new version from the second memory 1111 after the verification is passed and the second upgrade data is written, avoiding upgrade interruption that would cause the microcontroller 111 to become unbootable, and significantly improving the reliability, real-time performance, and storage resource utilization of the microcontroller 111 upgrade.

[0064] In one embodiment, if the initial composite upgrade package fails the first verification process, or if the first target composite upgrade package fails the second verification process, an upgrade failure message is output.

[0065] Exemplary verification includes the overall verification, data type verification, and redundancy verification of the initial composite upgrade package described above. If at least one of the above verifications fails, the initial composite upgrade package fails the first verification process. The second verification includes the data type verification and redundancy verification of the first target composite upgrade package described above. If at least one of the above verifications fails, the first target composite upgrade package fails the second verification process.

[0066] In this embodiment, upgrade failure information is triggered only when the initial composite upgrade package fails the first verification or the first target composite upgrade package after preliminary screening fails the second verification, so as to prevent defective packages from entering the subsequent parsing or writing process. In another embodiment, an upgrade success message is output after the microcontroller 111 completes the version upgrade. In this embodiment, the version upgrade is strictly performed in the order of upgrading the system-on-chip 112 first and then the microcontroller 111, with the completion of the version upgrade by the microcontroller 111 itself being the sole trigger condition for confirming the upgrade success, thus achieving accurate confirmation of the completion of the coprocessor 110 upgrade.

[0067] In one implementation, such as Figure 5 The diagram shows the timing sequence for the collaborative upgrade of the System-on-Chip 112 and the microcontroller 111. First, during the preparation and transmission phase, the upgrade tool 120 sends an initial composite upgrade packet to the System-on-Chip 112 via Ethernet. After overall verification of the initial composite upgrade packet, if verification fails, a verification failure message is returned to the upgrade tool 120, along with an error code, at which point the upgrade terminates. If verification is successful, a successful reception message for the initial composite upgrade packet is returned to the upgrade tool 120.

[0068] Then, during the SOC upgrade phase, data type verification and redundancy verification are performed on the first upgrade data. If the verification fails, an upgrade failure message is returned to the upgrade tool 120. If the verification succeeds, a verification success message is returned to the upgrade tool 120. At this time, the on-chip system 112 writes the first upgrade data to the first memory 1121 and restarts the system to start the new firmware.

[0069] Finally, during the MCU upgrade phase, data type verification and redundancy verification are performed on the second upgrade data. If the verification fails, an upgrade failure message is returned to the upgrade tool 120. If the verification succeeds, a verification success message is returned to the upgrade tool 120. At this time, the microcontroller 111 writes the second upgrade data to the second memory 1111 and restarts the system to start the new firmware.

[0070] This application also provides a coprocessor 110, which, exemplary, includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the coprocessor 110 to perform the above-described coprocessing method.

[0071] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0072] Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Memory is used to store computer programs, and the processor can execute these programs upon receiving execution instructions.

[0073] This application also provides a computer-readable storage medium for storing the computer program used in the coprocessor 110 described above. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0074] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that, as an alternative implementation, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0075] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0076] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0077] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A collaborative upgrade method, characterized in that, Applied to a coprocessor, the coprocessor including a microcontroller and a system-on-a-chip, the method includes: Receive an initial composite upgrade package, the initial composite upgrade package including first upgrade data and second upgrade data; The initial composite upgrade package is subjected to a first verification process to obtain a first target composite upgrade package that has passed verification. After upgrading the system-on-a-chip based on the first upgrade data in the first target composite upgrade package, the first target composite upgrade package is sent to the microcontroller. The first target composite upgrade package is subjected to a second verification process to obtain a second target composite upgrade package that has passed verification. The microcontroller is upgraded based on the second upgrade data in the second target composite upgrade package.

2. The collaborative upgrade method according to claim 1, characterized in that, The initial composite upgrade package further includes an overall verification field, the first upgrade data includes a first data type field and a first verification code, and the first verification process of the initial composite upgrade package includes: The initial composite upgrade package is subjected to overall verification based on the overall verification field to obtain an initial composite upgrade package that passes the overall verification. Based on the first data type field, the initial composite upgrade package that has passed the overall verification is validated for data type to obtain an initial composite upgrade package that conforms to the first preset data type. Based on the first verification code, the initial composite upgrade package conforming to the first preset data type is subjected to redundancy verification to obtain the first target composite upgrade package that passes the redundancy verification.

3. The collaborative upgrade method according to claim 2, characterized in that, The overall verification field includes an overall signature field and an overall verification code field. The overall verification of the initial composite upgrade package based on the overall verification field includes: Compare the overall signature field with the calculated initial composite upgrade package signature; Compare the overall checksum field with the calculated initial composite upgrade package checksum; If the overall signature field is the same as the initial composite upgrade package signature, and the overall verification code field is the same as the initial composite upgrade package verification code, then the initial composite upgrade package is determined to have passed the overall verification.

4. The collaborative upgrade method according to claim 2, characterized in that, The second upgrade data includes a second data type field and a second verification code. The second verification process for the first target composite upgrade package includes: Based on the second data type field, the data type of the first target composite upgrade package is validated to obtain a first target composite upgrade package that conforms to the second preset data type. Based on the second check code, the first target composite upgrade package that conforms to the second preset data type is subjected to redundancy verification to obtain the second target composite upgrade package that passes the redundancy verification.

5. The collaborative upgrade method according to claim 4, characterized in that, The redundancy check of the initial composite upgrade package conforming to the first preset data type based on the first check code includes: The first check code is compared with the calculated first upgrade data check code. If the first check code and the first upgrade data check code are the same, the initial composite upgrade package is determined to have passed the redundancy check. If the first check code is different from the first upgrade data check code, it is determined that the initial composite upgrade package has failed the redundancy check. The redundancy check of the first target composite upgrade package conforming to the second preset data type based on the second check code includes: The second check code is compared with the calculated second upgrade data check code. If the second check code and the second upgrade data check code are the same, the first target composite upgrade package is determined to have passed the redundancy check. If the second check code is different from the second upgrade data check code, it is determined that the first target composite upgrade package has failed the redundancy check.

6. The collaborative upgrade method according to claim 1, characterized in that, The on-chip system is connected to a first memory, and the version upgrade of the on-chip system based on the first upgrade data in the first target composite upgrade package includes: Delete the original upgrade data stored in the first memory, write the first upgrade data into the first memory, and enable the on-chip system to run based on the first upgrade data; The microcontroller is connected to a second memory, and the version upgrade of the microcontroller based on the second upgrade data in the second target composite upgrade package includes: The original upgrade data stored in the second memory is deleted, and the second upgrade data is written into the second memory, so that the microcontroller runs based on the second upgrade data.

7. The collaborative upgrade method according to claim 1, characterized in that, Also includes: If the initial composite upgrade package fails the first verification process, or if the first target composite upgrade package fails the second verification process, an upgrade failure message is output. Once the microcontroller has completed the version upgrade, it will output an upgrade success message.

8. A collaborative upgrade system, characterized in that, include: The coprocessor includes a microcontroller and a system-on-a-chip; The coprocessor is used to perform a version upgrade of the microcontroller and the system-on-a-chip by executing the collaborative upgrade method as described in any one of claims 1-7.

9. The collaborative upgrade system according to claim 8, characterized in that, Also includes: Upgrade tool, wherein the coprocessor is connected to the upgrade tool; The upgrade tool is used to send an initial composite upgrade package to the coprocessor.

10. The collaborative upgrade system according to claim 8, characterized in that, The system-on-a-chip is connected to the first memory, and the microcontroller is connected to the second memory; The first memory is used to store the first upgrade data of the on-chip system; The second memory is used to store the second upgrade data of the microcontroller.

Images