A method and system for transmitting MCU firmware upgrade

Abstract

The present invention relates to the technical field of computer data processing, and in particular to an upgrade method and system for transmitting MCU firmware. The method comprises the following steps: obtaining firmware file data in an upgrade source device, and performing fragmentation packaging to obtain a standardized firmware file fragmentation data set; forwarding the standardized firmware file fragmentation data set to a target MCU device in real time, and performing unpacking processing to obtain a received fragmentation unpacking data set; performing integrity check on the received fragmentation unpacking data set, if the integrity check is successful, then generating successfully received fragmentation unpacking data, if the integrity check fails, then performing data retransmission to generate repaired received fragmentation unpacking data. The present invention ensures that the firmware upgrade process is efficient, safe and reliable through firmware fragmentation packaging, real-time transmission, integrity check and data repair mechanisms, and reduces the risk of data loss and transmission delay.

Description

Technical Field

[0001] The present invention relates to the technical field of computer data processing, and in particular to an upgrade method and system for transmitting MCU firmware. Background Art

[0002] In the traditional firmware upgrade process, complex protocol stacks are usually required to handle data transmission. These protocol stacks include but are not limited to TCP / IP (Transmission Control Protocol), FTP (File Transfer Protocol), and HTTP (Hypertext Transfer Protocol). They often require high bandwidth and long transmission time. Especially when processing large data packets, the complexity of the protocol stack becomes the main bottleneck. Since traditional MCU firmware upgrades rely on transmission protocols based on serial or parallel communication, data packet loss and errors are inevitable, especially in wireless networks or long-distance communication scenarios, the reliability of data transmission cannot be guaranteed. For large file data transmission such as firmware files, packet loss is particularly serious, which will cause the entire firmware file to fail to transfer or the file to be damaged. Although existing MCU firmware upgrade methods usually perform basic verification of data, most systems lack effective data encryption and security verification mechanisms. During the transmission of firmware files, if there is no strong encryption measure, firmware data can be easily tampered with or stolen maliciously. Summary of the invention

[0003] Based on this, it is necessary for the present invention to provide an upgrade method and system for transmitting MCU firmware to solve at least one of the above technical problems.

[0004] To achieve the above object, a method for transmitting an upgrade of MCU firmware includes the following steps: Step S1: Obtain the firmware file data in the upgrade source device, and perform segmentation and packaging to obtain a standardized firmware file segmentation data set; Step S2: forwarding the standardized firmware file segment data set to the target MCU device in real time, and performing unpacking processing to obtain a received segment unpacking data set; Step S3: Perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, successfully received fragmented unpacked data is generated; if the integrity check fails, data is retransmitted to generate repaired received fragmented unpacked data; Step S4: recombining the successfully received segment unpacked data and the repaired received segment unpacked data to obtain complete received firmware file data; Step S5: Perform integrity verification on the completely received firmware file data using the MD5 message digest algorithm to obtain firmware file verification result data; Step S6: Perform an MCU device firmware upgrade based on the firmware file verification result data to obtain MCU device firmware upgrade feedback data.

[0005] The present invention can effectively reduce the problems of data loss and transmission delay in traditional transmission protocols by slicing and packaging firmware file data and forwarding them in real time, and ensure that data is optimized during the reception and unpacking process of the target MCU device. Through real-time integrity verification and data retransmission mechanism, the reliability of data transmission can be improved, especially in an environment with packet loss and errors, avoiding the failure or damage of firmware transmission caused by packet loss or errors in traditional methods. In addition, the MD5 message digest algorithm is used to verify the firmware file, which not only ensures that the file is not tampered with during the transmission process, but also enhances the security of data transmission, and effectively prevents the risk of malicious tampering or theft. In this way, not only the efficiency of the firmware upgrade process is improved, but also the security and data integrity of the system are strengthened, making the firmware upgrade process more stable and reliable.

[0006] Preferably, the present invention further provides an upgrade system for transmitting MCU firmware, which is used to execute the above-mentioned upgrade method for transmitting MCU firmware, and the upgrade system for transmitting MCU firmware includes: The firmware fragment packaging module is used to obtain the firmware file data in the upgrade source device and perform fragment packaging to obtain a standardized firmware file fragment data set; The firmware transmission and unpacking module is used to forward the standardized firmware file segment data set to the target MCU device in real time and perform unpacking processing to obtain the received segment unpacking data set; The data integrity check and repair module is used to perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, the successfully received fragmented unpacked data is generated. If the integrity check fails, the data is retransmitted to generate and repair the received fragmented unpacked data. The fragment data reassembly module is used to reassemble the successfully received fragment unpacked data and the repaired received fragment unpacked data to obtain the complete received firmware file data; The integrity verification and check module is used to verify the integrity of the completely received firmware file data through the MD5 message digest algorithm to obtain the firmware file verification result data; The firmware upgrade and feedback module is used to upgrade the MCU device firmware based on the firmware file verification result data and obtain the MCU device firmware upgrade feedback data.

[0007] The present invention ensures that the firmware data can be efficiently and safely transmitted by slicing and packaging the firmware file. The standardized firmware file slicing data set makes the data processing process more standardized and reduces the complexity and potential errors in the transmission. Through real-time forwarding and unpacking processing, the efficient transmission and reception of the firmware slicing data is ensured, and the possibility of delay and transmission failure is reduced. This module can ensure that the target MCU device accurately receives the firmware data and correctly unpacks it. By performing integrity check on the received data, the correctness of the data during the transmission process is ensured. If an error or packet loss is detected, the system will automatically trigger the data retransmission mechanism for repair, avoiding the failure of the firmware upgrade due to data errors, thereby improving the success rate and reliability of the upgrade. By reorganizing the successfully received and repaired slicing data, it is ensured that the complete firmware file data is accurately reconstructed. This module ensures that even if problems are encountered during the transmission process, the complete data can be effectively restored, and the stability of data reorganization is improved. The firmware file is verified by the MD5 message digest algorithm to ensure that the firmware data has not been tampered with or damaged. This module increases the security of the firmware upgrade process and avoids system failures caused by malicious tampering or transmission errors. Firmware upgrade operations are performed based on the integrity verification results to ensure that the target MCU device receives the verified complete firmware and successfully upgrades. By providing firmware upgrade feedback data, the system can promptly feedback the results of the upgrade process, ensuring that users can obtain the upgrade status in a timely manner, and improving the transparency and success rate of the overall upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments thereof made with reference to the following drawings: Figure 1 A schematic diagram of the steps of the upgrade method for transmitting MCU firmware according to the present invention; Figure 2 for Figure 1 Detailed step flow diagram of step S1; Figure 3 for Figure 1 Detailed step flow chart of step S2 in FIG. DETAILED DESCRIPTION

[0009] The technical method of the present invention is described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by technicians in this field without creative work are within the scope of protection of the present invention.

[0010] In addition, the accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor methods and / or microcontroller methods.

[0011] It should be understood that, although the terms "first", "second", etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are used only to distinguish one unit from another unit. For example, without departing from the scope of the exemplary embodiments, the first unit may be referred to as the second unit, and similarly the second unit may be referred to as the first unit. The term "and / or" used herein includes any and all combinations of one or more of the listed associated items.

[0012] To achieve this, please refer to Figures 1 to 3 The present invention provides an upgrade method for transmitting MCU firmware, the method comprising the following steps: Step S1: Obtain the firmware file data in the upgrade source device, and perform segmentation and packaging to obtain a standardized firmware file segmentation data set; Step S2: forwarding the standardized firmware file segment data set to the target MCU device in real time, and performing unpacking processing to obtain a received segment unpacking data set; Step S3: Perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, successfully received fragmented unpacked data is generated; if the integrity check fails, data is retransmitted to generate repaired received fragmented unpacked data; Step S4: recombining the successfully received segment unpacked data and the repaired received segment unpacked data to obtain complete received firmware file data; Step S5: Perform integrity verification on the completely received firmware file data using the MD5 message digest algorithm to obtain firmware file verification result data; Step S6: Perform an MCU device firmware upgrade based on the firmware file verification result data to obtain MCU device firmware upgrade feedback data.

[0013] In the embodiment of the present invention, reference Figure 1 FIG. 1 is a schematic diagram of a step flow chart of an upgrade method for transmitting MCU firmware according to the present invention. In this example, the upgrade method for transmitting MCU firmware includes the following steps: Step S1: Obtain the firmware file data in the upgrade source device, and perform segmentation and packaging to obtain a standardized firmware file segmentation data set; The embodiment of the present invention firstly uses a file reading tool to directly extract complete firmware file data from an upgrade source device, performs operations according to a fixed file path or storage location during reading, and loads the file content in a binary stream manner to ensure data integrity; then, performs data segmentation operations on the extracted firmware file data according to a predetermined slicing standard, and the slicing size is strictly set to 30 bytes per slice, ensuring that there is no information missing in the file header, data area, and file tail during the slicing operation; then, adds a fixed slicing number field, a slicing control field, and a slicing check field to each slicing data, the slicing number is sequentially marked from 1 in an increasing integer manner, the slicing control field is used to indicate the logical position and purpose of the slicing, and the check field is generated by a CRC A001 algorithm and bound to the slicing data; after completing the slicing process, uses a slicing combination algorithm to arrange all slicing data in sequence according to the numbers, and generates a slicing index table at the same time, the index table records the numbers, data start and end positions, and check values ​​of all slicings, to ensure accurate positioning and verification in subsequent operations; finally, the generated slicing data and slicing index table are uniformly stored as a standardized firmware file slicing data set.

