Method, device, storage medium and computer device for online upgrading of embedded software

Abstract

The application relates to the technical field of embedded system software updating, and discloses an embedded software online upgrading method, device, storage medium and computer equipment, which comprises the following steps: determining an upgrading stage by reading a main state flag bit and a counting flag bit in an embedded system through a boot program; the boot program and / or an application program receive, check and write a program according to a current stage, and redundantly store a new version program; the counting flag bit is used to record the number of operation failures, and when the number of failures exceeds a threshold value, the system is migrated to a backup recovery stage, and the boot program performs recovery based on a backup of a historical version program. The above method introduces a phased state management of double-flag-bit cooperation, retry control based on a failure number threshold value and a recovery path of a preset backup, improves the state controllability, error tolerance and system self-recovery capability of an embedded software online upgrading process, and further meets the requirements of high-reliability embedded scenarios such as medical devices and industrial control on upgrading robustness.

Description

Technical Field

[0001] This invention relates to the field of embedded system software update technology, and in particular to an embedded software online upgrade method, apparatus, storage medium, and computer device. Background Technology

[0002] In the field of embedded systems, online firmware upgrades are a key means to achieve device function iteration and defect repair. The typical architecture usually adopts a design that separates the bootloader and the application program. The bootloader is responsible for receiving, verifying and deploying the new version of firmware, while the application program responds to business logic and upgrade trigger commands during normal operation. In order to distinguish the operating mode, existing solutions generally rely on status flags in non-volatile memory to control the behavior switching during the boot phase, thereby realizing basic upgrade process management.

[0003] However, existing technologies have significant shortcomings in terms of state representation capabilities, error handling granularity, and system recovery mechanisms. First, using only a single state flag bit is insufficient to accurately characterize multiple key sub-stages in the upgrade process, making it impossible to pinpoint the specific faulty link when an anomaly occurs, and also making it impossible to implement targeted retry or rollback strategies. Second, there is a lack of a closed-loop confirmation mechanism for the effectiveness of the new version program. Once the program crashes or communication is interrupted after overwriting, the system is prone to becoming unavailable, and there is no reliable path to restore it to the normal operating version. Finally, it is impossible to quantitatively control retry behavior, making it difficult to balance upgrade success rate and system stability in resource-constrained embedded environments. These problems collectively limit the applicability of online upgrade solutions in high-reliability application scenarios. Summary of the Invention

[0004] In view of this, this application provides an embedded software online upgrade method, apparatus, storage medium and computer equipment. The main purpose is to solve the technical problem that the lack of closed-loop confirmation and retry mechanism in the prior art leads to insufficient fault tolerance and recovery capability in the embedded software online upgrade process, making it difficult to meet the technical requirements of high reliability embedded scenarios.

[0005] According to a first aspect of the present invention, an online upgrade method for embedded software is provided, the method being executed in an embedded system comprising a bootloader and an application program, comprising: After power-on, the bootloader reads the preset master status flag and count flag of the non-volatile memory in the embedded system, and determines the current upgrade stage of the system based on the master status flag. Based on the current upgrade phase of the system, the bootloader and / or the application execute corresponding program operations, wherein the program operations include receiving, verifying and writing the new version of the program, and the new version of the program is stored in the non-volatile memory in a redundant manner. During the execution of the program operation, the counting flag is used to record the number of failures of the program operation based on the operation result. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the main status flag, and the bootloader is used to perform system recovery operation based on the pre-stored historical version program backup.

[0006] Optionally, the upgrade phase includes a data reception and verification state and a program overlay state defined based on the main status flag. When the system is in the data reception and verification state, the application performs program operations, including: receiving an upgrade data packet sent by the host computer and performing integrity verification on the upgrade data packet; when the upgrade data packet is received and passes the integrity verification, parsing the upgrade data packet to obtain a new version program, generating multiple copies of the new version program, storing the multiple copies of the new version program in different areas of the non-volatile memory, updating the main status flag to a first preset value and resetting the counter flag, thereby triggering the system to migrate to the program overlay state.

[0007] Optionally, the method further includes: when the upgrade data packet fails to be received or fails the integrity check, increasing the value of the counting flag by a preset fixed step; if the increased value of the counting flag does not exceed a first failure count threshold, controlling the application to re-receive the upgrade data packet; if the increased value of the counting flag exceeds the first failure count threshold, resetting the main status flag and the counting flag to their initial values, and controlling the embedded system to restart.

[0008] Optionally, the upgrade phase further includes a running confirmation state defined by the main status flag; when the system is in the program overwrite state, the bootloader performs program operations, including: sequentially loading multiple copies of the new version program to perform an overwrite operation on the current application; when the overwrite operation of any copy of the new version program is completed and passes verification, the main status flag is updated to a second preset value to trigger the system to migrate to the running confirmation state; when the overwrite operation of any copy of the new version program fails or fails verification, the value of the counter flag is increased by a preset fixed step, and the embedded system is controlled to restart to continue loading other copies of the new version program to perform overwrite operations; when the overwrite operations of all copies of the new version program fail or all fail verification, and the number of failures of the program operation is determined to exceed a second failure threshold according to the updated counter flag, the main status flag is updated to a third preset value, and the counter flag is reset to trigger the system to migrate to the backup and recovery phase.

