Method, system, and program product for non-disruptive firmware upgrade

Abstract

The application is suitable for the technical field of embedded systems, and provides a firmware upgrading method, system and program product without interrupting services, the method comprising: when an application program currently running in a device receives a firmware upgrading instruction, reading a reset entry address of a secondary boot program from a fixed starting address of the secondary boot program pre-deployed by the application program; constructing an analog stack frame in a volatile memory of the device by the application program; setting a global pointer variable by the application program, so that the global pointer variable points to the address of the analog stack frame, and executing a soft interrupt instruction to trigger the processor to enter an exception processing mode; after the processor responds to the soft interrupt instruction, jumping to a preset soft interrupt processing function, triggering an exception return mechanism of the processor by the soft interrupt processing function, so that the processor jumps to the reset entry address of the secondary boot program without resetting. The application realizes no-reset jumping in a pure software mode, avoids resetting of peripheral states and interruption of services caused by hardware resetting, guarantees continuity of key services during firmware upgrading, retains all running states of the application program, and realizes seamless inheritance of states.

Description

Technical Field

[0001] This application belongs to the field of embedded system technology, and in particular relates to a firmware upgrade method, system and program product that does not interrupt services. Background Technology

[0002] In fields such as industrial control, automotive electronics, and power electronics, where continuous operation is extremely critical, firmware upgrades for embedded controllers are a necessary but risky operation. Current mainstream firmware upgrade solutions are typically based on a dual- or multi-zone storage architecture consisting of a bootloader and an application program. Under this architecture, the standard upgrade process is as follows: upon receiving an upgrade command, the running application triggers a system hardware reset; after the reset, the processor begins execution from the preset bootloader entry address, the bootloader gains system control, and erases the application program area in memory and writes the new firmware; after the upgrade is complete, the system resets again to launch the new application.

[0003] However, this upgrade mechanism relying on hardware reset has the following drawbacks. First, a hardware reset will reset the processor core and all peripherals (such as general purpose input / output ports, timers, communication interfaces, etc.) to their default states. This will cause the output control signals (such as signals driving relays and contactors) to momentarily fail, leading to unexpected power outages in the controlled main circuit, or forcibly terminating ongoing data acquisition, control calculations, or real-time communication, disrupting business continuity, and potentially even causing production accidents or safety risks. Second, after a reset, all running states established by the application before the upgrade will be lost, requiring re-initialization upon startup of the new program, making seamless business transition impossible.

[0004] Therefore, existing firmware upgrade methods suffer from technical problems such as critical service interruption and system state loss due to hardware reset. Summary of the Invention

[0005] This application provides a firmware upgrade method, system, and program product that do not interrupt services, aiming to solve the technical problem in the prior art that critical services are interrupted and system state is lost because firmware upgrades rely on hardware reset.

[0006] In a first aspect, embodiments of this application provide a firmware upgrade method that does not interrupt services, including: When the currently running application on the device receives a firmware upgrade instruction, the application reads the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader; The application constructs a simulated stack frame in the volatile memory of the device. The application sets a global pointer variable to point to the address of the simulated stack frame and executes a software interrupt instruction to trigger the processor to enter exception handling mode. After the processor responds to the software interrupt instruction, it jumps to a preset software interrupt handling function, which triggers the processor's exception return mechanism, causing the processor to jump to the reset entry address of the secondary boot program without resetting.

[0007] In one possible implementation of the first aspect, the method further includes: A first storage region, including the fixed starting address, is pre-allocated in the non-volatile memory of the device for the secondary boot program; An interrupt vector table is deployed at the starting address of the first storage area. The first word of the interrupt vector table stores the initial value of the stack pointer of the secondary boot program, and the second word of the interrupt vector table stores the reset entry address.

[0008] In one possible implementation of the first aspect, prior to constructing the simulated stack frame, the following is also included: The application reads the initial value of the stack pointer from the fixed starting address of the secondary bootloader; The construction of the simulated stack frame includes: Based on the initial value of the stack pointer, the storage location of the simulated stack frame in the volatile memory is determined, such that the base address of the simulated stack frame matches the initial value of the stack pointer, so that after the processor jumps to the secondary boot program, the main stack pointer of the processor is restored to the initial value of the stack pointer.

[0009] In one possible implementation of the first aspect, the data structure of the simulated stack frame is consistent with the data structure that the processor of the device automatically pushes onto the stack in response to an exception; The simulated stack frame includes at least the simulated values ​​of the following registers stored sequentially: status register, program counter, link register, and multiple general-purpose registers; The simulated value of the program counter is the reset entry address of the secondary bootloader, and the simulated value of the status register is a value indicating that the processor is in the Thumb instruction state.

[0010] In one possible implementation of the first aspect, the exception return mechanism triggered by the software interrupt handler function includes: The software interrupt handler checks whether the global pointer variable is valid; If effective, the processor's main stack pointer is modified to the address pointed to by the global pointer variable; The exception return instruction is executed by the software interrupt handling function to trigger the processor's exception return mechanism; The exception return mechanism includes: the processor recovers the values ​​of multiple registers from the simulated stack frame pointed to by the main stack pointer, the values ​​of the multiple registers including the value of the program counter, the value of the program counter being the reset entry address of the secondary boot program.

[0011] In one possible implementation of the first aspect, before modifying the processor's main stack pointer to the address pointed to by the global pointer variable, the method further includes: Perform the operation to disable global interrupts; Restore the value of the callee's saved register and write the preset exception return value into the processor's link register. The exception return value is used to trigger the exception return mechanism.

