Remote OTA firmware upgrading method and system for multiple MCUs

Abstract

The invention discloses a remote OTA firmware upgrading method for multiple MCUs. The remote OTA firmware upgrading method comprises the steps that a master control MCU receives OTA firmware data issued by a cloud server in real time and stores the OTA firmware data; the main control MCU carries out protocol analysis on the received OTA firmware data, carries out shunting processing on the OTA firmware data and Modbus data, and carries out data analysis and verification on the OTA firmware data to obtain a data packet passing verification; the master control MCU subpacks the data packets passing the verification and forwards the data packets to the target sub-MCUs; the sub-MCUs receive the data packets and carry out subpackage recombination and sequence control on the data packets to form a complete OTA upgrade packet; and the sub MCU executes the Bootloader upgrade according to the OTA upgrade package.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of firmware upgrade, in particular to a remote OTA firmware upgrade method and system for multiple MCUs. BACKGROUND

[0002] With the rapid development of the Internet of Things and intelligent devices, more and more electronic devices adopt multi-MCU architecture design to meet complex functional requirements and performance requirements. Such systems usually include a master MCU, a communication MCU, a power management MCU and other multiple processors working together. In practical applications, it is often necessary to upgrade the firmware of the system to fix bugs or add new functions.

[0003] Currently, there are mainly the following upgrade schemes:

[0004] 1. Single MCU upgrade scheme: simple to implement, clear upgrade process, low resource occupation and low cost, but not suitable for complex multi-MCU systems, and the system needs to be stopped during the upgrade process, with high risk of upgrade failure.

[0005] 2. Serial multi-MCU upgrade scheme: can gradually implement the upgrade of multiple MCUs, relatively simple to implement, but has the disadvantages of long upgrade time, multiple system restarts, asynchronous between MCUs, and difficult recovery after upgrade failure.

[0006] Both of these two schemes have the problems of imperfect power-off protection mechanism, missing version rollback function, difficult upgrade state synchronization, and multiple restarts during the upgrade process. SUMMARY

[0007] The purpose of the present application is to provide a remote OTA firmware upgrade method and system for multiple MCUs, which improves the reliability, security and automation level of remote upgrade of embedded devices.

[0008] The present application is achieved by the following technical solutions:

[0009] In a first aspect, the present application provides a remote OTA firmware upgrade method for multiple MCUs, comprising:

[0010] The master MCU receives and stores OTA firmware data issued by a cloud server in real time;

[0011] The master MCU performs protocol analysis on the received OTA firmware data, and processes the OTA firmware data and Modbus data separately, performs data analysis and verification on the OTA firmware data, and obtains a data packet that passes the verification;

[0012] The master MCU forwards the verified data packet to the target sub-MCU after packet splitting;

[0013] The sub-MCU receives the data packet and performs packet reassembly and sequence control to form a complete OTA upgrade package.

[0014] The sub-MCU performs Bootloader upgrade according to the OTA upgrade package.

[0015] Further, the specific method for the master MCU to perform data analysis and verification on the OTA firmware data to obtain a data packet that passes the verification includes:

[0016] In the initial state, the first byte of the frame header is waited for, and after the frame header is identified, the state is switched to the frame header identification state.

[0017] The complete frame header sequence is verified.

[0018] The packet header data is analyzed.

[0019] The data is received according to the data length, and after the reception is completed, the verification state is entered.

[0020] The CRC value at the end of the data packet is read and verified for consistency, and if the verification passes, the forwarding is prepared, otherwise the data retransmission is requested from the cloud server.

[0021] Further, the specific method for the sub-MCU to perform Bootloader upgrade according to the OTA upgrade package includes:

[0022] After the sub-MCU is powered on, the Bootloader initialization process is performed.

[0023] The Bootloader reads the flag information related to OTA from the firmware information area.

[0024] The Bootloader determines whether there is new firmware according to the flag information related to OTA.

[0025] If not, no upgrade is performed and the process ends.

[0026] If so, the backup area is erased and the backup area flag bit is cleared, the firmware in the current running area is completely copied to the backup area as rollback protection.

[0027] The backup firmware in the backup area is verified for completeness.

