System firmware upgrade method, terminal device, and computer program product

Abstract

This application relates to the field of embedded system technology, and provides a system firmware upgrade method, terminal device, and computer program product. The system includes a master MCU and at least one slave MCU connected to the master MCU. The master MCU's flash memory has a shared master-slave backup area. The method includes: in response to a first instruction sent by a host computer, entering a firmware download mode and sending a second instruction to the host computer; receiving upgrade verification data and firmware data sent by the host computer in response to the second instruction and storing the firmware data in the shared master-slave backup area, the upgrade verification data including the firmware type of the firmware data; and using the firmware data in the shared master-slave backup area to upgrade the firmware of a target MCU, where the target MCU is the MCU whose firmware type corresponds to that of the master and slave MCUs. This application enables master and slave MCUs to share the same backup area for firmware upgrades, saving storage resources of the slave MCU, reducing hardware costs, and providing a unified and efficient upgrade solution.

Description

Technical Field

[0001] This application relates to the field of embedded system technology, specifically to a system firmware upgrade method, terminal device, and computer program product. Background Technology

[0002] In embedded control systems, the master-slave MCU architecture is widely used in industrial automation, smart homes, and automotive electronics to achieve complex logic control and peripheral management. Existing solutions for firmware upgrades in this architecture typically employ wireless communication methods (such as Wi-Fi or BLE) to independently upgrade the master and slave devices, or to perform ISP (In-System Programming) or IAP (In-Application Programming) upgrades on a single MCU. In wired master-slave scenarios, the conventional implementation involves allocating an independent code backup area in each slave device's Flash memory. During upgrades, the new firmware is downloaded to each slave's respective backup area, and then each slave performs verification and jump operations.

[0003] However, in the existing technology, each slave device needs to be configured with an independent code backup area and corresponding bootloader resources, which increases the hardware storage cost. Moreover, for a master-slave system without a wireless communication module, there is a lack of a universal solution that can utilize host resources to uniformly manage and efficiently complete firmware upgrades for all nodes. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a system firmware upgrade method, a master-slave system, a terminal device, and a computer program product, which solves the problem of high hardware costs caused by each slave device independently occupying flash memory resources under the traditional master-slave architecture, realizes low-cost and highly reliable master-slave system firmware upgrade, and provides a unified upgrade solution in scenarios without wireless modules.

[0005] To achieve the above objectives, this application provides the following technical solution: The first aspect of this application provides a system firmware upgrade method, the system including a master MCU and at least one slave MCU connected to the master MCU, the master MCU having a shared master-slave backup area in its flash memory, the method being applied to the master MCU, the method comprising: In response to the first instruction sent by the host computer, the device enters firmware download mode and sends a second instruction to the host computer. The system receives upgrade verification data and firmware data sent by the host computer in response to the second instruction and stores the firmware data in the master-slave shared backup area. The upgrade verification data includes the firmware type of the firmware data. The firmware data in the master-slave shared backup area is used to upgrade the firmware of the target MCU, where the target MCU is the MCU with the firmware type corresponding to the master MCU and the slave MCU.

[0006] In an optional embodiment, upgrading the firmware of the target MCU using the firmware data in the master-slave shared backup area includes: The target MCU is determined from the master MCU and the slave MCUs, based on the firmware type. Control the target MCU to enter firmware upgrade mode; The firmware data in the master-slave shared backup area is burned into the application execution code area of ​​the target MCU.

[0007] In an optional embodiment, the flash memory of the main MCU further includes a main firmware flag area. After determining the MCU corresponding to the firmware type as the target MCU from the main MCU and the slave MCU, the method further includes: When the firmware type is a main MCU firmware, the main MCU is determined to be the target MCU and the upgrade verification data is written into the main firmware flag area; After burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU, the method further includes: The firmware data in the application execution program code area of ​​the main MCU is verified based on the upgrade verification data in the main firmware flag area, and a verification result is generated. If the verification result indicates that the main MCU firmware upgrade was successful, then the main firmware flag area is cleared; If the verification result indicates that the main MCU firmware upgrade was unsuccessful, then return to the step of copying the firmware data from the master-slave shared backup area to the application execution code area of ​​the main MCU.

[0008] In an optional embodiment, the flash memory of the master MCU further includes a firmware flag area. After determining from the master MCU and the slave MCU that the MCU corresponding to the firmware type is the target MCU, the method further includes: When the firmware type is slave MCU firmware, the slave MCU corresponding to the firmware type is determined as the target MCU and the upgrade verification data is written into the slave firmware flag area; After burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU, the method further includes: Based on the upgrade verification data from the firmware flag area, the firmware data in the application execution program code area of ​​the target MCU is verified and a verification result is generated. If the verification result indicates that the target MCU firmware upgrade is successful, then pull the boot pin of the target MCU low, restart the target MCU, and clear the slave firmware flag area; If the verification result indicates that the firmware upgrade of the target MCU was unsuccessful, then return to the step of controlling the target MCU to enter firmware upgrade mode.

[0009] In one optional embodiment, controlling the target MCU to enter firmware upgrade mode includes: When the target MCU is the main MCU, the main MCU is restarted and enters boot mode; If the target MCU is a slave MCU, pull the boot pin of the target MCU high and power on the slave MCU again to put the MCU into programming mode.

[0010] In an optional embodiment, burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU includes: When the target MCU is the master MCU, the firmware data in the master-slave shared backup area is copied to the application execution code area of ​​the master MCU; When the target MCU is a slave MCU, the firmware data in the master-slave shared backup area is burned to the application execution code area of ​​the target MCU based on the original manufacturer's burning protocol.

[0011] In one optional embodiment, the upgrade verification data further includes firmware data length; Before upgrading the firmware of the target MCU using the firmware data in the master-slave shared backup area, the process also includes: Calculate the actual length of the firmware data in the master-slave shared backup area; If the actual length is inconsistent with the firmware data length, a firmware data retransmission request is sent to the host computer. The steps include receiving firmware data sent by the host computer in response to the firmware data retransmission request, storing the firmware data in the master-slave shared backup area, and returning the actual length of the firmware data in the master-slave shared backup area.

[0012] In one optional embodiment, the upgrade verification data further includes an integrity verification code; After calculating the actual length of the firmware data in the master-slave shared backup area, the method further includes: When the actual length is consistent with the firmware data length, the firmware data in the master-slave backup area is verified for integrity based on the integrity check code. If the firmware data in the master-slave backup area fails the integrity check, a firmware data retransmission request is sent to the host computer.