[0012] In one possible implementation of the first aspect, the method further includes: The secondary bootloader skips the initialization operation of peripherals in the preset peripheral list in order to maintain the state of the peripherals; Firmware upgrade tasks and service maintenance tasks are executed in parallel.

[0013] In one possible implementation of the first aspect, the non-volatile memory of the device includes a second storage area and a third storage area, wherein the second storage area is used to store currently running applications and the third storage area is used to store firmware to be upgraded; The method further includes: The secondary bootloader receives and verifies the firmware to be upgraded; Erase the third storage area and write the firmware to be upgraded into the third storage area; The integrity of the firmware to be upgraded, written to the third storage area, is verified by the secondary bootloader. After verification, the boot configuration information stored in the non-volatile memory is modified so that the firmware to be upgraded is loaded from the third storage area when the device boots up next time.

[0014] Secondly, embodiments of this application provide a firmware upgrade system that does not interrupt services, including: The reading module is used to read the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader when the currently running application in the device receives a firmware upgrade instruction; A building module for constructing a simulated stack frame by the application in the volatile memory of the device; The execution module is used to set a global pointer variable by the application, make the global pointer variable point to the address of the simulated stack frame, and execute a soft interrupt instruction to trigger the processor to enter the exception handling mode. The jump module is used to jump to a preset soft interrupt handling function after the processor responds to the soft interrupt instruction. The soft interrupt handling function triggers the exception return mechanism of the processor, so that the processor jumps to the reset entry address of the secondary boot program without resetting.

[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the firmware upgrade method without interrupting services as described in any of the first aspects above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the firmware upgrade method for non-interrupted service as described in any of the first aspects above.

[0017] Fifthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to perform the firmware upgrade method described in any of the first aspects above without interrupting services.

[0018] In this embodiment, by constructing a simulated stack frame, executing a soft interrupt instruction, and triggering the processor's exception return mechanism to achieve a reset-free jump, the processor core and all peripheral register states are completely preserved because the entire jump process does not trigger any hardware reset. This avoids problems such as control signal failure and data acquisition interruption, ensuring the continuous operation of critical services with zero interruption. At the same time, because no hardware reset occurs during the jump, all running states (including stack contents, global variables, and peripheral configurations) established by the application before the upgrade are not lost. The secondary bootloader can perform firmware upgrades while maintaining these states, and the new application can seamlessly connect without re-initialization after startup.

[0019] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0021] Figure 1 This is a schematic flowchart of a firmware upgrade method that does not interrupt services, provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the firmware upgrade system that does not interrupt services, provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

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

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

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

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

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

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

[0028] Figure 1 A schematic flowchart of a firmware upgrade method that does not interrupt services, according to an embodiment of this application, is shown.

[0029] S101, when the currently running application in the device receives a firmware upgrade instruction, the application reads the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader.

[0030] The firmware upgrade command refers to the control information that can trigger the application to start the upgrade process. Its source can be external (such as a host computer or cloud platform) sent to the embedded device via a communication interface, or internal (such as a timer or state machine) generated by the device itself. Upon receiving (or detecting) this command, the application does not trigger a hardware reset, but instead executes the reset-free jump process described in this application.

[0031] The secondary bootloader is an executable code independently deployed in non-volatile memory, located between the primary bootloader and the application program. It is designed to take over processor control without triggering a hardware reset. A fixed physical memory address, called the fixed start address, is pre-allocated to this secondary bootloader. This address is determined at the factory and will not be overwritten by subsequent upgrades. At this fixed start address, the secondary bootloader's own interrupt vector table is deployed. The first word stores the initial stack pointer value, and the second word stores the reset entry address.

[0032] In this embodiment, if the application receives a firmware upgrade command through a communication interface (such as CAN, UART, etc.) during runtime, it immediately performs a pointer access to a fixed starting address (e.g., Flash address 0x00010000) and reads the reset entry address from a position offset by 4 bytes from that address. This read operation ensures that the application knows the accurate jump target, providing necessary information for subsequent jumps without a reset.

[0033] S102, the application constructs a simulated stack frame in the device's volatile memory.

[0034] A simulated stack frame is a memory region actively constructed by software in volatile memory (such as RAM), whose data structure is completely identical to the context format automatically pushed onto the stack by the processor when responding to an exception. This simulated stack frame is used to guide the processor's exception return mechanism in subsequent steps, allowing it to recover preset register values, thereby achieving a reset-free jump.

[0035] In this embodiment, the application writes simulated values ​​such as the status register, program counter, and link register to the region in the order in which the processor is abnormally pushed onto the stack, and sets the value of the program counter to the reset entry address.

[0036] It should be noted that for processors using a full decrementing stack, the base address of the simulated stack frame refers to its stack top address (i.e., the address of the last memory location where data was pushed). Subsequent global pointer variables will point to this stack top address so that the processor can correctly pop the context when an exception occurs.

[0037] S103: The application sets a global pointer variable to point to the address of the simulated stack frame and executes a software interrupt instruction to trigger the processor to enter exception handling mode.

[0038] Among them, the global pointer variable refers to a global variable shared between the application and the soft interrupt handler function, which is used to pass the address of the simulated stack frame.

[0039] Among them, a software interrupt instruction is an exception instruction that is actively triggered by software (such as the SVC instruction in the ARM architecture). After execution, the processor will be forced to enter the exception handling mode and jump to the pre-registered software interrupt handling function.

