Memory and storage exhausted device remote firmware upgrade method, device and medium

Abstract

This invention discloses a remote firmware upgrade method, device, and medium for devices with depleted memory and storage, relating to the field of firmware upgrades. The method includes: receiving a refactoring instruction and a dedicated upgrade loader, terminating the execution of at least one application to free up runtime memory space; running the dedicated upgrade loader to enter a temporary upgrade mode; requesting the Nth data segment of peripheral firmware data from a remote server; receiving the segment and verifying it in the freed runtime memory; if the verification is successful, forwarding it to the peripheral and starting a timer; waiting for the peripheral to return a write success confirmation message; if confirmation is received before the timer expires, requesting the next segment; if no confirmation is received before the timer expires, terminating the loop and reporting a failure; after all segments are upgraded, receiving and running the complete host software package, reloading the terminated application, and exiting the temporary upgrade mode. This invention can safely and reliably complete remote peripheral firmware upgrades under extreme conditions of depleted main controller resources and fragile peripheral firmware storage chips.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology, and in particular to a remote firmware upgrade method, device and medium for devices with depleted memory and storage. Background Technology

[0002] In the field of embedded systems and IoT device maintenance, firmware upgrades for peripheral modules connected to the main controller are a common requirement. Currently, firmware upgrades for such peripherals primarily employ two methods.

[0003] Method one is a host-based remote full upgrade, in which the device's main controller downloads the complete firmware upgrade package from the server via a wireless network, temporarily stores it in its own file system or reserved storage area, completes integrity verification, and then sequentially writes the data to the peripheral device's storage chip via the communication interface. This method requires the main controller to have sufficient free storage space to cache the upgrade package and a certain amount of running memory to execute the upgrade logic and verification calculations.

[0004] Method 2 is the local flashing method. In cases where the host device has insufficient resources or the software does not support remote upgrades, a technician removes the device and uses a dedicated programmer or adapter to directly flash the firmware onto the peripheral's storage chip via a physical cable. This method does not rely on host resources, but it must be performed on-site.

[0005] However, the aforementioned existing technologies all suffer from insurmountable drawbacks when faced with a scenario known as resource-depleted devices. These devices are typically older IoT terminals deployed for many years, whose main controllers have exhausted their RAM and program storage space after fulfilling their original functionalities, leaving no spare resources for executing additional complex tasks. Under these conditions, traditional remote full upgrade methods are completely unfeasible because the host cannot cache the complete firmware upgrade package or run complex upgrade management programs. When the remote upgrade path is blocked, the only available traditional method degenerates into local flashing. However, local flashing requires manual on-site disassembly and operation, which is not only cumbersome and inefficient but also demands technical expertise from operators. The high manpower, logistics, and time costs make large-scale software defect repair on a massive number of deployed devices impractical. Especially when the peripheral is a single programmable read-only memory (ROM), its firmware storage chip is a single, indivisible memory. The upgrade process requires continuous data writing; any interruption or error can easily lead to permanent module failure, further exacerbating the design complexity of remote upgrade solutions. Summary of the Invention

[0006] This invention provides a method, device, and medium for remote firmware upgrade of devices with depleted memory and storage. The technical problem to be solved by this invention is to provide an effective solution for safely and reliably completing peripheral firmware upgrades remotely under extreme conditions where the main controller resources are exhausted and the peripheral firmware storage chip is fragile.

[0007] In a first aspect, embodiments of the present invention provide a remote firmware upgrade method for a device suffering from memory and storage exhaustion, applied to an Internet of Things (IoT) device, the IoT device including a main controller and peripherals connected to the main controller, the method comprising: The main controller receives reconstruction instructions and a dedicated upgrade loader from a remote server; In response to the refactoring instruction, the main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to free up running memory space; The main controller runs the dedicated upgrade loader and enters a temporary upgrade mode; In the temporary upgrade mode, the main controller performs the following loop operation until the firmware upgrade of the peripheral device is completed: the main controller sends a request for the Nth data segment of the firmware data of the peripheral device to the remote server, where N is initially set to 1; the main controller receives the Nth data segment returned by the remote server; the main controller performs an integrity check on the received Nth data segment in the freed-up running memory; when the check passes, the main controller forwards the Nth data segment to the peripheral device and starts a timer; the main controller waits to receive a write success confirmation message for the Nth data segment returned by the peripheral device; when the write success confirmation message is received before the timer expires, the main controller stops the timer, assigns N to N+1, and returns to the step of sending the request for the Nth data segment of the firmware data of the peripheral device to the remote server; when the write success confirmation message is not received before the timer expires, the main controller terminates the loop operation and reports an upgrade failure message to the remote server. When all data fragments have been upgraded, the main controller receives the complete host software package sent by the remote server; The main controller runs the complete host software package and reloads the at least one application that was terminated, exiting the temporary upgrade mode.

