Firmware online upgrading method, embedded device, medium and product

Abstract

The invention provides a firmware online upgrading method, embedded equipment, a medium and a product, and relates to the technical field of intelligent terminals. The method comprises the following steps: after the embedded equipment is powered on, running a primary bootstrap program, and checking a first mark state: if the state is a state of updating a secondary bootstrap program, executing online updating of the program and resetting a system; and if the state is the default state, loading and running the secondary bootstrap program. Checking a second mark state; if the second mark state is an updating mirror image state, executing firmware mirror image online updating and resetting; and if the state is the default state, determining a target mirror image, copying the target mirror image from the nonvolatile memory to the random access memory, and skipping to run. And the equipment simultaneously monitors the running state of the target mirror image in real time, and executes successful confirmation or abnormal recovery operation according to the state. In this way, quick response of faults is achieved through running state feedback, the stability and reliability of firmware upgrading of the embedded device are effectively improved, and the risk of device paralysis in the upgrading process is reduced.

Description

Technical Field

[0001] This application relates to the field of smart terminal technology, and in particular to a firmware online upgrade method, embedded device, medium, and product. Background Technology

[0002] In fields such as IoT devices, industrial controllers, and automotive electronics, firmware over-the-air (OTA) upgrades or local upgrades are typically required to fix software defects or update functionality. This usually involves the bootloader, application image, and read / write operations on flash storage, demanding high stability and fault tolerance from the device during the upgrade process.

[0003] In existing firmware upgrade schemes based on the A / B dual-partition mechanism, a primary partition and a backup partition are typically created in the Flash memory. When the device needs to be upgraded, the new firmware version is downloaded and written to the backup partition, the system's boot flag or version record is updated, and then the device is rebooted. The bootloader reads the flag at startup, and if it finds a new firmware to be updated and the checksum is correct, it directly jumps to the partition where the new firmware is located and runs it.

[0004] However, the aforementioned existing technologies have significant drawbacks. The bootloader typically only performs static data integrity checks on the new firmware and cannot predict the stability of the firmware during runtime. Once the new firmware contains a logical defect that could cause the system to crash (such as an initialization error triggering a watchdog reset), the device will repeatedly attempt to boot the faulty firmware, thus entering an infinite loop, ultimately leading to device paralysis and difficulty in remote recovery. Summary of the Invention

[0005] This application provides a firmware online upgrade method, an embedded device, a medium, and a product for improving the stability and reliability of firmware upgrades for embedded devices.

[0006] In a first aspect, this application provides a firmware online upgrade method applied to an embedded device. The method includes: after the embedded device is powered on, running a primary bootloader; checking the current first flag state; if the first flag state is an update secondary bootloader state, then performing an online update of the secondary bootloader and a system reset; if the first flag state is a default state, then loading and running the secondary bootloader; checking the current second flag state; if the second flag state is an update image state, then performing an online update of the firmware image and a system reset; if the second flag state is a default state, then determining the target image; copying the target image from non-volatile memory to random access memory, and jumping to the random access memory to run the target image; monitoring the running status of the target image in real time, and performing a corresponding success confirmation operation or an exception recovery operation according to the running status.

[0007] By adopting the above technical solution, the primary bootloader prioritizes handling the update requests of the secondary bootloader, decoupling the boot layer and application layer upgrades through the first flag state to avoid mutual interference between upgrade operations. The secondary bootloader executes firmware image updates or startup logic based on the second flag state, achieving orderly triggering of the upgrade process. The real-time monitoring stage after image execution can promptly identify operational anomalies and perform recovery operations. Each stage proceeds in the order of "boot-upgrade-start-monitoring," ensuring both the independence and controllability of the upgrade process and enabling rapid fault response through operational status feedback. This effectively improves the stability and reliability of embedded device firmware upgrades and reduces the risk of device failure during the upgrade process.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the non-volatile memory is pre-configured with a first mirror area and a second mirror area. The steps of performing online firmware image updates and system resets specifically include: receiving new firmware image data sent by a host computer, which includes at least a local computer, a mobile terminal, and a cloud-embedded device; identifying the lower version of the two current mirror areas as the target mirror area for writing; writing the new firmware image data into the target mirror area; and performing a system reset operation after the writing is completed and the verification is successful.