[0028] If complete and undamaged, the backup area flag bit is set and it is determined whether the backup area flag bit is set, and if set, the upgrade is performed, the firmware in the OTA storage area is moved to the current running area for coverage, the CRC value of the current running area is recalculated after the original program is covered, and the CRC value of the current running area is compared with the CRC value of the OTA firmware data.

[0029] If not complete, the backup failure count is incremented by 1 and the abnormal processing step is entered.

[0030] Further, the checking whether the backup firmware in the backup area is complete specifically comprises:

[0031] The Bootloader calculates the CRC value of the backup firmware, and compares the calculated CRC value of the backup firmware with the CRC value of the current running area.

[0032] Further, after the sub-MCU performs the Bootloader upgrade step according to the OTA upgrade package, the method further comprises:

[0033] When the CRC value of the current running area is consistent with the CRC value of the OTA firmware data, it indicates that the upgrade is successful, and then the OTA upgrade flag bit is cleared, and the latest upgraded firmware program is executed by jumping;

[0034] If the upgrade fails, the failure count is increased by 1, and whether the maximum retry count is exceeded is determined;

[0035] If not, the upgrade is reattempted;

[0036] If yes, the current running area is erased, and the content of the backup area is restored to the current running area;

[0037] The CRC values of the backup area and the current running area are checked again;

[0038] If consistent, the OTA upgrade failure flag is set, and the old program before the upgrade is executed by jumping;

[0039] If not, the process is ended.

[0040] In a second aspect, another embodiment of the present application provides a remote OTA firmware upgrade system for multiple MCUs, comprising a cloud server, a master MCU and multiple sub-MCUs.

[0041] The data receiving module is configured to receive and store the OTA firmware data sent by the cloud server in real time.

[0042] The analysis module is configured to analyze the protocol of the received OTA firmware data, and process the OTA firmware data and the Modbus data in a separate manner.

[0043] The CAN forwarding module is configured to forward the data packets that pass the checking to the target sub-MCU after packetizing the data packets.

[0044] The sub-MCU comprises a packet recombination module and an upgrade module.

[0045] The packet recombination module is configured to recombine and sequentially control the received data packets to form a complete OTA upgrade package.

[0046] The upgrade module is configured to perform Bootloader upgrade according to the OTA upgrade package.

[0047] Further, the parsing module comprises a data parsing unit and a checking unit.

[0048] The data parsing unit is configured to switch to a frame header identification state after identifying a frame header, verify a complete frame header sequence, and parse packet header data.

[0049] The checking unit is configured to read and check a CRC value at the end of a data packet after receiving data according to a data length, and if the checking is passed, prepare to forward, or if not, request data retransmission from a cloud server.

[0050] Further, the upgrade module comprises an initialization unit, an OTA information reading unit, a judging unit, a backup management unit, a backup firmware checking unit, and a backup flag bit judging unit.

[0051] The initialization unit is configured to perform an initialization process of Bootloader after the sub-MCU is powered on.

[0052] The OTA information reading unit is configured to read flag information related to OTA from a firmware information area.

[0053] The judging unit is configured to judge whether there is new firmware according to the flag information related to OTA.

[0054] The backup management unit is configured to, when there is new firmware, erase a backup area, clear a backup area flag bit, completely copy firmware in a current running area to the backup area as a rollback protection.

[0055] The backup firmware checking unit is configured to check whether backup firmware in the backup area is complete.

[0056] The backup flag bit judging unit is configured to, when the backup firmware is complete and undamaged, set the backup area flag bit and judge whether the backup area flag bit is set, and perform upgrade when the backup area flag bit is set.

[0057] Further, the backup firmware checking unit is configured to check whether backup firmware in the backup area is complete, specifically, calculate a CRC value of the backup firmware and compare the CRC value with a CRC value of the current running area, if the CRC values are consistent, it indicates that the backup firmware is complete and undamaged, and if the CRC values are inconsistent, it indicates that the backup firmware is incomplete.