[0040] In this embodiment, after constructing the simulated stack frame, the application assigns the address of the simulated stack frame (e.g., the stack top pointer value) to a global pointer variable, and then executes a software interrupt instruction. After the instruction is executed, the processor hardware automatically saves the current application context, retrieves the entry address of the software interrupt handler function from the vector table, and jumps to it.

[0041] S104: After the processor responds to the software interrupt instruction, it jumps to the preset software interrupt handling function. The software interrupt handling function triggers the processor's exception return mechanism, causing the processor to jump to the reset entry address of the secondary boot program without resetting.

[0042] Among them, the software interrupt handling function refers to the service routine corresponding to the software interrupt instruction. This function is registered in the interrupt vector table when the system starts up.

[0043] The exception return mechanism refers to a function provided by the processor hardware. When a specific exception return instruction (such as BX LR in ARM Cortex-M, and the link register LR stores a special EXC_RETURN value) is executed in the exception handling function, the hardware will automatically pop the context from the memory pointed to by the current stack pointer, restore it to the register group, and then jump to the address pointed to by the restored program counter PC.

[0044] In this embodiment, the software interrupt handler first checks if the global pointer variable g_pJumpStack is valid (not null). If valid, it disables global interrupts, writes a preset exception return value (e.g., 0xFFFFFFF9) to the link register LR, then modifies the processor's main stack pointer (MSP) to the address pointed to by g_pJumpStack (i.e., the address of the simulated stack frame), and finally executes the exception return instruction BX LR. Since LR stores a special exception return value, this instruction triggers the hardware exception return mechanism. The processor automatically pops the values ​​of each register from the simulated stack frame pointed to by the main stack pointer, and the program counter PC is restored to the reset entry address, thus jumping to the secondary boot program without reset to begin execution.

[0045] In this embodiment, by constructing a simulated stack frame, executing a soft interrupt instruction, and triggering the processor's exception return mechanism to achieve a reset-free jump, the processor core and all peripheral register states are completely preserved because the entire jump process does not trigger any hardware reset. This avoids problems such as control signal failure and data acquisition interruption, ensuring the continuous operation of critical services with zero interruption. At the same time, because no hardware reset occurs during the jump, all running states (including stack contents, global variables, and peripheral configurations) established by the application before the upgrade are not lost. The secondary bootloader can perform firmware upgrades while maintaining these states, and the new application can seamlessly connect without re-initialization after startup.

[0046] In an optional embodiment, the method further includes: Step a1: Pre-allocate a first storage region with a fixed starting address in the device's non-volatile memory for the secondary boot program.

[0047] The first storage region refers to a contiguous address space in non-volatile memory (such as Flash) specifically allocated to the secondary boot program. The size of this region is predetermined based on the amount of code in the secondary boot program, and its starting address is a fixed starting address.

[0048] In this embodiment, the first storage area can be obtained by reserving it separately during the initial system design phase or by logically reorganizing the existing bootloader storage space. Regardless of the method used, the fixed starting address is determined at the time of device manufacture and will not be overwritten by subsequent application upgrades.

[0049] Step a2: Deploy an interrupt vector table at the starting address of the first storage area. The first word of the interrupt vector table stores the initial value of the stack pointer of the secondary boot program, and the second word of the interrupt vector table stores the reset entry address.

[0050] The initial value of the stack pointer refers to the initial address value that the processor's main stack pointer should be assigned when the secondary bootloader starts executing. This value determines the stack space location during the execution of the secondary bootloader.

[0051] In this embodiment, when the secondary bootloader is burned to the first storage area, its interrupt vector table is naturally located at the starting address of that area. The linker script can be used to forcibly specify the starting address of the interrupt vector table segment as a fixed starting address, and fill in the initial value of the stack pointer and the actual value of the reset entry address, respectively. This deployment method ensures that the application can directly read the correct reset entry address through the fixed starting address.

[0052] In an optional embodiment, before constructing the simulated stack frame, the method further includes: the application reading the initial value of the stack pointer from the fixed starting address of the secondary bootstrap program; then constructing the simulated stack frame includes: determining the storage location of the simulated stack frame in volatile memory based on the initial value of the stack pointer, such that the base address of the simulated stack frame matches the initial value of the stack pointer, so that after the processor jumps to the secondary bootstrap program, the processor's main stack pointer is restored to the initial value of the stack pointer.

[0053] In this context, matching the base address of the simulated stack frame with the initial value of the stack pointer means that the stack top pointer of the simulated stack frame (for processor architectures using a full decrementing stack) is set to be equal to the initial value of the stack pointer.

[0054] In this embodiment, the application reads the reset entry address and simultaneously reads the initial value of the stack pointer from a fixed starting address offset by 0 bytes. Subsequently, when constructing a simulated stack frame, the application uses this initial stack pointer value as the stack top address of the simulated stack frame, allocates a memory region in RAM, and writes the simulated value to the register. When the soft interrupt handler in S104 modifies the main stack pointer to point to this simulated stack frame and executes an exception return, the main stack pointer automatically restores to its initial value, ensuring that the secondary bootloader obtains the correct stack environment.

[0055] In one optional embodiment, the data structure of the simulated stack frame is consistent with the data structure automatically pushed onto the stack by the device's processor in response to an exception. The simulated stack frame includes at least the simulated values ​​of the following registers stored sequentially: a status register, a program counter, a link register, and multiple general-purpose registers. The simulated value of the program counter is the reset entry address of the secondary bootloader, and the simulated value of the status register is a value indicating that the processor is in the Thumb instruction state. In this embodiment, the data structure of the simulated stack frame is required to be strictly consistent with the processor's hardware exception push format because when the processor executes the exception return instruction, it pops register values ​​from the stack in a fixed order and restores them to the program counter, link register, etc. If the format is inconsistent or the order is disordered, the program counter will be restored to an incorrect address, causing a system crash. Setting the simulated value of the program counter to the reset entry address of the secondary bootloader allows the processor to automatically jump to that address when returning from an exception, thereby achieving a reset-free switching.