[0009] By adopting the above technical solution, the system first identifies the version difference between the two image partitions and then writes the new firmware to the partition with the lower version. This design avoids accidental operations on the currently running high-version stable image. It also supports firmware transmission from various types of host computers, adapting to both local and remote upgrade scenarios. The verification step after writing ensures the data integrity of the new firmware, and, in conjunction with a system reset, triggers the startup process of the new image. These technical features work together to achieve both accuracy and security in firmware updates, improve the compatibility of the upgrade scheme, ensure the availability of the original stable image of the device during the update process, and reserve reliable redundancy for subsequent fault rollback.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, if the second flag state is the default state, the step of determining the target image specifically includes: reading the firmware image header information stored in the first image area and the second image area; verifying the checksum and validity of the firmware image data in the two areas; if all firmware image data are valid, obtaining the corresponding version number, and selecting the firmware image data with the higher version number as the target image; if only one area of ​​the target firmware image data is valid, determining that target firmware image data as the target image.

[0011] By adopting the above technical solution, the header information of the dual image partitions is first read and its integrity verified, eliminating the possibility of a corrupted image being selected. Then, images with higher version numbers are prioritized to ensure the device can run the latest optimized version. Finally, a "single valid image fallback" rule is set to prevent boot failure when both partitions are abnormal. Each step is interconnected, ensuring the advanced nature of image booting while enhancing the device's fault tolerance through validity verification and fallback mechanisms. This effectively solves the boot problem when corrupted or version-inconsistent images exist in the dual-partition images, ensuring that the device selects the optimal usable image every time it powers on.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes: when the target image is selected as the current boot image, incrementing the boot failure count associated with the target image by one, and writing the updated count to the parameter record area of ​​the non-volatile memory, wherein the boot failure count is used to indicate the number of times the target image attempts to boot before its operational stability is confirmed.

[0013] By adopting the above technical solution, the number of failed startup attempts of the target image is associated with the image and written to non-volatile memory to ensure that the count information is not lost after device reset. This count value serves as the core indicator of image stability, providing data support for subsequent decisions on "whether to switch images." This technical feature upgrades the image startup result from a binary "success / failure" judgment to a quantitative assessment of "number of failures," enabling the system to make more accurate decisions based on cumulative failures. This avoids misjudging an image as unusable due to a single, occasional failure, and provides objective evidence for identifying potentially defective images, improving the accuracy of fault diagnosis.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the step of real-time monitoring of the running status of the target image and performing a corresponding success confirmation operation or anomaly recovery operation based on the running status specifically includes: reading the startup failure count value associated with the target image; determining whether the startup failure count value exceeds a preset failure threshold; if it exceeds, performing the anomaly recovery operation, which includes: determining that the target image is unavailable, switching to an image in another image area as the target image, and skipping the step of incrementing the startup failure count value; if it does not exceed, performing the success confirmation operation.

[0015] By adopting the above technical solution, the system first reads the startup failure count and compares it with a preset threshold. If the count exceeds the threshold, the image is deemed unusable and the system switches to another partition image; otherwise, operation continues. This logic strongly correlates the number of startup failures with image availability, balancing fault tolerance and security through threshold settings: it allows for a limited number of startup attempts to avoid accidental switching caused by occasional interference; it also stops losses in time when the accumulated failures reach the threshold, preventing the device from falling into a vicious cycle of repeated restarts due to faulty images. The synergistic effect of these steps enables automatic identification and isolation of faulty images, significantly improving the device's fault resistance and operational stability.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the step of performing the success confirmation operation specifically includes: after the target image has run in the random access memory for a preset duration or completed the preset critical task initialization, clearing the corresponding startup failure count value in the non-volatile memory parameter recording area; and updating the health status record of the target image to indicate that the target image has successfully and stably run.

[0017] By adopting the above technical solution, the preset runtime or critical task initialization conditions ensure that the image passes the stability test of actual operation; the count reset operation resets the image's startup failure record, providing a clean judgment benchmark for subsequent upgrades or restarts; and the health status update explicitly marks the image as a reliable version to the system. These technical features work together to complete a closed-loop confirmation of image stability from three dimensions: "operational verification," "status reset," and "version marking." This ensures the reliable retention of stable images and provides a clear version status reference for subsequent upgrade processes, further enhancing the reliability of device firmware operation.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the first flag state and the second flag state are stored in the non-volatile memory, and the method further includes: receiving a setting instruction sent by a host computer via a serial port; parsing the setting instruction, modifying the first flag state in the non-volatile memory to update the secondary boot program state, or modifying the second flag state to update the image state.