[0008] Optionally, the main controller receives a refactoring command and a dedicated upgrade loader issued by a remote server, including: The main controller receives the reconfiguration command issued by the remote server via a wireless network; In response to the refactoring instruction, the main controller sends a loader request to the remote server; The main controller receives the dedicated upgrade loader returned by the remote server and stores the dedicated upgrade loader in a predetermined secure area of ​​the main controller's program storage space.

[0009] Optionally, the main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to free up running memory space, including: The main controller identifies all application processes and system service processes currently residing in the running memory; The main controller selects at least one non-core process from all application processes and system service processes according to a preset priority strategy. The main controller sends a termination command to the at least one non-core process, causing the at least one non-core process to stop running; The main controller marks the running memory space occupied by the at least one non-core process as available for reallocation in order to release the running memory space.

[0010] Optionally, the main controller performs an integrity check on the received Nth data segment in the released running memory, including: The main controller extracts the verification value from the received Nth data segment; The main controller performs the same verification algorithm as the verification value generation algorithm on the data load portion of the Nth data segment to generate a real-time verification result. The main controller compares the real-time verification result with the extracted verification value. If the real-time verification result is consistent with the verification value, the verification is deemed to have passed. If the real-time verification result is inconsistent with the verification value, the verification is deemed to have failed.

[0011] Optionally, the main controller terminates the loop operation and reports an upgrade failure message to the remote server, including: The main controller stops sending requests for subsequent data segments to the remote server; The main controller generates an error report containing the failure reason code and the number of upgraded fragments; The main controller sends the error report to the remote server via a wireless network.

[0012] Optionally, the firmware storage chip of the peripheral is a single programmable read-only memory, wherein the single programmable read-only memory is required to complete the continuous writing of complete firmware data within a single programming cycle.

[0013] Optionally, the dedicated upgrade loader includes at least a wireless communication protocol stack module, a data verification program, and a device driver for the peripheral device. The code size of the dedicated upgrade loader is smaller than the code size of the complete host software currently running on the main controller.

[0014] Optionally, after the main controller runs the complete host software package and reloads the at least one application that was terminated, and exits the temporary upgrade mode, it further includes: The main controller sends an upgrade completion confirmation message to the remote server; The main controller executes a system restart command, causing the IoT device to restart with the complete host software package loaded.

[0015] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0016] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0017] This invention provides a remote firmware upgrade method, device, and medium for devices with depleted memory and storage. By terminating non-core applications on the main controller to free up runtime memory, this invention creates the necessary runtime space for subsequent upgrade operations, enabling remote upgrades of devices that were previously unable to perform any additional tasks due to resource exhaustion. Furthermore, by employing segmented transmission and real-time verification, firmware data fragments are processed one by one within the limited freed memory, avoiding the large storage space required for local caching of the complete upgrade package and solving the fundamental problem of the main controller's inability to cache data due to storage space exhaustion. Furthermore, by introducing a dual guarantee mechanism of timer monitoring and peripheral write confirmation, it ensures that the entire process of each data fragment from reception and verification to writing to the peripheral is completed within a controllable time. Any abnormality in any stage triggers process termination and reporting, fundamentally preventing data flow interruptions due to network fluctuations or device malfunctions, and preventing permanent failure of single-block programmable read-only memory type peripherals due to incomplete writes during the upgrade process. Finally, by restoring the complete host software package and reloading the application, a complete closed-loop migration of the system state is achieved, providing a secure, reliable, and scalable remote firmware upgrade solution for a large number of deployed legacy IoT devices. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a remote firmware upgrade method for a memory and storage depleted device, provided as an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0022] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0023] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

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

[0025] Please see Figure 1 This invention provides a remote firmware upgrade method for devices with depleted memory and storage, applied to Internet of Things (IoT) devices. The IoT device includes a main controller and peripherals connected to the main controller. The method includes the following steps: S1, the main controller receives a reconstruction instruction and a dedicated upgrade loader issued by a remote server.

[0026] In practice, the main controller receives a reconfiguration command and a dedicated upgrade loader from a remote server. Specifically, after determining that a firmware upgrade is needed for the peripherals of the IoT device, the remote server sends a reconfiguration command to the main controller of the IoT device via a wireless network. This reconfiguration command triggers the main controller to enter an upgrade-ready state.

[0027] Furthermore, the remote server distributes a dedicated upgrade loader to the main controller. The dedicated upgrade loader is a streamlined executable program, much smaller than the full host software currently running on the main controller, containing only the functional modules necessary to support subsequent upgrade operations.