[0058] Furthermore, the system also includes an upgrade completion and recovery module. This module is used to determine if the upgrade is successful when the CRC value of the current running area matches the CRC value of the OTA firmware data. In this case, the OTA upgrade flag is cleared, and execution of the latest upgraded firmware program is initiated. If the upgrade fails, the failure count is incremented by 1, and it is checked whether the maximum number of retries has been exceeded. If not, the upgrade is retried. If the maximum number of retries has been exceeded, the current running area is erased, and the contents of the backup area are restored to the current running area. The CRC values ​​of the backup area and the current running area are checked again. If they match, the OTA upgrade failure flag is set, and execution of the old program before the upgrade is initiated is initiated. If they do not match, the process ends. Compared with the prior art, this invention has the following advantages and beneficial effects:

[0059] This invention provides a remote OTA firmware upgrade method and system for multiple MCUs. The system coordinates the firmware upgrade process between a cloud server and multiple sub-MCUs through a master MCU. It employs a multi-level communication mechanism combining serial port and CAN bus to achieve highly reliable packet transmission of firmware, secure bootloader upgrades, response retransmission, anomaly recovery, and upgrade confirmation. This significantly improves the reliability, security, and automation level of remote upgrades for embedded devices. It possesses anomaly self-recovery capabilities, supports unified scheduling of multiple MCUs, is compatible with various communication protocols, and is suitable for intelligent maintenance and upgrades of large-scale distributed devices. This solution not only reduces maintenance costs but also greatly improves device availability and lifespan, possessing broad industrial application prospects and significant technological innovation value. Furthermore, it ensures that the device will not crash in the event of power outages or upgrade anomalies, always returning to a usable state, greatly enhancing system reliability and engineering practicality. Attached Figure Description

[0060] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0061] Figure 1 A flowchart illustrating a remote OTA firmware upgrade method for multiple MCUs provided in the first embodiment of the present invention;

[0062] Figure 2 This is a schematic diagram of the on-chip Flash partitioning of the sub-MCU;

[0063] Figure 3 This is a schematic diagram of a multi-MCU remote OTA firmware upgrade system provided in another embodiment of the present invention. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0065] like Figure 1 As shown, the first embodiment of the present invention provides a remote OTA firmware upgrade method for multiple MCUs, including the following steps:

[0066] The main control MCU receives and stores OTA firmware data sent from the cloud server in real time;

[0067] The main control MCU performs protocol parsing on the received OTA firmware data, separates the OTA firmware data from the Modbus data, and performs data parsing and verification on the OTA firmware data to obtain the data packets that pass the verification.

[0068] The main control MCU will repackage the verified data packets and forward them to the target sub-MCU;

[0069] The sub-MCU receives data packets and performs packet reassembly and sequence control to form a complete OTA upgrade package;

[0070] The sub-MCU performs a bootloader upgrade based on the OTA upgrade package.

[0071] In this embodiment, the main control MCU receives OTA firmware data from the cloud server (host computer) in real time via serial port. Each new byte received is immediately written to a circular buffer to prevent data loss. A circular buffer is used to manage the received data, combined with a timestamp mechanism, to periodically detect timeouts and automatically clear abnormal data, preventing deadlocks and resource waste. The main control MCU performs protocol parsing on the received OTA firmware data, identifies the OTA upgrade function code (such as 0x08), and separates the OTA data from ordinary Modbus data. The Modbus data is transmitted via serial port, ensuring efficient operation in a multi-protocol environment.

[0072] The main control MCU uses a multi-level state machine (such as IDLE, HEADER, DATA) to parse the OTA firmware data, and completes frame header recognition, packet header parsing, data reception and verification in a distributed manner.

[0073] IDLE (Idle State): Waiting for new OTA packets to arrive, switching to HEADER state after detecting the frame header.

[0074] HEADER (Frame Header Recognition Status): Parses packet header data, such as target address, packet sequence number, total number of packets, data length, and other key information. Upon successful verification, it enters the DATA state. If an error occurs, it returns the corresponding error code to the cloud server and re-enters the IDLE state.

[0075] DATA (Data Reception Status): Receives data according to the length specified in the packet header, accumulates the number of bytes, and enters CRC check status after reception is complete.

[0076] CRC (Cyclic Redundancy Check): Reads and verifies the CRC at the end of the data packet to ensure data integrity. If the verification passes, it is ready to be forwarded; otherwise, it requests the data to be retransmitted from the cloud server.