[0014] Step S2: forwarding the standardized firmware file segment data set to the target MCU device in real time, and performing unpacking processing to obtain a received segment unpacking data set; The embodiment of the present invention first extracts slice data and a slice index table from a slice data set of a standardized firmware file, loads the slice data into a sending buffer of an XMOS transparent transmission device, and the transparent transmission device establishes a stable data communication connection with a target MCU device through an HID protocol; then, the multi-core parallel processing function of the transparent transmission device is used to send the slice data in sequence according to the slice numbering sequence, and when sending, a frame header field and a frame tail field of the transmission protocol are added to each slice to identify the start and end of the slice data, and a transmission timestamp is embedded in the frame header field so that the receiving end can perform transmission delay calculation; after the target MCU device receives the slice data through a serial communication interface, it writes it into a local receiving buffer, and triggers an unpacking operation after receiving a complete slice, and the unpacking operation is performed by a verification module of the target MCU device, and the verification module first removes the frame header field and the frame tail field of the received slice data to extract the core data part; then, the verification module uses CRC The A001 algorithm verifies the extracted data part and compares the verification result with the verification field attached to the shard. If the verification passes, the unpacked shard data is stored in the unpacked data storage area, and the shard receiving status table is updated, which records the receiving status and verification result of each shard. If the verification fails, the shard is marked as an error state and waits for the retransmission mechanism to be processed in the subsequent steps. When all shard data are unpacked, a received shard unpacked data set is generated, and the valid data in the unpacked data storage area is organized into a structured format.

[0015] Step S3: Perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, successfully received fragmented unpacked data is generated; if the integrity check fails, data is retransmitted to generate repaired received fragmented unpacked data; The embodiment of the present invention first extracts the slice data one by one from the received slice unpacking data set, and reads sequentially according to the slice number during the extraction process to ensure that all slices are processed; the extracted slice data is loaded into the verification buffer by the verification module of the target MCU device, and then the core part of each slice data is calculated using the CRC A001 verification algorithm to generate a real-time verification value; the real-time verification value is compared with the verification field attached to the slice data one by one, and if the verification value is consistent, the slice data is marked as a verification success state and stored in the successfully received slice data storage area, and the slice verification state table is updated at the same time, which is used to record the number, verification result and storage location of each slice; if the real-time verification value is inconsistent with the verification field attached to the slice, the slice data is marked as a verification failure state and written into the list of slices to be retransmitted, which records all slices that have not passed the verification by number; then, the target MCU device sends a retransmission request to the upgrade source device through the communication interface. The retransmission request contains the fragment number in the list of fragments to be retransmitted and the specific request information. The upgraded source device resends the specified fragment data according to the request. After the retransmitted data arrives at the target MCU device, it is stored in the verification buffer and the CRC verification is re-performed. For the retransmitted fragments that have successfully been verified, the fragment status is updated according to the processing logic of the successfully verified fragments and stored in the successfully received fragment data storage area. After completing the verification of all fragment data, the data in the successfully received fragment data storage area is compared with the fragment status table in the original received fragment unpacking data set. After confirming that the verification of all fragment status is successful, the repaired received fragment unpacking data is generated and stored in the repaired fragment data storage area.

[0016] Step S4: recombining the successfully received segment unpacked data and the repaired received segment unpacked data to obtain complete received firmware file data; The embodiment of the present invention firstly extracts all the fragment data from the storage area of ​​the successfully received fragment unpacked data and the repaired received fragment unpacked data, and reads them in the order of increasing fragment numbers during extraction to ensure the sequential consistency of the fragment data during the reassembly process; after the extraction is completed, the fragment data is loaded into the fragment reassembly buffer of the target MCU device, and a reassembly status table is created, which records the number, data start and end positions and data content status of each fragment; then, the target MCU device splices all the fragment data in the fragment reassembly buffer, and during splicing, the data part of each fragment is connected one by one in the order of number, and the control field and the check field in the fragment are removed, and only the data field is retained. According to the content; during the splicing process, if the numbering is discontinuous, the missing fragment data is located according to the reorganization state table, and the retransmission process is triggered. The missing fragments are added to the buffer through the previous steps and then the splicing is continued; after the splicing of all fragment data is completed, the length of the spliced ​​data file is verified, and the length of the actual splicing result is compared with the expected file length. If the file lengths are consistent, the splicing result is marked as complete receiving firmware file data and stored in the complete file storage area; if the file lengths are inconsistent, the above process is repeated, the fragment integrity in the reorganization state table is checked and the data splicing operation is re-executed until the complete receiving firmware file data with matching length is generated.

[0017] Step S5: Perform integrity verification on the completely received firmware file data using the MD5 message digest algorithm to obtain firmware file verification result data; The embodiment of the present invention first extracts the binary content of the firmware file from the complete received firmware file data, and loads it into the message digest calculation module of the target MCU device, which supports the standard MD5 digest calculation algorithm; then, the message digest calculation module divides the extracted binary content into blocks according to a fixed block size (for example, every 512 bytes), and the data sequence of each block is not allowed to be interrupted to ensure the consistency of data processing; for each block, the MD5 calculation logic performs compression function calculation and bit operation on the data block one by one, and performs multiple rounds of iterations on the initial message digest value (fixed to 128 bits) and the block data, and finally generates an MD5 digest value of a fixed length; after completing all After the digest of the block data is calculated, the intermediate results of all the blocks are merged into the MD5 digest value of the complete firmware file; then, the generated MD5 digest value is compared bit by bit with the original firmware MD5 digest value provided by the upgrade source device. The comparison operation is performed by the comparison module of the target MCU device, and the two digest values ​​are analyzed byte by byte to see if they are completely consistent; if the comparison results are consistent, the firmware file verification result data is output and written into the verification result storage area; if the comparison results are inconsistent, a verification failure flag is generated, and a rollback mechanism is triggered to prevent the erroneous firmware file from affecting the MCU device; finally, the firmware file verification result data is used as the input of step S6 to indicate whether the subsequent firmware upgrade process can continue.

[0018] Step S6: Perform an MCU device firmware upgrade based on the firmware file verification result data to obtain MCU device firmware upgrade feedback data.

[0019] In the embodiment of the present invention, first, the verification status is extracted from the firmware file verification result data generated in step S5, and if the verification status is passed, the firmware upgrade process is started; the firmware upgrade process is executed by the upgrade control module of the target MCU device, and first the current running status of the MCU device is checked, and the MCU device is confirmed to be in the firmware upgrade permission mode through the hardware monitoring module to ensure that the upgrade process will not be interfered with by external tasks; then, the upgrade control module loads the complete received firmware file data generated in step S4 into the upgrade buffer, and initializes the memory partition of the MCU device, empties the specified firmware storage area and locks the backup storage area to prevent accidental writing; then, the upgrade control module writes the complete received firmware file data step by step into the firmware storage area according to the partition scheme, and the write operation adopts a segmented verification method. After each data segment is written, the CRC is checked. The A001 verification algorithm verifies whether the data is correctly stored in the target address. After the verification is passed, the next data segment is written until all data is burned. After the burning is completed, the upgrade control module performs an integrity check on the target firmware storage area and generates a firmware burning status report based on the verification result of the burning. If the report shows that the burning is successful, the firmware operating environment configuration module is started to adjust the operating parameters of the MCU device, including setting the boot loading address, updating the boot program flag, and reinitializing the system resources. Subsequently, the upgrade control module triggers the firmware activation operation, enters the trial operation mode by loading the new firmware code, and uses the hardware monitoring module to verify the running status of the new firmware. After the trial operation is successful, the upgrade control module generates the MCU device firmware upgrade feedback data and writes it to the feedback storage area to record the detailed process and result status of the upgrade. If the trial operation fails, the rollback process is started to restore the original firmware in the backup storage area to ensure system stability. Finally, the MCU device firmware upgrade feedback data is used as a summary of the entire firmware upgrade process to indicate the completion status and running results of the upgrade.

[0020] The present invention can effectively reduce the problems of data loss and transmission delay in traditional transmission protocols by slicing and packaging firmware file data and forwarding them in real time, and ensure that data is optimized during the reception and unpacking process of the target MCU device. Through real-time integrity verification and data retransmission mechanism, the reliability of data transmission can be improved, especially in an environment with packet loss and errors, avoiding the failure or damage of firmware transmission caused by packet loss or errors in traditional methods. In addition, the MD5 message digest algorithm is used to verify the firmware file, which not only ensures that the file is not tampered with during the transmission process, but also enhances the security of data transmission, and effectively prevents the risk of malicious tampering or theft. In this way, not only the efficiency of the firmware upgrade process is improved, but also the security and data integrity of the system are strengthened, making the firmware upgrade process more stable and reliable.

[0021] Preferably, step S1 comprises the following steps: Step S11: Obtain the firmware file data in the upgrade source device, and perform logical division to obtain a sliced ​​pre-processed firmware file data set; Step S12: performing data marking and standardization processing on the slice pre-processed firmware file data set to obtain a standardized slice marked data set; Step S13: encapsulate the standardized sliced ​​label data set to obtain a standardized firmware file sliced ​​data set.

[0022] As an embodiment of the present invention, refer to Figure 2 As shown, Figure 1 Detailed step flow diagram of step S1 in the embodiment of the present invention, step S1 includes the following steps: Step S11: Obtain the firmware file data in the upgrade source device, and perform logical division to obtain a sliced ​​pre-processed firmware file data set; The embodiment of the present invention firstly extracts firmware file data from a specified storage path of an upgrade source device through a file reading module, and the path adopts a fixed format, for example, accessed through an absolute path address or a configured file storage directory; the extraction process adopts a binary stream reading method to ensure that the read firmware file data is completely consistent with the source file data; after the reading is completed, the file parsing module parses the extracted firmware file data, extracts the file header information, data content and file tail identifier, and preliminarily divides the file data according to a predetermined logical slicing rule; the logical slicing rule is based on the total size of the firmware file and the slicing capacity. The specific implementation method is to take the total number of bytes of file data modulo the slice capacity. For example, if the capacity of each slice is set to 30 bytes, the file is divided into several slices according to the number of bytes. Each slice is strictly controlled within the set capacity to ensure that there is no data overlap or omission between slices. For each slice, the file parsing module extracts the starting address and ending address of the slice and records them in the slice index table. The slice index table includes the slice number, the start and end positions of the slice data, and the length of the slice data. After completing the logical slice, all the slice data and the slice index table are stored in the slice preprocessing buffer to form a slice preprocessing firmware file data set.