[0056] In this context, the data structure consistency of the simulated stack frame refers to the strict consistency between the storage order, quantity, and space occupation of the simulated values ​​in each register of the stack frame and the format of the processor hardware automatically pushing the values ​​onto the stack during an exception response. When the Thumb bit (bit 24) of the status register xPSR is 1, it indicates that the processor is in Thumb instruction mode, which is a necessary mode for the normal operation of processors such as ARM Cortex-M.

[0057] In this embodiment, the application writes register values ​​to the simulated stack frame in a fixed order of processor exception stack pushing (e.g., for Cortex-M, xPSR, PC, LR, R12, R3, R2, R1, R0). Specifically, the simulated value of the program counter PC is set to the secondary boot program reset entry address read in S101, and the simulated value of the status register xPSR is set to 0x01000000 (i.e., the Thumb bit is 1). Other registers (LR, R12, R0-R3) can be filled with 0s or reserved with undefined values ​​as needed. Thus, when the processor returns from an exception, the hardware restores these registers from the simulated stack frame in the same order, correctly pointing the PC to the secondary boot program and enabling the processor to begin execution in Thumb state.

[0058] In one optional embodiment, the exception return mechanism of the processor triggered by the software interrupt handler includes: Step b1 involves the software interrupt handler checking whether the global pointer variable is valid.

[0059] In this context, "valid" can refer to the value of the global pointer variable being non-null (i.e., not equal to NULL or 0). If the variable is non-null, it indicates that the application has completed the construction of the simulated stack frame and stored the address of the simulated stack frame in it. Thus, the soft interrupt handler function can use this condition to determine whether the current soft interrupt is a trigger request for a no-reset jump procedure.

[0060] In this embodiment, the soft interrupt handler checks whether a global pointer variable (such as g_pJumpStack) is not NULL using a conditional statement. If the variable is valid, the subsequent stack pointer modification and exception return operations continue; if invalid, the handler returns directly according to the normal soft interrupt handling process to avoid incorrect execution of jump logic.

[0061] If step b2 is effective, then modify the processor's main stack pointer to the address pointed to by the global pointer variable.

[0062] The main stack pointer is a pointer register used by the processor kernel to access the currently used stack. Its value determines the memory address from which the processor starts popping the context when returning from an exception. Modifying the main stack pointer to the address pointed to by a global pointer variable, that is, pointing the stack pointer to a pre-built simulated stack frame, allows the subsequent exception return mechanism to restore register values ​​from this simulated stack frame.

[0063] In this embodiment, after confirming the validity of the global pointer variable, the soft interrupt handler updates the value of the main stack pointer to the address stored in the global pointer variable (i.e., the base address or top address of the simulated stack frame, depending on the growth direction of the processor stack) through a special register write operation provided by the processor. After this operation, the processor's main stack pointer is forced to point to the beginning of the simulated stack frame. At this time, when the processor subsequently executes an exception return instruction, the hardware will automatically pop the context from the memory pointed to by this new stack pointer, thereby guiding the processor to jump to the secondary boot program. This modification operation is one of the key steps in triggering a jump without a reset and must be ensured to be completed before the exception return.

[0064] Step b3: The software interrupt handler executes an exception return instruction to trigger the processor's exception return mechanism.

[0065] The exception return instruction refers to a special instruction defined in the processor architecture (such as BX LR). When this instruction is executed, if the link register LR contains a preset exception return value EXC_RETURN, the processor will not treat it as a normal function return, but will instead initiate the hardware exception return procedure. The exception return mechanism includes: the processor restoring the values ​​of multiple registers from the simulated stack frame pointed to by the main stack pointer. These register values ​​include the program counter, which is the reset entry address of the secondary bootloader.

[0066] In this embodiment, after modifying the main stack pointer, the software interrupt handler executes an exception return instruction. Since the software interrupt handler has previously written the preset exception return value to the link register LR, the execution of this exception return instruction triggers the processor's exception return mechanism. The processor hardware then sequentially pops the values ​​of the status register, program counter, link register, and other registers from the simulated stack frame pointed to by the current main stack pointer. The program counter PC is restored to the preset secondary bootloader reset entry address in the simulated stack frame, thus the processor jumps to the secondary bootloader without a reset to begin execution. The entire process does not involve any hardware reset operation, and the states of all peripheral registers are completely preserved.

[0067] In an optional embodiment, before modifying the processor's main stack pointer to the address pointed to by the global pointer variable, the method further includes: Step c1: Perform the operation to disable global interrupts.

[0068] Global interrupts refer to the processor kernel's ability to respond to external or internal interrupt requests. When global interrupts are disabled, the processor will no longer respond to any maskable interrupts that arrive currently or subsequently, until they are re-enabled. The purpose of this operation is to ensure the atomicity of subsequent critical operations (such as modifying the stack pointer, executing exception returns, etc.) and prevent them from being interrupted by other interrupt service routines during execution, thereby avoiding context corruption or jump failures.