[0009] Optionally, when the system is in the running confirmation state, the bootloader and the application program perform program operations, including: after the bootloader determines that the system is in the running confirmation state based on the main status flag, it executes the new version program; after the new version program starts, it sends a running validity confirmation request to the host computer; if a valid confirmation response is received from the host computer within a preset time limit, the main status flag and the counter flag are reset to their initial values, so that the system enters the normal operating state defined by the main status flag.

[0010] Optionally, the method further includes: if the new version of the program fails to start or no valid confirmation response is received from the host computer within the preset time limit, the value of the counting flag is increased by a preset fixed step, and the embedded system is restarted; after the embedded system restarts, if the number of program operation failures is determined according to the updated counting flag not to exceed the third failure threshold, the running confirmation state is maintained and the program operation is re-executed; if the number of program operation failures is determined according to the updated counting flag to exceed the third failure threshold, the main status flag is updated to the third preset value, and the counting flag is reset to trigger the system to migrate to the backup and recovery phase.

[0011] Optionally, the step of using the bootloader to perform system recovery operations based on pre-stored historical version program backups includes: sequentially loading multiple historical version program backup copies; when any of the historical version program backup copies passes verification, using the verified historical version program backup copy to perform an overwrite operation on the current application; when all the historical version program backup copies fail verification, performing bitwise logical operations on the multiple historical version program backup copies, determining the reconstructed program image based on the majority bit state of each historical version program backup copy, using the reconstructed image to perform an overwrite operation on the current application, and resetting the main status flag and the counter flag to their initial values, so that the system enters normal operating state.

[0012] According to a second aspect of the present invention, an embedded software online upgrade device is provided, comprising: The status determination module is used to read the preset main status flag and count flag of the non-volatile memory in the embedded system after the boot program is powered on and started, and to determine the current upgrade stage of the system based on the main status flag. An operation module is used to perform corresponding program operations based on the current upgrade stage of the system, wherein the bootloader and / or the application performs corresponding program operations, wherein the program operations include receiving, verifying and writing a new version of the program, and the new version of the program is stored in the non-volatile memory in a redundant manner; The recovery module is used to record the number of failures of the program operation based on the operation result using the counting flag during the execution of the program operation. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the main status flag, and the system recovery operation is performed using the bootloader based on the pre-stored historical version program backup.

[0013] According to a third aspect of the present invention, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described embedded software online upgrade method.

[0014] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described embedded software online upgrade method.

[0015] This invention provides an embedded software online upgrade method, apparatus, storage medium, and computer device. Based on a master status flag, it determines the current upgrade stage of the system, forming a staged state management mechanism. This allows for precise differentiation and identification of key sub-states such as reception, verification, overwriting, and confirmation, providing a foundation for anomaly localization and targeted handling. Furthermore, by constructing a built-in, deterministic backup and recovery path, when the upgrade process ultimately triggers recovery conditions for various reasons, the system can proactively revert to a known and usable historical version via a bootloader, thus forming a closed loop from upgrade failure to secure recovery. Specifically, a counter flag is introduced to record the number of program operation failures, and a failure count threshold is set as a quantitative judgment basis for state transitions, achieving precise quantitative control of retry behavior. This enables the system to improve the reliability and controllability of the upgrade process under resource-constrained conditions. The above method, by introducing staged state management with dual flag collaboration, retry control based on a failure count threshold, and a pre-built backup recovery path, improves the state controllability, error tolerance, and system self-recovery capability of the embedded software online upgrade process, thereby meeting the upgrade robustness requirements of high-reliability embedded scenarios such as medical equipment and industrial control.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart illustrating an online upgrade method for embedded software provided in an embodiment of the present invention is shown. Figure 2 A flowchart illustrating another method for online upgrade of embedded software provided in an embodiment of the present invention is shown; Figure 3 This invention illustrates a flowchart of the application program's operation in another embedded software online upgrade method provided by an embodiment of the present invention. Figure 4 This invention illustrates a flowchart of the bootloader operation in another embedded software online upgrade method provided by an embodiment of the present invention. Figure 5 This diagram illustrates the structure of an embedded software online upgrade device according to an embodiment of the present invention. Figure 6 A schematic diagram of the device structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0018] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0019] This application provides an online upgrade method for embedded software, which is executed in an embedded system containing a bootloader and an application program, such as... Figure 1 As shown, the method includes the following steps: 101. After power-on, the bootloader reads the preset master status flag and count flag in the non-volatile memory of the embedded system, and determines the current upgrade stage of the system based on the master status flag.

[0020] The bootloader refers to a basic program stored in a specific area of ​​non-volatile memory in an embedded system and executed first after the device is powered on. It is responsible for system initialization, upgrade process control, and application loading. The application program refers to the main program stored in non-volatile memory and running after the bootloader is loaded to implement the core business functions of the device. It can be replaced by a new version of the program through online upgrades. Non-volatile memory refers to a storage medium that does not lose data after power failure, such as Flash memory. The main status flag is a specific variable stored in non-volatile memory. Different values ​​are used to uniquely identify the different upgrade stages of the system, such as receiving, verifying, overwriting, and acknowledging. The counter flag is another independent variable used to record the number of retries for failed operations during the upgrade process.