[0013] A second aspect of this application provides a system firmware upgrade method applied to a host computer, the system including a main MCU and at least one slave MCU connected to the main MCU, the method comprising: In response to the upgrade command input by the user, a first command is sent to the main MCU of the system; Upon receiving a second instruction sent by the master MCU in response to the first instruction, upgrade verification data and firmware data are sent to the master MCU. The upgrade verification data includes the firmware type of the firmware data. The firmware data is used to upgrade the target MCU in the system. The target MCU is the MCU corresponding to the firmware type in the master MCU and the slave MCU.

[0014] In an optional embodiment, the method further includes: In response to the firmware data retransmission request sent by the main MCU, the firmware data is sent to the main MCU.

[0015] A third aspect of this application provides a master-slave system, including a master MCU and at least one slave MCU connected to the master MCU via a boot pin and a serial communication interface. The flash memory of the master MCU is provided with a master-slave shared backup area, a BOOT area and an application execution code area, and the flash memory of the slave MCU is provided with an application execution code area. The main MCU is used to perform the steps of the method as described in any of the first aspects of this application.

[0016] In one alternative embodiment, the serial communication interface is either a universal asynchronous transceiver or a universal synchronous asynchronous transceiver.

[0017] A fourth aspect of this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that... When the terminal device is the main MCU, the processor executes the computer program to implement the steps of the system firmware upgrade method as described in any of the first aspects of this application; When the terminal device is a host computer, the processor executes the computer program to implement the steps of the system firmware upgrade method as described in the second aspect of this application.

[0018] The fifth aspect of this application provides a computer program product, including a computer program that, when run, causes a system firmware upgrade method as described in either the first or second aspect of this application to be executed.

[0019] Beneficial effects: This application provides a system firmware upgrade method, a master-slave system, a terminal device, and a computer program product. By setting a shared backup area in the flash memory of the master MCU, and based on upgrade verification data containing the firmware type issued by the host computer, targeted upgrades can be performed on either the master or slave MCU. This eliminates the need to configure a separate backup area for each slave MCU, effectively solving the problem of high hardware costs caused by each slave device independently occupying flash memory resources in traditional master-slave architectures. It achieves low-cost, highly reliable firmware upgrades for master-slave systems and provides a unified upgrade solution for scenarios without wireless modules. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram illustrating the implementation process of the system firmware upgrade method provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating the implementation process of the system firmware upgrade method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the master-slave system provided in the embodiments of this application; Figure 4 This is a schematic diagram of the terminal device provided in the embodiments of this application; Figure 5 This is a schematic diagram of a computer program product provided in an embodiment of this application. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0028] In one embodiment of this application, the embedded system upgrade technology, for a master-slave MCU system, uses a method of configuring an independent code backup area for each slave device for firmware updates. This approach leads to a waste of hardware resources and increases project costs. Furthermore, for wired connection systems without wireless communication modules (such as Wi-Fi or BLE), there is a lack of a unified, efficient, and low-cost firmware upgrade solution, making centralized management of master and slave devices difficult.

[0029] like Figure 1As shown in the figure, this application provides a system firmware upgrade method. The system includes a master MCU and at least one slave MCU connected to the master MCU. The master MCU has a shared master-slave backup area in its flash memory. The method is applied to the master MCU and includes: Step S1: In response to the first instruction sent by the host computer, enter the firmware download mode and send a second instruction to the host computer.

[0030] In the application, the first instruction is a firmware upgrade request signal initiated by the host computer, used to trigger the state switch of the main MCU. Upon receiving the first instruction, the main MCU immediately interrupts the current application execution flow and jumps to the preset Bootloader program segment, thus entering firmware download mode. In this mode, the main MCU sends a second instruction to the host computer via the serial communication interface. This second instruction serves as a handshake confirmation signal, indicating that the main MCU is ready and requests the host computer to send the specific upgrade data package. For example, the first instruction could be a specific UART interrupt character 0xAA. After parsing this character, the main MCU replies with a second instruction 0x55 containing baud rate negotiation information or a ready flag to the host computer. Through the interaction of the first and second instructions, a reliable communication link is established between the host computer and the main MCU, ensuring the synchronization of subsequent large data transmissions.

[0031] Step S2: Receive upgrade verification data and firmware data sent by the host computer in response to the second instruction, and store the firmware data in the master-slave shared backup area. The upgrade verification data includes the firmware type of the firmware data.

[0032] In applications, upgrade verification data is metadata accompanying firmware data transmission, originating from a header packet generated by the host computer based on the firmware file to be upgraded. The upgrade verification data includes at least the firmware type, which identifies whether the current firmware is applicable to the master MCU or a specific slave MCU (e.g., slave MCU1, slave MCU2, etc.). The firmware data is complete binary executable code. Upon receiving this data, the master MCU does not immediately program it; instead, it writes it completely to the shared master-slave backup area in flash memory. By temporarily storing the firmware data in the shared master-slave backup area, shared storage resources between the master and slave devices are achieved, avoiding the waste of Flash space caused by allocating independent backup areas on each slave MCU. Simultaneously, the firmware type field provides a basis for subsequent target device identification.

[0033] Step S3: Upgrade the firmware of the target MCU using the firmware data in the master-slave shared backup area. The target MCU is the MCU with the firmware type corresponding to the master MCU and the slave MCU.

[0034] In the application, the target MCU is dynamically determined as the execution object based on the firmware type parsed above. The master MCU reads the firmware type field in the master-slave shared backup area and compares it with the device identifier pre-stored in the system: if the firmware type matches the master MCU identifier, the target MCU is the master MCU itself; if it matches a slave MCU identifier, the target MCU is that specific slave MCU. After determining the target MCU, the master MCU calls the corresponding upgrade subroutine to migrate or burn the firmware data in the master-slave shared backup area to the application execution code area of ​​the target MCU. For example, when the firmware type is Type_Master, the master MCU restarts itself and enters internal boot mode, copying the backup area data to its own App area; when the firmware type is Type_Slave_02, the master MCU controls the hardware pins of slave MCU2 to enter burning mode and burns the backup area data to slave MCU2 through the original manufacturer's ISP protocol. This step, through precise mapping between firmware type and target MCU, achieves flexible support for multiple types of devices from a single backup area, significantly improving the automation and reliability of system upgrades.