[0028] In some preferred embodiments, the main controller receives a refactoring instruction and a dedicated upgrade loader from a remote server, including: the main controller receiving the refactoring instruction from the remote server via a wireless network; in response to the refactoring instruction, the main controller sending a loader request to the remote server; the main controller receiving the dedicated upgrade loader returned by the remote server and storing the dedicated upgrade loader in a predetermined secure area of ​​the main controller's program storage space.

[0029] In practice, the main controller receives reconfiguration commands from the remote server via a wireless network. Specifically, the main controller of the IoT device maintains a connection to the wireless network, listening in real time or periodically polling for control commands from the remote server. When the remote server decides to upgrade the peripheral firmware of a specific device, it sends a reconfiguration command to the device's main controller. Upon receiving the command, the main controller parses it and identifies it as a command requesting entry into an upgrade preparation state.

[0030] Furthermore, in response to the refactoring command, the main controller sends a loader request to the remote server. Specifically, after parsing and confirming the validity of the refactoring command, the main controller does not directly execute the subsequent memory release operation. Instead, it first interacts with the server to obtain the dedicated upgrade loader necessary for the upgrade. The main controller generates a loader request message, which at least contains the device's identification information to identify itself to the server and request the issuance of the corresponding dedicated upgrade loader. Further, the main controller sends this loader request to the remote server via a wireless network.

[0031] Furthermore, the main controller receives a dedicated upgrade loader returned by the remote server and stores it in a predetermined secure area of ​​the main controller's program storage space. Specifically, after verifying the device's identity and the legitimacy of the request, the remote server sends a dedicated upgrade loader matching the device model and hardware configuration to the main controller via a wireless network. The main controller then receives all the data from this dedicated upgrade loader and writes it to a pre-defined and reserved secure area in the main controller's program storage space. This secure area is specifically designed to store critical startup code or upgrade programs; even during subsequent memory cleanup and feature unloading processes, the contents of this area will not be accidentally erased or overwritten, ensuring that the dedicated upgrade loader can be reliably loaded and executed when needed.

[0032] This embodiment ensures a reliable software foundation for subsequent dynamic reconstruction and upgrade operations by proactively requesting and securely storing a dedicated upgrade loader upon receiving a reconstruction instruction. This avoids the risk of the upgrade process failing to start due to a missing or corrupted loader. Furthermore, storing the dedicated upgrade loader in a predetermined secure area of ​​the program storage space utilizes a protected reserved portion of the program storage space, guaranteeing that the loader's storage integrity will not be compromised even during extreme memory release operations. This provides a reliable software foundation for the smooth startup and continuous operation of the entire remote upgrade process.

[0033] S2, in response to the refactoring instruction, the main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to free up running memory space.

[0034] In practice, in response to a refactoring command, the main controller terminates the execution of at least one currently running application and removes it from runtime memory to free up runtime memory space. Specifically, after receiving a refactoring command, the main controller identifies the various applications currently residing and executing in runtime memory. To free up sufficient memory resources for subsequent upgrade operations, the main controller proactively terminates the execution of at least one of these applications and releases the memory space they occupy. These terminated applications are typically those unrelated to the core functionality of the firmware upgrade; by terminating these programs, the main controller gains access to a usable runtime memory area.

[0035] In some preferred embodiments, the main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to release the running memory space, including: the main controller identifying all application processes and system service processes currently residing in the running memory; the main controller selecting at least one non-core process from all application processes and system service processes according to a preset priority policy; the main controller sending a termination instruction to the at least one non-core process to stop the at least one non-core process from running; and the main controller marking the running memory space occupied by the at least one non-core process as reallocatable to release the running memory space.

[0036] In practice, the main controller identifies all application processes and system service processes currently residing in the running memory. Specifically, the main controller uses the process management functions of its operating system or underlying firmware to scan and obtain a list of all processes currently active in the running memory. These processes include both user-level application processes and system service processes that support the basic operation of the system.

[0037] Furthermore, the main controller, based on a preset priority strategy, selects at least one non-core process from all application and system service processes. Specifically, the main controller internally stores a priority strategy that defines the termination order of various processes when resources are scarce. For example, applications that directly interact with the user but are not currently essential are defined as low priority, while system services that ensure basic communication and hardware drivers are defined as high priority. Based on this strategy, the main controller selects non-core processes marked as temporarily terminating from the process list as targets for memory release.

[0038] Furthermore, the main controller sends a termination instruction to at least one non-core process, causing it to stop running. Specifically, the main controller sends a termination signal or instruction to each selected non-core process. The process receiving the instruction executes its own cleanup and exit procedures, stopping running in an orderly manner, thereby releasing the CPU time slice and memory resources it occupied back to the system.