[0069] In this embodiment, after confirming the validity of the global pointer variable but before modifying the main stack pointer, the soft interrupt handler disables the global interrupt using privileged instructions provided by the processor (such as _disable_irq() in the ARM Cortex-M architecture or by directly manipulating the PRIMASK register). This ensures that no nested interrupts occur within the entire window from the start of interrupt disabling to the completion of the exception return instruction, guaranteeing the integrity of stack pointer switching and exception return operations. After the processor successfully jumps to the secondary bootloader, the secondary bootloader can decide when to re-enable the global interrupt as needed.

[0070] Step c2: Restore the value of the callee's saved register and write the preset exception return value into the processor's link register. The exception return value is used to trigger the exception return mechanism.

[0071] The callee-saved registers refer to a set of registers (such as R4-R11 in the ARM architecture) that are saved and restored by the called function during a function call, according to the application's binary interface conventions. Restoring the values ​​of these registers ensures that the software interrupt handler does not corrupt the caller's execution environment upon return. The link register (LR) stores the function return address or exception return value. When a preset exception return value (such as 0xFFFFFFF9 in ARM Cortex-M) is stored, subsequent exception return instructions will trigger the hardware exception return mechanism instead of a normal function return.

[0072] In this embodiment, after disabling global interrupts, the software interrupt handler first restores the original values ​​of the callee's saved registers (such as R4-R11) from the current stack to avoid application state corruption after function return. Then, a preset exception return value (e.g., 0xFFFFFFF9, indicating that the main stack pointer is used and the thread returns to its original state) is written to the link register LR. This value is defined by the processor architecture specification; after being written, the processor will recognize this return as an exception. Only after completing these operations can the software interrupt handler continue executing subsequent main stack pointer modification and exception return instructions, thus ensuring that the entire jump process conforms to the processor's underlying hardware requirements.

[0073] In an optional embodiment, the method further includes: In step d1, the secondary bootloader skips the initialization operation of peripherals in the preset peripheral list in order to maintain the status of the peripherals.

[0074] The preset peripheral list refers to a list predefined in the secondary bootloader that lists peripheral modules (such as GPIO ports of the driver contactor, real-time clock, communication interface, etc.) that must remain unchanged during firmware upgrades.

[0075] In this embodiment, since the reset-free jump in the aforementioned steps fully preserves the register states of all peripherals, the secondary bootloader, after gaining control, first reads the preset peripheral list. For each peripheral in the list, the secondary bootloader bypasses its corresponding configuration function during the initialization process. For example, for a GPIO peripheral, if the application has already set the PA0 pin to a high level output to drive the contactor before the jump, the secondary bootloader does not reinitialize the GPIO port, so PA0 continues to output a high level, and the contactor remains engaged. In this way, the secondary bootloader can safely perform firmware upgrades while executing service maintenance tasks (such as refreshing the watchdog timer and responding to communication heartbeats) without affecting critical services.

[0076] Step d2 involves executing firmware upgrade and service maintenance tasks in parallel.

[0077] Parallel execution refers to the secondary bootstrap program alternately or simultaneously executing two different types of tasks within the same time period. This is usually achieved through time slice rotation, interrupt-driven execution, or state machine scheduling, rather than strictly speaking multi-threaded parallelism.

[0078] The firmware upgrade task includes operations such as receiving the firmware to be upgraded, verifying its integrity, erasing non-volatile memory, writing the new firmware, and verifying the burning results.

[0079] Business maintenance tasks refer to continuous operations related to existing business, such as refreshing the watchdog timer, maintaining output signals, collecting sensor data, and responding to communication heartbeats.

[0080] In this embodiment, the secondary bootloader breaks down the firmware upgrade operation into multiple small steps (such as receiving a data block, writing a data block, and verifying a data block) within the main loop or scheduler, inserting service maintenance task execution segments between each pair of steps. For example, after erasing the Flash sector, the service maintenance function is immediately called to refresh the GPIO output level and feed the watchdog timer; after writing a data block, the communication interface is checked again for new instructions or heartbeat packets. Through this task interleaving method, the secondary bootloader can both gradually complete the entire firmware upgrade process and ensure that critical services (such as contactor driving and voltage monitoring) are not interrupted due to the upgrade operation, thereby achieving continuous service that is transparent to the user during the upgrade process.

[0081] In an optional embodiment, the device's non-volatile memory includes a second storage area and a third storage area, the second storage area for storing currently running applications and the third storage area for storing firmware to be upgraded. The method further includes: Step e1: The secondary bootloader receives and verifies the firmware to be upgraded.

[0082] Verification refers to using a preset integrity verification algorithm (such as SHA256) to calculate a check value for the received firmware data and comparing it with the original check value attached to the firmware package to confirm that no errors have occurred during the transmission or storage of the data.

[0083] In this embodiment, after the secondary bootloader gains control of the processor, it first determines the firmware source according to a preset upgrade strategy. If the upgrade is initiated by an external device, firmware data is received in blocks via the communication interface; if the upgrade is triggered internally, firmware data is read in segments from a designated internal storage medium (such as external Flash or EEPROM). For each data block acquired, a real-time checksum is calculated and compared with the expected value. After all data is acquired, the entire firmware image is verified (e.g., the CRC32 of the complete image is calculated). Only when the checksums match perfectly is the firmware considered valid, allowing subsequent erasure and write steps. If the verification fails, the received / read data is discarded, and an error is reported to the host computer (or invalid firmware in internal storage is cleared), awaiting a retry. This step ensures the integrity and correctness of the firmware data entering the non-volatile memory, avoiding system anomalies caused by firmware corruption.

[0084] Step e2: Erase the third storage area and write the firmware to be upgraded into the third storage area.