[0023] Step S12: performing data marking and standardization processing on the slice pre-processed firmware file data set to obtain a standardized slice marked data set; The embodiment of the present invention first extracts slice data and slice index tables one by one from the slice preprocessing firmware file data set, and each extraction operation is performed in the ascending order of the slice number to ensure the sequential consistency of data processing; after extraction, the marking module adds a slice number field to each slice data, and the slice number is identified by a continuous integer value, and each number corresponds to a unique slice data; then, the marking module adds a version number field to each slice data, and the version number field is generated by the overall version information of the firmware file, and the consistency is ensured by comparing it with the version number record provided by the upgrade source device; then, the marking module adds a check field to each slice data, and the check field is verified by CRC. The A001 algorithm is used for calculation and generation. During the calculation process, a cyclic redundancy check is performed on each byte of the shard data content, and the check result is stored in 16-bit hexadecimal format. After the shard data is marked, the standardization processing module verifies and verifies all marked data, confirms that the marking information matches the index table content of the shard data, and checks the byte alignment format of the shard data to ensure that the shard data conforms to the standard format of the transmission protocol. After the verification is completed, the standardization processing module recombines each shard data with the corresponding marking information, and updates the shard index table. The entries in the index table increase the starting position and data length of the marking information. Finally, all the marked and verified shard data and the updated index table are stored in the standardized data buffer to form a standardized shard marking data set.

[0024] Step S13: encapsulate the standardized sliced ​​label data set to obtain a standardized firmware file sliced ​​data set.

[0025] The embodiment of the present invention first extracts the slice data and its marking information one by one from the standardized slice marking data set, and each extraction operation is performed in the ascending order of the slice number to ensure the logical consistency of the data; after the extraction is completed, the encapsulation module adds the frame header and frame tail fields of the transmission protocol to each slice data, wherein the frame header field is fixed to a 16-bit binary value "0x55AA" for identifying the starting position of each slice data, and the frame tail field is fixed to a 16-bit binary value "0xAA55" for identifying the ending position of each slice data; after the frame header field, the encapsulation module sequentially adds the slice number, version number, data length and check field, wherein the slice number and version number are directly read from the slice marking information, the data length is generated by calculating the number of bytes of the slice data, and the check field is generated by CRC of the slice data and the marking information. The A001 verification algorithm is recalculated and generated; then, the encapsulation module appends the core content of the slice data to the above fields, and adjusts the order of the data in strict accordance with the byte alignment requirements specified in the protocol to ensure that the encapsulated slice data meets the transmission protocol specifications; after completing the encapsulation of each slice data, the slice index table is updated, and the frame header field position, frame tail field position and the total length of the encapsulated data are added to the index table; the encapsulated slice data and the updated index table are stored in the standardized slice data buffer to form a standardized firmware file slice data set.

[0026] The present invention ensures the efficiency and consistency of firmware files during transmission by logically dividing, data marking, standardizing and encapsulating firmware files. By logically dividing and preprocessing firmware files, it is possible to avoid problems such as files being too large or packetization problems occurring during transmission, laying the foundation for subsequent data marking and standardization processing, thereby improving the organization and controllability of data transmission. Data marking and standardization processing enable each data fragment to have a clear identification and a consistent format, which helps the target device to quickly and accurately parse and receive data, and reduces transmission failures or data confusion caused by inconsistent formats or incorrect identification. The final encapsulation process ensures the integrity and consistency of the fragmented data, making the firmware files easier to manage and process during transmission, further improving transmission efficiency and reliability.

[0027] Preferably, step S2 comprises the following steps: Step S21: encrypt and package the standardized firmware file segment data set and send it to the XMOS device, perform message digest, and obtain firmware file upgrade message header data; Step S22: Based on the firmware file upgrade message header data, the standardized firmware file segment data set is forwarded to the target MCU device in real time by using the transparent transmission protocol to obtain transparent transmission real-time forwarding data; Step S23: performing protocol analysis on the transparent real-time forwarding data, and extracting the fragmented data to obtain a parsed fragmented data set; Step S24: Separate the fragmentation mark from the data content based on the parsed fragmentation data set to obtain a received fragmentation unpacked data set.

[0028] As an embodiment of the present invention, refer to Figure 3 As shown, Figure 1 Detailed step flow diagram of step S2 in the embodiment of the present invention, step S2 includes the following steps: Step S21: encrypt and package the standardized firmware file segment data set and send it to the XMOS device, perform message digest, and obtain firmware file upgrade message header data; In the embodiment of the present invention, first, the slice data and its corresponding tag information are extracted from the standardized firmware file slice data set, and these data are loaded into the encryption module; the encryption module performs an encryption operation on the slice data through the RSA encryption algorithm, and the specific implementation method is to use the public key pre-stored in the target MCU device to encrypt the slice data byte by byte to generate encrypted slice data, and then reassemble the encrypted data to form an encrypted slice data set; during the encryption process, the public key used is determined by reading the device unique identifier from the XMOS device and calculating its hash value, so as to ensure the uniqueness and security of the encryption process; after the encryption is completed, the message digest module performs MD5 message digest calculation on the encrypted slice data set, and converts each byte of the slice data into a byte. The compression function of the MD5 algorithm is input into each part one by one, and multiple rounds of iterative calculation are performed to finally generate a 128-bit message digest value of fixed length; then, the message digest module uses the generated message digest value as the firmware file upgrade message header data, and combines it with the encrypted fragmented data set to form encrypted packaged data; after the packaging is completed, the encrypted packaged data is transmitted to the XMOS device through the communication interface module. During the transmission process, the communication interface module uses the HID protocol for data encapsulation, adds the frame header, frame footer and check field of the communication protocol, and ensures that the data can maintain integrity when transmitted to the XMOS device; finally, the XMOS device verifies the received encrypted packaged data, and stores it in the transparent transmission buffer after confirming that the data is correct.

[0029] Step S22: Based on the firmware file upgrade message header data, the standardized firmware file segment data set is forwarded to the target MCU device in real time by using the transparent transmission protocol to obtain transparent transmission real-time forwarding data; The embodiment of the present invention first extracts complete slice data from the encrypted packaged data and the firmware file upgrade message header data, and loads it into the transparent transmission buffer of the XMOS device; after the loading is completed, the transparent transmission scheduling module initializes the transparent transmission protocol stack and sets the transparent transmission link, the link adopts the xCONNECT communication architecture, and establishes a high-speed communication channel with the target MCU device through full-duplex mode; then, the transparent transmission protocol stack extracts the slice data from the transparent transmission buffer one by one according to the slice number sequence, and adds a transparent transmission protocol frame header field to each slice data, the frame header field includes the slice data length, the slice number and the timestamp information, so as to ensure that the target MCU device can decode in the correct order and time; the transparent transmission protocol stack adds a CRC-based The checksum calculated by the A001 algorithm is used to ensure that no errors occur during data transmission. After data encapsulation is completed, the XMOS device accurately controls the transmission timing of each slice through the xTIME scheduling module to ensure that the slice data is sent to the target MCU device at fixed time intervals, and monitors the status of the transmission link through multi-core parallel processing technology to dynamically adjust the data transmission rate to match the receiving capability of the target MCU device. During the transmission process, the communication link monitoring module records the sending status of each slice in real time and updates the sending result to the slice status table. If it is detected that the slice data fails to be sent or the link is abnormal, the transparent transmission protocol stack immediately interrupts the sending of the current slice and triggers the automatic retransmission mechanism to ensure that all slice data are successfully sent to the target MCU device. After completing the real-time forwarding of all slice data, the transparent transmission protocol stack generates transparent real-time forwarding data.

[0030] Step S23: performing protocol analysis on the transparent real-time forwarding data, and extracting the fragmented data to obtain a parsed fragmented data set; In the embodiment of the present invention, first, the real-time forwarding data is received through the communication interface module of the target MCU device. During the receiving process, the transmission data is read frame by frame according to the frame structure of the transparent transmission protocol. Each frame of data consists of a frame header, fragment data, and a frame tail to ensure the segment consistency of the data. After the reception is completed, the protocol parsing module starts the parsing process, firstly parses the frame header field, extracts the fragment number, fragment length and timestamp information, verifies the continuity of the fragment number and records the fragment timestamp to ensure the time sequence of the data; then, the CRC check code in the frame tail field is parsed, and the CRC is used to check the fragment length and timestamp information. The A001 algorithm recalculates the check value for the received fragmented data part, and compares the calculated result with the check code in the frame tail. If the check is consistent, the fragmented data is confirmed to be complete and valid; if the check is inconsistent, the fragment is marked as invalid data and recorded in the data exception table for subsequent processing; for the fragmented data that passes the check, the parsing module extracts its data content into the fragmented data buffer, and updates the fragment status table at the same time, which records the fragment number, data length and parsing status; after completing the parsing of all fragmented data, the parsing module verifies the fragment status table to confirm the numbering continuity and integrity of all fragmented data, and marks the missing fragment records as pending retransmission status; then, the parsing module recombines all the fragmented data that have passed the check to generate a parsed fragmented data set, and stores the parsing results in the parsed data storage area.

[0031] Step S24: Separate the fragmentation mark from the data content based on the parsed fragmentation data set to obtain a received fragmentation unpacked data set.

[0032] The embodiment of the present invention first extracts the slice data one by one from the parsed slice data set, and the extraction process is performed in the order of increasing slice numbers to ensure the logical consistency of data processing; after the extraction is completed, the data separation module parses and separates the tag information and core content of each slice data, and the tag information includes the slice number, version number, data length and check code, which are directly located and extracted from the frame structure of the slice by the parsing module; after the separation is completed, the separation module stores the core data content in the slice data buffer, and records the separated tag information in the slice tag table, which records the number, version number, start and end address and corresponding data status of each slice in detail; then, the data separation module parses the slice number, and separates the core data from the slice data. The integrity of the data is verified again, and the check code in the shard mark table is compared with the recalculated check code of the core data content to ensure that the data has not changed during the separation process; for the shard data that passes the verification, the separation module marks it as valid and writes it to the receiving shard unpacked data storage area; if the verification fails, it is marked as invalid and recorded in the shard abnormal status table for subsequent processing; after completing the separation and verification of all shards, the data separation module organizes the receiving shard unpacked data storage area, reorganizes the data in the order of shard numbers, and ensures that the correspondence between the data content and the marking information is clear; finally, the organized receiving shard unpacked data set includes all valid shard data and their associated marking information.