[0039] Furthermore, the main controller marks the runtime memory space occupied by at least one non-core process as available for reallocation, thereby freeing up runtime memory space. Specifically, after a process terminates, the main controller's memory management unit marks the memory address space previously allocated to those processes as free or available for reallocation. This means that these memory regions can be re-allocated and used by subsequently running programs, especially the upcoming dedicated upgrade loader. In this way, the main controller successfully transforms the memory space occupied by non-core processes into a free memory pool available for upgrade operations.

[0040] This embodiment ensures, through refined process identification, filtering, and termination operations, that core processes required to maintain basic communication and hardware functions are preserved to the maximum extent during memory release, while resources occupied by non-core processes are effectively reclaimed, creating conditions for subsequent upgrades.

[0041] This embodiment implements an intelligent resource reclamation mechanism by identifying all running processes and terminating non-core processes based on a preset priority strategy. This mechanism ensures that the main controller does not simply terminate processes randomly when releasing memory, but selectively shuts down applications or services that are unrelated to the upgrade task and have low priority, thereby maximizing the continuous operation of the device's basic communication capabilities and core functions such as hardware drivers. Furthermore, in this way, although the device's functionality is significantly simplified after entering temporary upgrade mode, it can still maintain a stable connection with the remote server and basic control capabilities over peripherals, providing the necessary foundational support for the smooth execution of subsequent segmented upgrade operations. Furthermore, marking the released memory space as reallocatable clarifies the purpose of these resources, allowing the dedicated upgrade loader to seamlessly take over and use this memory to process firmware data fragments, achieving a smooth transition of resources from old tasks to new tasks.

[0042] S3, the main controller runs the dedicated upgrade loader and enters the temporary upgrade mode.

[0043] In practice, the main controller runs a dedicated upgrade loader, entering a temporary upgrade mode. Specifically, after releasing memory, the main controller loads and executes the previously received and stored dedicated upgrade loader. At this point, the IoT device's main controller no longer runs the original full host software, but instead runs this streamlined dedicated upgrade loader. The entire device thus enters a temporary upgrade mode with limited functionality but available resources. In this mode, all available resources of the device, especially the released RAM, are dedicated to performing peripheral firmware upgrade tasks.

[0044] S4, in the temporary upgrade mode, the main controller performs the following loop operation until the firmware upgrade of the peripheral device is completed: the main controller sends a request for the Nth data segment of the firmware data of the peripheral device to the remote server, where the initial value of N is 1; the main controller receives the Nth data segment returned by the remote server; the main controller performs an integrity check on the received Nth data segment in the released running memory; when the check passes, the main controller forwards the Nth data segment to the peripheral device and starts a timer; the main controller waits to receive a write success confirmation message for the Nth data segment returned by the peripheral device; when the write success confirmation message is received before the timer expires, the main controller stops the timer, assigns N to N+1, and returns to the step of sending the request for the Nth data segment of the firmware data of the peripheral device to the remote server; when the write success confirmation message is not received before the timer expires, the main controller terminates the loop operation and reports an upgrade failure message to the remote server.

[0045] In practice, under temporary upgrade mode, the main controller performs the following cyclical operations until the peripheral firmware upgrade is complete. This series of cyclical operations constitutes the core process of the segmented upgrade.

[0046] The main controller sends a request to the remote server for the Nth data segment of the firmware data for the peripheral device, where N is initially set to 1. Specifically, the running dedicated upgrade loader communicates with the remote server via a wireless network, proactively initiating a data request. This request explicitly points to the data segment of the firmware data that the target peripheral device needs to update. The firmware data is pre-segmented into multiple consecutive data segments on the server side to accommodate transmission and processing in memory-constrained environments.

[0047] Furthermore, the main controller receives the Nth data segment returned by the remote server. Specifically, in response to the main controller's request, the remote server sends the corresponding Nth data segment to the IoT device via a wireless network. The main controller receives this data segment through its wireless communication module and temporarily stores it in the previously freed runtime memory.

[0048] Furthermore, the main controller performs an integrity check on the received Nth data segment in the freed-up RAM. Specifically, the dedicated upgrade loader invokes its built-in data verification function to verify the Nth data segment temporarily stored in RAM. The purpose of the verification is to confirm whether the data segment has been damaged or lost during wireless transmission, ensuring that the data written to the peripheral is correct. Common verification algorithms include cyclic redundancy check (CRC), which is accomplished by calculating the checksum of the data segment and comparing it with the original checksum sent along with the data.

[0049] Furthermore, upon successful verification, the main controller forwards the Nth data segment to the peripheral and starts a timer. Specifically, if the integrity verification result indicates that the data segment is correct, the dedicated upgrade loader sends the data segment to the peripheral through the communication interface between the main controller and the peripheral. After receiving the data segment, the peripheral writes it into its own firmware storage chip. Simultaneously with data forwarding, the main controller starts a timer. This timer monitors the entire process from the start of data forwarding to receiving the peripheral's confirmation message, preventing process delays.