[0021] Specifically, each time the embedded device is powered on, the bootloader actively reads the pre-set main status flag and count flag in the non-volatile memory. The bootloader first parses the value of the main status flag and, according to the preset mapping relationship, such as a specific value corresponding to a specific stage, accurately determines the upgrade process node in which the system is, thus realizing the persistent storage of the upgrade status and ensuring the continuity and controllability of the upgrade process.

[0022] In this embodiment, by actively reading and parsing the flag bit through the bootloader, the system can determine its precise position in the upgrade process at the moment of power-on. This avoids the problems of process confusion or having to start from scratch after restarting caused by the ambiguity of the status expression in the traditional single flag bit scheme. It not only improves the reliability and predictability of the upgrade process, but also lays the technical foundation for subsequent targeted program operations based on the precise status. It is especially suitable for embedded scenarios such as industrial control and medical equipment where the deterministic requirements of system startup are high.

[0023] 102. Based on the current upgrade stage of the system, the bootloader and / or application execute corresponding program operations, including receiving, verifying and writing the new version of the program, and storing the new version of the program in non-volatile memory in a redundant manner.

[0024] The upgrade phase refers to the different state nodes in the upgrade process defined by the master status flag, such as data reception and verification status, program overwrite status, etc.; program operation refers to the specific execution actions related to the upgrade; reception refers to obtaining new version program data from an external source; verification refers to verifying the integrity or correctness of the received or stored program data; writing refers to storing the verified new version program data into the target area of ​​non-volatile memory; redundant storage refers to generating multiple identical copies of the same new version program data and storing them in different physical or logical storage locations of non-volatile memory.

[0025] Specifically, the system dynamically allocates the execution entity based on the determined current upgrade stage, that is, selects the bootloader, the application program, or both working together, and calls the corresponding operation process. For example, in the data receiving stage, the application program is responsible for communicating with the host computer and receiving data, while in the program overwrite stage, the bootloader is responsible for reading data from the memory and performing the write operation. The entire process covers the entire chain operation of the new version program. At the same time, the successfully verified new version program is persistently stored in a redundant form, providing multiple original data sources for possible overwrite failures or program corruption, thus enhancing the fault tolerance of the upgrade process.

[0026] In this embodiment, the upgrade task is finely divided and the data storage is enhanced to improve fault tolerance. The bootloader and application execution are dynamically allocated according to the stage, making the upgrade process efficient and safe. The new version of the program is stored in a redundant manner, which directly improves the reliability and availability of the upgrade data. Even in extreme cases where a single data copy is corrupted or a single overwrite operation fails, the system still has alternative data sources to continue or retry the upgrade operation, reducing the risk of upgrade failure and enhancing the robustness of the upgrade system.

[0027] 103. During the execution of the program operation, the counting flag is used to record the number of program operation failures based on the operation results. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the main status flag, and the boot program is used to perform system recovery operations based on the pre-stored historical version of the program backup.

[0028] Among them, the operation result refers to the result obtained after performing program operations such as receiving, verifying, or writing, and is usually divided into success or failure; the number of failures refers to the cumulative number of operation failures that occur in a certain stage or link during the upgrade process; the failure number threshold is a pre-set upper limit value used to determine whether the number of failures has reached or exceeded the critical point that requires specific handling measures; the backup and recovery stage refers to a system state defined by the master status flag, and its function is to perform system recovery; the historical version program backup refers to one or more copies of the previous version or multiple previous version applications that are known to be able to run normally and are pre-saved in non-volatile memory before the upgrade begins.

[0029] Specifically, at any stage of the upgrade process, for each identifiable operation failure, the system updates the counter flag to increment its value. The system compares the current value of the counter flag with a preset failure count threshold in real time. Once the accumulated failure count exceeds the threshold, it indicates that it is impossible or inappropriate to continue retrying at the current stage. The system will actively control the state transition. In one case, the main state flag is first updated to explicitly switch the system state to the backup and recovery stage. Subsequently, the bootloader, as the execution core, reads the pre-stored, reliable historical version of the program backup from non-volatile memory and uses it to overwrite the currently potentially damaged or incomplete application, thereby forcibly restoring the system to a known working state.

[0030] In this embodiment, quantitative control of upgrade risks and deterministic recovery of faults are achieved. By accurately recording the number of failures and comparing them with a threshold, resource waste and system deadlock in permanent faults or harsh environments are avoided. Once a failure is determined to be insurmountable, the system automatically jumps to the preset backup and recovery stage. Based on this, through threshold triggering and forced recovery, it is ensured that in upgrade failure scenarios, the system can still automatically roll back to an available version through the operation of the bootloader, thereby improving the reliability and security of online upgrades of embedded systems.

[0031] This invention provides an online upgrade method for embedded software. Based on a master status flag, it determines the current upgrade stage of the system, forming a staged state management mechanism. This mechanism can precisely distinguish and identify key sub-states such as reception, verification, overwriting, and confirmation, providing a foundation for anomaly localization and targeted handling. Furthermore, by constructing a built-in, deterministic backup and recovery path, when the upgrade process ultimately triggers recovery conditions for various reasons, the system can proactively revert to a known and usable historical version through a bootloader, thus forming a closed loop from upgrade failure to safe recovery. Specifically, a counter flag is introduced to record the number of program operation failures, and a failure count threshold is set as a quantitative judgment basis for state transitions, achieving precise quantitative control of retry behavior. This allows the system to improve the reliability and controllability of the upgrade process under resource-constrained conditions. The above method, by introducing staged state management with dual flags, retry control based on a failure count threshold, and a pre-built backup recovery path, improves the state controllability, error tolerance, and system self-recovery capability of the online upgrade process for embedded software, thereby meeting the upgrade robustness requirements of high-reliability embedded scenarios such as medical equipment and industrial control.