[0033] The present invention effectively improves the security, reliability and efficiency of the firmware file transmission process through encryption packaging, transparent transmission protocol, protocol parsing and fragmented data processing. The application of encryption packaging and message digest ensures the confidentiality and integrity of the firmware data during the transmission process, and prevents malicious tampering or theft. At the same time, the use of the transparent transmission protocol to forward data in real time reduces the delay caused by the traditional transmission protocol and improves the real-time and efficiency of data transmission. Through the protocol parsing and fragment extraction of the transparent transmission data, the data fragments that appear in the transmission process can be accurately extracted and reconstructed, ensuring that the target device can smoothly receive and process the firmware data. Finally, the separation of the fragmentation mark and the data content enables the receiving device to efficiently and accurately process the received data, avoiding data confusion or disorder, and further ensuring the stability and reliability of the firmware upgrade process.

[0034] Preferably, step S3 comprises the following steps: Step S31: Read the received sliced ​​unpacked data sets one by one to obtain the sliced ​​data to be verified; The embodiment of the present invention first extracts the slice data from the received slice unpacking data set, and the extraction process is performed in the order of increasing slice numbers to ensure the logical consistency of data processing; the slice extraction module locates the specific position of each slice data in the storage area by reading the slice start and end addresses in the slice mark table, and reads the slice data byte by byte during extraction and loads it into the verification buffer; during the reading process, the slice extraction module verifies the consistency between the slice number and the slice mark table record in real time to ensure that no slice data is omitted or repeatedly processed; for each slice data, the extracted content includes the data content field and the additional mark The information field is recorded, and the verification information field of the shard data is stored separately in the verification information buffer during extraction for use in subsequent verification operations; after completing the extraction of each shard data, the shard extraction module updates the shard status table, records the reading status and verification preparation status of the shard, and marks whether the shard has completed reading; if shard data is missing or read abnormally during the extraction process, the shard extraction module marks the shard as abnormal in the shard status table and generates an abnormal data record for use in subsequent steps; all extracted shard data are stored in the data buffer to be verified, forming shard data to be verified.

[0035] Step S32: parsing the verification information field of the fragment data to be verified to obtain the verification preliminary fragment data; The embodiment of the present invention first extracts the slice data one by one from the slice data buffer to be checked, and each extraction operation is performed in the order of increasing the slice number to ensure the logical consistency of data processing; after the extraction is completed, the check information parsing module locates and parses the check information field of each slice data, and the position of the check information field is determined by a predetermined slice protocol structure, which is generally located at the head or tail of the slice data; the check information parsing module extracts the CRC check code, the slice length and the slice number information from the check information field, and stores the extracted check information in the check information buffer, and at the same time stores the core content part of the slice data separately in the check data buffer, to ensure that the check information and the core data are consistent. physical separation; during the parsing process, the check information parsing module verifies in real time whether the extracted check information conforms to the format specification of the sharding protocol, such as whether the CRC check code length is a 16-bit binary value and whether the shard length is consistent with the record in the sharding mark table; if the check information parsing fails or the data format is abnormal, the check information parsing module marks the sharding data as abnormal and records it in the abnormal sharding log for supplementary processing in subsequent steps; for successfully parsed sharding data, the check information parsing module matches the extracted check information with the sharding number one by one, and updates the check information status in the sharding status table; all parsed check information and sharding core data are recombined into check preparation sharding data.

[0036] Step S33: Perform CRC check calculation on the check preparation slice data to obtain the current slice check result data; The embodiment of the present invention first extracts the verification preparation slice data one by one from the verification preparation buffer, and the extraction order is strictly in the order of increasing slice numbers to ensure the logical consistency of data processing; after the extraction is completed, the verification calculation module initializes the CRC A001 algorithm, sets the initial check value of the algorithm to the 16-bit binary value "0xFFFF", and loads the core content of the current slice data into the verification input buffer; then, the verification calculation module performs CRC on each byte data in the verification input buffer one by one The polynomial operation of the A001 algorithm is based on the generating polynomial "0x1021", and performs bit-by-bit XOR calculation and shift operation on the input data to generate an intermediate check value; after completing the data processing of all bytes, the check calculation module uses the final intermediate check value as the check code of the current shard, and compares it with the original CRC check code extracted from the check preparation shard data; if the comparison results are consistent, the check calculation module marks the current shard as a successful check state, and stores the check result data in the successful check buffer, and updates the check status in the shard status table; if the comparison results are inconsistent, the check calculation module marks the current shard as a failed check state, and records it in the failed check log, and stores the failed check result data in the failed check buffer; after completing the CRC check calculation of all shard data, the check calculation module classifies and organizes the successful and failed check result data, and stores them in the shard check result storage area to obtain the current shard check result data.

[0037] Step S34: Perform integrity determination based on the current shard verification result data to obtain shard verification determination data; In the embodiment of the present invention, first, the current shard verification result data is extracted from the shard verification result storage area, and the extraction order is strictly executed in the order of increasing shard numbers to ensure the logical consistency of data processing; after the extraction is completed, the integrity determination module loads the shard verification result data and the corresponding shard mark table record, and the shard mark table contains the number, data length, check code and status information of the current shard; the integrity determination module first compares the check code field of the check result data with the original check code in the shard mark table bit by bit, and if the comparison results are consistent, the current shard verification result is determined to be passed, and the shard is marked as verified successfully in the shard status table; if If the comparison results are inconsistent, the current shard verification result is determined to be a failure, and the shard is marked as a verification failure in the shard status table, and a shard exception record is generated; after completing the determination of each shard verification result, the integrity determination module summarizes all shard status table entries to verify whether the verification status of all shards meets the numbering continuity and status consistency requirements. If the verification status of any shard is found to be a failure, these shard numbers are recorded and added to the abnormal shard list; after completing the summary, the integrity determination module generates shard verification determination data, which includes a list of shard numbers that have passed the verification, a list of shard numbers that have failed the verification, and the corresponding abnormal reasons.

[0038] Step S35: judging the fragment verification judgment data, if the integrity verification succeeds, generating successfully received fragment depacketized data, if the integrity verification fails, generating failed received fragment depacketized data; The embodiment of the present invention first extracts the slice verification determination data one by one from the slice verification determination data storage area, and the extraction process is performed in the ascending order of the slice number to ensure the logical consistency of data processing; after the extraction is completed, the state judgment module performs one-by-one judgment according to the verification status field in the slice verification determination data, and the verification status field includes a flag bit that identifies the current slice integrity determination result, and the flag bit indicates a successful verification or a failed verification in binary form; for the slices that have successfully verified, the state judgment module moves the corresponding slice data from the to-be-processed buffer to the successfully received slice unpacking data storage area, and at the same time updates the status of the slice in the slice status table to "successfully received"; for the slices that have failed to verify, the state judgment module The fragment data is moved from the pending buffer to the failed received fragment unpacking data storage area, and the status of the fragment is updated to "failed to receive" in the fragment status table. At the same time, an exception record is generated and written into the exception log table, recording the cause of failure and the fragment number for subsequent tracking and processing; after completing the judgment of all fragment verification judgment data, the status judgment module counts the successfully received fragment unpacking data storage area and the failed received fragment unpacking data storage area, and generates a statistical report, which includes the number of successful fragments, the number of failed fragments and detailed information of the exception log; the data in the successfully received fragment unpacking data storage area is used as the input source of step S4, and the data in the failed received fragment unpacking data storage area is used as the basis for the retransmission request of step S36.

[0039] Step S36: Based on the failed received fragment unpacking data, a retransmission request is made to the upgrade source device to obtain the repaired received fragment unpacking data.

[0040] The embodiment of the present invention first extracts the number information of all failed fragments from the failed received fragment unpacking data storage area, and the number information is recorded in the failed fragment log table, and the log table also includes the failure reason and abnormal state of each fragment; after the extraction is completed, the retransmission request generation module generates a retransmission request according to the failed fragment number and the original fragment information in the fragment mark table, and the retransmission request contains the fragment number, fragment length and data starting position detailed information to ensure that the source device can accurately locate the fragment data to be retransmitted; then, the retransmission request generation module sends the retransmission request to the upgrade source device through the communication interface module, and the communication process strictly adopts the preset transparent transmission protocol and attaches identity authentication information to Verify the legitimacy of the request; after receiving the retransmission request, the upgrade source device re-extracts the specified fragment data from the source data storage area according to the fragment number provided in the request, and encapsulates the re-extracted data into a retransmission fragment data packet; the retransmission data packet contains the recalculated CRC check code and the complete fragment data content. After the encapsulation is completed, the upgrade source device sends the retransmission fragment data to the target MCU device through the transparent transmission link; after receiving the retransmission fragment data, the target MCU device first uses the protocol parsing module to parse the retransmission data packet, extracts the fragment number and data content, and loads them into the retransmission data buffer; then, the verification module performs integrity check on the retransmission data, using CRC The A001 algorithm verifies whether the checksum of the retransmitted data matches. If the check is successful, the retransmitted fragment data is marked as successfully repaired and written into the repaired received fragment unpacking data storage area. At the same time, the fragment status table is updated to reflect the latest fragment status. If the check fails, it is recorded in the retransmission failure log and the subsequent retry mechanism is triggered until all fragment data are successfully repaired or the maximum number of retransmissions is reached. The data in the repaired received fragment unpacking data storage area is used as the input source for subsequent steps to provide reliable support for the integrity recovery of the firmware file.

[0041] The present invention effectively ensures the reliability and integrity of firmware file data by reading, verifying calculation and determining integrity one by one. During the firmware data transmission process, by reading the sliced ​​data to be verified one by one and parsing the verification information field, it is ensured that each data slice can be accurately processed when received. The CRC verification calculation is used to further verify the correctness of each slice, effectively preventing errors or damage to the data during the transmission process. Through the integrity determination, it is possible to accurately identify whether data loss or errors have occurred during the transmission, ensuring that the received data is complete and correct. When the integrity check is successful, the data is regarded as successfully received, and when the check fails, the data problem is promptly repaired through the retransmission mechanism to ensure that the firmware upgrade process is not interrupted, further improving the stability and reliability of the firmware upgrade. This process not only ensures the accuracy and integrity of the data, but also can be repaired through the retransmission mechanism when problems are encountered, thereby ensuring the smooth completion of the firmware file transmission.

