Firmware remote upgrading method based on double backups

Abstract

The invention relates to a firmware remote upgrading method based on double backups, which belongs to the technical field of firmware upgrading and comprises the following operation steps of: 1, starting an overall upgrading process; and 2, upgrading the equipment. 3, judging an equipment upgrading state, and if the equipment upgrading state succeeds, skipping to a process 4; if the upgrade fails, jumping to the upgrade retry of the equipment, and jumping to the process 2; and if the number of failed upgrading times is greater than 3, skipping to the fifth process. And 4, judging that equipment needs to be upgraded, and if no equipment needs to be upgraded, skipping to the step 5. And (5) the overall upgrading process is ended. The problems of upgrading failure and equipment abnormity caused by poor communication, equipment power failure and the like in the upgrading process can be effectively solved, and meanwhile secondary upgrading after backup restoration is supported. Double firmware storage areas are realized in the equipment, and security verification and an automatic switching mechanism are combined, so that the security, reliability and efficiency of multi-equipment remote firmware upgrading are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware upgrade, and in particular to a firmware remote upgrade method based on dual backup. Background Art

[0002] Over-the-air firmware upgrades are the process of upgrading the firmware in a device via a wireless network (such as Wi-Fi, Bluetooth, etc.) or other remote connection methods. This upgrade method does not require a physical connection to the device, but rather updates the firmware in the device remotely.

[0003] Over-the-air (OTA) firmware updates are commonly used for smart devices, embedded systems, sensors, and IoT devices, particularly those that are difficult to access or distributed over a wide area. OTA updates allow device manufacturers or system administrators to remotely manage device firmware, providing software updates, feature improvements, and security fixes.

[0004] Prior Art 1, "A Method and System for Remotely Upgrading Firmware for a Multi-Device Assembly," with application number CN200910190528.9, discloses that the master device receives a firmware upgrade package from an upgrade server, verifies and unpacks the firmware upgrade package, and distributes the split firmware upgrade sub-packages; the master device or sub-device completes its respective firmware upgrade based on its respective firmware upgrade sub-package. The system includes an upgrade package receiving module, an upgrade process control module, and an upgrade package processing module located in the master device; and an upgrade processing module located in the sub-device. Prior Art 1 does not adequately address the risks of over-the-air firmware upgrades. For example, in the event of an upgrade failure due to poor communication conditions or abnormal power outages on various devices, the device cannot be restored to a working state, causing the entire system to become abnormal.

[0005] Prior Art 2, "Firmware Upgrade System and Method for Intelligent Inertial Navigation Sensor Systems," application number CN201811309799.7, discloses a system comprising a processor and memory, the memory being used to store programs. The processor is configured to receive firmware upgrade requests and firmware upgrade packages and execute the programs stored in the memory to implement a dual-backup firmware upgrade process. While Prior Art 2 includes a backup system to address communication anomalies and power outages, its redundant parameter fields and single-device upgrade protocols are increasingly unable to meet the increasingly complex system upgrade requirements and control costs. Summary of the Invention

[0006] This invention primarily addresses the shortcomings of the existing technology by providing a dual-backup remote firmware upgrade method. This method effectively addresses upgrade failures and device anomalies caused by poor communication, device power outages, and other issues during the upgrade process, while also supporting secondary upgrades after a backup and restore. By implementing dual firmware storage areas within the device, combined with security verification and an automatic switching mechanism, the security, reliability, and efficiency of remote firmware upgrades for multiple devices are significantly improved.

[0007] The above technical problems of the present invention are mainly solved by the following technical solutions:

[0008] A method for remote firmware upgrade based on dual backup includes the following operations:

[0009] Process 1: Start the overall upgrade process.

[0010] Process 2: Upgrade the device.

[0011] Process 3: Determine the device upgrade status. If successful, jump to process 4. If the upgrade fails, jump to retry the device upgrade and jump to process 2. If the number of failed upgrades is greater than 3, jump to process 5.

[0012] Process 4: Check if there are any devices that need to be upgraded. If no devices need to be upgraded, jump to process 5.

[0013] Process 5: End the overall upgrade process.

[0014] Preferably, the device storage block is divided into storage block 1, storage block 2, storage block 3 and storage block 4; storage block 1 is the Bootloader area, the device upgrade module running area; storage block 2 is the OTA_data area, used to store the information area corresponding to the device upgrade firmware; storage block 3 is the APP area, used to store the device firmware area; storage block 4 is the APP_BK area, used to back up the device firmware area.