[0035] This application constructs a complete firmware upgrade mechanism for a master-slave system through the synergistic effect of the aforementioned technical features. A stable download handshake process is established by the master MCU responding to the first instruction and sending the second instruction. Based on this, upgrade verification data containing the firmware type guides the storage of firmware data in the shared master-slave backup area. This not only achieves centralized data management but also implicitly defines the upgrade target through the firmware type field. Furthermore, the master MCU intelligently locks onto the target MCU based on the firmware type and executes the upgrade operation, enabling master and slave devices to share the same storage resource for differentiated upgrades. This design effectively solves the problems of difficult and costly upgrades for multiple devices in systems without wireless modules. It saves on the Flash hardware cost of slave devices and simplifies the upgrade logic of the host computer, achieving low-cost, high-reliability centralized firmware maintenance.

[0036] In one embodiment, step S3, which involves upgrading the firmware of the target MCU using the firmware data in the master-slave shared backup area, includes: Step S31: Determine the MCU corresponding to the firmware type as the target MCU from the master MCU and the slave MCU.

[0037] In applications, firmware type is a key identifier carried by the host computer when sending upgrade verification data, indicating the specific MCU object to which the firmware to be upgraded applies. Upon receiving upgrade verification data containing the firmware type, the master MCU parses the data type and matches it against a pre-stored device list within the system. This pre-stored device list records the unique identifiers or type codes of the master MCU itself and all connected slave MCUs. Through comparison, the master MCU can accurately select a unique target MCU from the master and slave MCU set. For example, if the parsed firmware type is Type_Slave_02, and the system list records the master MCU type as Type_Master, slave MCU1 as Type_Slave_01, and slave MCU2 as Type_Slave_02, then the master MCU determines slave MCU2 as the target MCU. This dynamic matching mechanism based on firmware type allows the same upgrade process to flexibly adapt to any node in a master-slave architecture, eliminating the need to write separate upgrade scripts for different devices.

[0038] Step S32: Control the target MCU to enter firmware upgrade mode.

[0039] In applications, firmware upgrade mode refers to the MCU's internal program pointer jumping to the running state of the bootloader or ISP firmware code area. In this state, the MCU suspends the execution of the user application and instead listens for and responds to external write commands. The control method varies depending on the target MCU's identity (master or slave). When the target MCU is a master MCU, the master MCU executes a software reboot command and configures the startup parameters in the reset vector table, causing it to automatically switch to its internal boot mode after reboot. When the target MCU is a slave MCU, the master MCU achieves control through hardware pin interaction.

[0040] Step S33: Burn the firmware data in the master-slave shared backup area into the application execution code area of ​​the target MCU.

[0041] In applications, firmware programming refers to the process of writing a binary data stream stored in a non-volatile storage medium into a specified address area of ​​the target MCU's flash memory using a specific communication protocol. Since the firmware data is already fully stored in the master MCU's shared master-slave backup area, the master MCU, acting as a data relay station, directly reads the data blocks from this backup area. If the target MCU is the master MCU, it performs a memory copy operation, directly overwriting its own application execution code area with the backup area data. If the target MCU is a slave MCU, the master MCU calls the original manufacturer's programming protocol (such as the UART-based YMODEM protocol or a custom query-answer protocol) matched to the slave MCU model, sending the backup area data packet by packet to the slave MCU via a serial communication interface. The slave MCU receives the data in ISP mode and writes it into its own application execution code area. The master MCU manages the firmware distribution of multiple slave MCUs simultaneously through the shared backup area, avoiding the waste of storage resources caused by each slave MCU having its own separate backup area. Through this programming process, the new firmware program is fully deployed to the target device's operating area, laying the foundation for subsequent feature updates.

[0042] This application achieves efficient firmware upgrades in a master-slave architecture through the synergistic effect of the aforementioned technical features. By accurately identifying the target MCU from the master-slave MCU set based on firmware type, the risk of incorrect upgrades is avoided. Relying on the shared master-slave backup area as a unified data source, the master MCU directly calls the original manufacturer's protocol to complete data burning, which not only eliminates the hardware cost of separate backup areas for slave MCUs but also simplifies the data transmission logic of the host computer, significantly improving the stability and scalability of system upgrades.

[0043] In one embodiment, the flash memory of the main MCU also includes a main firmware flag area. Step S31, after determining the MCU corresponding to the firmware type as the target MCU from the main MCU and the slave MCU, further includes: Step S311: If the firmware type is a main MCU firmware, determine that the main MCU is the target MCU and write the upgrade verification data into the main firmware flag area.

[0044] In applications, the main firmware flag area is a specific storage region in the main MCU flash memory, independent of the application execution code area and the master-slave shared backup area. It is used to persistently store the context information of the current upgrade task. Upgrade verification data includes the firmware data length, integrity check code (such as a CRC32 value), and firmware type identifier. Writing the upgrade verification data to the main firmware flag area provides a baseline for subsequent reboot verification, ensuring that the expected characteristics of the firmware to be verified can be accurately determined after the main MCU reboots into Boot mode. This step aims to establish the foundation for breakpoint resumption and security verification during the upgrade process, ensuring that the main MCU has the complete metadata required for self-recovery after reboot.

[0045] Step S33, after burning the firmware data in the master-slave shared backup area to the application execution code area of ​​the target MCU, further includes: Step S3311: Verify the firmware data in the application execution program code area of ​​the main MCU based on the upgrade verification data in the main firmware flag area and generate a verification result.

[0046] In application, the above verification process occurs after the main MCU copies firmware data from the shared backup area to the application execution code area. Specifically, the main MCU reads the actual data of the firmware already burned into the application execution code area, calculates its actual length and actual integrity checksum, and compares it with the expected length and expected checksum stored in the main firmware flag area. If the two are completely consistent, a verification result indicating a successful upgrade is generated; if any discrepancy exists, a verification result indicating an upgrade failure is generated. This step, through a closed-loop verification mechanism, ensures that the firmware data migrated from the backup area to the running area has not been tampered with or that bit flips have occurred during transmission, thus guaranteeing the operational reliability of the system after startup.

[0047] Step S3312: If the verification result indicates that the main MCU firmware upgrade was successful, then clear the main firmware flag area.

[0048] In applications, a clearing operation can refer to erasing or resetting all upgrade verification data stored in the main firmware's flag area to an initial invalid state (such as all 0s or all 1s). The purpose of this operation is to mark the successful completion of the upgrade process, preventing the main MCU from mistakenly identifying it as being in an intermediate upgrade state during the next normal reboot and repeating the copying or verification actions. For example, after successful verification, the main MCU executes a flash erase instruction, clearing the contents of the flag area to zero, and then jumps to the entry address of the application execution code area to begin normal operation. Thus, the system can distinguish between the states of upgrading and upgrade completed, ensuring the logical rigor of the business process.

[0049] Step S3313: If the verification result indicates that the main MCU firmware upgrade was unsuccessful, then return to the step of copying the firmware data from the master-slave shared backup area to the application execution code area of ​​the main MCU.