[0042] Preferably, step S4 comprises the following steps: Step S41: classifying and arranging the generated received fragment unpacking data, and performing integrity check on the repaired received fragment unpacking data, to obtain a fragment unpacking data set to be reassembled; The embodiment of the present invention generates received fragment unpacked data and repaired received fragment unpacked data, uses a fragment data management module to classify and sort the two types of data, sorts them according to the received timestamp and the fragment number, arranges the data in ascending order according to the number to form a preliminary classified data set, and performs CRC A001 verification on the repaired received fragment unpacked data through a built-in verification module, compares the verification value of each fragment with its corresponding verification code one by one, generates a data block set that passes the verification and a data block set that fails the verification, and integrates the data block set that passes the verification and the preliminary classified data set into a fragment unpacked data set to be reassembled; the classification and sorting process performs index maintenance through a hardware register to ensure that the unique mapping relationship between the fragment data storage location and the number is not confused, the fragment number is extracted from the metadata of the received fragment unpacked data and the repaired fragment unpacked data, and the index is generated by the number parsing module; when storing data, efficient data read and write operations are realized through the intermediate layer of the hardware cache to avoid repeated retrieval of fragment data; in the whole process, the classification and sorting and integrity verification operations are performed synchronously, and after completing the data verification of all fragments, the fragment unpacked data set to be reassembled is output.

[0043] Step S42: performing a shard data merging process on the sharded unpacked data set to be reassembled to obtain a preliminary merged sharded data set; The embodiment of the present invention is based on the fragmented unpacked data set to be reassembled, and uses the fragmented data merging module to perform data merging operations. First, the fragmented data merging module loads the fragmented data blocks in the fragmented unpacked data set to be reassembled into the cache area one by one according to the ascending order of the fragment numbers, and verifies the numbering order and uniqueness of the fragments through the number index table. During the loading process, the cache area uses a multi-threading mechanism to perform parallel processing, and stores the data content of each fragment in a predefined storage buffer in sequence. For each fragmented data, when loading into the buffer, the fragmented data is filled into the target memory block according to a fixed byte length through a byte alignment method to ensure the integrity and consistency of the data storage. Subsequently, all the fragmented data are spliced ​​one by one into the target merge buffer through a memory block splicing operation to form a preliminary merged fragmented data set. During the splicing process, a dedicated hardware verification engine is used to perform a segmented verification operation on the spliced ​​data to ensure that no data errors are introduced during the merging process. After the splicing is completed, the data in the merge buffer is written to the target storage area through the bus interface, and the number index table is updated to record the storage address and length information corresponding to the merged data block, and finally the preliminary merged fragmented data set is output.

[0044] Step S43: numbering and marking the preliminary merged shard data set to obtain a sorted merged shard data set; The embodiment of the present invention is based on the preliminary merged shard data set, and uses the number marking module to perform number marking processing on the shard data. First, the number marking module extracts the shard data block by block from the preliminary merged shard data set, and assigns unique numbers according to the physical storage order of the shards in the data set through the preset number index rule, generates a number allocation table, and the numbers are stored in the register in hexadecimal format. Subsequently, the number marking tool is used to embed the number marking information into the header and tail of each shard data block, wherein the header mark includes the shard number, data length and shard check code, and the tail mark includes the reverse check value of the shard number, so as to ensure that the number of each shard remains consistent and traceable during data storage and subsequent processing. While embedding the number mark, the number marking module compares the number allocation table and the shard check code in real time through the hardware check mechanism. If a number conflict or a check code inconsistency is found, an error mark data is generated and the operation is interrupted, and the preliminary merged shard data set is rolled back to the previous processing state. For the shard data that has been marked and verified, the number marking module rearranges it and stores it in the target memory buffer to ensure that the shard data is arranged in ascending order by number, and records the storage address and number information of each shard by updating the number index table, and finally outputs the sorted and merged shard data set.

[0045] Step S44: performing data continuity verification based on the sorted and merged sharded data sets to obtain continuity verification result data; The embodiment of the present invention is based on sorting and merging fragmentation data sets, and uses a data continuity verification module to verify the numbering continuity and content integrity of the fragmentation data. First, the data continuity verification module reads the fragmentation data block by block from the sorting and merging fragmentation data sets, and performs number comparison according to the numbering sequence and storage address in the numbering index table. For each fragmentation data, the verification module matches the numbering information with the expected number in the numbering index table one by one. If the number is found to be missing or repeated, the numbering exception information is recorded and the abnormal fragmentation data is marked as invalid, and a numbering exception report is generated for subsequent investigation. After completing the numbering verification, the verification module parses the first and last numbering marks of the fragmentation data, calculates the storage range of the fragmentation content by parsing the fragmentation length field of the numbering mark, and compares and verifies the actual data content within the range with the check value of the numbering mark to confirm whether the fragmentation data is complete. If it is found that the content is missing or the check fails, the verification module records the fragmentation number and the corresponding storage location of the missing content in the error log, and generates a content exception report. For the fragmentation data that has passed the verification, the verification module marks it as a valid fragmentation, and updates the numbering index table to record the status of the verified fragmentation. The entire continuity verification process is carried out through a hardware pipeline, and the number verification and content verification are completed simultaneously with the help of a multi-threaded processing mechanism to improve processing efficiency. Finally, the data continuity verification module outputs the continuity verification result data.

[0046] Step S45: combining the sorted and merged fragmented data sets based on the continuity verification result data to obtain complete received firmware file data.

[0047] The embodiment of the present invention uses a data combination module to reorganize the complete file data on the shard data based on the continuity verification result data and the sorted and merged shard data set. First, the data combination module extracts the number and storage address information of the valid shards from the continuity verification result data, and loads the valid shard data in the sorted and merged shard data set to the target buffer block by block through the address index table; during the loading process, the data combination module performs dynamic alignment operations on the shard data through the hardware buffer unit to ensure that the starting byte addresses of all shard data blocks meet the fixed byte boundary alignment requirements to avoid storage offset problems in the file data during the combination process. Subsequently, a dedicated hardware interface control unit is used to perform serial splicing operations on the valid fragment data in the target buffer in the order of the number index table, and the fragment data is copied byte by byte to the complete file storage area through the data splicing pipeline. During the splicing process, splicing completion mark data is generated in real time to identify the splicing status of each fragment, and the spliced ​​complete file data is verified segment by segment through the hardware verification engine. After the verification is completed, the verification result is recorded in the splicing log for subsequent tracking; for the splicing segment that failed the verification, the data combination module reloads the corresponding fragment data by backtracking the number index table for splicing repair, and verifies again after the repair is completed until it passes. After all the fragments are spliced, the data combination module updates the file status field of the number index table to indicate the file reorganization completion status, and writes the complete receiving firmware file data to the target storage medium, and generates a reorganization completion report to indicate the end of the reorganization operation. Finally, the data combination module outputs the complete receiving firmware file data.

[0048] The present invention ensures that the received firmware fragments can be correctly reorganized into a complete firmware file through classification, integrity verification, data merging and continuity verification operations. First, by classification and integrity verification of the repair fragments, it is ensured that all received fragment data are effectively processed and verified, avoiding potential data loss or errors. Then, the fragment data that is initially merged is numbered and sorted to ensure the correct order of the fragment data after merging, so that the reorganization process proceeds smoothly. By performing continuity verification on the sorted and merged fragment data, the logical consistency and coherence of the data after merging are further ensured, avoiding file damage or errors caused by data confusion. Finally, a completely received firmware file is obtained through data combination, ensuring that the target MCU device can receive complete and correct firmware data, and improving the stability, accuracy and reliability of the firmware upgrade process.

[0049] Preferably, step S5 comprises the following steps: Step S51: Initialize the MD5 digest of the completely received firmware file data to obtain MD5 initialization data; The embodiment of the present invention is based on the complete reception of firmware file data, and uses the MD5 digest initialization module to perform digest initialization processing on the data. First, the MD5 digest initialization module reads the complete reception firmware file data byte by byte from the storage area to the dedicated buffer through the high-speed data interface, and performs byte alignment operation on the read data to ensure that the storage address of the data block in the memory meets the hardware requirement of four-byte alignment, so as to improve the efficiency of subsequent digest calculation; then, the initialization module divides the complete reception firmware file data into 512-bit data blocks of fixed length according to the standard requirements of the MD5 message digest algorithm, and adds padding bits and length information to each data block. The value of the padding bit is generated in the form of a single bit "1" followed by several bits of "0" according to the definition of the MD5 algorithm, and the length information records the total length of the data block in the form of a 64-bit binary number. After completing data segmentation and padding, the initialization module generates the initial summary state of each data block, including four 32-bit link variables (named A, B, C, and D respectively), and assigns a fixed initial value to each link variable. The initial value is written into the register according to the value defined by the MD5 algorithm standard, and the state information of the link variable is stored in the state register stack for use in the summary calculation of the subsequent step S52. After the initialization is completed, the MD5 summary initialization module updates the processing status register to indicate the end of the initialization operation, and outputs the MD5 initialization data.

[0050] Step S52: Based on the MD5 initialization data, the MD5 message digest algorithm is used to perform a digest calculation on the completely received firmware file data to generate firmware file digest data; The embodiment of the present invention uses an MD5 summary calculation module to perform summary calculation on the completely received firmware file data based on MD5 initialization data. First, the MD5 summary calculation module reads the segmented 512-bit data block and its initial link variable (A, B, C, D) from the MD5 initialization data, and loads each data block into the input register of the hardware calculation engine. Subsequently, the MD5 summary calculation module performs 64 rounds of iterative calculations on each data block according to the standard process of the MD5 algorithm, and uses 4 logical operation functions (F, G, H, I) in each round of calculation to perform nonlinear mixing operations on the current link variable and the specific bits of the data block. The mixed result generates an intermediate calculation value through bitwise XOR, bitwise AND and left shift operations, and the link variable state after each round of calculation is updated in the register. After the 64 rounds of calculation for each data block are completed, the MD5 summary calculation module accumulates the finally generated link variable state and the input initial link variable value to obtain a partial summary value of the data block. The module processes all data blocks in sequence according to this process, and merges the partial summary value of each data block into a complete 128-bit firmware file summary data. After the calculation is completed, the MD5 summary calculation module saves the summary result to the output register through the register locking mechanism, generates a processing completion flag signal to indicate the end of the calculation operation, and outputs the firmware file summary data.