[0015] Preferably, the device upgrade process includes the following steps:

[0016] Step 1: The device waits for the master device to issue an upgrade command. If an upgrade command is issued, it jumps to step 1.

[0017] Step 2: The device determines whether to perform the upgrade based on the upgrade package information sent by the master device. If the information in the upgrade firmware package is consistent with the information in the device's storage block 2, the upgrade is not performed, the information is reported to the master device, and the device returns to step 1. If an upgrade is required, the device returns the upgrade information to the master device and jumps to storage block 1 to run the upgrade module.

[0018] Step 3: Accept the upgrade data sent by the master device and verify each package of data. After the verification is passed, write it into storage block 3 and report the completion status of the data writing of this package to the master device; if the data verification fails or the data writing fails, report the failure information of this package and wait for the master device to retry multiple times; jump to step 4 until the last package of firmware upgrade is completed or multiple attempts fail.

[0019] Step 4: Compare the information in storage block 3 (APP area) with the upgrade firmware package information. If they are consistent, jump to step 5. If inconsistency is found, overwrite the firmware in storage block 4 to storage block 3, report the upgrade failure status, and then restart the device.

[0020] Step 5: After the upgrade is complete, restart the device.

[0021] Preferably, when the sub-device is run again, a self-test is performed on the sub-device. If the self-test passes, the firmware of storage block 3 is backed up to storage block 4, and the upgrade success status is reported. If the device self-test fails, the firmware of storage block 4 is re-overwritten to storage block 3, and the upgrade failure status is reported.

[0022] Preferably, the upgrade package structure includes a Header field, a Dev_ID field, a Type field, a Data field and a CRC field.

[0023] The Header field is a fixed packet header, using two bytes: 0xA5 and 0x5A, which can better detect bus status. The Dev_ID field is the ID of the device to be upgraded. When the device responds, the Dev_ID field is 0x00. The Type field is the upgrade package type: 0x01 indicates the upgrade has started, 0x02 indicates the upgrade is in progress, and 0x03 indicates the upgrade has ended. The Data field contains the upgrade package data. The CRC field is the upgrade package checksum.

[0024] As a preferred option, if it is determined that there are still devices that need to be upgraded, the Dev_ID field in the upgrade package is modified to the device ID that needs to be upgraded, and the process jumps to process 2 to start the upgrade.

[0025] The present invention can achieve the following effects:

[0026] This invention provides a dual-backup remote firmware upgrade method. Compared with existing technologies, it effectively addresses upgrade failures and device anomalies caused by poor communication, power outages, and other issues during the upgrade process. It also supports secondary upgrades after a backup and restore. By implementing dual firmware storage areas within the device, combined with security verification and automatic switching mechanisms, it significantly improves the security, reliability, and efficiency of remote firmware upgrades for multiple devices.

[0027] (1) Improve the reliability and security of upgrades.

[0028] The present invention adopts a partition storage method to store firmware-related information and the firmware body separately, ensuring the integrity and consistency of information during the upgrade process (reasonable layout of storage block 2 and storage block 3).

[0029] Use a verification mechanism (such as CRC check for each data packet) to ensure the correctness of data transmission and writing, and avoid device firmware damage caused by data errors.

[0030] The header (0xA5, 0x5A) design in the firmware upgrade package structure helps detect the bus status and ensure stable communication.

[0031] (2) Support batch upgrade management of multiple devices and multiple versions.

[0032] Different devices are distinguished by the Dev_ID field to achieve personalized upgrade control for different devices; at the same time, the Dev_ID is dynamically modified during the upgrade process to support batch management and upgrade scheduling of multiple devices (device ID modification operation in process 2).

[0033] (3) Effectively avoid Flash failure caused by multiple upgrades.

[0034] During the upgrade process, the device will compare the storage block information (storage block 3) before each upgrade to avoid repeated upgrades of the same version of firmware, thereby extending the service life of F1ash (information comparison judgment in process 4).

[0035] (4) Support firmware backup and rollback mechanism.

[0036] After the upgrade is successful, the new firmware is backed up to the backup block (storage block 4). If the firmware self-test fails or the upgrade is rejected, it can be quickly overwritten and rolled back to ensure stable operation of the device (firmware backup and rollback operations in process 5).