[0050] In the application, when the verification result indicates data inconsistency, the system triggers an automatic retry mechanism. The main MCU does not clear the flag area; instead, it directly controls the program flow to roll back and re-executes the action of copying firmware data from the shared master-slave backup area to the application execution code area. For example, if power fluctuations cause some data to be written incorrectly during the copy process, resulting in a mismatch between the calculated CRC value and the flag area record, the main MCU will immediately re-initiate the copy request, using the intact source data in the backup area to overwrite the erroneous App area data. This cyclical retry strategy effectively overcomes the upgrade failure problem caused by momentary interference, significantly improving the robustness and success rate of the main MCU firmware update, and achieving self-repair without upper-level computer intervention.

[0051] This application introduces a main firmware flag area to achieve state persistence and closed-loop verification during the main MCU firmware upgrade process. Specifically, by writing key verification parameters into the main firmware flag area before the upgrade, it ensures that the upgrade context is not lost even in a reboot scenario. Based on this, the flag area data is used to rigorously compare the burned firmware, accurately identifying data integrity issues. Furthermore, based on the verification results, the process is dynamically terminated by clearing the flag area or by returning to the copy step for retrying, thus constructing an automated fault-tolerant recovery mechanism. This design not only avoids the risk of the main control chip becoming unusable due to upgrade failure but also eliminates the dependence on additional external storage resources, achieving highly reliable master-slave system firmware upgrades at a lower cost.

[0052] In one embodiment, the flash memory of the master MCU also includes a firmware flag area. Step S31, after determining the MCU corresponding to the firmware type as the target MCU from the master MCU and the slave MCU, further includes: Step S312: If the firmware type is slave MCU firmware, determine the slave MCU corresponding to the firmware type as the target MCU and write the upgrade verification data into the slave firmware flag area.

[0053] In applications, the slave firmware flag area is a dedicated storage area in the master MCU's flash memory used to store status information during the slave MCU upgrade process. Its function is to physically isolate it from the master firmware flag area, preventing confusion between master and slave upgrade information. Upgrade verification data includes firmware data length, integrity check code (such as a CRC32 value), and firmware type identifier. When the master MCU parses the received upgrade package and identifies that the firmware type identifier points to a specific slave MCU (e.g., slave MCU_1), the master MCU writes the upgrade verification data corresponding to that slave MCU into the slave firmware flag area. This operation aims to provide baseline data for subsequent programming verification and anomaly recovery.

[0054] After burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU in step S33, the method further includes: Step S3321: Verify the firmware data in the application execution program code area of ​​the target MCU based on the upgrade verification data from the firmware flag area and generate a verification result.

[0055] In application, the above verification step is performed after the firmware data is burned into the application execution code area of ​​the target slave MCU. The master MCU sends a read command to the target slave MCU that has completed the burning process via a serial communication interface, reads the data in its application execution code area, and calculates the read data using an integrity check code (such as the CRC32 algorithm) stored in the slave firmware's flag area. The calculation result is compared with the check code pre-stored in the flag area to generate a verification result indicating consistency. The purpose of this step is to confirm whether the code burned into the slave MCU is completely consistent with the original firmware issued by the host computer, eliminating data corruption caused by communication interference or storage medium errors. This closed-loop verification mechanism based on pre-stored benchmark data effectively avoids the risk of system crashes caused by erroneous firmware running on the slave MCU.

[0056] Step S3322: If the verification result indicates that the target MCU firmware upgrade is successful, then pull down the boot pin of the target MCU, restart the target MCU, and clear the slave firmware flag area.

[0057] In application, a successful verification result indicates that the new firmware has been correctly written and is complete. At this point, the main MCU performs a cleanup and reset operation: First, it controls the boot pin of the target MCU to go from high to low (pull low), causing the slave MCU to exit the programming mode (ISP mode) and prepare to enter the normal operation mode (APP mode); then, the main MCU controls the slave MCU to power on again or sends a reset signal to restart the slave MCU, enabling it to load the new firmware and start working; finally, the main MCU erases or clears the data in the slave firmware's flag area, freeing up storage space and clearing the upgrade status flag, preparing for the next upgrade task. The above steps achieve a seamless switch from programming state to running state, and by clearing the flag area, it eliminates the potential interference of historical states on subsequent operation, ensuring a clean system startup.

[0058] Step S3323: If the verification result indicates that the firmware upgrade of the target MCU was unsuccessful, then return to the step of controlling the target MCU to enter the firmware upgrade mode.

[0059] In applications, when the verification result fails, it indicates an anomaly in the burning process or incomplete data, meaning the data in the application execution code area of ​​the current slave MCU is unavailable. At this point, the master MCU triggers an automatic retry mechanism, abandoning the reset and startup operation and directly jumping back to the step of controlling the target slave MCU to enter firmware upgrade mode, re-initiating the burning process. This step utilizes the upgrade verification data retained in the firmware flag area as the basis for retry, eliminating the need for the host computer to resend data, allowing for a second burning attempt locally. For example, if the verification finds a CRC mismatch, the master MCU immediately pulls the boot pin of the target slave MCU high again and powers it back on, forcing it into ISP mode, and then calls the original manufacturer's burning protocol again to write the firmware data from the shared master-slave backup area to the slave MCU. This automatic rollback and retry strategy based on local backup and flag area status significantly improves the success rate of slave MCU firmware upgrades in complex electromagnetic environments or unstable communication scenarios, avoiding upgrade termination due to a single accidental error.

[0060] This application achieves physical isolation and exclusive information sharing between master and slave upgrade states by setting up a separate slave firmware flag area, thus avoiding confusion of upgrade context in multi-slave systems.

[0061] In one embodiment, step S32, controlling the target MCU to enter firmware upgrade mode, includes: Step S321: If the target MCU is the main MCU, restart the main MCU and enter boot mode.

[0062] In applications, rebooting can refer to the main MCU executing a software reset instruction or triggering an internal watchdog reset, causing the processor core to resume code execution from the reset vector address. Boot mode can refer to the running state of the pre-installed bootloader within the main MCU, typically located in a specific reserved area of ​​flash memory (i.e., the BOOT area), independent of the user application's execution code area. The main MCU, by reading the upgrade verification data written into the main firmware flag area, identifies itself as the target of the upgrade and initiates a reset operation. During the reset and startup process, the main MCU's detection circuit or boot configuration register detects specific startup conditions (such as a flag being set), thus skipping the normal application jump logic and directly mapping and executing the boot code in the BOOT area. For example, when the firmware type field in the main firmware flag area identifies the main MCU and passes verification, the main CPU executes a soft reset instruction. After startup, it detects that the upgrade flag is valid and then enters the Bootloader environment in IAP (In-Application Programming) mode, preparing to receive a copy of firmware data from the backup area. By combining software restart with flag-based judgment, the system can safely switch to upgrade mode without external hardware intervention, ensuring the automation and controllability of the main device upgrade process.