[0032] This application provides another method for online upgrade of embedded software, such as... Figure 2 As shown, it specifically includes: 201. Initial state judgment.

[0033] Specifically, after the device completes hardware initialization, the bootloader runs. The bootloader actively accesses two predefined state variables in non-volatile memory: the main status flag and the counter flag. The bootloader first reads the value of the main status flag and makes a branch judgment based on its content. If the value of the main status flag is a specific initial value, i.e., 0x00, it indicates that there is no ongoing or incomplete upgrade process in the system, and no recovery operation is required. At this time, the bootloader will directly jump to the entry address of the application, so that the device enters the normal operating state and is marked as state 0. Conversely, if the value of the main status flag is not the initial value, i.e., not 0x00, it indicates that the system may have been interrupted during the last run due to upgrade, recovery or other processes, or is in a certain upgrade sub-stage. At this time, the bootloader will determine the corresponding state that the system should enter based on the specific value of the main status flag and the preset state mapping relationship, and continue to execute the subsequent process corresponding to this state.

[0034] 202. Data reception and verification.

[0035] When the system is in the data receiving and verification state, the application performs program operations, including: receiving the upgrade data packet sent by the host computer and performing integrity verification on the upgrade data packet; when the upgrade data packet is received and passes the integrity verification, parsing the upgrade data packet to obtain the new version program, generating multiple copies of the new version program, storing the multiple copies of the new version program in different areas of the non-volatile memory, updating the main status flag to the first preset value and resetting the counter flag to trigger the system to migrate to the program overwrite state.

[0036] Furthermore, when the upgrade data packet fails to be received or fails the integrity check, the value of the counter flag is increased by a preset fixed step. If the value of the counter flag after the increase does not exceed the first failure count threshold, the application is controlled to re-receive the upgrade data packet. If the value of the counter flag after the increase exceeds the first failure count threshold, the main status flag and the counter flag are reset to their initial values, and the embedded system is controlled to restart.

[0037] Specifically, this step corresponds to the data reception and initial verification stage in the online upgrade process, i.e., state 1. In this stage, the application acts as the execution entity, responsible for communicating with the host computer and processing upgrade data. After receiving the upgrade instruction from the host computer, the application will proactively update the main status flag to a specific value that represents the data reception and verification status, i.e., 0x11, to indicate to the bootloader that the system has entered this stage.

[0038] The specific operational process is divided into two paths: success and failure. In the successful path, the application receives the upgrade data packet sent by the host computer and performs an integrity check on the upgrade data packet. If the upgrade data packet is received and the check passes, the application parses the executable new version program from the data packet and then generates three identical program copies. The application then stores the three copies in independent storage areas of non-volatile memory to achieve redundant backup of the new version program. After storage is completed, the application updates the main status flag to a specific value to indicate the next stage, such as updating it to the first preset value 0x22 corresponding to the program overlay state, and resets the counter flag to 0x00. This constitutes the complete signal and data preparation to trigger the system state to migrate to the program overlay state.

[0039] In the failure path, if a data packet reception failure or integrity verification failure occurs, the system will initiate a quantized retry and fault tolerance mechanism. Specifically, each time such a failure event occurs, the value of the counter flag will increase by a preset fixed step, such as 0x11. The system will then determine the increased counter value. If the counter flag value does not exceed the preset first failure count threshold, such as 0x33, the system will control the application to retry receiving the upgrade data packet and enter a new round of reception and verification process. If the counter flag value has exceeded the first failure count threshold, indicating that it still cannot succeed within a reasonable retry range, the system will reset both the main status flag and the counter flag to their initial values, i.e., both set to 0x00, and actively control the embedded system to restart, thereby exiting the upgrade process and returning to the initial state.

[0040] 203. Program Overlay.

[0041] When the system is in the program overwrite state, the bootstrap program executes program operations, including: sequentially loading multiple new version program copies to overwrite the current application; when the overwrite operation of any new version program copy is completed and passes verification, the main status flag is updated to a second preset value to trigger the system to migrate to the running confirmation state; when the overwrite operation of any new version program copy fails or fails verification, the value of the counter flag is increased by a preset fixed step, and the embedded system is controlled to restart to continue loading other new version program copies to perform overwrite operations; when the overwrite operations of all new version program copies fail or all fail verification, and the number of program operation failures exceeds a second failure threshold according to the updated counter flag, the main status flag is updated to a third preset value, and the counter flag is reset to trigger the system to migrate to the backup and recovery stage.

[0042] Specifically, this step corresponds to the program overwrite and verification phase in the online upgrade process, i.e., state 2. In this phase, the system is in a program overwrite state, with the bootloader acting as the execution entity. It is responsible for replacing the current application with the new version of the program that has been received and redundantly stored. The bootloader sequentially loads three copies of the new version of the program stored in different areas of the non-volatile memory, and uses the currently loaded copy to perform an overwrite operation on the application storage area of ​​the embedded system, i.e., erase and write. After each overwrite operation is completed, the bootloader immediately verifies the contents of the overwritten storage area to verify the integrity and correctness of the written data. The operation results and subsequent behaviors are divided into the following three scenarios: Successful Overwrite Path: If the overwrite operation for any program copy is completed and subsequent verification passes, taking the first program copy as an example, it indicates that the new version of the program has been successfully deployed. At this time, the bootloader updates the main status flag to a specific value used to indicate the next stage, namely the second preset value 0x33 corresponding to the running confirmation status, thereby triggering the system status to migrate to the running confirmation status, in preparation for subsequent running verification.