[0019] By adopting the above technical solution, the host computer can send commands via serial port to directly modify the first and second flag states, triggering the upgrade process of the secondary bootloader and firmware image, respectively. This design overcomes the limitations of automatic upgrades, providing a reliable local intervention point when the device cannot automatically trigger an upgrade due to firmware failure. Simultaneously, the serial port command transmission method is adaptable to complex environments such as industrial sites, possessing strong anti-interference capabilities. The synergistic effect of these technical features makes the upgrade process both automatic and controllable, meeting both conventional remote upgrade needs and solving the local upgrade problem in fault scenarios, thus improving the applicability and flexibility of the solution.

[0020] In a second aspect, this application provides an embedded device comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the embedded device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on an embedded device, cause the embedded device to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product, including a computer program that, when run on an embedded device, causes the embedded device to perform the method described in the first aspect and any possible implementation thereof.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By adopting a hierarchical bootloader architecture, a dual-flag state orderly triggering upgrade and startup process, and collaborative technologies such as real-time monitoring of image operation and anomaly recovery, it effectively solves the technical problems in existing technologies, such as easy interference between the boot layer and application layer upgrades during firmware upgrades and the inability to respond in time after the image operation is abnormal, leading to device paralysis. Thus, it realizes the orderly and controllable firmware upgrade process and rapid fault self-healing, improving the technical effect of stability and reliability of embedded device firmware upgrades.

[0024] 2. By adopting a three-layer screening technology that includes dual-image zone header information verification, version number priority selection, and single valid image fallback, the technology effectively solves the technical problems of device startup failure and inability to accurately select the optimal available image when dual-partition images are damaged or have inconsistent versions in the existing technology. This achieves the accuracy and reliability of target image screening, ensuring that the device can start with the optimal available image every time it is powered on, and improving the device's startup fault tolerance.

[0025] 3. By adopting fault-tolerant technologies such as quantified tracking of startup failure counts, threshold-based assessment of image availability, and automatic switching to the backup image area in case of anomalies, the technology effectively solves the technical problems in existing technologies, such as repeated startup of faulty images causing the equipment to fall into an infinite loop and the tendency to misjudge image unavailability due to occasional failures. This achieves accurate identification and isolation of faulty images, balances the fault tolerance and security of equipment startup, and significantly improves the equipment's fault resistance and operational stability. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the firmware online upgrade method in an embodiment of this application; Figure 2 This is another flowchart illustrating the firmware online upgrade method in this application embodiment; Figure 3 This is a schematic diagram of the physical device structure of an embedded device in the embodiments of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0029] For ease of understanding, the method provided in this implementation is described in process below. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating the firmware online upgrade method in an embodiment of this application.

[0030] S101. After the embedded device is powered on, the first-level boot program runs. The first-level bootloader (Bootloader1st) is the first software program stored at the starting address of non-volatile memory or a specific boot sector. It is used for system initialization and loading subsequent programs.

[0031] This step is typically executed immediately after the embedded device completes its hardware reset sequence. When the embedded device's main power is turned on or a reset signal is triggered, the CPU's program counter (PC) is forced by hardware to point to the reset vector address. The Level 1 bootloader is usually stored at the beginning of the on-chip Flash memory. After the device boots, this program is executed first to complete the necessary hardware initializations, including clock system configuration, general purpose input / output (GPIO) initialization, and stack pointer setting. The Level 1 bootloader has the highest execution privileges and the lowest level of hardware control capabilities, and is usually designed to be read-only or protected to ensure that the device has the most basic boot capabilities under any abnormal conditions.

[0032] S102. Check the current status of the first flag; The first flag state refers to a status variable or flag bit stored in a specific parameter recording area of ​​non-volatile memory, which is used to indicate the next working mode of the first-level boot program; this status variable is usually modified by the host computer through a communication protocol, or set by internal logic when the system is abnormal.