[0063] Step S322: If the target MCU is a slave MCU, pull the boot pin of the target MCU high and power on the slave MCU again to put the MCU into programming mode.

[0064] In applications, the boot pin is a dedicated hardware input port on the MCU chip used to select the boot mode. Its level determines the program execution entry point after the chip is powered on. The programming mode can refer to the MCU entering the manufacturer-preset ISP (In-System Programming) mode, in which the slave MCU waits to receive programming instructions and data through a serial communication interface. The master MCU, as the control entity, is electrically connected to the slave MCU's boot pin through its general purpose input / output interface (GPIO). When the target MCU is determined to be a slave device, the master MCU first controls the corresponding GPIO port to output a high-level signal, pulling the slave MCU's boot pin potential high to logic 1. Subsequently, the master MCU controls the power management module to cut off and reapply the slave MCU's power supply voltage, or sends a reset pulse in conjunction with power timing control to achieve a power-on reprogramming action. Under this hardware timing, the slave MCU samples the boot pin as high during the power-on initialization phase, thus forcibly skipping its internal user application program and directly entering the manufacturer's preset ISP programming boot program. This mechanism, which combines hardware pin control with power timing, solves the problem that slave devices cannot autonomously enter upgrade mode without an independent human-machine interface, and enables remote forced programming control of slave devices by the master device.

[0065] This application constructs a unified master-slave dual-path upgrade triggering mechanism through the synergistic effect of the aforementioned technical features. By distinguishing the type of the target MCU, the system can adaptively select either software reset to enter IAP mode or hardware pin control to enter ISP mode. Specifically, by utilizing the different states of the master firmware flag area and the slave firmware flag area, the master MCU can accurately determine the upgrade target. Based on this, an internal soft reset jump is used for the master device, reducing the dependence on external circuits; while for the slave device, the GPIO control capability of the master MCU is used to simulate manual operation of the boot pin and coordinate with the power-on and power-off timing to force the slave device into the original factory programming channel. This design not only accommodates the boot characteristics of MCUs with different architectures but also eliminates the cost of designing complex upgrade switching circuits for each slave device. This allows a master-slave system to seamlessly connect the IAP upgrade process of the master device and the ISP programming process of the slave device while sharing a backup area, significantly improving the flexibility and reliability of system firmware upgrades.

[0066] In one embodiment, step S33, burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU, includes: Step S331: If the target MCU is the master MCU, copy the firmware data in the master-slave shared backup area to the application execution code area of ​​the master MCU.

[0067] In this application, this step is for scenarios where the target MCU is the system's main control unit. The main MCU's flash memory is physically divided into multiple areas, including an application execution code area for storing the currently running program, a shared master-slave backup area for temporarily storing the firmware to be upgraded, and a bootloader area. Since the main MCU has direct read / write access to all internal flash memory areas, and is currently in normal operation or a specific boot loading state, data transmission via an external communication interface is unnecessary. Specifically, the processor calls an internal memory copy function to read the firmware data already fully stored in the shared master-slave backup area, in bytes or data blocks, and writes it segment by segment to the starting address of the application execution code area. This direct internal copy method utilizes the main MCU's high-speed bus bandwidth, significantly shortening firmware writing time, avoiding external communication protocol overhead, and achieving efficient in-application programming (IAP) upgrades.

[0068] Step S332: If the target MCU is a slave MCU, the firmware data in the master-slave shared backup area is burned to the application execution code area of ​​the target MCU based on the original manufacturer's burning protocol.

[0069] In this application, this step is for scenarios where the target MCU is a controlled slave unit in the system. Slave MCUs typically do not have direct access to the master MCU's memory space, and their flash write operations must follow specific serial programming protocols specified by the chip manufacturer (such as the YMODEM protocol based on the UART interface, a custom command-response protocol, or a standard ISP instruction set). In this mode, the master MCU, acting as the host controller, first establishes a communication connection with the slave MCU, which has entered programming mode, via a serial communication interface (such as UART, SPI, or I2C). Subsequently, the master MCU parses the firmware data stored in its shared master-slave backup area and encapsulates it according to the frame format specified by the manufacturer's programming protocol (including frame header, command word, data packet length, payload data, and checksum). By strictly adhering to the manufacturer's programming protocol, the timing compliance and electrical compatibility of the data writing process are ensured, effectively preventing programming failures or memory damage due to protocol incompatibility, and enabling reliable firmware updates from the master device to heterogeneous slave devices.

[0070] This application constructs a hybrid upgrade system compatible with master-slave architectures by differentiating the target MCU type and adapting to differentiated programming strategies. For the master MCU, a direct copy mechanism is adopted using its internal memory mapping characteristics to maximize upgrade efficiency; for the slave MCU, remote programming across chips is achieved by leveraging the relay capabilities of the master MCU and original manufacturer protocol support. The master and slave share a backup area as a data hub, uniformly storing firmware packages from the host computer. This eliminates the hardware cost of independently configuring the backup area for the slave MCU and solves the upgrade problem of antennaless slave devices through unified scheduling by the master MCU. The coordinated operation of internal copying and external protocol programming enables a single upgrade process to adapt to MCU combinations with different core architectures and storage characteristics, significantly improving the maintenance flexibility and scalability of multi-node embedded systems.

[0071] In one embodiment, the upgrade verification data may also include firmware data length.

[0072] Before performing firmware upgrade on the target MCU using the firmware data in the master-slave shared backup area, step S3 further includes: Step S301: Calculate the actual length of the firmware data in the master-slave shared backup area.

[0073] In applications, calculating the actual length refers to the process by which the master MCU, after completely storing the received firmware data in the master-slave shared backup area, counts the total number of bytes in the data blocks already stored in that backup area. This step quantifies the physical size of the received data, providing a baseline value for subsequent data integrity verification. Specifically, the master MCU traverses the master-slave shared backup area from its starting address to the current write pointer address, accumulating the number of storage units to obtain the actual length of the firmware data. This real-time calculation mechanism accurately obtains the amount of data in the current storage state, providing an objective basis for determining whether data transmission is complete.

[0074] Step S302: If the actual length is inconsistent with the firmware data length, a firmware data retransmission request is sent to the host computer.