[0043] Single-failure retry path: If the overwrite operation for a program copy fails, such as a write error or a verification failure after the overwrite operation, it means that the attempt was unsuccessful. At this time, the system performs fault tolerance processing. First, the value of the counter flag is increased by a preset fixed step, such as automatically increasing by 0x11, to accumulate the failure. Then, the bootloader controls the entire embedded system to restart. After restarting, the bootloader will re-enter the program overwrite state according to the persistent status flag and automatically continue to load the next new version of the program copy, such as loading the second program copy to repeat the overwrite and verification process.

[0044] Complete failure recovery path: If the bootloader has attempted to load and use all three available redundant program copies for overwriting in sequence, but all attempts have failed, i.e. the overwriting operation failed or the verification failed, and the total number of program operation failures has exceeded the second failure threshold preset for this stage, as determined by the cumulative updated counter flag, for example, the counter flag value exceeds 0x33, it indicates that the upgrade cannot be completed by retrying in this stage. At this time, the system will execute the security policy, the bootloader will update the main status flag to the third preset value 0x44 specifically used to indicate that recovery is required, and reset the counter flag to 0x00. This status change triggers the system to forcibly migrate to the backup and recovery stage and start the system recovery operation based on the historical version of the program backup.

[0045] 204. Operation status confirmed.

[0046] When the system is in the running confirmation state, the bootloader and application program execute program operations, including: after the bootloader determines that the system is in the running confirmation state based on the main status flag, it executes the new version program; after the new version program starts, it sends a running validity confirmation request to the host computer; if a valid confirmation response is received from the host computer within a preset time limit, the main status flag and the counter flag are reset to their initial values, so that the system enters the normal operating state defined by the main status flag.

[0047] Furthermore, if the new version of the program fails to start or does not receive a valid confirmation response from the host computer within a preset time limit, the value of the counter flag will be increased by a preset fixed step, and the embedded system will be restarted. After the embedded system restarts, if the number of program operation failures is determined to be less than the third failure threshold based on the updated counter flag, the running confirmation state will be maintained and the program operation will be re-executed. If the number of program operation failures is determined to be greater than the third failure threshold based on the updated counter flag, the main status flag will be updated to the third preset value, and the counter flag will be reset to trigger the system to migrate to the backup and recovery phase.

[0048] Specifically, this step corresponds to the running confirmation state in the online upgrade process, i.e., state 3, which is completed collaboratively by the bootloader and the updated new version of the application. The specific process begins with the bootloader determining that the system has entered the running confirmation state based on the value of the main status flag. Subsequently, the bootloader jumps to the application storage area that has been overwritten, starts and executes the new version of the program. After the new version of the program starts, its primary task is to proactively send a running validity confirmation request to the host computer to report that it has successfully started and request the host computer to perform functional or communication-level confirmation. The operation result and subsequent behavior are divided into the following two scenarios: Successful confirmation path: If the new version program starts normally and receives a clear and valid confirmation response from the host computer within the preset communication time limit, it indicates that the new version program is running stably and is connected to the host computer normally. At this time, the system will reset the main status flag and the counter flag to the initial value 0x00 defined by the system, so that the main status flag of the system represents the normal operating state, i.e., state 0, thereby completing the entire upgrade closed loop and the device enters the normal operating mode.

[0049] Confirmation of Failure Path: If the new version of the program fails to start, or if the program starts but fails to receive a valid confirmation response from the host computer within a preset time limit, the system initiates a fault handling and retry mechanism. First, the system increments the value of the counter flag by a preset fixed step, such as automatically incrementing by 0x11, to record this confirmation failure. Then, the system triggers the embedded device to restart. After the device restarts, the bootloader will read the status flag again. If the system is still in the running confirmation state, it will judge based on the updated counter flag value. If the value does not exceed the preset third failure count threshold of 0x33, the system maintains the running confirmation state, and the bootloader will try to execute the new version of the program again and initiate confirmation, thus entering a new round of running and confirmation loop. If the value has exceeded the third failure count threshold, it indicates that a valid running confirmation cannot be established after a limited number of retries. The system updates the main status flag to the third preset value used to trigger recovery, such as 0x44, and resets the counter flag, thereby forcibly triggering the system to migrate to the backup and recovery stage, ensuring system availability by restoring the historical version.

[0050] 205. Backup and restore.

[0051] The process involves sequentially loading multiple historical version program backup copies; when any historical version program backup copy passes verification, the current application is overwritten using the verified historical version program backup copy; when all historical version program backup copies fail verification, bitwise logical operations are performed on multiple historical version program backup copies, and the reconstructed program image is determined based on the majority bit state of each historical version program backup copy. The reconstructed image is then used to overwrite the current application, and the main status flag and the count flag are reset to their initial values, allowing the system to enter normal operation.