[0033] After the primary bootloader completes basic hardware initialization, the program reads a reserved parameter recording area from a non-volatile memory (such as a specific sector of Flash or EEPROM). This parameter recording area is non-volatile and retains data even after power loss. The system reads the corresponding memory address, obtains the value of the first flag status, and compares this value with a preset status code. This check process is the watershed that determines whether the system enters the firmware upgrade process or the normal boot process, ensuring that the system can flexibly switch operating modes through software configuration without external hardware intervention.

[0034] S103. If the first flag status is the update secondary bootloader status, then perform online update of the secondary bootloader and system reset; Among them, the second-level bootloader (Bootloader2nd) refers to the intermediate boot software that runs after the first-level bootloader and before the application programs; system reset refers to the operation of triggering a microcontroller reset or watchdog overflow reset through software instructions, so that the system can restart the boot process.

[0035] When the first flag state is detected as updated, the primary bootloader enters firmware receive mode. At this time, the embedded device initializes the serial communication interface (such as UART) for communication with the host computer and waits to receive data packets from the host computer for the secondary bootloader according to the agreed communication protocol. During reception, the system writes data to the storage area reserved for the secondary bootloader in non-volatile memory and performs integrity verification (such as CRC check) after writing. If the verification passes, the system clears or modifies the first flag state to avoid an infinite loop, and then executes a software reset command. After reset, the device will restart from step S101, thus making the new secondary bootloader effective.

[0036] S104. If the first flag state is the default state, then load and run the second-level bootloader; The default state refers to the value of the first flag state being a preset normal boot code (e.g., 0x00 or 0xFF), indicating that no upgrade operation is required; loading refers to the process of verifying the legality of the secondary boot program and preparing its runtime environment.

[0037] Specifically, when the first flag state is confirmed to be the default state, the first-level bootloader will relinquish its listening to the communication interface and instead execute the jump logic. During this process, the first-level bootloader may first perform a check and verification on the memory area where the second-level bootloader resides to ensure that the code is not corrupted. After confirming that everything is correct, the first-level bootloader will jump its program counter (PC) to the entry address of the second-level bootloader, completely transferring control of the system to the second-level bootloader. At this point, the lifecycle of the first-level bootloader temporarily ends until the next system reset.

[0038] S105. Check the current status of the second flag; The second flag state refers to another state variable stored in the parameter recording area of ​​the non-volatile memory, which is used to indicate the operation mode of the secondary boot program on the target firmware image; this flag state is independent of the first flag state and is specifically used to control the update logic of the application layer firmware.

[0039] Specifically, after the secondary bootloader begins running, its primary task is to determine whether the next action is to update the application firmware or to boot the application firmware. The system will again access the parameter recording area of ​​the non-volatile memory and read the value of the second flag state. This step typically occurs during the initialization phase of the secondary bootloader. By parsing this flag, the system can identify whether there is a firmware update request issued by the host computer, or a forced update request set due to previous operational anomalies.

[0040] S106. If the second flag state is the update image state, then perform online firmware image update and system reset. Among them, updating the image status means that the value of the second flag status is equal to the preset image upgrade command code; the firmware image refers to the application code containing the actual business logic, which usually exists in the form of a binary file; online update refers to the process of receiving data through the communication interface and writing it into the Flash image area.

[0041] Specifically, when in image update mode, the secondary bootloader initiates a handshake process with the host computer. The system reads the header information of the preset first and second image areas in the current non-volatile memory, identifies areas with lower versions or marked as invalid as write targets, and retains a higher version image as a backup. The device receives the new firmware data stream sent by the host computer and writes it to the selected target image area. After writing and verification are complete, the system updates the relevant version record information, restores the second flag state to the default value, and finally performs a system reset so that the newly written image can be loaded on the next boot.