[0051] Step S53: Compare the firmware file summary data with the preset source file summary data to obtain file summary comparison result data; The embodiment of the present invention is based on firmware file summary data, and performs comparison processing with preset source file summary data, and uses a summary comparison module to complete data integrity verification. First, the summary comparison module reads 128-bit summary data byte by byte from the firmware file summary data storage register through a high-speed data interface, and synchronously loads the corresponding 128-bit preset summary data from the preset source file summary data storage area to a dedicated cache area. The summary comparison module performs a byte-by-byte matching operation on the two summary data, and compares the binary bits of each byte bit by bit in turn. During the comparison process, a bit matching result flag is generated in real time. The flag value "0" indicates that the current bit is inconsistent, and the flag value "1" indicates that the current bit is consistent. After completing the bitwise matching of all bytes, the summary comparison module performs a logical product operation on all matching result flags. If the result is "1", it means that the summary data is completely consistent, and a matching success flag data is generated; if the result is "0", it means that there is a difference in the summary data, and a matching failure flag data is generated. After the matching result is generated, the summary comparison module selects to write the matching result into the comparison result register according to the flag value, and updates the summary comparison completion flag to indicate the end of the comparison operation, and outputs the file summary comparison result data at the same time.

[0052] Step S54: Perform integrity verification on the file summary comparison result data. If the integrity verification fails, a rollback mechanism is executed. If the integrity verification passes, firmware file verification result data is generated.

[0053] The embodiment of the present invention uses an integrity verification module to determine the file summary comparison result based on the file summary comparison result data and take corresponding processing. First, the integrity verification module loads the comparison result data from the summary comparison result storage register, and parses the comparison result bit by bit according to the logic operation rules. If all bits of the comparison result are consistent flags "1", the verification module generates verification pass flag data and writes it into the verification result register, and updates the firmware verification status to "pass", and outputs the firmware file verification result data for subsequent firmware upgrade steps; if there is any inconsistent flag "0" in the comparison result, the verification module generates verification failure flag data and starts the rollback mechanism. The rollback mechanism extracts the initial firmware file data from the system backup storage area through the storage control unit, overwriting the complete received firmware file data in the current storage area to ensure that the MCU device is restored to the initial state when the firmware upgrade fails. In the process of performing the rollback operation, the verification module sequentially completes the operations of backup data loading, storage area cleaning and data overwriting through the hardware pipeline, and generates a rollback status log in real time and records the storage address and data block information involved in the rollback process. After the rollback is completed, the verification module updates the firmware verification status to "failed" and generates a verification failure report for system troubleshooting.

[0054] The present invention effectively ensures the integrity of the firmware file and the accuracy of data transmission through MD5 digest calculation and integrity verification. By performing MD5 digest initialization and digest calculation on the completely received firmware file data, unique summary data of the firmware file is generated, which provides an effective basis for subsequent verification of whether the firmware is complete. The generated firmware file digest is compared with the preset source file digest to ensure that the received firmware file is consistent with the original file and has not been tampered with or damaged. Through integrity verification judgment, a rollback mechanism can be triggered when the verification fails, thereby preventing the use of erroneous firmware files and ensuring system stability. If the verification passes, a firmware file verification result is generated to confirm the integrity of the firmware file, further ensuring the success and reliability of the firmware upgrade process. This process not only improves the security of firmware upgrades, but also provides an effective error repair mechanism and enhances the robustness of the system.

[0055] Preferably, step S54 includes the following steps: Step S541: parsing the file summary comparison result data to generate summary integrity determination data; The embodiment of the present invention uses a summary parsing module to parse the data step by step and generate summary integrity judgment data based on the file summary comparison result data. First, the summary parsing module loads 128-bit summary comparison result data from the file summary comparison result storage register through a high-speed data bus, and divides it into multiple 32-bit data segments, which are loaded into the input buffer of the hardware parsing unit by segment. The parsing unit performs a logical parsing operation on each data segment bit by bit, and generates a parsing status flag for each bit by comparing it bit by bit with a preset integrity standard value. The parsing status flag is "1" to indicate that the bit matches, and "0" to indicate that the bit does not match. After completing the parsing of each segment of data, the parsing unit summarizes all parsing status flags into summary integrity judgment data, and verifies the accuracy of flag generation in the parsing process in real time through a verification engine to ensure that the parsing result is completely consistent with the input data. After completing the parsing of all segments of data, the summary parsing module stores the generated summary integrity judgment data in the judgment result register, indicates the end of the parsing operation through a status flag, and outputs the summary integrity judgment data at the same time.

[0056] Step S542: Perform file integrity status determination based on the summary integrity determination data to obtain file integrity determination result data; The embodiment of the present invention firstly performs a further integrity status judgment on the file by comparing the summary integrity judgment data. The judgment process uses preset rules, such as verifying the hash value of the firmware file, comparing the file summary with the known valid summary, and if there is no abnormality in the file summary, indicating that the file has not been damaged or tampered with, the file integrity is judged to be successful; if there is a difference in the file summary, indicating that the file has been damaged or tampered with, the file integrity is judged to be failed. In this process, a hash algorithm such as SHA256 is used for verification to ensure that the hash value of the file completely matches the reference hash value. This operation is automatically performed by the firmware verification tool to generate file integrity judgment result data. The judgment result data is generated according to the verification result. If the integrity judgment is successful, the data with the integrity of "success" is returned; if the integrity judgment fails, the data with the integrity of "failure" is returned. Finally, the file integrity judgment result data is obtained.

[0057] Step S543: classify and identify the file integrity determination result data, and if the determination result is failure, generate rollback mechanism trigger data; if the determination result is success, generate firmware file verification result data; The embodiment of the present invention first extracts the integrity status of the file from the file integrity determination result data and performs classification judgment. If the file integrity determination result is a failure, rollback mechanism trigger data is generated, and this data is used to activate the firmware recovery operation to ensure that the device is restored to a previous stable state. The generation of the rollback mechanism trigger data is based on the "failure" status in the determination result data, triggering the rollback operation process, and transmitting the data to the control unit of the device. If the file integrity determination result is a success, firmware file verification result data is generated, indicating that the firmware file has been successfully verified and is complete and correct, and the device can continue the firmware upgrade process.

[0058] Step S544: based on the rollback mechanism triggering data, the firmware backup area of ​​the MCU device is restored, and the process returns to step S2.

[0059] The embodiment of the present invention first receives rollback mechanism trigger data, which is triggered when the file integrity determination result is a failure. Next, the firmware management system starts the firmware backup recovery operation according to the rollback mechanism trigger data. In this process, the firmware management system loads and restores the firmware backup area data in the device to a previous valid state, usually by extracting the backed-up firmware file from the non-volatile storage area (such as flash memory) of the device. The recovery operation is controlled by the hardware driver to ensure that the firmware data in the backup area is correctly restored and overwrites the currently damaged or incomplete firmware. After the recovery is completed, the firmware management system will update the device status to the restored version and return the control flow to step S2.

[0060] The present invention ensures the high reliability and stability of the firmware upgrade process through detailed summary integrity analysis, file integrity determination and rollback mechanism. First, by parsing the file summary comparison results, summary integrity determination data is generated, which provides a clear basis for file integrity verification. Then, through the file integrity status determination, the accuracy and consistency of the firmware file are ensured. If the firmware file fails to pass the integrity verification, the system can immediately identify and take corresponding measures. The classified identification of the file integrity determination results can trigger the rollback mechanism in time when the file verification fails, start the firmware backup area recovery, and ensure that the device can be restored to a normal state, thereby avoiding device failures caused by firmware damage or errors. If the verification is successful, the integrity of the firmware file is confirmed, and the firmware upgrade process is further promoted. This series of steps not only enhances the security of the firmware upgrade process, but also provides an effective fault recovery method to ensure that the system always maintains high availability and stability during the firmware upgrade process.

[0061] Preferably, step S6 comprises the following steps: Step S61: reading and parsing the firmware file verification result data to obtain firmware upgrade permission data; In an embodiment of the present invention, the MCU device main controller receives a firmware file verification result data packet through a CAN bus interface, wherein the firmware file verification result data packet includes a firmware file check code, a firmware version number, and firmware size information. The MCU device main controller first performs a CRC check on the received firmware file verification result data packet to ensure data transmission integrity. Then, the MCU device main controller parses the data in the firmware file verification result data packet according to a preset parsing rule. The parsing rule is: the data packet is divided according to a fixed byte length, the first 4 bytes are the firmware file check code, the next 4 bytes are the firmware version number, and the last 4 bytes are the firmware size information. After the parsing is completed, the MCU device main controller compares the parsed firmware file check code with the locally stored firmware file check code. After the comparison is consistent, the firmware version number is compared with the currently running version number to confirm the version upgrade direction. Then, the MCU device main controller plans the storage space required for the upgrade based on the parsed firmware size information, and obtains the firmware upgrade permission data through the above operation.

[0062] Step S62: Initializing the upgrade environment of the target MCU device based on the firmware upgrade permission data to obtain upgrade environment initialization data; In the embodiment of the present invention, the MCU device main controller reads the firmware upgrade permission data stored in the RAM, and confirms the execution of the upgrade operation by judging the upgrade confirmation flag. The MCU device main controller first sets the upgrade status indicator to yellow and always on through the GPIO interface to indicate entering the upgrade mode. Then the MCU device main controller executes the Flash memory erase operation according to the required storage space size in the firmware upgrade permission data. The specific erasing process is: the MCU device main controller sends an erase command to the Flash controller, specifies the erase start address 0x08020000 and the erase length, and the Flash controller executes sector erase, erasing 4KB sectors each time, and returns to the erase state after the erasing is completed. In addition to the status flag, the MCU device main controller confirms that the erasure is complete and backs up the currently running firmware program to the backup partition of the Flash memory. The starting address of the backup partition is 0x08060000. After the backup is completed, the MCU device main controller configures the DMA channel for subsequent firmware data transmission. The configuration includes setting the DMA transfer direction to memory to memory mode, the data width to 32 bits, the transfer priority to high, and setting the transfer completion interrupt enable. The MCU device main controller organizes the above initialization configuration results into upgrade environment initialization data, including three status flags: Flash erase status, firmware backup status, and DMA configuration status, and stores them in the specified status register.