[0037] (5) Ensure the secondary upgrade capability of the equipment.

[0038] After an upgrade fails, the device will automatically restore the backup to the main area and retry the upgrade, solving the problem of being unable to upgrade again after a firmware upgrade fails, and improving the system's maintainability and reliability.

[0039] (6) Build a complete upgraded data transmission protocol.

[0040] A structured upgrade package (including header, device ID, type, data, and checksum fields) is used to ensure correct and complete data transmission and support precise control of different upgrade states. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a schematic diagram of the overall upgrade process of the present invention.

[0042] Figure 2 It is a schematic diagram of the device storage area division of the present invention.

[0043] Figure 3 It is a schematic diagram of the upgrade process of the device of the present invention.

[0044] Figure 4 It is the upgrade package structure for upgrading the device of the present invention. DETAILED DESCRIPTION

[0045] The technical solution of the invention is further described in detail below through embodiments and in conjunction with the accompanying drawings.

[0046] Example: Figure 1-4 As shown, a remote firmware upgrade method based on dual backup includes the following operations:

[0047] Process 1: Start the overall upgrade process.

[0048] The device storage blocks are divided into storage block 1, storage block 2, storage block 3 and storage block 4; storage block 1 is the Bootloader area, the device upgrade module running area; storage block 2 is the OTA_data area, used to store information corresponding to the device upgrade firmware; storage block 3 is the APP area, used to store the device firmware; storage block 4 is the APP_BK area, used to back up the device firmware.

[0049] Process 2: Upgrade the device.

[0050] The device upgrade process includes the following steps:

[0051] Step 1: The device waits for the master device to issue an upgrade command. If an upgrade command is issued, it jumps to step 1.

[0052] Step 2: The device determines whether to perform the upgrade based on the upgrade package information sent by the master device. If the information in the upgrade firmware package is consistent with the information in the device's storage block 2, the upgrade is not performed, the information is reported to the master device, and the device returns to step 1. If an upgrade is required, the device returns the upgrade information to the master device and jumps to storage block 1 to run the upgrade module.

[0053] Step 3: Accept the upgrade data sent by the master device and verify each package of data. After the verification is passed, write it into storage block 3 and report the completion status of the data writing of this package to the master device; if the data verification fails or the data writing fails, report the failure information of this package and wait for the master device to retry multiple times; jump to step 4 until the last package of firmware upgrade is completed or multiple attempts fail.

[0054] Step 4: Compare the information in storage block 3 with the upgrade firmware package information. If they are consistent, jump to step 5. If inconsistency is found, overwrite the firmware in storage block 4 to storage block 3, report the upgrade failure status, and then restart the device.

[0055] Step 5: After the upgrade is complete, restart the device.

[0056] When the sub-device is run again, it will perform a self-test on it. If it passes the self-test, it will back up the firmware in storage block 3 to storage block 4 and report the upgrade success status. If the device fails the self-test, it will overwrite the firmware in storage block 4 to storage block 3 and report the upgrade failure status.

[0057] Process 3: Determine the device upgrade status. If successful, jump to process 4. If the upgrade fails, jump to retry the device upgrade and jump to process 2. If the number of failed upgrades is greater than 3, jump to process 5.

[0058] Process 4: Determine if there are still devices requiring an upgrade. If no devices require an upgrade, proceed to process 5. The upgrade package structure includes a Header field, a Dev_ID field, a Type field, a Data field, and a CRC field. If it is determined that there are still devices requiring an upgrade, the Dev_ID field in the upgrade package is modified to the device ID requiring an upgrade, and the process proceeds to process 2 to begin the upgrade.

[0059] Process 5: End the overall upgrade process.

[0060] The firmware upgrade system of this multi-device component robot mainly includes the following key parts:

[0061] (1) Central Control Management Module: Responsible for obtaining and managing firmware versions and formulating upgrade strategies. It coordinates and controls the simultaneous upgrade of multiple devices and communicates with each device component through serial and parallel communications (such as CAN bus and 485 bus).

[0062] (2) Multiple equipment components: Multiple equipment components (such as sensors, actuators, etc.) distributed inside the robot. Equipped with a communication module to communicate with the central control management module.

[0063] Firmware upgrade process:

[0064] (1) Upgrade preparation: The central control management module detects the new version of firmware, schedules the upgrade task, and notifies each device one by one to prepare for the upgrade. After receiving the notification, each device enters the waiting state and suspends normal operation.

[0065] (2) Devices are upgraded sequentially: The central control management module transmits the firmware of each device in blocks to each device. The device upgrades and verifies each block as it receives it, and reports the upgrade status until the upgrade is complete. The central control system upgrades the devices sequentially until all devices are successfully upgraded. If a device fails to upgrade, it can be upgraded again after self-recovery from the backup. If the upgrade fails after multiple attempts, the overall upgrade failure is reported.

[0066] In summary, this dual-backup remote firmware upgrade method, utilizing scientifically rational storage area division, a rigorous upgrade process, a multi-level verification mechanism, and a firmware backup strategy, effectively improves the reliability, security, and maintainability of multi-device firmware upgrades. It effectively addresses upgrade failures and device anomalies caused by poor communication, device power outages, and other issues during the upgrade process, while also supporting secondary upgrades after a backup and restore. By implementing dual firmware storage areas within the device, combined with secure verification and an automatic switching mechanism, the security, reliability, and efficiency of remote firmware upgrades for multiple devices are significantly improved.

[0067] The above description is only a specific embodiment of the present invention, but the structural features of the present invention are not limited thereto. Any changes or modifications made by any technician in this field within the scope of the present invention are included in the patent scope of the present invention.

Claims

1. A remote firmware upgrade method based on dual backup, characterized in that The following operations are included: Process 1: Start the overall upgrade process; Process 2: Equipment upgrade; Process 3: Determine the device upgrade status. If successful, jump to process 4. If the upgrade fails, jump to retry the device upgrade and jump to process 2. If the number of failed upgrades is greater than 3, jump to process 5; Process 4: Check if there are any devices that need to be upgraded. If no devices need to be upgraded, jump to process 5. Process 5: End the overall upgrade process.

2. The method for remote firmware upgrade based on dual backup according to claim 1, characterized in that: The device storage blocks are divided into storage block 1, storage block 2, storage block 3 and storage block 4; storage block 1 is the Bootloader area, the device upgrade module running area; storage block 2 is the OTA_data area, used to store information corresponding to the device upgrade firmware; storage block 3 is the APP area, used to store the device firmware; storage block 4 is the APP_BK area, used to back up the device firmware.

3. The method for remote firmware upgrade based on dual backup according to claim 2, characterized in that The device upgrade process includes the following steps: Step 1: The device waits for the master device to issue an upgrade command. If an upgrade command is issued, it jumps to step 1. Step 2: The device determines whether to perform the upgrade based on the upgrade package information sent by the master device. If the upgrade package information is consistent with the information in the device's storage block 2, the upgrade is not performed, the information is reported to the master device, and the process returns to step 1. If an upgrade is required, the system returns the upgrade information of the main device and jumps to storage block 1 to run the upgrade module; Step 3: Accept the upgrade data sent by the master device and verify each package of data. After verification, write it into storage block 3 and report the completion status of the data writing to the master device; If data verification fails or data writing fails, the failure information of this package will be reported and the master device will be asked to retry multiple times. The process will not jump to step 4 until the last firmware package upgrade is completed or multiple attempts fail. Step 4: Compare the information in storage block 3 with the information in the upgrade firmware package. If they are consistent, jump to step 5. If inconsistency is found, the firmware in storage block 4 is overwritten to storage block 3, and the upgrade failure status is reported, and then the device is restarted; Step 5: After the upgrade is complete, restart the device.

4. The method for remote firmware upgrade based on dual backup according to claim 3, characterized in that: When the sub-device is run again, it will perform a self-test on it. If it passes the self-test, it will back up the firmware in storage block 3 to storage block 4 and report the upgrade success status. If the device fails the self-test, it will overwrite the firmware in storage block 4 to storage block 3 and report the upgrade failure status.

5. The method for remote firmware upgrade based on dual backup according to claim 3, characterized in that: The upgrade package structure includes a Header field, a Dev_ID field, a Type field, a Data field, and a CRC field.

6. The method for remote firmware upgrade based on dual backup according to claim 5, characterized in that: If it is determined that there are still devices that need to be upgraded, the Dev_ID field in the upgrade package is modified to the device ID that needs to be upgraded, and jump to process 2 to start the upgrade.

Images