[0052] Specifically, this step corresponds to the backup and recovery state triggered by various failures in the online upgrade process, i.e., state 4. The bootloader acts as the sole execution entity, responsible for restoring a runnable application from the pre-stored historical version backup to ensure minimum system availability. The bootloader first attempts to load three copies of the historical version program backup pre-stored in non-volatile memory, and performs integrity verification on each loaded copy. The operation results and subsequent behaviors fall into the following two categories: Direct recovery path: If any copy is successfully loaded and passes verification during the attempt, it indicates that a complete and usable historical program image has been found. The bootloader then uses the verified backup copy to overwrite the current application storage area and completes the program recovery.

[0053] Recovery path after repair: If loading all three available backup copies fails, or all copies fail verification, it indicates that all original backups may be corrupted to varying degrees. In this case, the bootloader will simultaneously read all available corrupted backup copies and perform bitwise logical operations on these copies. Specifically, the operation is based on the majority voting principle, that is, on the same data bit of all copies, the state that accounts for the majority is determined as the correct value of the reconstructed program image at this bit. It is preferred to use the bitwise two-out-of-three method. Through bitwise operation, a complete and logically consistent program image is finally reconstructed. Subsequently, the bootloader uses this reconstructed image to overwrite the application storage area.

[0054] Ultimately, regardless of which path is used to overwrite the application storage area, it is considered a recovery attempt. If the overwrite operation itself fails, the system will maintain the backup recovery state and control the restart to try the recovery process again. If the overwrite operation is successful, it means that the system has been restored to a known and usable historical version. At this time, the bootloader resets both the main status flag and the counter flag to the initial value 0x00, so that the system main status flag represents the normal operating state, i.e., state 0. The device exits the recovery process and enters normal business operation.

[0055] In the embedded software online upgrade method provided in this application, the application execution flow is as follows: Figure 3 As shown, during the normal execution of the main program, the application continuously monitors or periodically checks whether it has entered the update program status confirmation stage. When preset conditions are met, such as receiving an external command, reaching a timed detection point, or being triggered by internal logic, the application will actively communicate with the host computer to initiate an update status confirmation request to confirm whether an online upgrade is required. If the host computer returns a negative confirmation or the communication times out, the application will continue to maintain normal operation and will not trigger the upgrade process. If a clear upgrade confirmation is received from the host computer, the application will then check whether a valid online update command has actually been received. Once the confirmation command is valid, the application will first update the online main status flag in the non-volatile memory, setting it to indicate an update status. The specific value of the new state and the update of the main state flag are key to the bootloader's identification of the upgrade entry point. After the main state flag is set, the application actively jumps to the bootloader's entry address, and the bootloader takes over the subsequent core upgrade operations such as firmware reception, verification, overwriting, and restoration. After the entire upgrade process is completed, the application refreshes the online update flag to the corresponding state according to the final result. If the upgrade is successful and verification is passed, the main state flag is set to the normal working state. If the upgrade process fails and the recovery mechanism is triggered, the main state flag is set to the recovery program state. After that, the application enters the corresponding normal working task loop or the recovery running state, thus completing a complete online upgrade judgment and collaboration process.

[0056] In the embedded software online upgrade method provided in this application, the bootloader execution process is as follows: Figure 4 As shown, after the embedded system powers on, the bootloader first performs initialization operations to complete the necessary hardware initialization. Then, it reads and checks the status of the preset master status flag in the non-volatile memory. If the master status flag indicates that the system does not need to perform an upgrade or recovery operation, the bootloader directly jumps to the application entry point, allowing the system to enter normal operation. If the master status flag indicates that the system needs to enter the recovery procedure, the bootloader refreshes the master status flag and enters the recovery routine. The ultimate goal is to restore the system to a runnable state by loading backup programs, etc., and then jump to the application. If the master status flag indicates that the system needs to perform an online update process, the bootloader is responsible for receiving the new version program data from the communication interface and continuously checking whether the data has been received completely and passed verification. If the reception fails or the verification fails... The process may transition to exception handling or retry logic. Once reception is complete and verification is successful, the bootstrap program executes the overwrite update program and verification program operations. This involves overwriting the application's storage area with the received data and immediately verifying the overwritten program. The bootstrap program determines whether the overwrite operation itself and subsequent verification were successful. If the overwrite or verification fails, the process may transition to a retry or recovery path. If the overwrite is successful and verification passes, the bootstrap program jumps to the updated application for execution, and the application is responsible for confirming the operation with the host computer. The bootstrap program's control flow ensures that the upgrade process has the ability to resume transmission after a power outage. If the system unexpectedly restarts for any reason, the bootstrap program can accurately restore to the sub-stage before the interruption by reading these saved states and continue execution, thereby enhancing the reliability and robustness of the entire upgrade process.

[0057] Furthermore, as Figure 1 In terms of specific implementation, this application provides an embedded software online upgrade device, such as... Figure 5 As shown, the device includes: a status judgment module 301, an operation module 302, and a recovery module 303.

[0058] The status judgment module 301 is used to read the preset main status flag and count flag in the non-volatile memory of the embedded system after the boot program is powered on, and to determine the current upgrade stage of the system based on the main status flag. The operation module 302 is used to guide the program and / or application to perform corresponding program operations based on the current upgrade stage of the system. The program operations include receiving, verifying and writing the new version of the program, and the new version of the program is stored in non-volatile memory in a redundant manner. The recovery module 303 is used to record the number of program operation failures based on the operation results using a counter flag during the execution of program operations. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the master status flag, and the bootloader is used to perform system recovery operations based on the pre-stored historical version of the program backup.