[0077] Error and timeout handling: During the parsing process, timeouts and format errors are continuously monitored, the state machine is automatically reset and the cache is cleared to ensure system robustness.

[0078] The OTA firmware data, which has passed verification, is read from external Flash into the main control MCU's transmit buffer using a first-in, first-out (FIFO) method. After the OTA firmware data packet is written to the transmit buffer, CAN transmission is triggered.

[0079] Because OTA firmware data is large, CAN frame construction and packetization are generally required. Specifically, the main control MCU parses and verifies the data packets, then forwards them to the target sub-MCU via the CAN bus. Since the maximum payload of a CAN frame is 8 bytes, the system automatically packets the large data packets, each with a sequence number and verification information. The sending service program then sends the data frame by frame to the sub-MCU's OTA storage area. The target sub-MCU is identified by a flag bit indicating that the data packet should be sent to the target sub-MCU when the cloud server sends the OTA firmware data. The main control MCU then communicates with the target sub-MCU based on the flag bit, receives its response, and sends the OTA firmware data to it. Packet reassembly and sequence control (performed by the sub-MCU): Each data packet has a sequence number, which the sub-MCU can use to reassemble the data. If a non-contiguous sequence number or packet loss is detected, the sub-MCU can request the main control MCU to retransmit the specified packet. The reassembled data forms a complete OTA upgrade package. Figure 2 As shown, the on-chip Flash partition of the sub-MCU includes: Bootloader area, application area, backup area, OTA storage area, and firmware information area. In embedded systems, Flash partitioning divides the Flash memory into multiple independent logical regions, each performing a specific function to achieve modular management, security upgrades, and data protection of the MCU system. A well-designed Flash partition is crucial for the stability, maintainability, and security of the MCU system.

[0080] After the sub-MCU powers on, the Bootloader initialization process is executed first. This initialization process includes hardware peripheral initialization, Flash controller configuration, and clearing of key registers and variables, preparing for subsequent firmware verification and upgrades. The Bootloader is the first program to run after the embedded system powers on. It is responsible for initializing the hardware and booting the operating system or application. It is a crucial bridge connecting the hardware and upper-layer software, and is essential to the system's reliability and security.

[0081] The bootloader reads OTA-related flags from the firmware information area, including: version number, availability of new firmware, backup status, upgrade flag, and failure count. This information determines subsequent upgrade decisions and branching.

[0082] The bootloader determines whether new firmware exists based on the OTA flag. If no new firmware is available, it jumps directly to the existing application (APP), and the process ends. The existing application can be considered the previous firmware version. If new firmware is available, it proceeds to the backup and flag management steps.

[0083] Backup and Flag Management: When a new OTA firmware is detected, the backup area is erased. To ensure data security, the backup area is erased first, and its flag is cleared. Firmware Backup: The firmware of the currently running (application) area is completely copied to the backup area as a rollback protection.

[0084] Verify the integrity of the backup firmware in the backup area: This is done through CRC check. Specifically, the bootloader calculates the CRC value of the backup firmware and compares it with the CRC value of the currently running area to determine if they match. Consistency check: If the CRC values ​​match, it means the backup firmware is complete and undamaged, and the system proceeds to the backup area flag and rollback check; otherwise, the backup failure count is incremented by 1, and the system enters the exception handling branch.

[0085] Backup flag and rollback check: Set the backup flag in the firmware information area to indicate that the old firmware has been backed up. This is usually achieved by setting a specific value for the flag or version number. Check if the backup flag is set. If not set, the upgrade will not proceed and the process will end; if set, the upgrade process will be executed.

[0086] Upgrade Process: The firmware from the OTA storage area is transferred and overwritten by the current running area, replacing the existing program. After the transfer is complete, the CRC value of the current running area is recalculated and compared with the CRC value of the OTA firmware data. If the CRC values ​​match, the upgrade is successful, the OTA upgrade flag is cleared, and the process jumps to execute the latest upgraded firmware program. If the CRC values ​​do not match, the failure count is incremented by 1, and it is checked whether the maximum number of retries (e.g., 3) has been exceeded. If not, the upgrade is retried; if the maximum number of retries is exceeded, the rollback and fault tolerance steps are initiated.