[0050] Furthermore, the main controller waits to receive a successful write confirmation message for the Nth data segment from the peripheral device. Specifically, after successfully writing the data segment to its memory chip, the peripheral device returns a confirmation message to the main controller via the communication interface. The main controller continuously listens to this interface, waiting to receive this confirmation message.

[0051] Furthermore, when a successful write confirmation message is received before the timer expires, the main controller stops the timer, assigns N to N+1, and returns to the step of requesting the Nth data segment of firmware data for the peripheral to be sent to the remote server. Specifically, if the main controller successfully receives the confirmation message from the peripheral within the time range set by the timer, it indicates that the current data segment has been written safely and reliably. At this time, the main controller stops the timer, increments the segment number N by 1, and then restarts the loop to request the next data segment from the server for processing.

[0052] Furthermore, if no successful write confirmation message is received before the timer expires, the main controller terminates the loop operation and reports an upgrade failure message to the remote server. Specifically, if the timer expires before the confirmation message arrives, it indicates a problem in the data forwarding, peripheral device writing, or confirmation return stage, causing the process to be unable to continue. Furthermore, to prevent peripheral devices from being damaged due to incomplete data writing, the main controller immediately terminates the entire loop upgrade process and no longer requests subsequent data segments. Simultaneously, the main controller generates an upgrade failure message and reports it to the remote server via the wireless network, notifying the server that the upgrade attempt has failed.

[0053] In some preferred embodiments, the main controller performs integrity verification on the received Nth data segment in the released running memory, including: the main controller extracts a verification value from the received Nth data segment; the main controller executes the same verification algorithm as the verification value generation algorithm on the data load portion of the Nth data segment to generate a real-time verification result; the main controller compares the real-time verification result with the extracted verification value, and if the real-time verification result is consistent with the verification value, the verification is deemed successful; if the real-time verification result is inconsistent with the verification value, the verification is deemed unsuccessful.

[0054] In practice, the main controller extracts the checksum from the received Nth data segment. Specifically, after receiving the Nth data segment, the main controller parses the structure of the data segment according to a predefined communication protocol. Typically, a data segment contains a data payload and additional checksum information. Further, the main controller extracts the additional checksum information, which is the checksum calculated by the sender based on the data payload content, such as a cyclic redundancy check (CRC) value or a hash value.

[0055] Furthermore, the main controller executes the same verification algorithm as the checksum generation algorithm on the data payload portion of the Nth data segment, generating a real-time verification result. Specifically, the main controller independently runs a verification algorithm identical to that used by the sending end for the data payload portion separated from the data segment. By calculating all bytes of the data payload portion, the main controller obtains a locally generated real-time verification result.

[0056] Furthermore, the main controller compares the real-time verification result with the extracted verification value. If the real-time verification result matches the verification value, the verification is deemed successful; otherwise, the verification is deemed unsuccessful. Specifically, the main controller compares the locally calculated real-time verification result with the original verification value extracted from the data segment bit by bit. If they are completely identical, it proves that the data payload has not been altered or damaged during transmission from the server to the main controller, and the main controller determines that the verification has passed. Further, if they are inconsistent, it indicates that the data payload may have been interfered with or erroneous during transmission, and the main controller determines that the verification has failed and can proceed according to subsequent procedures, such as requesting a retransmission of the data segment.

[0057] This embodiment ensures the correctness of each data segment to be written to the peripheral device by performing real-time verification of received data in memory, thus providing a prerequisite for subsequent secure writing.

[0058] This embodiment precisely verifies the integrity and correctness of each data segment transmitted from the remote server to the local device by performing real-time verification on the received data segments in the freed-up running memory. Furthermore, by extracting the original checksum from the data segments and applying the same algorithm to the data payload to generate real-time verification results, the main controller can independently and accurately determine whether the data has been interfered with or damaged during wireless transmission. Moreover, this in-memory verification mechanism ensures that only verified, correct data is forwarded to the peripheral for writing, fundamentally eliminating the risk of peripheral malfunction or firmware corruption due to the use of incorrect data. Furthermore, this step is particularly critical for single-block programmable read-only memory requiring continuous writing, as it guarantees the reliability of every data segment written to the peripheral.

[0059] In some preferred embodiments, the main controller terminates the loop operation and reports an upgrade failure message to the remote server, including: the main controller stops sending requests for subsequent data segments to the remote server; the main controller generates an error report containing a failure reason code and the number of upgraded segments; and the main controller sends the error report to the remote server via a wireless network.