[0085] Erasing refers to restoring a designated area (i.e., the third storage area) in non-volatile memory to its initial write state (usually all 1s, i.e., 0xFF) to facilitate subsequent programming operations. Writing refers to programming the data of the firmware to be upgraded into the third storage area one address at a time. Both erasing and writing operations must comply with the underlying operation timing specifications of non-volatile memory (e.g., for embedded Flash, erasing by sector, programming by page or byte).

[0086] In this embodiment, after confirming that the firmware to be upgraded has passed verification, the secondary bootloader performs an erase operation on the third storage area (e.g., calling the underlying driver function to erase by sector). After erasure, the firmware data received and verified in step e1 is read from the temporary storage area (such as a memory buffer or external storage) and written to the area in address order. To improve reliability, a readback verification can be performed after each data block is written to ensure that the written content is consistent with the original data. This operation is only performed on the third storage area (i.e., the backup partition) and does not affect the application currently running in the second storage area. Therefore, even if an accident occurs during the writing process (such as a power outage), the system can still start normally from the current application.

[0087] Step e3 involves the secondary bootloader verifying the integrity of the firmware to be upgraded, which is written to the third storage area.

[0088] Integrity verification refers to recalculating the verification value (e.g., CRC32 or SHA256) of the firmware data written to the third storage area and comparing it with the original verification value obtained in step e1 to confirm that no data errors or data loss were introduced during the burning process.

[0089] In this embodiment, after the entire firmware to be upgraded is written to the third storage area, the secondary bootloader recalculates the checksum of the entire firmware image in that area and compares it with the original checksum parsed from the firmware package in step e1. If they match, the firmware is considered complete and the writing is successful; if they do not match, the upgrade is considered to have failed. The secondary bootloader can erase invalid data in the third storage area and report the error to the host computer (or clear the failure flag in the internal storage), waiting to receive the firmware again. This secondary verification mechanism ensures that only completely correct firmware can be activated, avoiding firmware corruption caused by power outages, interference, or memory damage during the writing process, thereby improving the reliability and security of firmware upgrades.

[0090] Step e4: After the verification is successful, modify the boot configuration information stored in the non-volatile memory so that the firmware to be upgraded is loaded from the third storage area when the device boots up next time.

[0091] The startup configuration information refers to the flags, version number, or partition pointer stored in a fixed location in non-volatile memory (such as a specific sector of internal Flash or external EEPROM), which is used to indicate from which memory area the processor loads and executes the application after a hardware reset or power-on.

[0092] In this embodiment, after the integrity verification passes, the secondary bootloader modifies the boot configuration information in the non-volatile memory to point to the starting address of the third storage area (or sets the corresponding partition validity flag). For example, a specific flag value (such as 0x5A5A) is written to a preset address, indicating that the next boot should be from the backup partition. It should be noted that since the jump process in the aforementioned steps of this application does not trigger any hardware reset, a reset is not immediately performed in this upgrade process; the device will continue to run the secondary bootloader and maintain critical services. When a hardware reset occurs in the future due to other reasons (such as user operation, timed reset, watchdog timeout, etc.), the processor will load the new firmware from the third storage area according to the modified boot configuration information when it starts up, and finally complete the application switching. Thus, firmware writing and configuration modification are completed without interrupting the current service, achieving a seamless upgrade.

[0093] In one alternative implementation, after completing the writing and integrity verification of the new firmware, the secondary bootloader does not modify the boot configuration information or wait for a hardware reset. Instead, it directly uses the same or similar reset-free jump method as S101 to S104 to jump back from the secondary bootloader to the entry address of the newly written application, so that the new application can start running immediately.

[0094] Specifically: The secondary bootloader reads the initial stack pointer value and reset entry address from the interrupt vector table of the newly written application; the secondary bootloader reconstructs a new simulated stack frame in volatile memory, sets the simulated program counter (PC) value of this simulated stack frame to the read application's reset entry address, and sets the simulated status register (xPSR) value to indicate the Thumb instruction status; the secondary bootloader sets another global pointer variable to point to the address of this new simulated stack frame and executes a soft interrupt instruction; after responding to the soft interrupt, the processor jumps to the same or another soft interrupt handler function, which triggers the exception return mechanism again, modifies the processor's main stack pointer to point to the new simulated stack frame, and then executes the exception return instruction; the processor hardware restores the context from the new simulated stack frame, sets the program counter to the reset entry address of the new application, thus achieving a reset-free jump to the new application to begin execution. Through this method, the entire firmware upgrade process—from the application to the secondary bootloader, and then from the secondary bootloader to the new application—does not require triggering any hardware reset, achieving truly uninterrupted and seamless upgrades.

[0095] In one optional embodiment, taking a microcontroller based on an ARM Cortex-M4 core as an example, its non-volatile Flash memory starts at address 0x00000000. During system design, Flash addresses 0x00010000 to 0x0001FFFF (64KB in total) are designated as the first storage area for the secondary bootloader, with a fixed starting address of 0x00010000. The interrupt vector table for the secondary bootloader is deployed at starting address 0x00010000, where the first word stores the initial stack pointer value and the second word stores the reset entry address.

[0096] Upon receiving the firmware upgrade command, the currently running application reads the reset entry address and initial stack pointer value of the secondary bootloader from address 0x00010000. The application constructs a simulated stack frame in RAM, writing simulated values ​​to the status register (xPSR), program counter (PC), link register (LR), etc., in the order of processor exceptions being pushed onto the stack, and sets the program counter (PC) to the read reset entry address. Subsequently, the application sets a global pointer variable to point to the top address of this simulated stack frame and executes a software interrupt instruction (such as SVC 0).