[0075] The firmware data length is a key parameter included in the aforementioned upgrade verification data. It originates from metadata predefined by the host computer before sending the firmware data, used to declare the standard size of the firmware to be transmitted. The execution logic of this step is based on a branching process of the comparison result: when the main MCU detects that the actual length calculated above is not equal to the firmware data length carried in the upgrade verification data, it determines that the currently received firmware data is missing or redundant, and does not meet the burning conditions. At this time, the main MCU sends a specific firmware data retransmission request command to the host computer through the serial communication interface. This step, used in conjunction with the above, forms a closed-loop control logic of calculation-comparison-feedback, effectively avoiding subsequent verification failures or system malfunctions caused by incomplete data.

[0076] Step S303: Receive firmware data sent by the host computer in response to the firmware data retransmission request, store the firmware data in the master-slave shared backup area, and return the step of calculating the actual length of the firmware data in the master-slave shared backup area.

[0077] In application, the above steps describe the data update and cyclic verification process after the retransmission mechanism is triggered. After sending a retransmission request, the master MCU enters a waiting state. Once it receives the complete firmware data retransmitted from the host computer, it overwrites the new data into the master-slave shared backup area, replacing the incomplete data that failed the previous verification. Subsequently, the process automatically jumps back to the above, re-executes the actual length calculation operation, forming an iterative loop until the actual length is completely consistent with the declared length. Through this automatic retry and overwrite update mechanism, the absolute accuracy of the firmware data used for the final upgrade in the length dimension is ensured, significantly improving the system's fault tolerance and upgrade success rate in non-ideal communication environments.

[0078] This application significantly improves data transmission reliability by introducing a pre-verification mechanism for firmware data length. Specifically, it uses the firmware data length carried in the upgrade verification data as a standard reference and dynamically compares it with the actual length calculated in real time in the shared master-slave backup area. This allows for the immediate identification of data truncation issues caused by network fluctuations or communication interference. Based on this, an automated data error correction closed loop is constructed by sending firmware data retransmission requests and triggering a receive-store-recalculate loop. This synergistic effect not only prevents the risk of incomplete firmware being mistakenly burned to the target MCU, thus avoiding system crashes, but also reduces reliance on manual intervention. This enables the master-slave system to maintain highly stable firmware upgrade capabilities even in complex electromagnetic environments or long-distance communication scenarios.

[0079] In one embodiment, the upgrade verification data further includes an integrity verification code.

[0080] After calculating the actual length of the firmware data in the master-slave shared backup area, step S301 further includes: Step S304: If the actual length is consistent with the firmware data length, perform integrity verification on the firmware data in the master-slave backup area based on the integrity check code.

[0081] In applications, an integrity checksum refers to a characteristic value used to verify whether data content has experienced bit flips, noise interference, or other transmission errors. It originates from the upgrade verification data sent by the host computer. This integrity checksum is typically generated by the host computer using a Cyclic Redundancy Check (CRC), hash, or parity check algorithm to calculate the original firmware data before sending it. In this embodiment, the integrity checksum is specifically a CRC32 checksum. After confirming that the actual length of the received firmware data is completely consistent with the length recorded in the upgrade verification data, the master MCU does not immediately determine that the data is usable. Instead, it further initiates a content integrity verification mechanism. Specifically, the master MCU reads the firmware data stored in the shared master-slave backup area and uses the same verification algorithm (such as CRC32) as the host computer to perform real-time calculation on this data segment to obtain a local checksum. Subsequently, the master MCU compares this local checksum with the integrity checksum contained in the upgrade verification data. Through this secondary verification based on the integrity checksum, it is possible to effectively identify data packets with correct length but corrupted content, avoiding the burning of incorrect firmware to the target MCU and causing system failure.

[0082] Step S305: If the firmware data in the master-slave backup area fails the integrity check, a firmware data retransmission request is sent to the host computer.

[0083] In applications, a firmware data retransmission request is a control command generated by the master MCU when it detects a data integrity anomaly. Its function is to notify the host computer that the currently received firmware data contains errors and needs to be retransmitted. When the locally calculated checksum does not match the received integrity checksum, the master MCU determines that the firmware data in the shared master-slave backup area has failed the integrity check. At this time, the master MCU sends a firmware data retransmission request to the host computer via the serial communication interface. This request may include an error type identifier or a simple retransmission signal. After receiving the request, the host computer will reread the firmware file to be upgraded and re-execute the process of sending upgrade checksum data and firmware data. This step, in conjunction with the aforementioned length verification step, constructs a dual verification defense of length and content, ensuring that only complete and accurate firmware data is used for subsequent burning operations, thereby significantly improving the reliability and security of the firmware upgrade process.

[0084] This application achieves highly reliable firmware data transmission verification by introducing an integrity check code combined with a length check mechanism. Specifically, it first uses the firmware data length for preliminary screening to quickly eliminate cases of lost or truncated data packets. Based on this, it further uses an integrity check code to perform in-depth verification of the data content, effectively capturing hidden errors such as bit flips. When any verification step fails, the system automatically triggers a retransmission request, forming a closed-loop error correction mechanism. This dual verification strategy not only greatly reduces the upgrade failure rate caused by transmission noise or interference but also prevents erroneous firmware from being burned into the application execution code area of ​​the master or slave MCU, preventing the risk of device bricking or malfunction. Through the synergistic effect of length and content verification, it provides robust protection for the data quality in the shared backup area between the master and slave, ensuring that subsequent firmware upgrade operations based on this data can be executed accurately and without error.

[0085] like Figure 2 As shown in the embodiments of this application, a system firmware upgrade method is also provided, applied to a host computer. The system includes a main MCU and at least one slave MCU connected to the main MCU. The method includes: Step S4: In response to the upgrade command input by the user, send the first command to the main MCU of the system.

[0086] In applications, the upgrade command input by the user can refer to a start signal triggered by the operator through the human-machine interface of the host computer. This signal is used to initialize the firmware upgrade process. After detecting the upgrade command, the host computer generates and sends a first command to the system's main MCU. The purpose of the first command is to notify the main MCU to prepare to receive firmware data and enter firmware download mode, thereby establishing an upgrade communication link between the host computer and the main MCU. For example, the user can input the upgrade command by clicking the "Start Upgrade" button on the host computer software interface. The host computer then sends a specific handshake command to the main MCU as the first command through the serial communication interface. This response mechanism ensures that the upgrade operation is only initiated with explicit user authorization, avoiding system restarts or data corruption caused by accidental operation. This step aims to establish the initial communication connection between the master and slave ends, providing a prerequisite for subsequent data transmission.