[0060] In practice, the main controller stops sending requests for subsequent data segments to the remote server. Specifically, when the timer expires and the main controller has not yet received a write success confirmation message from the peripheral device, the main controller immediately interrupts the currently executing loop process. This means that the main controller no longer generates and sends request messages for the N+1th or any subsequent data segment, thus preventing the possibility of continuing to request new data from the server in abnormal conditions.

[0061] Furthermore, the main controller generates an error report containing the failure reason code and the number of upgraded fragments. Specifically, after terminating the loop, the main controller collects relevant information about this upgrade failure and organizes it into a structured error report. This report contains at least two key pieces of information: first, the failure reason code, which identifies the specific reason that caused the upgrade to stop, such as a write confirmation timeout; and second, the number of upgraded fragments, which records the number of data fragments that were successfully written before the failure, so that the server can understand the progress and breakpoint of the upgrade.

[0062] Furthermore, the main controller sends the error report to the remote server via the wireless network. Specifically, the main controller encapsulates the generated error report into a data packet suitable for wireless network transmission and sends it to the remote server through its wireless communication module. After receiving the error report, the server can record the device status, analyze the cause of the failure, and determine the subsequent retry strategy or manual intervention plan as needed.

[0063] This embodiment provides the remote server with accurate information for diagnosing faults by executing an orderly termination and reporting process when an anomaly occurs, thus preventing the device from falling into an unknown stagnation in an abnormal state.

[0064] This embodiment constructs a complete closed loop for exception handling by executing an ordered termination and reporting process after the timer expires. The main controller first stops requesting subsequent data segments, preventing the transmission of new data without confirmation of successful writing of the previous data segment. This immediate interruption of control flow avoids more serious errors caused by process disruption. Furthermore, an error report containing a failure reason code and the number of upgraded segments is generated and reported, providing the remote server with accurate fault diagnosis information. The failure reason code allows the server to distinguish whether the failure is due to network problems, unresponsive peripherals, or other reasons; the number of upgraded segments informs the server of the upgrade progress, facilitating subsequent strategies such as resuming interrupted transmissions or restarting.

[0065] S5, when all data fragments have been upgraded, the main controller receives the complete host software package sent by the remote server.

[0066] In practice, once all data segments have been upgraded, the main controller receives the complete host software package from the remote server. Specifically, after the aforementioned loop successfully processes the last data segment—that is, after all firmware data for the peripherals has been successfully written in segments—communication between the main controller and the remote server enters the next stage. The remote server sends a complete host software package to the main controller. This package is identical to the original host software running on the IoT device and contains all the functions required for the device to function properly.

[0067] S6, the main controller runs the complete host software package and reloads the at least one application that was terminated, exiting the temporary upgrade mode.

[0068] In practice, the main controller runs the complete host software package and reloads at least one application that was terminated, exiting the temporary upgrade mode. Specifically, after receiving the complete host software package, the main controller loads and runs the package, restoring the device's full functionality. Furthermore, the main controller reloads and starts those applications that were previously terminated to free up memory, restoring the device to its pre-upgrade state. At this point, the IoT device successfully exits the temporary upgrade mode, resumes operation with a complete software configuration, and its peripheral firmware is updated to the latest version.

[0069] This embodiment, through the steps described above, creatively achieves remote firmware upgrades for peripherals on a main controller with completely exhausted memory and storage resources. Its core lies in dynamically reconstructing a temporary dedicated operating environment and employing a segmented transmission mechanism with acknowledgment and timeout protection, ensuring the feasibility and security of the upgrade process under the dual challenges of limited resources and network instability.

[0070] This embodiment utilizes a dynamic reconfiguration mechanism to terminate non-core applications on a resource-depleted main controller, freeing up runtime memory and creating the necessary runtime space for subsequent upgrade operations. This overcomes the physical limitation that the main controller cannot execute any additional tasks due to memory exhaustion, enabling existing devices that previously lacked remote upgrade capabilities to gain remote maintenance capabilities. Furthermore, this embodiment employs segmented transmission and real-time verification, processing firmware data fragments one by one within the released limited memory. This avoids the large storage space required for locally caching the complete upgrade package, solving the fundamental problem of the main controller's inability to cache data due to running out of program storage space. Moreover, by introducing a dual guarantee mechanism of timer monitoring and peripheral write confirmation, this embodiment ensures that the entire process of each data fragment, from reception and verification to writing to the peripheral, is completed within a controllable time. Any abnormality in any stage triggers process termination and reporting. This timeout circuit breaker mechanism fundamentally prevents data flow interruptions caused by network fluctuations or device malfunctions, avoiding permanent failure of single-block programmable read-only memory peripherals due to incomplete writing during the upgrade process. Furthermore, by restoring the complete host software package and reloading the application, this embodiment achieves a complete closed-loop migration of the system state, ensuring that the device can quickly restore all functions after the upgrade, thereby providing a secure, reliable, and scalable remote firmware upgrade solution for a large number of deployed legacy IoT devices.