[0087] Rollback and fault tolerance: After exceeding the maximum number of retries, the current running area is erased, and the contents of the backup area are restored to the current running area. The CRC value of the backup area is then checked against the CRC value of the current running area. If they match, the OTA upgrade failure flag is set, and the process jumps to execute the old program before the upgrade; otherwise, the process terminates. Rollback and fault tolerance can ensure that the device will not crash in the event of power failure, upgrade anomalies, etc., and can always be restored to a usable state, greatly improving the reliability and engineering practicality of the system.

[0088] This invention provides a remote OTA firmware upgrade method for multiple MCUs. The main control MCU coordinates the firmware upgrade process between a cloud server and multiple sub-MCUs. It employs a multi-level communication mechanism combining serial port and CAN bus to achieve highly reliable packet transmission of firmware, secure bootloader upgrades, response retransmission, anomaly recovery, and upgrade confirmation. This significantly improves the reliability, security, and automation level of remote upgrades for embedded devices. It also features anomaly self-recovery capabilities, supports unified scheduling of multiple MCUs, is compatible with various communication protocols, and is suitable for intelligent maintenance and upgrades of large-scale distributed devices. This solution not only reduces maintenance costs but also greatly improves device availability and lifespan, possessing broad industrial application prospects and significant technological innovation value. Furthermore, it ensures that the device will not crash in the event of power outages or upgrade anomalies, always returning to a usable state, greatly enhancing system reliability and engineering practicality.

[0089] like Figure 3As shown in another embodiment of the present invention, a multi-MCU remote OTA firmware upgrade system includes: a cloud server, a main control MCU, and multiple sub-MCUs. The main control MCU is used to forward OTA firmware data sent by the cloud server to the sub-MCUs. The main control MCU includes a data receiving module, a parsing module, and a CAN forwarding module. The data receiving module is used to receive and store the OTA firmware data sent by the cloud server in real time. The parsing module is used to perform protocol parsing on the received OTA firmware data, separate the OTA firmware data from Modbus data, and perform data parsing and verification on the OTA firmware data to obtain verified data packets. The CAN forwarding module is used to repackage the verified data packets and forward them to the target sub-MCUs. The sub-MCUs include a packet reassembly module and an upgrade module. The packet reassembly module is used to reassemble the received data packets and perform sequence control to form a complete OTA upgrade package. The upgrade module is used to perform a Bootloader upgrade according to the OTA upgrade package.

[0090] The parsing module includes a data parsing unit and a verification unit. The data parsing unit switches to the frame header recognition state after recognizing the frame header, verifies the complete frame header sequence, and parses the packet header data, which includes the target address, packet sequence number, total number of packets, and data length. After successful verification, it enters the data receiving state. The verification unit reads and verifies whether the CRC value at the end of the data packet is consistent after receiving the data according to the data length. If the verification is successful, it prepares to forward the data; otherwise, it requests the cloud server to retransmit the data.

[0091] The upgrade module includes an initialization unit, an OTA information reading unit, a judgment unit, a backup management unit, a backup firmware verification unit, and a backup flag bit judgment unit. The initialization unit executes the Bootloader initialization process after the sub-MCU is powered on, including hardware peripheral initialization, Flash controller configuration, and clearing of key registers and variables. The OTA information reading unit reads OTA-related flag information from the firmware information area, including: version number, whether there is new firmware, backup area status, upgrade status, and failure count. The judgment unit determines whether new firmware exists based on the OTA-related flag information. When new firmware exists, the backup management unit erases the backup area and clears the backup area flag bit, then completely copies the firmware from the current running area to the backup area as rollback protection. The backup firmware verification unit verifies whether the backup firmware in the backup area is complete. The backup flag bit judgment unit sets the backup area flag bit and determines whether the backup area flag bit is set when the backup firmware is complete and undamaged; if set, the upgrade is performed.

[0092] The backup firmware verification unit is used to verify whether the backup firmware in the backup area is complete. Specifically, it calculates the CRC value of the backup firmware and compares it with the CRC value of the current running area. If they match, it means that the backup firmware is complete and undamaged. If they do not match, it means that the backup firmware is incomplete.