[0059] In specific application scenarios, the upgrade phase includes a data reception and verification state and a program overwrite state defined based on the main status flag. The operation module 302 is specifically used to perform program operations when the system is in the data reception and verification state, including: receiving the upgrade data packet sent by the host computer and performing integrity verification on the upgrade data packet; when the upgrade data packet is received and passes the integrity verification, parsing the upgrade data packet to obtain the new version program, generating multiple copies of the new version program, storing the multiple copies of the new version program in different areas of the non-volatile memory, updating the main status flag to the first preset value and resetting the counter flag to trigger the system to migrate to the program overwrite state.

[0060] In specific application scenarios, the operation module 302 is also used to increase the value of the counting flag by a preset fixed step when the upgrade data packet fails to be received or fails the integrity check; if the value of the count flag after the increase does not exceed the first failure count threshold, the application is controlled to re-receive the upgrade data packet; if the value of the count flag after the increase exceeds the first failure count threshold, the main status flag and the counting flag are reset to their initial values, and the embedded system is controlled to restart.

[0061] In specific application scenarios, the upgrade phase also includes a running confirmation state defined by the main status flag. The operation module 302 is specifically used to guide the program to perform program operations when the system is in the program overwrite state, including: sequentially loading multiple new version program copies to perform overwrite operations on the current application; when the overwrite operation of any new version program copy is completed and passes verification, the main status flag is updated to a second preset value to trigger the system to migrate to the running confirmation state; when the overwrite operation of any new version program copy fails or fails verification, the value of the counter flag is increased by a preset fixed step, and the embedded system is controlled to restart to continue loading other new version program copies to perform overwrite operations; when the overwrite operations of all new version program copies fail or all fail verification, and the number of program operation failures exceeds the second failure threshold according to the updated counter flag, the main status flag is updated to a third preset value, and the counter flag is reset to trigger the system to migrate to the backup and recovery phase.

[0062] In specific application scenarios, the operation module 302 is specifically used to enable the bootloader and application program to perform program operations when the system is in the running confirmation state, including: after the bootloader determines that the system is in the running confirmation state based on the main status flag, it executes the new version program; after the new version program starts, it sends a running validity confirmation request to the host computer; if a valid confirmation response is received from the host computer within a preset time limit, the main status flag and the counter flag are reset to their initial values, so that the system enters the normal operating state defined by the main status flag.

[0063] In specific application scenarios, the operation module 302 is also used to increment the value of the counter flag by a preset fixed step size and trigger the embedded system to restart if the new version of the program fails to start or if a valid confirmation response is not received from the host computer within a preset time limit; after the embedded system restarts, if the number of program operation failures is determined to be less than the third failure threshold based on the updated counter flag, the running confirmation state is maintained and the program operation is re-executed; if the number of program operation failures is determined to be greater than the third failure threshold based on the updated counter flag, the main status flag is updated to the third preset value and the counter flag is reset to trigger the system to migrate to the backup and recovery stage.

[0064] In specific application scenarios, the recovery module 303 is used to sequentially load multiple historical version program backup copies; when any historical version program backup copy passes verification, the current application is overwritten using the verified historical version program backup copy; when all historical version program backup copies fail verification, bitwise logical operations are performed on multiple historical version program backup copies, the reconstructed program image is determined based on the majority bit state of each historical version program backup copy, the current application is overwritten using the reconstructed image, and the main status flag and the count flag are reset to their initial values, so that the system enters normal operation state.

[0065] It should be noted that other corresponding descriptions of the functional units involved in the embedded software online upgrade device provided in this embodiment can be found in [reference]. Figure 1 and Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0066] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the above-described online embedded software upgrade method.

[0067] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product to be identified can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), including several instructions to enable a computer device (such as a personal computer, server, or network device) to execute the embedded software online upgrade method of various implementation scenarios of this application.

[0068] Based on the above, Figure 1 and Figure 2 The method shown, and Figure 5 The embedded software online upgrade device embodiment shown is designed to achieve the above objectives, such as... Figure 6 As shown, this embodiment also provides a physical device for online embedded software upgrades. This device includes a communication bus, a processor, a memory, and a communication interface. It may also include input / output interfaces and a display device. The various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the online embedded software upgrade method described in the above embodiment.

[0069] Optionally, the physical device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0070] Those skilled in the art will understand that the embedded software online upgrade physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0071] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs to be identified. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0072] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware. By applying the technical solution of this application, the current upgrade stage of the system is determined based on the main status flag, forming a staged status management mechanism. This allows for precise differentiation and identification of key sub-states such as reception, verification, overwriting, and confirmation, providing a foundation for anomaly location and targeted handling. Furthermore, by constructing a built-in, deterministic backup and recovery path, when the upgrade process ultimately triggers recovery conditions for various reasons, the system can proactively revert to a known and usable historical version through the bootstrap program, thus forming a closed loop from upgrade failure to safe recovery. Specifically, a counting flag is introduced, which records the number of failed program operations and sets a failure threshold as a quantitative judgment basis for state transition, achieving precise quantitative control of retry behavior. This enables the system to improve the reliability and controllability of the upgrade process under resource-constrained conditions. The above method improves the state controllability, error tolerance, and system self-recovery capability of the online upgrade process of embedded software by introducing phased state management with dual flags, retry control based on failure count thresholds, and recovery paths with pre-set backups, thereby meeting the requirements of high-reliability embedded scenarios such as medical equipment and industrial control for upgrade robustness.