[0071] In some preferred embodiments, the firmware storage chip of the peripheral is a single programmable read-only memory, wherein the single programmable read-only memory is required to complete the continuous writing of complete firmware data within a single programming cycle.

[0072] In specific implementation, the firmware storage chip of the peripheral is a single programmable read-only memory (PROM). This PROM requires the continuous writing of complete firmware data within a single programming cycle. This embodiment further clarifies the specific and vulnerable peripheral type targeted by this method. A characteristic of PROMs is that their programming process has atomicity requirements; once writing begins, data must be continuously provided until the entire firmware image is completely written. If the data flow is interrupted during writing, or if the written data is discontinuous or incomplete, the memory chip may enter an unpredictable state, leading to firmware corruption. Consequently, the peripheral cannot boot or function properly, resulting in the so-called "bricked" state. The technical solution of this embodiment is specifically designed for peripherals with extremely high requirements for write continuity. Through segmented transmission, instant forwarding, and write confirmation mechanisms, it simulates the conditions for continuous data writing in a remote environment, thereby overcoming its inherent vulnerability.

[0073] In some preferred embodiments, the dedicated upgrade loader includes at least a wireless communication protocol stack module, a data verification program, and a device driver for the peripheral device. The code size of the dedicated upgrade loader is smaller than the code size of the complete host software currently running on the main controller.

[0074] In practice, the dedicated upgrade loader includes at least a wireless communication protocol stack module, a data verification program, and device drivers for peripherals. The code size of the dedicated upgrade loader is smaller than the code size of the complete host software currently running on the main controller. This embodiment specifically describes the composition and characteristics of the dedicated upgrade loader. The wireless communication protocol stack module enables the loader to communicate independently with a remote server, sending requests and receiving data. Furthermore, the data verification program provides the ability to verify the integrity of data fragments in memory. Furthermore, the device drivers for peripherals enable the main controller to interact with the target peripherals through a communication interface, sending firmware data and receiving confirmation messages returned by the peripherals. More importantly, the code size of this loader is deliberately designed to be much smaller than the complete host software, allowing it to run smoothly in the limited memory space freed up by the dynamic refactoring of the main controller without exhausting system resources again. Its streamlined design ensures that only the absolutely core functions necessary for the upgrade are retained, removing all complex applications and services unrelated to the upgrade.

[0075] In some preferred embodiments, after the main controller runs the complete host software package and reloads the at least one application that was terminated, and exits the temporary upgrade mode, the process further includes: the main controller sending an upgrade completion confirmation message to the remote server; and the main controller executing a system restart command to restart the IoT device with the complete host software package loaded.

[0076] In practice, the main controller sends an upgrade completion confirmation message to the remote server. Specifically, after successfully running the complete host software package and reloading all terminated applications, the main controller confirms that it has fully recovered to a normal operating state. Furthermore, to notify the remote server of this result, the main controller generates an upgrade completion confirmation message and sends it to the server via the wireless network. This message informs the server that the peripheral firmware upgrade task has been successfully completed and the device has returned to normal functionality.

[0077] Furthermore, the main controller executes a system reboot command, causing the IoT device to restart with the complete host software package loaded. Specifically, the main controller executes a system reboot command after or simultaneously with sending an acknowledgment message. This command triggers a complete reboot process for the IoT device. During the reboot, the main controller reinitializes the hardware and loads the restored complete host software package and all relevant applications. Furthermore, after the reboot is complete, the IoT device restarts in a clean and stable state, with the main controller running complete, fully functional software and peripherals running updated firmware. Moreover, the reboot thoroughly clears any temporary states that may have been left over from the temporary upgrade mode, ensuring long-term operational stability.

[0078] This embodiment completes the entire remote upgrade process by confirming and restarting after the upgrade is finished, ensuring the final consistency and reliability of the device status.

[0079] This embodiment adds the steps of sending an upgrade completion confirmation message and performing a system restart after exiting the temporary upgrade mode, providing a formal and verifiable closing step for the entire remote upgrade process. Sending the upgrade completion confirmation message allows the remote server to confirm that the device has successfully restored full functionality, thereby updating the device status record on the server side, closing the upgrade task, and providing accurate data for subsequent maintenance decisions. Furthermore, executing the system restart command ensures that the IoT device starts operating in a completely new and clean system state. The restart operation clears all temporary data, caches, and intermediate states that may have been generated during the temporary upgrade mode, avoiding any potential impact of these residual information on the long-term stable operation of the device. Furthermore, the fully loaded host software package and new peripheral firmware loaded after the restart can work together under the initial conditions of a system cold start, further verifying the upgrade's compatibility and stability.