[0063] Step S63: partition-burning the complete received firmware file data based on the upgrade environment initialization result data to obtain partition-burning result data; The MCU device main controller of the embodiment of the present invention reads the upgrade environment initialization data in the status register, confirms that the Flash erase state, the firmware backup state, and the DMA configuration state are all valid, and then receives the complete firmware file data through the SPI interface. When receiving the data, a data block transmission mode of 4KB is adopted. Each time a data block is received, the MCU device main controller immediately transmits the data block to the specified address of the Flash memory through the configured DMA channel. The starting address of the data block writing is 0x08020000. The MCU device main controller performs a write check through the DMA interrupt response function after each data block transmission is completed. The check mode is to compare the written data with the source data byte by byte. If an inconsistency is found, the data block is rewritten. After the write check passes, the MCU device main controller updates the write progress counter and continues to receive the next data block. When all data blocks are written, the MCU device main controller performs a CRC check on the entire firmware data, calculates the CRC value of the firmware data written in the Flash memory and compares it with the expected CRC value to complete the firmware integrity verification. The MCU device main controller forms the partition burning result data with the data block write status, write progress, and CRC check result.

[0064] Step S64: configuring the firmware operating environment of the target MCU device based on the partition burning result data to obtain firmware operating environment configuration data; The MCU device main controller of the embodiment of the present invention reads the partition burning result data in the result status register, confirms that the data block write status is successful and the CRC check result is passed, and then the MCU device main controller starts to execute the firmware operating environment configuration. First, the MCU device main controller writes the entry address 0x08020000 of the new firmware program into the vector table offset register VTOR, updates the interrupt vector table to point to the new firmware program, and then the MCU device main controller configures the system clock, sets the system main frequency to 72MHz, configures the peripheral clock, including setting the APB1 bus clock to 36MHz and the APB2 bus clock to 72MHz. Then, the MCU device main controller initializes the communication interface parameters, sets the UART baud rate to 115200 and the SPI clock The MCU device main controller also needs to configure the timer parameters, set the TIM2 timing period to 1ms for system tick timing, and set the TIM3 timing period to 10ms for task scheduling. Finally, the MCU device main controller configures the memory mapping and maps the 0x08020000-0x08060000 address segment of the Flash memory to the system memory space. The MCU device main controller uses the above configuration results, including the vector table configuration status, clock configuration status, interface configuration status, timer configuration status, and memory mapping status, to form the firmware running environment configuration data.

[0065] Step S65: performing a firmware activation operation using the firmware operating environment configuration data to obtain firmware activation result data; In the embodiment of the present invention, the MCU device main controller reads the firmware operating environment configuration data in the configuration status register, and after confirming that the vector table configuration state, clock configuration state, interface configuration state, timer configuration state, and memory mapping state are all valid, the MCU device main controller performs a firmware activation operation. First, the MCU device main controller writes the new firmware version number into the firmware information area of ​​the Flash memory, with the starting address being 0x08019000. Then, the MCU device main controller writes the running flag bit of the firmware program into the firmware information area, marking the firmware program as the current running version. After that, the MCU device main controller activates the firmware through the GPIO interface. The level status indicator is set to green and always on to indicate that the upgrade is about to be completed. Then the MCU device main controller writes the startup parameters into the startup configuration register, sets the startup mode to the normal operation mode, sets the program counter PC to point to the new firmware program entry address 0x08020000, and sets the stack pointer SP to point to the new firmware program stack starting address 0x20002000. After the MCU device main controller completes the startup parameter configuration, it executes the jump instruction to prepare to enter the new firmware program. Before the jump, the MCU device main controller writes the firmware version status, the run flag write status, the startup parameter configuration status, and the jump preparation status to form the firmware activation result data.

[0066] Step S66: verify the running status of the target MCU device based on the firmware activation result data to obtain the MCU device firmware upgrade feedback data.

[0067] In the embodiment of the present invention, the MCU device main controller reads the firmware activation result data in the activation status register, and after confirming that the firmware version writing status, the running flag bit writing status, the startup parameter configuration status, and the jump preparation status are all valid, the MCU device main controller starts to perform the running status verification. First, the MCU device main controller detects the system running status through the watchdog timer, sets the watchdog timeout time to 1 second, starts the watchdog count, and the new firmware program needs to complete the watchdog clearing operation within the specified time. Then, the MCU device main controller reads the running status flag in the system status register to confirm that the processor core is working in the normal running mode. Then, the MCU device main controller reads Fl The firmware version information at the address 0x08019000 of the ash memory is used to verify that the current running firmware version number is correct. Then the MCU device main controller collects the peripheral working status through the GPIO interface to verify that the PA0-PA7 output port status is normal and the PB0-PB7 input port signal is normal. At the same time, the MCU device main controller sends a test data packet through the serial port to verify that the communication interface is working properly. Finally, the MCU device main controller packages the above verification results, including the system running status, firmware version verification results, peripheral working status, and communication interface status, to form the MCU device firmware upgrade feedback data and send it to the host computer through the CAN bus to complete the entire firmware upgrade process.

[0068] The present invention ensures the smooth execution of firmware upgrade and the efficient operation of MCU device through a series of upgrade environment initialization, partition burning, firmware activation and running status verification operations. First, by reading and parsing the firmware file verification result, the permission of firmware upgrade is ensured, and the unverified firmware is prevented from being installed incorrectly. Then, the upgrade environment of the target MCU device is initialized based on the firmware upgrade permission data, providing suitable environmental conditions for the firmware upgrade and ensuring the smooth progress of the upgrade process. Through partition burning, the correct writing of firmware data is ensured, and the target device is ensured to run the new firmware smoothly through the firmware running environment configuration. The completion of the firmware activation operation enables the new firmware to be successfully started and take effect, and the running status verification further confirms whether the firmware upgrade is successful, ensuring that the device is in the correct running state after the upgrade. The whole process not only improves the efficiency of firmware upgrade, but also ensures the stability and efficient operation of the MCU device after the firmware upgrade through multiple verifications and configurations, and guarantees the long-term reliability of the system.

[0069] Preferably, step S66 includes the following steps: Step S661: Perform message header comparison analysis on the firmware activation result data and the firmware file upgrade message header data using the MD5 message digest algorithm to obtain upgrade data status verification data; The MCU device main controller of the embodiment of the present invention first reads the firmware activation result data from the activation status register through the data bus, including the firmware version writing status, the running flag bit writing status, the startup parameter configuration status, and the jump preparation status, and at the same time reads the firmware file upgrade message header data from the 0x08010000 address of the Flash memory, including the firmware identifier, the firmware version number, the firmware size, and the checksum. Then the MCU device main controller inputs the two sets of data into the MD5 hash function for processing. The MD5 algorithm performs 512-bit grouping processing on the input data through 4 rounds of transformation operations, each round including 16 basic operation steps, and finally generates two 128-bit message digest values ​​after filling, buffer initialization, and cyclic compression operations. Then the MCU device main controller compares the two message digest values ​​bit by bit, and judges the data integrity in the firmware upgrade process through the comparison result. After that, the MCU device main controller generates a status verification record in a standard format, and the record includes a data comparison timestamp, a message digest value, and a comparison result flag. Finally, the MCU device main controller composes the upgrade data status verification data with the status verification record.

[0070] Step S662: Perform a hardware status check on the target MCU device based on the firmware activation result data, and perform a performance evaluation based on the hardware status check result to obtain firmware operation performance data; The MCU device main controller of the embodiment of the present invention first reads the firmware activation result data in the activation status register to confirm the firmware running status, and then starts to perform hardware status check. The check process includes: collecting the MCU core voltage through ADC, and the measured value needs to be kept in the range of 3.0V to 3.6V; reading the internal temperature sensor, and the core temperature needs to be kept in the range of -40℃ to 85℃; measuring the CPU main frequency through the timer TIM2, which needs to be stable at 72MHz; reading the FLASH controller status register to check the memory read and write timing; measuring the SRAM data read and write speed, performing standard read and write tests, and writing speed The speed must reach 8MB / s, and the reading speed must reach 12MB / s; detect the stability of the external crystal frequency, and measure the frequency deviation of the 8MHz crystal to be less than 50ppm; measure the GPIO flip speed, and the high and low level flip frequency of the PA0 port must reach 10MHz; detect the CAN communication quality, send 100 frames of test data packets, and the bit error rate must be less than 0.1%; measure the serial communication baud rate error, and the error must be less than 2% under the 115200 baud rate setting; then the MCU device main controller compares all the measured data with the standard threshold to obtain a performance score, and combines the performance score and specific measurement data into firmware operation performance data.

[0071] Step S663: Integrate the upgrade data status verification data with the firmware operation performance data to obtain MCU device upgrade feedback data.

[0072] The firmware management system of the embodiment of the present invention integrates the upgrade data status verification data with the firmware operation performance data. The upgrade data status verification data includes the status information obtained by comparing and analyzing the firmware activation result data and the firmware file upgrade message header data through the MD5 message digest algorithm. The firmware operation performance data comes from the hardware status check and performance evaluation, and includes various hardware indicators and performance performance of the device. The integration operation includes merging these two types of data in a specific standardized format for unified analysis and subsequent processing. During the data integration process, the firmware management system splices or maps these data according to a preset structure (such as JSON format or binary structure), and processes them through a built-in data processing module. Finally, the integrated data generates MCU device upgrade feedback data, which serves as the feedback result of the firmware upgrade process and provides the current status and performance evaluation information of the device.

[0073] The present invention ensures the data integrity and performance optimization of the device after the firmware upgrade through message header comparison analysis, hardware status check and performance evaluation. By using the MD5 message digest algorithm to compare and analyze the firmware activation result with the firmware file upgrade message header, the status of the firmware upgrade is verified, and the consistency and reliability of the data are ensured. Based on the hardware status check, the hardware environment of the target MCU device can be accurately evaluated, and the new firmware can be further ensured to be compatible and run efficiently. At the same time, the performance evaluation provides a comprehensive understanding of the firmware running status, which helps to detect the performance changes of the system after the firmware upgrade. By integrating the upgrade data status verification and the firmware running performance data, the upgrade feedback data of the MCU device is finally obtained, which not only confirms the success of the upgrade process, but also ensures that the running status of the device after the upgrade meets expectations, and improves the stability and optimization of the system. These steps effectively improve the quality of the firmware after the upgrade and the overall performance of the device, and ensure the continuous and stable operation of the MCU device.