[0042] More specifically, when the secondary bootloader is in "image update state," the embedded device establishes a connection with the host computer via a serial port (UART), USB, or other communication interface and receives data packets for the new firmware. To implement a "dual backup" mechanism, the system does not directly overwrite the currently running or highest-version image. Instead, it first reads the header information of the two image areas in the Flash memory and parses their respective version numbers. The system automatically identifies the older version area and locks it as the write target. Subsequently, the system erases the Flash sectors of that target area and writes the received new firmware data block by block. Throughout the writing process, the system calculates the checksum (e.g., CRC32) of the received data and compares it with the checksum at the end of the data packet. Simultaneously, after writing, it reads back the Flash data for verification to ensure data integrity. Once the verification passes, the system updates the version information marker for that area and then immediately executes a software reset command. After the device restarts, it enters the normal boot process. At this point, because the newly written image version is higher, the system will automatically attempt to load and run the new image, thus completing a seamless upgrade.

[0043] S107. If the second flag state is the default state, then determine the target image; This step, performed by the secondary bootloader at the initial startup, aims to select the best executable firmware from the existing storage partitions. First, the system reads the header data from the first and second image regions, respectively. Next, the system verifies the integrity of the firmware data in both regions: on the one hand, it calculates the checksum of the firmware data and compares it with the checksum recorded in the header information; on the other hand, it checks specific format identifiers in the header information to confirm the validity of the image.

[0044] If the verification results show that both firmware images in both regions are correctly formatted and data-free (i.e., both are valid), the system will further parse the version number fields of both, identify the firmware with the higher version through numerical comparison, and lock it as the target image for this boot, ensuring that the system runs the latest functions. If, during the verification process, the firmware in one region is found to be corrupted (e.g., checksum mismatch) or the header information is invalid (i.e., invalid), the system will automatically ignore the invalid region and directly determine the other valid firmware image as the target image. This mechanism ensures that even if the upgrade of one partition fails or the data is corrupted, the device can still boot normally through a valid backup of the other partition.

[0045] S108. Copy the target image from non-volatile memory to random access memory, and jump to the random access memory to run the target image; Non-volatile memory refers to Flash memory, which is used to save code when power is off. Random access memory (RAM) refers to SRAM or DRAM, which is used for high-speed program execution.

[0046] Because the firmware image generated by this scheme uses a memory address-dependent linking method, or to improve execution efficiency, the firmware is designed to run in RAM. The secondary bootloader, based on the source address and length of the target image in Flash determined by S107, uses DMA (Direct Memory Access) or CPU instructions to completely copy the entire image data to the preset execution address in RAM. After the copy is complete, the system updates the interrupt vector table offset (VTOR) to point to the new vector table in RAM, and sets the stack pointer (SP) and program counter (PC) to the addresses defined in the header of the target image, thereby enabling the jump from the Flash bootloader to the RAM application program.

[0047] S109. Monitor the running status of the target image in real time, and perform the corresponding success confirmation operation or abnormal recovery operation according to the running status.

[0048] This step will be described in detail in subsequent steps S201-S207, and will not be repeated here.

[0049] In some embodiments, after the secondary bootloader determines the target image based on the version number and validity, the system does not immediately jump to the next step. Instead, it first accesses the parameter record area and reads the boot failure count value corresponding to the target image. The system increments this count value and immediately writes the updated result back to the parameter record area for storage. The logic behind this operation is that the system assumes that the current boot may fail, so it pre-increments the count. If the target image subsequently boots successfully and runs stably, the application will be responsible for clearing the count value to zero (i.e., confirming stability). Conversely, if the target image has defects that cause the device to crash immediately after boot or the watchdog timer to reset, the count value will not be cleared, and this step will be executed again during the next reboot, causing the count value to continue to accumulate. When the count value reaches a preset threshold (e.g., 3 times), the system can determine that the target image is unusable, and thus automatically switch to another image area in subsequent processes to ensure the recoverability of the device.

[0050] In the above embodiment, due to the adoption of a dual-partition backup storage architecture with a first and a second image area, and the arbitration to determine the target image by combining the validity verification of header information and version number comparison during the startup phase, while using the startup failure count value in the parameter recording area to monitor the number of times the target image is attempted to run in real time, the system can not only ensure that the target image with a higher version and complete data is loaded first, but also detect the unstable state in a timely manner and trigger the protection mechanism (such as automatically switching to another image area) when the target image causes multiple consecutive startup anomalies due to its own defects. This effectively solves the problems in traditional firmware upgrade schemes where the device cannot start due to image data corruption, and the problem of the device getting stuck in an infinite loop and unable to automatically recover due to problems with the new version of firmware. Thus, it achieves high fault tolerance and self-healing capability in the device startup process, and significantly improves the reliability of firmware remote upgrade (OTA) and the operational stability of the system.