[0097] After the processor responds to a software interrupt, it jumps to the preset software interrupt handler. This function checks that the global pointer variable is valid, disables global interrupts, restores the callee's saved registers, writes the exception return value to the link register LR, modifies the main stack pointer to the address pointed to by the global pointer variable, and finally executes the exception return instruction (e.g., BX LR). The processor hardware automatically pops register values ​​from the simulated stack frame and restores the program counter (PC) to the reset entry address of the secondary bootloader, thus achieving a reset-free jump. After the secondary bootloader gains control, all peripheral states are completely consistent with those before the jump, allowing for safe firmware upgrade operations.

[0098] To more intuitively illustrate the practical effectiveness of this method in achieving zero disruption to critical business operations, the following description uses a specific industrial control scenario as an example.

[0099] In one alternative embodiment, the contactor drive unit of a smart distribution cabinet employs a 32-bit microcontroller, with one pin of its general purpose input / output port (e.g., PA0) driving the contactor coil via an optocoupler and a MOSFET. During normal operation, the currently running application sets this pin to a high-level output to keep the contactor engaged, thereby maintaining power supply to the main circuit.

[0100] When the application receives a firmware upgrade command, it executes the reset-free jump method of this application without changing the PA0 output register configuration. The application reads the reset entry address of the secondary bootloader, constructs a simulated stack frame in RAM, triggers a software interrupt, and the software interrupt handler completes the context switch. Throughout the entire microsecond-level jump process, the processor's GPIO output register is never reset or rewritten, and the PA0 pin continuously outputs a high level.

[0101] After the processor jumps to the secondary bootloader, the secondary bootloader skips the initialization of GPIO peripherals, and the contactor remains engaged, achieving zero-interruption power supply to the main circuit. While maintaining contactor drive, the secondary bootloader receives new firmware through the communication interface and erases and programs the application program area in the internal Flash memory. After the upgrade is complete, the secondary bootloader verifies the integrity of the new firmware and modifies the boot configuration information so that the device will boot from the new firmware upon the next reset. Throughout the entire upgrade process, the contactor remains engaged, and critical services are not interrupted.

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

[0103] Corresponding to the firmware upgrade method without interrupting services described in the above embodiments, Figure 2The diagram shows a structural block diagram of a firmware upgrade system that does not interrupt services, as provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0104] Reference Figure 2 The uninterrupted service firmware upgrade system includes: The reading module is used to read the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader when the currently running application in the device receives a firmware upgrade instruction; Modules for building simulated stack frames by the application in the device's volatile memory; The execution module is used by the application to set a global pointer variable, make the global pointer variable point to the address of the simulated stack frame, and execute a soft interrupt instruction to trigger the processor to enter exception handling mode. The jump module is used to jump to a preset soft interrupt handler function after the processor responds to a soft interrupt instruction. The soft interrupt handler function triggers the processor's exception return mechanism, causing the processor to jump to the reset entry address of the secondary boot program without resetting.

[0105] In one possible implementation, the non-disruptive firmware upgrade system further includes: a preprocessing module, used for: In the non-volatile memory of the device, a first storage area including a fixed starting address is pre-allocated for the secondary boot program; and an interrupt vector table is deployed at the starting address of the first storage area, the first word of the interrupt vector table stores the initial value of the stack pointer of the secondary boot program, and the second word of the interrupt vector table stores the reset entry address.

[0106] In one possible implementation, a building module is used for: Based on the initial value of the stack pointer, the storage location of the simulated stack frame in volatile memory is determined so that the base address of the simulated stack frame matches the initial value of the stack pointer, so that after the processor jumps to the secondary boot program, the processor's main stack pointer is restored to the initial value of the stack pointer.

[0107] In one possible implementation, the data structure of the simulated stack frame is consistent with the data structure that the device's processor automatically pushes onto the stack in response to an exception; the simulated stack frame includes at least the simulated values ​​of the following registers stored sequentially: a status register, a program counter, a link register, and multiple general-purpose registers; the simulated value of the program counter is the reset entry address of the secondary bootloader, and the simulated value of the status register is a value indicating that the processor is in the Thumb instruction state.

[0108] In one possible implementation, the jump module is used for: The software interrupt handler checks whether the global pointer variable is valid. If effective, the processor's main stack pointer will be modified to the address pointed to by the global pointer variable; The exception return instruction is executed by the software interrupt handler to trigger the processor's exception return mechanism; The exception return mechanism includes: the processor recovers the values ​​of multiple registers from the simulated stack frame pointed to by the main stack pointer. The values ​​of the multiple registers include the value of the program counter, which is the reset entry address of the secondary boot program.

[0109] In one possible implementation, the uninterrupted firmware upgrade system further includes: an interruption assistance module, used for: Performs the operation of disabling global interrupts; and restores the value of the callee's saved register and writes the preset exception return value to the processor's link register. The exception return value is used to trigger the exception return mechanism.

[0110] In one possible implementation, the uninterrupted firmware upgrade system further includes: a service maintenance and upgrade parallel module. The secondary bootloader skips the initialization operation of peripherals in the preset peripheral list in order to maintain the state of the peripherals; Firmware upgrade tasks and service maintenance tasks are executed in parallel.