[0073] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0074] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for online upgrade of embedded software, characterized in that, The method is executed in an embedded system containing a bootloader and an application program, and includes: After power-on, the bootloader reads the preset master status flag and count flag of the non-volatile memory in the embedded system, and determines the current upgrade stage of the system based on the master status flag. Based on the current upgrade phase of the system, the bootloader and / or the application execute corresponding program operations, wherein the program operations include receiving, verifying and writing the new version of the program, and the new version of the program is stored in the non-volatile memory in a redundant manner. During the execution of the program operation, the counting flag is used to record the number of failures of the program operation based on the operation result. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the main status flag, and the bootloader is used to perform system recovery operation based on the pre-stored historical version program backup.

2. The method according to claim 1, characterized in that, The upgrade phase includes data reception and verification status and program overwrite status based on the main status flags; When the system is in the data receiving and verification state, the application performs program operations, including: Receive the upgrade data packet sent by the host computer and perform integrity verification on the upgrade data packet; When the upgrade data packet is received and passes the integrity check, the upgrade data packet is parsed to obtain the new version program, multiple copies of the new version program are generated, the multiple copies of the new version program are stored in different areas of the non-volatile memory, the main status flag is updated to the first preset value and the counter flag is reset to trigger the system to migrate to the program overwrite state.

3. The method according to claim 2, characterized in that, The method further includes: When the upgrade data packet fails to be received or fails the integrity check, the value of the counting flag is increased by a preset fixed step. If the value of the increased counter flag does not exceed the first failure count threshold, then the application is controlled to re-receive the upgrade data packet; If the value of the count flag after the increase exceeds the first failure count threshold, the main status flag and the count flag are reset to their initial values, and the embedded system is restarted.

4. The method according to claim 2, characterized in that, The upgrade phase also includes a running confirmation status based on the main status flag; When the system is in the program overridden state, the bootloader performs program operations, including: The current application is overwritten by sequentially loading multiple copies of the new version of the program. When the overwrite operation of any of the new version program copies is completed and passes the verification, the main status flag is updated to the second preset value to trigger the system to migrate to the running confirmation state. When the overwrite operation of any new version program copy fails or fails the verification, the value of the counter flag is increased by a preset fixed step, and the embedded system is controlled to restart to continue loading other new version program copies to perform the overwrite operation. When the overwrite operation of all copies of the new version of the program fails or all fail the verification, and the number of failures of the program operation exceeds the second failure threshold according to the updated counting flag, the main status flag is updated to the third preset value and the counting flag is reset to trigger the system to migrate to the backup and recovery stage.

5. The method according to claim 4, characterized in that, When the system is in the running confirmation state, the bootloader and the application perform program operations, including: After the bootloader determines that the system is in the running confirmation state based on the main status flag, it executes the new version of the program. After the new version of the program starts, it sends a request to the host computer to confirm the validity of its operation. If a valid confirmation response is received from the host computer within the preset time limit, the main status flag and the counter flag are reset to their initial values, so that the system enters the normal operating state defined by the main status flag.

6. The method according to claim 5, characterized in that, The method further includes: If the new version of the program fails to start or does not receive a valid confirmation response from the host computer within the preset time limit, the value of the counting flag will be increased by a preset fixed step, and the embedded system will be triggered to restart. After the embedded system restarts, if the number of failures of the program operation is determined to be less than the third failure threshold according to the updated counting flag, the running confirmation state is maintained and the program operation is re-executed. If the updated counting flag determines that the number of program operation failures exceeds the third failure threshold, then the main status flag is updated to the third preset value, and the counting flag is reset to trigger the system to migrate to the backup and recovery phase.

7. The method according to claim 1, characterized in that, The process of performing system recovery operations based on pre-stored historical version program backups using the bootloader includes: Load multiple historical version backup copies of the program sequentially; When any of the aforementioned historical version program backup copies pass verification, the current application is overwritten using the verified historical version program backup copy. When all the historical version program backup copies fail the verification, bitwise logical operations are performed on multiple historical version program backup copies. Based on the majority bit state of each historical version program backup copy, a reconstructed program image is determined. The reconstructed image is used to perform an overwrite operation on the current application, and the main status flag and the count flag are reset to their initial values, so that the system enters normal operation.

8. An embedded software online upgrade device, characterized in that, include: The status determination module is used to read the preset main status flag and count flag of the non-volatile memory in the embedded system after the boot program is powered on and started, and to determine the current upgrade stage of the system based on the main status flag. An operation module is used to perform corresponding program operations based on the current upgrade stage of the system, wherein the bootloader and / or the application performs corresponding program operations, wherein the program operations include receiving, verifying and writing a new version of the program, and the new version of the program is stored in the non-volatile memory in a redundant manner; The recovery module is used to record the number of failures of the program operation based on the operation result using the counting flag during the execution of the program operation. When the number of failures exceeds the failure threshold, the system is migrated to the backup and recovery stage defined by the main status flag, and the system recovery operation is performed using the bootloader based on the pre-stored historical version program backup.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images