[0051] Following the above embodiments, the method provided in this embodiment will now be described in more detail. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the firmware online upgrade method in this application embodiment.

[0052] S201. Read the boot failure count value associated with the target image; The bootloader accesses the parameter record area in non-volatile memory (such as Flash), and addresses and reads the corresponding "boot failure counter" variable based on the index of the currently selected target image (first image or second image). This value reflects the number of times the target image has attempted to boot unsuccessfully in the past or recently.

[0053] S202. Determine whether the startup failure count value exceeds the preset failure threshold; The system compares the count value read in step S201 with the maximum tolerance threshold preset in the code (e.g., 3 or 5 times). The threshold is set to balance the startup fault tolerance rate and the recovery response speed: setting it too low may cause occasional interference to trigger rollback, while setting it too high will cause the device to remain in a fault state for too long.

[0054] S203. If the error exceeds the limit, then perform the exception recovery operation. When the comparison result shows a count value greater than or equal to the threshold, it means that the currently selected target image has a fatal defect or is damaged, causing the device to fall into a "boot-crash" infinite loop. At this point, the system determines that the normal boot process has failed, and the program logic jumps to the exception handling branch, that is, triggers the rollback protection mechanism. This exception recovery operation includes the contents of step S204.

[0055] S204. Determine that the target image is unavailable, switch to an image in another image area as the target image, and skip the step of incrementing the startup failure count by one; The system first marks the currently selected image as "unavailable"; then, it modifies the boot pointer to force it to point to another backup image area (for example, if the original target is partition A, it switches to partition B), and uses the old or secure version firmware in the backup partition as the new target image.

[0056] It should be noted that the system will skip the aforementioned "incrementing the startup failure count" operation at this time. This is because the current operation is an emergency rollback, and the backup image is usually a known stable version, so there is no need to preset the "trial and error count" for it. Furthermore, skipping the count can prevent the backup image from failing to start due to logical deadlock, ensuring that the device can quickly restore normal operation through the backup firmware.

[0057] S205. If the time limit is not exceeded, then perform the success confirmation operation; When the comparison result shows that the count value is less than the threshold, it indicates that although the current target image may have undergone a reboot, it has not yet reached the standard for being deemed "dead" and is still worth trying to run. The system will load the image according to the normal process and enter the "running observation period," that is, start the success confirmation logic. This success confirmation operation includes the contents of S206 and S207.

[0058] S206. After the target image runs in the random access memory for a preset duration or completes the preset key task initialization, the corresponding startup failure count value in the non-volatile memory parameter recording area is cleared to zero. The system moves the target image's code to Random Access Memory (RAM) and jumps to execute it. After the application starts, it initiates a timer or status monitoring task. If the device does not reset within a preset time (e.g., 5 minutes), or successfully executes a critical task (e.g., successfully connecting to the cloud server or successfully initializing the sensor), the system determines that the startup is "substantially successful." At this point, the application calls an interface to reset the startup failure count value corresponding to the image stored in the non-volatile memory parameter recording area to 0, thereby eliminating the previous accumulated count.

[0059] S207. Simultaneously update the health status record of the target image to indicate that the target image has been successfully and stably running.

[0060] While resetting the counter value, the system also modifies the "image status flag" (i.e., health status record) in the parameter recording area, setting it to "stable" or "valid." This step provides a reference for subsequent boots, indicating that this firmware version has passed real device testing and is a trustworthy version. The next time the device powers on, the bootloader can prioritize trusting and loading this image based on this record.

[0061] In this embodiment, a threshold judgment mechanism based on failure count is introduced in the startup process. When the count exceeds the limit, the system is forced to switch to another mirror area and skip the count accumulation. The count is cleared and the health status is updated only after the mirror does not exceed the limit and the system has run for a preset time or completed the initialization of critical tasks. Therefore, the system can not only sensitively identify the continuous "start-reset" dead loop caused by firmware defects and automatically trigger rollback protection, but also eliminate the count misjudgment caused by occasional failures or normal restarts through the stability verification closed loop during runtime. This effectively solves the problem of devices getting stuck in infinite restarts and unable to heal themselves due to incompatibility with new versions in traditional firmware upgrades, as well as the problem of the system being unable to accurately judge firmware availability due to the lack of a startup success confirmation mechanism. Thus, the system achieves automatic repair capability of startup failure and accurate health management of firmware running status in unattended scenarios.