[0111] In one possible implementation, the device's non-volatile memory includes a second storage area and a third storage area. The second storage area stores the currently running application, and the third storage area stores the firmware to be upgraded. This firmware upgrade system, which does not interrupt service, also includes: The firmware receiving and verification module is used by the secondary bootloader to receive and verify the firmware to be upgraded. The erase module is used to erase the third storage area and write the firmware to be upgraded into the third storage area; The integrity verification module is used by the secondary bootloader to verify the integrity of the firmware to be upgraded written to the third storage area; The integrity verification module is used to modify the boot configuration information stored in non-volatile memory after the verification is successful, so that the firmware to be upgraded can be loaded from the third storage area when the device boots up next time.

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

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

[0114] This application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

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

[0116] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0117] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 3 As shown, the computer device of this embodiment includes: at least one processor 30 ( Figure 3 (Only one is shown in the diagram), memory 31, and computer program 32 stored in said memory 31 and executable on said at least one processor 30, wherein the processor 30 executes said computer program 32 to implement the steps in any of the above embodiments of the firmware upgrade method without interrupting services.

[0118] The computer device may include, but is not limited to, a processor 30 and a memory 31. Those skilled in the art will understand that... Figure 3The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0119] The processor 30 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. A general-purpose processor may be a microprocessor or any conventional processor.

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

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

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

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

[0124] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

Claims

1. A firmware upgrade method that does not interrupt services, characterized in that, The method includes: When the currently running application on the device receives a firmware upgrade instruction, the application reads the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader; The application constructs a simulated stack frame in the volatile memory of the device. The application sets a global pointer variable to point to the address of the simulated stack frame and executes a software interrupt instruction to trigger the processor to enter exception handling mode. After the processor responds to the software interrupt instruction, it jumps to a preset software interrupt handling function, which triggers the processor's exception return mechanism, causing the processor to jump to the reset entry address of the secondary boot program without resetting.

2. The method according to claim 1, characterized in that, The method further includes: A first storage region, including the fixed starting address, is pre-allocated in the non-volatile memory of the device for the secondary boot program; An interrupt vector table is deployed at the starting address of the first storage area. The first word of the interrupt vector table stores the initial value of the stack pointer of the secondary boot program, and the second word of the interrupt vector table stores the reset entry address.

3. The method according to claim 2, characterized in that, Before constructing the simulated stack frame, the following is also included: The application reads the initial value of the stack pointer from the fixed starting address of the secondary bootloader; The construction of the simulated stack frame includes: Based on the initial value of the stack pointer, the storage location of the simulated stack frame in the volatile memory is determined, such that the base address of the simulated stack frame matches the initial value of the stack pointer, so that after the processor jumps to the secondary boot program, the main stack pointer of the processor is restored to the initial value of the stack pointer.

4. The method according to claim 3, characterized in that, The data structure of the simulated stack frame is consistent with the data structure that the processor of the device automatically pushes onto the stack when responding to an exception. The simulated stack frame includes at least the simulated values ​​of the following registers stored sequentially: status register, program counter, link register, and multiple general-purpose registers; The simulated value of the program counter is the reset entry address of the secondary bootloader, and the simulated value of the status register is a value indicating that the processor is in the Thumb instruction state.

5. The method according to claim 3, characterized in that, The exception return mechanism triggered by the software interrupt handler function includes: The software interrupt handler checks whether the global pointer variable is valid; If effective, the processor's main stack pointer is modified to the address pointed to by the global pointer variable; The exception return instruction is executed by the software interrupt handling function to trigger the processor's exception return mechanism; The exception return mechanism includes: the processor recovers the values ​​of multiple registers from the simulated stack frame pointed to by the main stack pointer, the values ​​of the multiple registers including the value of the program counter, the value of the program counter being the reset entry address of the secondary boot program.

6. The method according to claim 5, characterized in that, Before modifying the processor's main stack pointer to the address pointed to by the global pointer variable, the method further includes: Perform the operation to disable global interrupts; Restore the value of the callee's saved register and write the preset exception return value into the processor's link register. The exception return value is used to trigger the exception return mechanism.

7. The method according to claim 1, characterized in that, The method further includes: The secondary bootloader skips the initialization operation of peripherals in the preset peripheral list in order to maintain the state of the peripherals; Firmware upgrade tasks and service maintenance tasks are executed in parallel.

8. The method according to claim 2, characterized in that, The non-volatile memory of the device includes a second storage area and a third storage area, wherein the second storage area is used to store currently running applications and the third storage area is used to store firmware to be upgraded; The method further includes: The secondary bootloader receives and verifies the firmware to be upgraded; Erase the third storage area and write the firmware to be upgraded into the third storage area; The integrity of the firmware to be upgraded, written to the third storage area, is verified by the secondary bootloader. After verification, the boot configuration information stored in the non-volatile memory is modified so that the firmware to be upgraded is loaded from the third storage area when the device boots up next time.

9. A firmware upgrade system that does not interrupt services, characterized in that, include: The reading module is used to read the reset entry address of the secondary bootloader from the fixed starting address of the pre-deployed secondary bootloader when the currently running application in the device receives a firmware upgrade instruction; A building module for constructing a simulated stack frame by the application in the volatile memory of the device; The execution module is used to set a global pointer variable by the application, make the global pointer variable point to the address of the simulated stack frame, and execute a soft interrupt instruction to trigger the processor to enter the exception handling mode. The jump module is used to jump to a preset soft interrupt handling function after the processor responds to the soft interrupt instruction. The soft interrupt handling function triggers the exception return mechanism of the processor, so that the processor jumps to the reset entry address of the secondary boot program without resetting.

10. A computer program product, characterized in that, Includes a computer program that, when run, implements the method as described in any one of claims 1 to 8.

Images