[0093] The system also includes an upgrade completion and recovery module. This module determines that the upgrade was successful when the CRC value of the current running area matches the CRC value of the OTA firmware data. It then clears the OTA upgrade flag and jumps to execute the latest firmware upgrade program. If the upgrade fails, the failure count is incremented by 1, and it is checked whether the maximum number of retries has been exceeded. If not, the upgrade is retried. If the maximum number of retries has been exceeded, the current running area is erased, and the contents of the backup area are restored to the current running area. The CRC values ​​of the backup area and the current running area are checked again. If they match, the OTA upgrade failure flag is set, and the old program before the upgrade is executed is executed. If they do not match, the process ends.

[0094] This invention provides a multi-MCU remote OTA firmware upgrade system. The system coordinates the firmware upgrade process between a cloud server and multiple sub-MCUs through a master MCU. It employs a multi-level communication mechanism combining serial port and CAN bus to achieve highly reliable packet transmission of firmware, secure bootloader upgrades, response retransmission, anomaly recovery, and upgrade confirmation. This significantly improves the reliability, security, and automation level of remote upgrades for embedded devices. It features anomaly self-recovery capabilities, supports unified scheduling of multiple MCUs, is compatible with various communication protocols, and is suitable for intelligent maintenance and upgrades of large-scale distributed devices. This solution not only reduces maintenance costs but also greatly improves device availability and lifespan, possessing broad industrial application prospects and significant technological innovation value. Furthermore, it ensures that the device will not crash in the event of power outages or upgrade anomalies, always returning to a usable state, greatly enhancing system reliability and engineering practicality.

[0095] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A multi-MCU remote OTA firmware upgrade method, characterized in that, The application comprises the following steps: The main control MCU receives OTA firmware data sent by a cloud server and stores the data; The main control MCU analyzes the received OTA firmware data according to a protocol, processes the OTA firmware data and Modbus data separately, analyzes and checks the OTA firmware data, and obtains data packets that pass the check; The main control MCU forwards the data packets that pass the check to a target sub-MCU after packetizing the data packets; The sub-MCU receives the data packets, reorganizes and controls the order of the data packets, and forms complete OTA upgrade packets; The sub-MCU executes Bootloader upgrade according to the OTA upgrade packets.

2. The multi-MCU remote OTA firmware upgrade method of claim 1, wherein, The specific method for the main control MCU to analyze and check the OTA firmware data to obtain data packets that pass the check comprises the following steps: In an initial state, the first byte of a frame header is waited for, and after the frame header is identified, the state is switched to a frame header identification state; A complete frame header sequence is verified; Packet header data is analyzed; Data is received according to the data length, and after the data is received, a check state is entered; The CRC value at the end of the data packet is read and checked for consistency, and if the check passes, the data packet is forwarded, otherwise, the cloud server is requested to resend the data.

3. The multi-MCU remote OTA firmware upgrade method of claim 1, wherein, The specific method for the sub-MCU to execute Bootloader upgrade according to the OTA upgrade packets comprises the following steps: After the sub-MCU is powered on, the initialization process of Bootloader is executed; Bootloader reads the flag information related to OTA from the firmware information area; Bootloader determines whether there is new firmware according to the flag information related to OTA; If not, the process ends without upgrading; If yes, the backup area is erased, the backup area flag bit is cleared, the firmware in the current running area is completely copied to the backup area as rollback protection; The backup firmware in the backup area is checked for completeness; If complete and undamaged, the backup area flag bit is set and it is determined whether the backup area flag bit is set, and if set, the upgrade is executed, the firmware in the OTA storage area is moved to the current running area to overwrite the original program, and the CRC value of the current running area is recalculated and compared with the CRC value of the OTA firmware data; If not complete, the backup failure count is increased by 1, and the process enters an abnormal handling step.

4. The multi-MCU remote OTA firmware upgrade method of claim 3, wherein, The specific method for checking whether the backup firmware in the backup area is complete comprises the following steps: Bootloader calculates the CRC value of the backup firmware, and compares the calculated CRC value of the backup firmware with the CRC value of the current running area, if consistent, it indicates that the backup firmware is complete and undamaged, if not consistent, it indicates that the backup firmware is not complete.