[0062] The embedded device in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of an embedded device in the embodiments of this application.

[0063] It should be noted that, Figure 3 The structure of the embedded device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0064] like Figure 3As shown, the embedded device includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage portion 308 into Random Access Memory (RAM) 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0065] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0066] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0067] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0068] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0069] Specifically, the embedded device in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the firmware online upgrade method provided in the above embodiment.

[0070] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the embedded device described in the above embodiments; or it may exist independently and not assembled into the embedded device. The storage medium carries one or more computer programs that, when executed by a processor of the embedded device, cause the embedded device to implement the firmware online upgrade method provided in the above embodiments.

[0071] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. 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 scope of the technical solutions of the embodiments of this application.

[0072] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0073] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A firmware online upgrade method, characterized in that, Applied to embedded devices, the method includes: After the embedded device is powered on, the first-level bootloader runs; Check the current status of the first flag; If the first flag status is the update of the secondary bootloader status, then perform online update of the secondary bootloader and system reset; If the first flag state is the default state, then load and run the secondary bootloader; Check the current status of the second flag; If the second flag state is the update image state, then perform online firmware image update and system reset; If the second flag state is the default state, then the target image is determined; The target image is copied from non-volatile memory to random access memory, and the process jumps to the random access memory to run the target image; The system monitors the running status of the target image in real time and performs corresponding success confirmation or anomaly recovery operations based on the running status.

2. The method according to claim 1, characterized in that, The non-volatile memory has a first image area and a second image area pre-defined. The steps of performing online firmware image updates and system resets specifically include: Receive new firmware image data sent by a host computer, wherein the host computer includes at least a local computer, a mobile terminal, and a cloud-embedded device; Identify the lower version of the two current image regions as the target image region for writing; Write the new firmware image data into the target image region; After the write operation is completed and the verification is successful, a system reset operation is performed.

3. The method according to claim 1, characterized in that, The step of determining the target image if the second flag state is the default state specifically includes: Read the header information of the firmware image stored in the first and second image areas; Based on the header information, verify the checksum and validity of the firmware image data in the two regions; If all firmware image data are valid, obtain the corresponding version number and select the firmware image data with the higher version number as the target image; If only one region's target firmware image data is valid, then the target firmware image data is determined to be the target image.

4. The method according to claim 1, characterized in that, Also includes: When the target image is selected as the current boot image, the boot failure count associated with the target image is incremented by one, and the updated count is written to the parameter record area of ​​the non-volatile memory. The boot failure count is used to indicate the number of times the target image attempts to boot before its operational stability is confirmed.

5. The method according to claim 1 or 4, characterized in that, The steps of real-time monitoring of the target image's running status and performing corresponding success confirmation or anomaly recovery operations based on the running status specifically include: Read the boot failure count value associated with the target image; Determine whether the startup failure count value exceeds a preset failure threshold; If the error exceeds the limit, the exception recovery operation is performed, which includes: If the target image is determined to be unavailable, switch to an image in another image region as the target image, and skip the step of incrementing the startup failure count. If the time limit is not exceeded, then perform the success confirmation operation.

6. The method according to claim 5, characterized in that, The steps for performing the successful confirmation operation specifically include: After the target image runs in the random access memory for a preset time or completes the preset key task initialization, the corresponding startup failure count value in the non-volatile memory parameter recording area is cleared to zero. At the same time, the health status record of the target image is updated to indicate that the target image has been successfully and stably running.

7. The method according to claim 1, characterized in that, The first flag state and the second flag state are stored in the non-volatile memory, and the method further includes: Receive setting commands sent by the host computer via serial port; The setting instruction is parsed to modify the first flag state in the non-volatile memory to update the secondary bootloader state, or to modify the second flag state to update the image state.

8. An embedded device, characterized in that, The embedded device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the embedded device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an embedded device, the embedded device performs the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is run on an embedded device, the embedded device performs the method as described in any one of claims 1-7.

Images