[0087] Step S5: Upon receiving a second instruction sent by the main MCU in response to the first instruction, upgrade verification data and firmware data are sent to the main MCU. The upgrade verification data includes the firmware type of the firmware data. The firmware data is used to upgrade the target MCU in the system. The target MCU is the MCU corresponding to the firmware type in the main MCU and the slave MCU.

[0088] This application constructs an efficient host computer-driven upgrade mechanism through the synergistic effect of the aforementioned technical features. By sending a first instruction in response to the user-input upgrade command, and sending upgrade verification data containing the firmware type and firmware data after receiving a second instruction from the main MCU, the upgrade process is automatically triggered and accurately distributed. The host computer is responsible for providing the data source and type identifier, while the main MCU is responsible for parsing the type and scheduling the specific burning execution. This division of labor not only reduces the dependence on direct communication with the slave MCUs and lowers the complexity of system wiring, but also ensures the accuracy of the upgrade object through a unified verification data structure. This effectively solves the technical problems of high upgrade cost and fragmented process in traditional master-slave systems, significantly improving the convenience and reliability of system firmware maintenance.

[0089] In one embodiment, the method further includes: Step S6: In response to the firmware data retransmission request sent by the main MCU, send the firmware data to the main MCU.

[0090] In applications, a firmware data retransmission request is an instruction triggered by the host computer when it receives an abnormal feedback signal from the main MCU. Specifically, when the main MCU, during the firmware upgrade process described above, detects data inconsistency or corruption by verifying the received data (e.g., comparing the actual length with the expected length, or performing integrity checksums such as CRC32), it sends a specific retransmission request instruction to the host computer via the serial communication interface. This retransmission request indicates the identifier of the currently failed data packet or requests the retransmission of the entire firmware data block. The host computer is configured to continuously listen for feedback information from the main MCU. Once it parses the firmware data retransmission request, it automatically initiates the retransmission mechanism without requiring the user to manually input upgrade commands or intervene in the upgrade process again. The host computer directly retrieves the previously sent but invalid firmware data from its storage buffer and retransmits it to the main MCU according to the original communication protocol format. Through this response mechanism, a closed-loop error handling channel is established between the host computer and the main MCU, ensuring that the upgrade process can be automatically restored in the event of momentary interference or data packet loss in the communication link. This avoids the termination of the entire upgrade task due to a single transmission error, and significantly improves the robustness and success rate of system firmware upgrades.

[0091] This application establishes a close working relationship between the host computer's response mechanism for firmware data retransmission requests and the main MCU's data verification logic. The main MCU is responsible for real-time monitoring of data integrity and proactively initiating retransmission requests upon detecting anomalies, while the host computer, acting as a reliable data source, immediately retransmits data upon receiving the request. This two-way interaction not only solves the noise interference problem that may exist in wired communication in antenna-less environments but also eliminates the need for repetitive manual operations. Furthermore, the retransmission mechanism ensures that the firmware data stored in the shared master-slave backup area is always complete and correct, providing a solid data foundation for subsequent firmware data burning to the application execution code area of ​​the target MC (whether it's the master MCU or the slave MCU), thereby guaranteeing the one-time success rate of the final firmware upgrade and the stability of the system.

[0092] In one embodiment, the method further includes upgrading the verification data, which also includes firmware data length and integrity verification codes, such as CRC check codes.

[0093] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0094] like Figure 3 As shown, this application also provides a master-slave system, which includes a master MCU and at least one slave MCU connected to the master MCU via a boot pin and a serial communication interface. The flash memory of the master MCU is provided with a master-slave shared backup area, a BOOT area and an application execution code area, and the flash memory of the slave MCU is provided with an application execution code area.

[0095] In applications, the master-slave shared backup area can be used to temporarily store firmware data to be upgraded received from the host computer. This area is shared between the master MCU and each slave MCU, thus avoiding the need to set up a separate backup area in each slave MCU and saving hardware resource costs. The BOOT area can be used to store the boot program, enabling the master MCU to enter a specific upgrade mode or perform code copying operations. The application execution code area can be used to store and run the applications required for the master MCU to work normally.

[0096] The slave MCU has an application execution code area in its flash memory, which stores and runs the applications required for the slave MCU to function properly. In the technical solution of this application, the slave MCU does not need a separate firmware backup area; the firmware data required during the upgrade process comes directly from the master-slave shared backup area of ​​the master MCU. The slave MCU interacts with the master MCU via a serial communication interface and is connected to the master MCU via a boot pin to receive mode switching control signals from the master MCU.

[0097] The serial communication interface serves as the physical communication link between the master MCU and the slave MCU for transmitting firmware data and control commands. This interface can be a Universal Asynchronous Receiver / Transmitter (UART), a Universal Synchronous Asynchronous Receiver / Transmitter (USART), or other interface protocols supporting serial data transmission, such as SPI or I2C, as long as it enables stable transmission of firmware data from the master MCU to the slave MCU. During the upgrade process, the master MCU reads the firmware data from the shared master-slave backup area and sends the data to the slave MCU via this serial communication interface according to a preset communication protocol (e.g., the UART-based YMODEM protocol or a custom query-response protocol), so that the slave MCU can write the data into its application execution code area.

[0098] As a preferred embodiment, the solution of this application is implemented as follows: In a system comprising one master MCU and two slave MCUs (slave MCU1 and slave MCU2), the flash memory of the master MCU is divided into a BOOT area, an application execution code area, a master-slave shared backup area, a master firmware flag area, and a slave firmware flag area. The flash memory of slave MCU1 and slave MCU2 is only divided into an application execution code area. Two boot control lines are respectively led out from the GPIO port of the master MCU, one connected to the BOOT pin of slave MCU1 and the other connected to the BOOT pin of slave MCU2; at the same time, the USART interface of the master MCU is connected to the serial interfaces of slave MCU1 and slave MCU2 respectively via bus or point-to-point mode. When the host computer sends a firmware package for slave MCU1, the master MCU stores it in the master-slave shared backup area, then pulls the boot pin connected to slave MCU1 high and performs a power-on operation on slave MCU1, enabling slave MCU1 to enter ISP mode; then the master MCU burns the backup area data to the application execution code area of ​​slave MCU1 through the USART interface; after burning is completed, the master MCU pulls the boot pin low and restarts slave MCU1 again, enabling it to run normally. During this process, MCU2 remains unaffected, maintaining its original operating state, and does not require the Flash space of MCU1 or MCU2 to be used as a backup area.