[0074] Preferably, the present invention further provides an upgrade system for transmitting MCU firmware, which is used to execute the above-mentioned upgrade method for transmitting MCU firmware, and the upgrade system for transmitting MCU firmware includes: The firmware fragment packaging module is used to obtain the firmware file data in the upgrade source device and perform fragment packaging to obtain a standardized firmware file fragment data set; The firmware transmission and unpacking module is used to forward the standardized firmware file segment data set to the target MCU device in real time and perform unpacking processing to obtain the received segment unpacking data set; The data integrity check and repair module is used to perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, the successfully received fragmented unpacked data is generated. If the integrity check fails, the data is retransmitted to generate and repair the received fragmented unpacked data. The fragment data reassembly module is used to reassemble the successfully received fragment unpacked data and the repaired received fragment unpacked data to obtain the complete received firmware file data; The integrity verification and check module is used to verify the integrity of the completely received firmware file data through the MD5 message digest algorithm to obtain the firmware file verification result data; The firmware upgrade and feedback module is used to upgrade the MCU device firmware based on the firmware file verification result data and obtain the MCU device firmware upgrade feedback data.

[0075] The present invention ensures that the firmware data can be efficiently and safely transmitted by slicing and packaging the firmware file. The standardized firmware file slicing data set makes the data processing process more standardized and reduces the complexity and potential errors in the transmission. Through real-time forwarding and unpacking processing, the efficient transmission and reception of the firmware slicing data is ensured, and the possibility of delay and transmission failure is reduced. This module can ensure that the target MCU device accurately receives the firmware data and correctly unpacks it. By performing integrity check on the received data, the correctness of the data during the transmission process is ensured. If an error or packet loss is detected, the system will automatically trigger the data retransmission mechanism for repair, avoiding the failure of the firmware upgrade due to data errors, thereby improving the success rate and reliability of the upgrade. By reorganizing the successfully received and repaired slicing data, it is ensured that the complete firmware file data is accurately reconstructed. This module ensures that even if problems are encountered during the transmission process, the complete data can be effectively restored, and the stability of data reorganization is improved. The firmware file is verified by the MD5 message digest algorithm to ensure that the firmware data has not been tampered with or damaged. This module increases the security of the firmware upgrade process and avoids system failures caused by malicious tampering or transmission errors. Firmware upgrade operations are performed based on the integrity verification results to ensure that the target MCU device receives the verified complete firmware and successfully upgrades. By providing firmware upgrade feedback data, the system can promptly feedback the results of the upgrade process, ensuring that users can obtain the upgrade status in a timely manner, and improving the transparency and success rate of the overall upgrade process.

[0076] Therefore, no matter from which point of view, the embodiments should be regarded as illustrative and non-restrictive, and the scope of the present invention is not limited by the above description, so it is intended to include all changes within the meaning and scope of the equivalent elements of the application documents in the present invention.

[0077] The above description is only a specific embodiment of the present invention, so that those skilled in the art can understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but should conform to the widest scope consistent with the principles and novel features invented herein.

Claims

1. A method for transmitting an upgrade of an MCU firmware, characterized in that: The following steps are involved: Step S1: Obtain the firmware file data in the upgrade source device, and perform segmentation and packaging to obtain a standardized firmware file segmentation data set; Step S2: forwarding the standardized firmware file segment data set to the target MCU device in real time, and performing unpacking processing to obtain a received segment unpacking data set; Step S3: Perform integrity check on the received segmented unpacked data set. If the integrity check succeeds, successfully received segmented unpacked data is generated. If the integrity check fails, the data is retransmitted to generate and repair the received fragment unpacking data; Step S4: recombining the successfully received segment unpacked data and the repaired received segment unpacked data to obtain complete received firmware file data; Step S5: Perform integrity verification on the completely received firmware file data using the MD5 message digest algorithm to obtain firmware file verification result data; Step S6: Perform an MCU device firmware upgrade based on the firmware file verification result data to obtain MCU device firmware upgrade feedback data.

2. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S1 includes the following steps: Step S11: Obtain the firmware file data in the upgrade source device, and perform logical division to obtain a sliced ​​pre-processed firmware file data set; Step S12: performing data marking and standardization processing on the slice pre-processed firmware file data set to obtain a standardized slice marked data set; Step S13: encapsulate the standardized sliced ​​label data set to obtain a standardized firmware file sliced ​​data set.

3. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S2 includes the following steps: Step S21: encrypt and package the standardized firmware file segment data set and send it to the XMOS device, perform message digest, and obtain firmware file upgrade message header data; Step S22: Based on the firmware file upgrade message header data, the standardized firmware file segment data set is forwarded to the target MCU device in real time by using the transparent transmission protocol to obtain transparent transmission real-time forwarding data; Step S23: performing protocol analysis on the transparent real-time forwarding data, and extracting the fragmented data to obtain a parsed fragmented data set; Step S24: Separate the fragmentation mark from the data content based on the parsed fragmentation data set to obtain a received fragmentation unpacked data set.

4. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S3 includes the following steps: Step S31: Read the received sliced ​​unpacked data sets one by one to obtain the sliced ​​data to be verified; Step S32: parsing the verification information field of the fragment data to be verified to obtain the verification preliminary fragment data; Step S33: Perform CRC check calculation on the check preparation slice data to obtain the current slice check result data; Step S34: Perform integrity determination based on the current shard verification result data to obtain shard verification determination data; Step S35: judging the fragment verification judgment data, if the integrity verification succeeds, generating successfully received fragment depacketized data, if the integrity verification fails, generating failed received fragment depacketized data; Step S36: Based on the failed received fragment unpacking data, a retransmission request is made to the upgrade source device to obtain the repaired received fragment unpacking data.

5. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S4 includes the following steps: Step S41: classifying and arranging the generated received fragment unpacking data, and performing integrity check on the repaired received fragment unpacking data, to obtain a fragment unpacking data set to be reassembled; Step S42: performing a shard data merging process on the sharded unpacked data set to be reassembled to obtain a preliminary merged sharded data set; Step S43: numbering and marking the preliminary merged shard data set to obtain a sorted merged shard data set; Step S44: performing data continuity verification based on the sorted and merged sharded data sets to obtain continuity verification result data; Step S45: combining the sorted and merged fragmented data sets based on the continuity verification result data to obtain complete received firmware file data.

6. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S5 includes the following steps: Step S51: Initialize the MD5 digest of the completely received firmware file data to obtain MD5 initialization data; Step S52: Based on the MD5 initialization data, the MD5 message digest algorithm is used to perform a digest calculation on the completely received firmware file data to generate firmware file digest data; Step S53: Compare the firmware file summary data with the preset source file summary data to obtain file summary comparison result data; Step S54: Perform integrity verification on the file summary comparison result data. If the integrity verification fails, a rollback mechanism is executed. If the integrity verification passes, firmware file verification result data is generated.

7. The upgrade method for transmitting MCU firmware according to claim 6, characterized in that: Step S54 includes the following steps: Step S541: parsing the file summary comparison result data to generate summary integrity determination data; Step S542: Perform file integrity status determination based on the summary integrity determination data to obtain file integrity determination result data; Step S543: classify and identify the file integrity determination result data, and if the determination result is failure, generate rollback mechanism trigger data; if the determination result is success, generate firmware file verification result data; Step S544: based on the rollback mechanism triggering data, the firmware backup area of ​​the MCU device is restored, and the process returns to step S2.

8. The upgrade method for transmitting MCU firmware according to claim 1, characterized in that: Step S6 includes the following steps: Step S61: reading and parsing the firmware file verification result data to obtain firmware upgrade permission data; Step S62: Initializing the upgrade environment of the target MCU device based on the firmware upgrade permission data to obtain upgrade environment initialization data; Step S63: partition-burning the complete received firmware file data based on the upgrade environment initialization result data to obtain partition-burning result data; Step S64: configuring the firmware operating environment of the target MCU device based on the partition burning result data to obtain firmware operating environment configuration data; Step S65: performing a firmware activation operation using the firmware operating environment configuration data to obtain firmware activation result data; Step S66: verify the running status of the target MCU device based on the firmware activation result data to obtain the MCU device firmware upgrade feedback data.

9. The upgrade method for transmitting MCU firmware according to claim 8, characterized in that: Step S66 includes the following steps: Step S661: Perform message header comparison analysis on the firmware activation result data and the firmware file upgrade message header data using the MD5 message digest algorithm to obtain upgrade data status verification data; Step S662: Perform a hardware status check on the target MCU device based on the firmware activation result data, and perform a performance evaluation based on the hardware status check result to obtain firmware operation performance data; Step S663: Integrate the upgrade data status verification data with the firmware operation performance data to obtain MCU device upgrade feedback data.

10. An upgrade system for transmitting MCU firmware, characterized in that: Used to execute the upgrade method for transmitting MCU firmware according to claim 1, the upgrade system for transmitting MCU firmware includes: The firmware fragment packaging module is used to obtain the firmware file data in the upgrade source device and perform fragment packaging to obtain a standardized firmware file fragment data set; The firmware transmission and unpacking module is used to forward the standardized firmware file segment data set to the target MCU device in real time and perform unpacking processing to obtain the received segment unpacking data set; The data integrity check and repair module is used to perform integrity check on the received fragmented unpacked data set. If the integrity check succeeds, the successfully received fragmented unpacked data is generated. If the integrity check fails, the data is retransmitted to generate and repair the received fragmented unpacked data. The fragment data reassembly module is used to reassemble the successfully received fragment unpacked data and the repaired received fragment unpacked data to obtain the complete received firmware file data; The integrity verification and check module is used to verify the integrity of the completely received firmware file data through the MD5 message digest algorithm to obtain the firmware file verification result data; The firmware upgrade and feedback module is used to upgrade the MCU device firmware based on the firmware file verification result data and obtain the MCU device firmware upgrade feedback data.

Images