5. The multi-MCU remote OTA firmware upgrade method of claim 4, wherein, After the step of the sub-MCU executing Bootloader upgrade according to the OTA upgrade packets, the following steps are further included: When the CRC value of the current running area is consistent with the CRC value of the OTA firmware data, it indicates that the upgrade is successful, the OTA upgrade flag bit is cleared, and the latest upgraded firmware program is executed by jumping; If not, the failure count is increased by 1, and it is determined whether the maximum retry count is exceeded; If not, the upgrade is reattempted; If yes, the current running area is erased, and the content of the backup area is restored to the current running area; The CRC values of the backup area and the current running area are checked again for consistency; If consistent, set OTA upgrade failure flag, jump to execute old program without upgrade; If inconsistent, end. 6.A multi-MCU remote OTA firmware upgrade system, characterized in that, It comprises: a cloud server, a master MCU and a plurality of slave MCUs, the master MCU is used to forward OTA firmware data sent by the cloud server to the slave MCUs, and the master MCU comprises a data receiving module, an analysis module and a CAN forwarding module; the data receiving module is used to receive OTA firmware data issued by the cloud server in real time and store the OTA firmware data; the analysis module is used to analyze the protocol of the received OTA firmware data, split the OTA firmware data and the Modbus data, analyze and check the OTA firmware data to obtain a data packet that passes the check; the CAN forwarding module is used to forward the data packet that passes the check to a target slave MCU after packet splitting; the slave MCU comprises a packet splitting and recombining module and an upgrade module; the packet splitting and recombining module is used to split and recombine the received data packet and control the sequence to form a complete OTA upgrade packet; the upgrade module is used to execute Bootloader upgrade according to the OTA upgrade packet.

7. The multi-MCU remote OTA firmware upgrade system of claim 6, wherein, The analysis module comprises a data analysis unit and a check unit; the data analysis unit is used to switch to a frame header identification state after identifying a frame header, verify a complete frame header sequence and analyze packet header data; the check unit is used to read and check whether a CRC value at the end of a data packet is consistent after receiving data according to a data length, prepare to forward if the check passes, or request data retransmission from the cloud server if the check fails.

8. The multi-MCU remote OTA firmware upgrade system of claim 6, wherein, The upgrade module comprises an initialization unit, an OTA information reading unit, a judgment unit, a backup management unit, a backup firmware check unit and a backup flag bit judgment unit; the initialization unit is used to execute an initialization process of Bootloader after the slave MCU is powered on; the OTA information reading unit is used to read flag information related to OTA from a firmware information area; the judgment unit is used to judge whether there is new firmware according to the flag information related to OTA; the backup management unit is used to erase a backup area and clear a backup area flag bit, copy firmware in a current running area to the backup area completely as rollback protection when there is new firmware; the backup firmware check unit is used to check whether backup firmware in the backup area is complete; the backup flag bit judgment unit is used to set the backup area flag bit and judge whether the backup area flag bit is set when the backup firmware is complete and undamaged, and execute upgrade when the backup area flag bit is set.

9. The multi-MCU remote OTA firmware upgrade system of claim 8, wherein, The backup firmware check unit is used to check whether backup firmware in the backup area is complete, specifically: calculate a CRC value of the backup firmware, and compare the CRC value with a CRC value of the current running area, if consistent, it indicates that the backup firmware is complete and undamaged, if inconsistent, it indicates that the backup firmware is incomplete.

10. The multi-MCU remote OTA firmware upgrade system of claim 9, wherein, The system further comprises an upgrade completion and recovery module, the upgrade completion and recovery module is used to clear an OTA upgrade flag bit, jump to execute a firmware program of the latest upgrade when a CRC value of the current running area is consistent with a CRC value of the OTA firmware data, indicating that the upgrade is successful, or increase a failure count by 1 and judge whether the failure count exceeds a maximum retry number if the upgrade fails. If not, re-try the upgrade; If yes, erase the current running area and restore the backup area content to the current running area; Check again if the CRC values of the backup area and the current running area are consistent; If yes, set the OTA upgrade failure flag and jump to execute the old program without upgrade; If no, end.

Images