[0099] Through the above technical solution, this application optimizes the hardware architecture of the master-slave system. Since the master MCU and slave MCU are directly connected via the boot pin, the master MCU can directly control the mode switching of the slave MCU in hardware, eliminating the need for the slave MCU to have complex autonomous switching logic, thus improving the reliability of the upgrade. Due to the design of a shared backup area between master and slave, the slave MCU does not need to reserve Flash space for storing backup firmware, significantly reducing the hardware cost of the slave MCU and the Flash capacity requirements. By configuring the master MCU to execute the aforementioned upgrade method steps, close collaboration between hardware and software is achieved, making the firmware upgrade process under the master-slave architecture centralized and standardized, facilitating system maintenance and expansion.

[0100] In one embodiment, the serial communication interface is either a universal asynchronous transceiver or a universal synchronous asynchronous transceiver.

[0101] Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Figure 4 As shown, the terminal device 4 in this embodiment includes: at least one processor 40 ( Figure 4 (Only one is shown in the image) a processor, a memory 41, and a computer program 42 stored in the memory 41 and executable on the at least one processor 40. When the terminal device is the main MCU, the processor 40 executes the computer program 42 to implement the steps of the system firmware upgrade method applied to the main MCU described above. When the terminal device is a host computer, the processor 40 executes the computer program 42 to implement the steps of the system firmware upgrade method applied to the host computer.

[0102] The terminal device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4 This is merely an example of terminal device 4 and does not constitute a limitation on terminal device 4. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0103] The processor 40 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0104] In some embodiments, the memory 41 may be an internal storage unit of the terminal device 4, such as a hard disk or memory of the terminal device 4. In other embodiments, the memory 41 may be an external storage device of the terminal device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal device 4. Furthermore, the memory 41 may include both internal and external storage units of the terminal device 4. The memory 41 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0105] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0106] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0107] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0108] like Figure 5 As shown, this application embodiment provides a computer program product 50, including a computer program 42. When the computer program 42 is run, the steps in the above-described system firmware upgrade method embodiments are executed.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0110] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A system firmware upgrade method, characterized in that, The system includes a master MCU and at least one slave MCU connected to the master MCU. The master MCU has a shared master-slave backup area in its flash memory. The method is applied to the master MCU and includes: In response to the first instruction sent by the host computer, the device enters firmware download mode and sends a second instruction to the host computer. The system receives upgrade verification data and firmware data sent by the host computer in response to the second instruction and stores the firmware data in the master-slave shared backup area. The upgrade verification data includes the firmware type of the firmware data. The firmware data in the master-slave shared backup area is used to upgrade the firmware of the target MCU, where the target MCU is the MCU with the firmware type corresponding to the master MCU and the slave MCU.

2. The system firmware upgrade method as described in claim 1, characterized in that, The step of upgrading the firmware of the target MCU using the firmware data in the master-slave shared backup area includes: The target MCU is determined from the master MCU and the slave MCUs, based on the firmware type. Control the target MCU to enter firmware upgrade mode; The firmware data in the master-slave shared backup area is burned into the application execution code area of ​​the target MCU.

3. The system firmware upgrade method as described in claim 2, characterized in that, The main MCU's flash memory also contains a main firmware flag area. After determining the MCU corresponding to the firmware type as the target MCU from the main MCU and the slave MCU, the process further includes: When the firmware type is a main MCU firmware, the main MCU is determined to be the target MCU and the upgrade verification data is written into the main firmware flag area; After burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU, the method further includes: The firmware data in the application execution program code area of ​​the main MCU is verified based on the upgrade verification data in the main firmware flag area, and a verification result is generated. If the verification result indicates that the main MCU firmware upgrade was successful, then the main firmware flag area is cleared; If the verification result indicates that the main MCU firmware upgrade was unsuccessful, then return to the step of copying the firmware data from the master-slave shared backup area to the application execution code area of ​​the main MCU.

4. The system firmware upgrade method as described in claim 2, characterized in that, The master MCU's flash memory also includes a firmware flag area. After determining from the master MCU and the slave MCU that the MCU corresponding to the firmware type is the target MCU, the process further includes: When the firmware type is slave MCU firmware, the slave MCU corresponding to the firmware type is determined as the target MCU and the upgrade verification data is written into the slave firmware flag area; After burning the firmware data from the master-slave shared backup area to the application execution code area of ​​the target MCU, the method further includes: Based on the upgrade verification data from the firmware flag area, the firmware data in the application execution program code area of ​​the target MCU is verified and a verification result is generated. If the verification result indicates that the target MCU firmware upgrade is successful, then pull the boot pin of the target MCU low, restart the target MCU, and clear the slave firmware flag area; If the verification result indicates that the firmware upgrade of the target MCU was unsuccessful, then return to the step of controlling the target MCU to enter firmware upgrade mode.

5. The system firmware upgrade method as described in claim 2, characterized in that, The process of controlling the target MCU to enter firmware upgrade mode includes: When the target MCU is the main MCU, the main MCU is restarted and enters boot mode; If the target MCU is a slave MCU, pull the boot pin of the target MCU high and power on the slave MCU again to put the MCU into programming mode.

6. The system firmware upgrade method as described in claim 2, characterized in that, The step of burning the firmware data from the master-slave shared backup area into the application execution code area of ​​the target MCU includes: When the target MCU is the master MCU, the firmware data in the master-slave shared backup area is copied to the application execution code area of ​​the master MCU; When the target MCU is a slave MCU, the firmware data in the master-slave shared backup area is burned to the application execution code area of ​​the target MCU based on the original manufacturer's burning protocol.

7. A system firmware upgrade method, characterized in that, Applied to a host computer, the system includes a master MCU and at least one slave MCU connected to the master MCU, and the method includes: In response to the upgrade command input by the user, a first command is sent to the main MCU of the system; Upon receiving a second instruction sent by the master MCU in response to the first instruction, upgrade verification data and firmware data are sent to the master MCU. The upgrade verification data includes the firmware type of the firmware data. The firmware data is used to upgrade the target MCU in the system. The target MCU is the MCU corresponding to the firmware type in the master MCU and the slave MCU.

8. The system firmware upgrade method as described in claim 7, characterized in that, The method further includes: In response to the firmware data retransmission request sent by the main MCU, the firmware data is sent to the main MCU.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the terminal device is the main MCU, the processor executes the computer program to implement the steps of the system firmware upgrade method as described in any one of claims 1 to 6; When the terminal device is a host computer, the processor executes the computer program to implement the steps of the system firmware upgrade method as described in claim 7 or 8.

10. A computer program product, characterized in that, Includes a computer program, which, when executed, causes the system firmware upgrade method as described in any one of claims 1 to 8 to be performed.

Images