[0080] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0081] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0082] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to perform a remote firmware upgrade method for a memory and storage depleted device.

[0083] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0084] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can perform a remote firmware upgrade method for memory and storage depletion devices.

[0085] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0086] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of a remote firmware upgrade method for a memory and storage depleted device provided in any of the above method embodiments.

[0087] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0088] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0089] Therefore, the present invention also provides a storage medium. This storage medium may be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of a remote firmware upgrade method for a memory and storage depletion device provided in any of the above method embodiments.

[0090] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0091] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0092] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0093] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0094] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

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

[0096] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0097] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A remote firmware upgrade method for a device with depleted memory and storage, characterized in that, Applied to Internet of Things (IoT) devices, the IoT devices including a main controller and peripherals connected to the main controller, the method includes: The main controller receives reconstruction instructions and a dedicated upgrade loader from a remote server; In response to the refactoring instruction, the main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to free up running memory space; The main controller runs the dedicated upgrade loader and enters a temporary upgrade mode; In the temporary upgrade mode, the main controller performs the following loop operation until the firmware upgrade of the peripheral device is completed: the main controller sends a request for the Nth data segment of the firmware data of the peripheral device to the remote server, where N is initially set to 1; the main controller receives the Nth data segment returned by the remote server; the main controller performs an integrity check on the received Nth data segment in the freed-up running memory; when the check passes, the main controller forwards the Nth data segment to the peripheral device and starts a timer; the main controller waits to receive a write success confirmation message for the Nth data segment returned by the peripheral device; when the write success confirmation message is received before the timer expires, the main controller stops the timer, assigns N to N+1, and returns to the step of sending the request for the Nth data segment of the firmware data of the peripheral device to the remote server; when the write success confirmation message is not received before the timer expires, the main controller terminates the loop operation and reports an upgrade failure message to the remote server. When all data fragments have been upgraded, the main controller receives the complete host software package sent by the remote server; The main controller runs the complete host software package and reloads the at least one application that was terminated, exiting the temporary upgrade mode.

2. The method according to claim 1, characterized in that, The main controller receives a reconfiguration command and a dedicated upgrade loader from a remote server, including: The main controller receives the reconfiguration command issued by the remote server via a wireless network; In response to the refactoring instruction, the main controller sends a loader request to the remote server; The main controller receives the dedicated upgrade loader returned by the remote server and stores the dedicated upgrade loader in a predetermined secure area of ​​the main controller's program storage space.

3. The method according to claim 1, characterized in that, The main controller terminates the execution of at least one currently running application and removes the at least one application from the running memory to free up running memory space, including: The main controller identifies all application processes and system service processes currently residing in the running memory; The main controller selects at least one non-core process from all application processes and system service processes according to a preset priority strategy. The main controller sends a termination command to the at least one non-core process, causing the at least one non-core process to stop running; The main controller marks the running memory space occupied by the at least one non-core process as available for reallocation in order to release the running memory space.

4. The method according to claim 1, characterized in that, The main controller performs an integrity check on the received Nth data segment in the freed-up running memory, including: The main controller extracts the verification value from the received Nth data segment; The main controller performs the same verification algorithm as the verification value generation algorithm on the data load portion of the Nth data segment to generate a real-time verification result. The main controller compares the real-time verification result with the extracted verification value. If the real-time verification result is consistent with the verification value, the verification is deemed to have passed. If the real-time verification result is inconsistent with the verification value, the verification is deemed to have failed.

5. The method according to claim 1, characterized in that, The main controller terminates the loop operation and reports an upgrade failure message to the remote server, including: The main controller stops sending requests for subsequent data segments to the remote server; The main controller generates an error report containing the failure reason code and the number of upgraded fragments; The main controller sends the error report to the remote server via a wireless network.

6. The method according to claim 1, characterized in that, The firmware storage chip of the peripheral is a single programmable read-only memory, wherein the single programmable read-only memory is required to complete the continuous writing of complete firmware data within a single programming cycle.

7. The method according to claim 1, characterized in that, The dedicated upgrade loader includes at least a wireless communication protocol stack module, a data verification program, and a device driver for the peripheral device. The code size of the dedicated upgrade loader is smaller than the code size of the complete host software currently running on the main controller.

8. The method according to claim 1, characterized in that, After the main controller runs the complete host software package and reloads the at least one application that was terminated, and exits the temporary upgrade mode, it also includes: The main controller sends an upgrade completion confirmation message to the remote server; The main controller executes a system restart command, causing the IoT device to restart with the complete host software package loaded.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images