Firmware upgrade method based on storage and running separation, microcontroller, embedded system and storage medium

Abstract

Embodiments of the present application relate to the technical field of firmware upgrade, in particular to a firmware upgrade method based on storage and operation separation, a microcontroller, an embedded system and a storage medium. Embodiments of the present application store firmware upgrade data to an external storage module, after the target application program / target boot program passes the verification, backup the reference application program / reference boot program normally running, and can quickly roll back when the upgrade fails, thereby improving the reliability of firmware upgrade. The target application program is written to the internal storage of the microcontroller and verified, after the verification passes, the target application program is run. The target boot program is written to the storage area of the external storage module and verified, after the verification passes, the code of the target boot program is loaded to the internal storage of the microcontroller for running, without occupying too much internal storage resource of the microcontroller, and the upgrade of the boot program only involves the erasing and writing operation of the external storage, thereby significantly reducing the risk of internal storage abnormality or damage caused by data erasing and writing operation.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, and in particular to a firmware upgrade method based on storage and operation separation, a microcontroller, an embedded system, and a storage medium. Background Technology

[0002] In the booming field of embedded industrial control, many devices require multiple modules to work together, each with its own independent firmware. Currently, program upgrade methods in embedded systems mainly fall into two categories: updates via bootloader and software upgrades via application programs. However, these methods also have some drawbacks. For example, updating the bootloader itself is dangerous, as a failed update may damage the device and cannot be repaired remotely, requiring factory repair. Furthermore, for application program upgrades, the microcontroller unit (MCU) internal memory is typically divided into two partitions: one for storing upgrade status, reset flags, jump flags, etc., and the other for storing application code data. However, this approach requires twice the internal Flash storage space, resulting in wasted storage resources. Frequent erasing and writing of internal memory can easily lead to accidental erasure and the reaching of the internal memory's lifespan limit, increasing the risk of internal memory damage. Summary of the Invention

[0003] One objective of this application is to provide a firmware upgrade method, microcontroller, embedded system, and storage medium based on the separation of storage and operation, aiming to improve the situation in related technologies where firmware upgrades cause waste of storage resources and increase the risk of internal storage damage.

[0004] In a first aspect, embodiments of this application provide a firmware upgrade method based on storage and operation separation, applied to a microcontroller in an embedded system. The embedded system further includes an external storage module, which is communicatively connected to the microcontroller. The external storage module includes a first storage area and a first backup area. The first storage area stores a reference bootloader. The microcontroller includes an internal storage module, which stores a fixed bootloader and a reference application. The firmware upgrade method includes: receiving firmware upgrade data and storing the firmware upgrade data to the external storage module. The firmware upgrade data includes a target application and / or a target bootloader. The method performs the following first upgrade operations: in response to a successful first verification operation of the target application, writing the reference application to the external storage module, wherein the first verification operation includes verifying the correctness of the target application version and verifying the integrity of the target application in the external storage module; writing the target application from the external storage module to the internal storage module; and in response to a successful second verification operation of the target application, generating... A first success flag is displayed, and a second verification operation verifies the integrity of the target application in the internal storage module. The first success flag indicates that the reference application has been successfully upgraded. Upon restarting, the target application in the internal storage module is run using the fixed bootloader after detecting the first success flag. And / or, the following second upgrade operation is performed: Upon passing a third verification operation on the target bootloader, the reference bootloader is written to the first backup area. The third verification operation includes verifying the correctness of the target bootloader version and verifying the integrity of the target bootloader in the external storage module. The target bootloader in the external storage module is written to the first storage area. Upon passing a fourth verification operation on the target bootloader, a second success flag is generated. The fourth verification operation verifies the integrity of the target bootloader in the first storage area. The second success flag indicates that the reference bootloader has been successfully upgraded. Upon restarting, the code of the target bootloader in the first storage area is loaded into the internal storage module for execution using the fixed bootloader.

[0005] In some embodiments, the internal storage module includes a first running area and a second running area, with the fixed startup program and the reference application running in the first running area and the second running area, respectively. The external storage module further includes a firmware cache area and a second backup area. Storing firmware upgrade data to the external storage module includes: storing the firmware upgrade data in the firmware cache area. Writing the reference application to the external storage module includes: writing the reference application to the second backup area. Writing the target application in the external storage module to the internal storage module includes: writing the target application in the firmware cache area to the second running area. Running the target application in the internal storage module includes: running the target application in the second running area.

[0006] In some embodiments, the internal storage module further includes a third running area. Writing the target bootloader from the external storage module to the first storage area includes: writing the target bootloader from the firmware cache area to the first storage area; loading the code of the target bootloader in the first storage area to the internal storage module for execution includes: reading the code of the target bootloader in the first storage area; and loading the code of the target bootloader into the third running area for execution.

[0007] In some embodiments, the method further includes: in response to a first verification operation or a second verification operation failing, determining that the reference application upgrade has failed, and recording the number of times the reference application upgrade has failed; in response to a reference application upgrade failure number being greater than a first preset failure number and less than or equal to a second preset failure number, performing the following first rollback operation: writing the reference application in the second backup area to the second running area; in response to a first reference operation of the reference application passing, generating a first reference flag, the first reference operation being an operation to verify the integrity of the reference application in the second running area, the first reference flag being used to indicate that the reference application rollback is successful; in response to the first reference flag being detected by a fixed startup program after a restart, running the reference application in the second running area; and in response to a reference application upgrade failure number being greater than a second preset failure number, generating a first upgrade flag.

[0008] In some embodiments, the method further includes: storing the target application in a firmware cache in response to detecting a first upgrade flag; performing the following third upgrade operation: writing the target application in the firmware cache to a second runtime area in response to passing a fifth verification operation of the target application, wherein the fifth verification operation includes verifying the correctness of the version of the target application and verifying the integrity of the target application in the firmware cache; generating a first success flag in response to passing a sixth verification operation of the target application, wherein the sixth verification operation is verifying the integrity of the target application in the second runtime area; and running the target application in the second runtime area in response to detecting the first success flag using a fixed bootloader after a reboot.

[0009] In some embodiments, the method further includes: in response to a third verification operation or a fourth verification operation failing, determining that the reference bootloader upgrade has failed, and recording the number of times the reference bootloader upgrade has failed; in response to a reference bootloader upgrade failure count being greater than a third preset failure count and less than or equal to a fourth preset failure count, performing the following second rollback operation: writing the reference bootloader in the first backup area to the first storage area; in response to a second reference operation of the reference bootloader passing, generating a second reference flag, the second reference operation being an operation to verify the integrity of the reference bootloader in the first storage area, the second reference flag being used to indicate that the reference bootloader rollback is successful; in response to the second reference flag being detected by the fixed bootloader after a restart, loading the code of the reference bootloader in the first storage area to the third runtime area for execution; and in response to a reference bootloader upgrade failure count being greater than a fourth preset failure count, generating a second upgrade flag.

[0010] In some embodiments, the method further includes: storing the target bootloader in a firmware cache in response to detecting a second upgrade flag; performing the following fourth upgrade operation: writing the target bootloader in the firmware cache to a first storage area in response to passing a seventh verification operation of the target bootloader, the seventh verification operation including verifying the correctness of the version of the target bootloader and verifying the integrity of the target bootloader in the firmware cache; generating a second success flag in response to passing an eighth verification operation of the target bootloader, the eighth verification operation being an operation to verify the integrity of the target bootloader in the first storage area; and loading the code of the target bootloader in the first storage area to a third runtime area for execution in response to detecting the second success flag using a fixed bootloader after a reboot.

[0011] In some embodiments, the method further includes: performing a repair operation on a reference application in response to detecting a third upgrade flag, the third upgrade flag being used to characterize an anomaly in the code of the reference application.

[0012] In a second aspect, embodiments of this application provide a microcontroller, including a processor and an internal storage module. The processor is communicatively connected to the internal storage module, which stores computer program instructions, a fixed startup program, and a reference application. The processor executes the computer program instructions to cause the microcontroller to perform the firmware upgrade method based on storage and operation separation provided in the first aspect.

[0013] In a third aspect, embodiments of this application provide an embedded system including an external storage module and a microcontroller provided in the second aspect, wherein the external storage module is communicatively connected to the microcontroller.

[0014] In a fourth aspect, embodiments of this application provide a computer-readable storage medium storing processor-executable computer program instructions, which, when executed by a processor, cause the processor to perform the firmware upgrade method based on storage and execution separation provided in the first aspect.

[0015] The embodiments of this application have the following beneficial effects: Unlike related technologies, the embodiments of this application store firmware upgrade data to an external storage module, without occupying the internal storage space of the microcontroller. After the target application / target bootloader passes verification, a normally functioning reference application / reference bootloader is written to the external storage module for backup. This allows for rapid rollback in case of firmware upgrade failure, improving the reliability of firmware upgrades. For application upgrades, the target application is written to the microcontroller's internal storage and verified. After verification, the target application is run. For bootloader upgrades, the target bootloader is written to the storage area of ​​the external storage module and verified. After verification, the target bootloader's code is loaded into the microcontroller's internal storage for execution. This achieves separation of storage and execution, without occupying the microcontroller's internal storage resources, saving internal storage resources, maximizing the utilization of internal storage resources, and the bootloader upgrade only involves external storage erase / write operations, reducing internal storage data erase / write operations and significantly reducing the risk of internal storage abnormalities or damage. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of this application and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of the firmware upgrade method based on storage and operation separation provided in some embodiments of this application; Figure 2 These are schematic diagrams of the microcontroller structure provided in some embodiments of this application; Figure 3 This is a schematic diagram of the structure of an embedded system provided in some embodiments of this application. Figure 1 ; Figure 4A This is a flowchart illustrating a firmware upgrade method based on storage and operation separation provided in some embodiments of this application; Figure 4B This is a schematic diagram illustrating the process of upgrading an application in some embodiments of this application; Figure 4C This is a schematic diagram of the process of upgrading the bootloader in some embodiments of this application; Figure 4D This is a schematic diagram of the structure of an embedded system provided in some embodiments of this application. Figure 2 . Detailed Implementation

[0018] To make the objectives and advantages of the embodiments of this application more readily understood, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The detailed description of the embodiments of this application in the accompanying drawings is not intended to limit the scope of protection claimed by this application, but only represents selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of this application described below can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0020] Unless otherwise defined, the technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. It should be understood that the term "and / or" as used in this specification includes any and all combinations of one or more of the listed items.

[0021] Currently, mainstream OTA upgrade solutions for embedded systems have at least the following drawbacks: 1) The bootloader (i.e., the bootloader / bootloader) cannot be upgraded. In traditional upgrade solutions, the bootloader is embedded inside the MCU. Once there is a design flaw or security vulnerability, it cannot be repaired remotely. When the bootloader verification logic has a problem, the system will fail to start normally, resulting in a "bricked" system; 2) The power-down protection mechanism is lacking. The probability of firmware corruption due to power failure during the upgrade process is as high as 15-20%. The unfinished firmware cannot be rolled back to a usable state, resulting in low reliability of firmware upgrades; 3) A single FLASH... h) Dependency risk: When bad blocks appear in the internal Flash, the traditional solution cannot continue to perform firmware upgrades; 4) Low resource utilization: The traditional solution divides the internal Flash into two storage partitions, one for storing status data and the other for storing code data, requiring twice the internal Flash storage space, resulting in a waste of storage resources; 5) Frequent Flash erasure: There is a risk of accidental erasure and Flash erase / write lifespan risk. Status data such as upgrade status, reset flag, and jump flag are stored in the internal Flash. Frequent erasure and write of the internal Flash can easily lead to accidental erasure and the internal Flash reaching its lifespan limit, increasing the risk of damage to the internal Flash.

[0022] In view of this, this application provides a firmware upgrade method based on storage and execution separation. Firmware upgrade data is stored in an external storage module, without occupying the microcontroller's internal storage space. After the target application / bootstrap passes verification, a normally functioning reference application / bootstrap is written to the external storage module for backup. This allows for rapid rollback in case of firmware upgrade failure, improving the reliability of the firmware upgrade. For application upgrades, the target application is written to the microcontroller's internal storage and verified. After successful verification, the target application is run. For bootstrap upgrades, the target bootstrap is written to the storage area of ​​the external storage module and verified. After successful verification, the target bootstrap's code is loaded into the microcontroller's internal storage and run. This achieves storage and execution separation, without occupying the microcontroller's internal storage resources, saving internal storage resources and maximizing their utilization. Furthermore, bootstrap upgrades only involve external storage write operations, reducing internal storage write operations and significantly lowering the risk of internal storage anomalies or damage.

[0023] Please refer to the following: Figure 1 and Figure 3 , Figure 1 The illustration shows application scenarios of the firmware upgrade method based on storage and operation separation provided in some embodiments of this application. Figure 3 The schematic diagram illustrates the structure of an embedded system provided in some embodiments of this application.

[0024] The embedded system 1000 includes a microcontroller 100 and an external storage module 200, which is connected to the microcontroller 100 via a network. The external storage module 200 includes a first storage area 210 and a first backup area 220.

[0025] The first storage area 210 stores a reference bootloader, which is the bootloader that runs normally in the embedded system 1000, such as the normally running bootloader A (abbreviated as Boot A). The reference bootloader is an upgradable bootloader that supports remote updates and upgrades.

[0026] The microcontroller 100 includes a processor 110 and an internal storage module 120, which stores a fixed bootloader and a reference application. The fixed bootloader, acting as a hardware-level root of trust, is never updated and cannot be erased, ensuring minimal basic recovery capabilities. Even in the worst-case scenario, the system or device has an unalterable recovery startup point. The fixed bootloader is the first step in system startup and forms the basis for any upgrades or program execution. The fixed bootloader is a non-upgradeable bootloader, such as a non-upgradeable bootloader. The reference application is an application that runs normally in the embedded system 1000, such as a running application A (Application A, abbreviated as App A). ​​The reference application is an upgradeable application that supports remote updates. The processor 110 is configured to execute the firmware upgrade method based on storage and execution separation provided in the embodiments of the following application.

[0027] See Figure 1 As shown, the host computer 300 sends firmware upgrade data to the embedded system 1000 via a network. In this embodiment, the firmware upgrade data is received and stored in the external storage module 200. For example, in some embodiments, the firmware upgrade data is stored in the temporary firmware storage area of ​​the external storage module 200. It is understood that... Figure 1 This illustration is merely schematic, showing that the embedded system 1000 is a laptop computer and the host computer 300 includes a smartphone 301, a server 302, or any other suitable type of device or apparatus. It does not impose any limitation on the structure, type, or number of embedded systems or host computers in other embodiments.

[0028] The firmware upgrade data includes the target application and / or the target bootloader. After receiving and storing the firmware upgrade data, this embodiment verifies the target application. If the first verification operation of the target application passes, a reference application is written to the external storage module for backup. The first verification operation includes verifying the correctness of the target application version and verifying the integrity of the target application in the external storage module. Next, the target application in the external storage module is written to the internal storage module, and the target application is verified. If the second verification operation of the target application passes, a first success flag is generated. The second verification operation verifies the integrity of the target application in the internal storage module, and the first success flag indicates that the reference application has been successfully upgraded. After writing the complete target application to the internal storage module, the embedded system is restarted. After the embedded system restarts, if the first success flag is detected using the fixed bootloader, it indicates that the reference application has been successfully upgraded to the target application, and the target application in the internal storage module is run.

[0029] Or, in this embodiment, the target bootloader is verified. If the third verification operation of the target bootloader passes, a reference bootloader is written to the first backup area to back up the reference bootloader. The third verification operation includes verifying the correctness of the target bootloader version and verifying the integrity of the target bootloader in the external storage module. Next, the target bootloader in the external storage module is written to the first storage area, and the target bootloader is verified. If the fourth verification operation of the target bootloader passes, a second success flag is generated. The fourth verification operation verifies the integrity of the target bootloader in the first storage area, and the second success flag indicates that the reference bootloader has been successfully upgraded. For example, after writing the complete target bootloader to the first storage area, the embedded system is restarted. After the embedded system restarts, if the second success flag is detected using the fixed bootloader, it indicates that the reference bootloader has been successfully upgraded to the target bootloader, and the code of the target bootloader in the first storage area is loaded into the internal storage module for execution.

[0030] By employing the above methods, program storage and execution are separated, minimizing the use of the microcontroller's internal storage resources, conserving internal storage capacity, maximizing the utilization of internal storage resources, and reducing internal storage data write / erase operations during bootloader upgrades. This significantly lowers the risk of internal storage anomalies or corruption. Furthermore, it allows for rapid rollback in case of firmware upgrade failure, improving the reliability of firmware upgrades.

[0031] To understand the firmware upgrade method based on storage and operation separation provided in the embodiments of this application, the microcontroller provided in the embodiments of this application will be described in detail first.

[0032] Please see Figure 2 , Figure 2 The schematic diagram illustrates the structure of a microcontroller provided in some embodiments of this application.

[0033] See Figure 2 As shown, the microcontroller 100 includes at least one processor 110 and at least one internal storage module 120 connected in communication, wherein, Figure 2 Taking a bus system 130, a processor 110, and an internal storage module 120 as an example, the various components of the microcontroller 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include, in addition to the data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 2 The various buses are all labeled as Bus System 130. Understandably, Figure 2 The structures shown in the embodiments are merely illustrative and do not limit the structure of the microcontroller described above. For example, the microcontroller may also include... Figure 2 The structure shown has more or fewer components, or has the same as Figure 2 The diagram shows different configurations of the structure.

[0034] Specifically, the processor 110 provides computational and control capabilities to support the microcontroller 100 in executing corresponding business logic and functions. For example, it supports the microcontroller 100 in executing the firmware upgrade method based on storage and operation separation provided in this application embodiment, or in executing steps in any possible implementation of the firmware upgrade method based on storage and operation separation provided in this application embodiment. It is understood that the processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or it can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0035] The internal storage module 120 serves as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the firmware upgrade method based on storage and execution separation in the embodiments of this application. The internal storage module 120 is also used to store the fixed boot program and reference application program in the embodiments of this application. In some embodiments, the internal storage module 120 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, and the data storage area may store data created according to the use of the processor 110. The processor 110 executes various functional applications and data processing of the microcontroller 100 by running the non-transitory software programs, instructions, and modules stored in the internal storage module 120, thereby implementing the firmware upgrade method based on storage and execution separation provided in the embodiments of this application, or executing the steps in any possible implementation of the firmware upgrade method based on storage and execution separation provided in the embodiments of this application. In some embodiments, the internal storage module 120 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the internal storage module 120 may further include memory remotely configured relative to the processor 110, which can be connected to the processor 110 via a communication network. It is understood that examples of such communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0036] As can be understood from the above, the firmware upgrade method based on storage and operation separation provided in this application embodiment can be implemented by any suitable type of microcontroller with certain computing and control capabilities, such as the microcontroller 100 of the embedded system 1000 described above. In some feasible implementations, the firmware upgrade method based on storage and operation separation provided in this application embodiment can be implemented by the processor executing computer program instructions stored in the memory.

[0037] The following describes in detail the firmware upgrade method based on storage and operation separation provided in this application embodiment, with reference to exemplary applications and implementations of the embedded system provided in the embodiments of this application.

[0038] It is understood that the firmware upgrade method based on storage and operation separation provided in this application embodiment can be applied to the aforementioned microcontroller (such as microcontroller 100). Specifically, the execution entity of the firmware upgrade method based on storage and operation separation is one or at least two processors of the microcontroller.

[0039] Please see Figure 4AAs shown, the firmware upgrade method based on storage and operation separation provided in this application includes steps S41 and S42, and / or steps S41 and S43, to achieve firmware upgrade.

[0040] Step S41: Receive firmware upgrade data and store the firmware upgrade data to the external storage module.

[0041] In this embodiment, the firmware upgrade data includes the target application and / or the target bootloader. That is, when the firmware upgrade data includes the target application, the reference application is updated to the target application; when the firmware upgrade data includes the target bootloader, the reference bootloader is updated to the target bootloader; and when the firmware upgrade data includes both the target application and the target bootloader, the reference application is updated to the target application and the reference bootloader is updated to the target bootloader.

[0042] For example, the embedded system communicates with a host computer via a network, and the host computer sends firmware upgrade data to the embedded system via the network. This application embodiment receives the firmware upgrade data and stores it in an external storage module. For instance, in some embodiments, the firmware upgrade data is stored in the firmware temporary storage area of ​​the external storage module.

[0043] Step S42: Perform the following first upgrade operation: In response to the first verification operation of the target application passing, write the reference application to the external storage module; write the target application in the external storage module to the internal storage module; in response to the second verification operation of the target application passing, generate a first success flag; in response to the detection of the first success flag by the fixed startup program after restarting, run the target application in the internal storage module.

[0044] The first verification operation includes verifying the correctness of the target application version and verifying the integrity of the target application in the external storage module. It can be understood that the first verification operation passes when both the verification of the target application version's correctness and the verification of the target application's integrity in the external storage module are successful. Verifying the correctness of the target application version means verifying whether the target application version is the first target version to be upgraded. If yes, the target application version is correct, and the verification operation passes; otherwise, the target application version is incorrect, and the verification operation fails. The second verification operation verifies the integrity of the target application in the internal storage module. The first success flag indicates that the reference application upgrade was successful.

[0045] For example, see Figure 4BAs shown, in this embodiment, the target application 21 in the external storage module 200 is subjected to operations to verify the correctness of the version of the target application 21 and operations to verify the integrity of the target application 21 (i.e., a first verification operation). If the first verification operation of the target application 21 passes, the reference application 11 in the internal storage module 120 is written to the external storage module 200 to back up the reference application 11. Then, the target application 21 in the external storage module 200 is written to the internal storage module 120. Next, a second verification operation to verify the integrity of the target application 21 is performed on the target application 21 in the internal storage module 120. If the second verification operation of the target application 21 passes, a first success flag is generated.

[0046] After writing the complete target application 21 to the internal storage module 120 and generating the first success flag, the embedded system is restarted. After the embedded system restarts, if the first success flag is detected using the fixed boot program, it indicates that the reference application 11 has been successfully upgraded to the target application 21, and the target application 21 in the internal storage module 120 is run.

[0047] Step S43: Perform the following second upgrade operation: In response to the passing of the third verification operation of the target bootloader, write the reference bootloader to the first backup area; write the target bootloader in the external storage module to the first storage area; In response to the passing of the fourth verification operation of the target bootloader, generate a second success flag; In response to the detection of the second success flag by the fixed bootloader after reboot, load the code of the target bootloader in the first storage area into the internal storage module for execution.

[0048] The third verification operation includes verifying the correctness of the target bootloader version and the integrity of the target bootloader in the external storage module. It can be understood that the third verification operation passes when both the verification of the target bootloader version's correctness and the verification of the target bootloader's integrity in the external storage module are successful. Verifying the correctness of the target bootloader version means verifying whether the target bootloader version is the second target version to be upgraded. If yes, the target bootloader version is correct, and the verification operation passes; otherwise, the target bootloader version is incorrect, and the verification operation fails. The fourth verification operation verifies the integrity of the target bootloader in the first storage area. The second success flag is used to indicate that the reference bootloader upgrade was successful.

[0049] For example, see Figure 4CAs shown, in this embodiment of the application, the target bootloader 22 of the external storage module 200 is subjected to operations for verifying the correctness of the version of the target bootloader 22 and operations for verifying the integrity of the target bootloader 22 (i.e., a third verification operation). If the third verification operation of the target bootloader 22 passes, the reference bootloader 12 in the first storage area 210 is written to the first backup area 220 to back up the reference bootloader 12. Then, the target bootloader 22 in the external storage module 200 is written to the first storage area 210. Next, a fourth verification operation for verifying the integrity of the target bootloader 22 is performed on the target bootloader 22 in the first storage area 210. If the fourth verification operation of the target bootloader 22 passes, a second success flag is generated.

[0050] After writing the complete target bootloader 22 to the first storage area 210 and generating the second success flag, the embedded system is restarted. After the embedded system restarts, if the second success flag is detected using the fixed bootloader, it indicates that the reference bootloader 12 has been successfully upgraded to the target bootloader 22, and the code of the target bootloader 22 in the first storage area 210 is loaded into the internal storage module 120 for execution.

[0051] It is understandable that, to address reliability issues during the writing of large-capacity firmware, this embodiment employs a block-based writing mechanism. Data is divided into blocks, such as 4KB blocks, and each block is written. Therefore, during the execution of the first, second, third, or fourth verification operation, each data block can be verified immediately after writing, thus improving verification speed. Specifically, when a data block verification fails, the erroneous data block is marked and the error / abnormality is recorded. This confirms that the first, second, third, or fourth verification operation failed, generates a corresponding status flag / status identifier, and updates the firmware upgrade status.

[0052] It is easy to understand that when performing integrity verification on a target application or target bootloader, any suitable verification algorithm can be used, such as any one or a combination of algorithms such as SHA-256, ECDSA, and CRC32.

[0053] This application embodiment receives and stores firmware upgrade data to an external storage module without occupying the microcontroller's internal storage space. After the target application / target bootloader passes verification, a normally functioning reference application / reference bootloader is written to the external storage module for backup. This allows for rapid rollback in case of firmware upgrade failure, improving the reliability of firmware upgrades. For application upgrades, the target application is written to the microcontroller's internal storage and verified. After successful verification, the target application runs. For bootloader upgrades, the target bootloader is written to the external storage module's storage area and verified. After successful verification, the target bootloader's code is loaded into the microcontroller's internal storage for execution. This separation of storage and execution avoids occupying the microcontroller's internal storage resources, conserving internal storage resources and maximizing their utilization. Furthermore, bootloader upgrades only involve external storage write / erase operations, reducing internal storage write / erase operations and significantly lowering the risk of internal storage anomalies or damage.

[0054] Please see Figure 4D In some embodiments, the internal storage module 120 includes a first running area 121 and a second running area 122, with the fixed startup program and the reference application running in the first running area 121 and the second running area 122, respectively; that is, the fixed startup program runs in the first running area 121 and the reference application runs in the second running area 122. The external storage module 200 also includes a firmware cache area 230 and a second backup area 240.

[0055] In some embodiments, storing firmware upgrade data to external storage module 200 includes storing firmware upgrade data to firmware cache 230, that is, storing target application and / or target bootloader to firmware cache 230.

[0056] Writing the reference application to the external storage module 200 includes: writing the reference application of the internal storage module 120 to the second backup area 240, that is, writing the reference application running in the second running area 122 of the internal storage module 120 to the second backup area 240.

[0057] Writing the target application from the external storage module 200 to the internal storage module 120 includes: writing the target application from the firmware cache 230 to the second running area 122, that is, writing the target application stored in the firmware cache 230 of the external storage module 200 to the second running area 122 of the internal storage module 120.

[0058] Running the target application in the internal storage module 120 includes running the target application in the second running area 122, that is, running the target application written to the second running area 122 in the internal storage module 120.

[0059] Please refer to it again. Figure 4D In some embodiments, the internal storage module 120 further includes a third running area 120.

[0060] In some embodiments, writing the target bootloader in the external storage module 200 to the first storage area 210 includes: writing the target bootloader in the firmware cache area 230 to the first storage area 210, that is, writing the target bootloader stored in the firmware cache area 230 of the external storage module 200 to the first storage area 210 of the external storage module 200.

[0061] In some embodiments, loading the code of the target boot program in the first storage area 210 into the internal storage module 120 for execution includes: reading the code of the target boot program stored in the first storage area 210 and loading the code of the target boot program into the third execution area 123 for execution.

[0062] In some embodiments, the third running area 120 refers to RAM (Random-Access Memory), a volatile memory used to temporarily store data and program instructions. In this embodiment, it is used to temporarily store the code of the target boot program, thereby enabling the target boot program to run.

[0063] It's understandable that while the target bootloader is stored in the first storage area of ​​the external storage module, its code needs to be loaded into RAM for execution during actual runtime (separation of storage and execution). Therefore, the target bootloader's code needs to be linked to a RAM address. This way, after the target bootloader's code is copied from the first storage area of ​​the external storage module to RAM using a fixed bootloader, the microcontroller's central processing unit (CPU) can directly jump to the address in RAM for execution. The linker file defines the layout of the target bootloader's code in RAM, including the vector table, code segment, and data segment.

[0064] In some embodiments, the linked file is shown in the following code example.

[0065] LR_IROM1 0x20000000 0x0010000{;load region size_region ER_IROM1 0x20000000 0x0010000{;load address = execution address .o (RESET, +First) (InRoot$$Sections) .ANY (+RO) ANY(+XO) } RW_IRAM1 0x20010200 0x0007000{;RW data .ANY (+RW +ZI) } RESET_VAR Ox0017FCO UNINIT 0x40{ : class b inverted variables .ANY (RESET_SAVE_REGION) } } In this context, LR_IROM1 refers to the name of the loading region of the target bootloader in RAM (i.e., the third execution area), 0x20000000 refers to the starting address of the target bootloader stored in RAM, and 0x0010000 refers to the size of the RAM space allocated for the target bootloader's code. ER_IROM1 refers to the name of the execution region of the target bootloader's code in RAM, and RW_IRAM10x20010200 0x0007000 refers to the starting address and size of the read / write data area.

[0066] The specific loading and execution method of the target bootloader is as follows: when compiling the target bootloader, a linker file is used. In this way, the target file address of the generated target bootloader is based on RAM. The fixed bootloader loads and executes the code of the target bootloader according to the target file address.

[0067] In some implementations, the firmware upgrade method based on storage and operation separation provided in this application further includes steps S51 to S53.

[0068] Step S51: If the first verification operation or the second verification operation fails, determine that the reference application upgrade has failed, and record the number of times the reference application upgrade has failed.

[0069] Each time the first or second verification operation fails, it corresponds to one failure in the upgrade of the reference application. The total number of failed upgrades for the reference application is then calculated by summing up the total number of failed upgrades for the reference application.

[0070] Step S52: In response to the number of failures in upgrading the reference application being greater than the first preset failure number and less than or equal to the second preset failure number, perform the following first rollback operation: write the reference application in the second backup area to the second running area; in response to the first reference operation of the reference application passing, generate a first reference flag; in response to the first reference flag being detected by the fixed startup program after restarting, run the reference application in the second running area.

[0071] In this embodiment, the first reference operation is to verify the integrity of the reference application in the second runtime area. It is understood that any suitable verification algorithm can be used when performing integrity verification on the reference application, such as any one or a combination of algorithms like SHA-256, ECDSA, and CRC32. The first reference flag is used to indicate that the reference application has been successfully rolled back.

[0072] It should be understood that engineers can customize the first preset number of failures and the second preset number of failures based on experimental data and experience data, etc., and the embodiments of this application do not impose any specific limitations on this. The first preset number of failures is less than the second preset number of failures. For example, in some embodiments, the first preset number of failures is set to 5 times, and the second preset number of failures is set to twice the first preset number of failures (i.e., the second preset number of failures is 10 times).

[0073] For example, when the number of times the reference application upgrade fails is greater than a first preset failure number and less than or equal to a second preset failure number, the following first rollback operation is performed: the reference application stored in the second backup area of ​​the external storage module is written to the second running area of ​​the internal storage module; an integrity verification operation (i.e., a first reference operation) is performed on the reference application in the second running area; if the first reference operation passes, a first reference flag is generated; after writing the complete reference application to the second running area of ​​the internal storage module and generating the first reference flag, the embedded system is restarted; after the embedded system restarts, if the first reference flag is detected by the fixed boot program, it indicates that the reference application has been successfully rolled back, and the reference application in the second running area of ​​the internal storage module is run.

[0074] Step S53: If the number of times the reference application upgrade fails is greater than the second preset number of failures, generate a first upgrade flag.

[0075] For example, when the number of times the reference application upgrade fails exceeds a second preset number of failures, a first upgrade flag is generated. The first upgrade flag is used to trigger a switch to the bootloader upgrade path.

[0076] It is understandable that the bootloader upgrade path refers to the path of upgrading applications using the bootloader. That is, when the fixed bootloader detects the first upgrade flag, it jumps to the reference bootloader and uses the reference bootloader to perform the operation of upgrading the reference application.

[0077] In some implementations, the firmware upgrade method based on storage and operation separation provided in this application further includes steps S61 to S62.

[0078] Step S61: In response to the detection of the first upgrade flag, the target application is stored in the firmware cache.

[0079] Step S62: Perform the following third upgrade operation: In response to the fifth verification operation of the target application passing, write the target application in the firmware cache to the second running area; in response to the sixth verification operation of the target application passing, generate a first success flag; in response to the detection of the first success flag by the fixed boot program after reboot, run the target application in the second running area.

[0080] In this embodiment, the fifth verification operation includes verifying the correctness of the target application version and verifying the integrity of the target application in the firmware cache. It can be understood that the fifth verification operation passes when both the verification of the target application version and the verification of the integrity of the target application in the firmware cache pass. The sixth verification operation verifies the integrity of the target application in the second runtime area.

[0081] For example, when the fixed bootloader detects the first upgrade flag, it jumps to the reference bootloader to perform the upgrade of the reference application. Specifically, the target application is stored in the firmware cache, and operations to verify the correctness of the target application version and the integrity of the target application (i.e., the fifth verification operation) are performed on the target application in the firmware cache. If the fifth verification operation of the target application passes, the target application in the firmware cache is written to the second running area of ​​the internal storage module. Then, a sixth verification operation to verify the integrity of the target application is performed on the target application in the second running area of ​​the internal storage module. If the sixth verification operation of the target application passes, a first success flag is generated.

[0082] After writing the complete target application to the second runtime area of ​​the internal storage module and generating the first success flag, the embedded system is restarted. After the embedded system restarts, if the first success flag is detected using the fixed bootloader, it indicates that the reference application has been successfully upgraded to the target application, and the target application in the second runtime area of ​​the internal storage module is then run.

[0083] In some implementations, the firmware upgrade method based on storage and operation separation provided in this application further includes steps S71 to S73.

[0084] Step S71: If the third or fourth verification operation fails, determine that the reference bootloader upgrade has failed, and record the number of times the reference bootloader upgrade has failed.

[0085] Each time the third or fourth verification operation fails, the reference bootloader upgrade fails once. The total number of failed upgrades for the reference bootloader is then calculated by summing these counts.

[0086] Step S72: In response to the number of failures of the reference bootloader upgrade being greater than the third preset failure number and less than or equal to the fourth preset failure number, perform the following second rollback operation: write the reference bootloader in the first backup area to the first storage area; in response to the second reference operation of the reference bootloader being passed, generate a second reference flag; in response to the second reference flag being detected by the fixed bootloader after restart, load the code of the reference bootloader in the first storage area to the third runtime area for execution.

[0087] In this embodiment, the second reference operation is to verify the integrity of the reference bootloader in the first storage area. It is understood that any suitable verification algorithm can be used when performing integrity verification on the reference bootloader, such as any one or a combination of algorithms like SHA-256, ECDSA, and CRC32. The second reference flag is used to indicate that the reference bootloader has been successfully rolled back.

[0088] It should be understood that engineers can customize the third and fourth preset failure counts based on experimental and empirical data, and this application embodiment does not impose any specific limitations on this. The third preset failure count is less than the fourth preset failure count. For example, in some embodiments, the third preset failure count is set to 5 times, and the fourth preset failure count is set to twice the third preset failure count (i.e., the fourth preset failure count is 10 times).

[0089] For example, when the number of failed upgrade attempts of the reference bootloader is greater than the third preset failure number and less than or equal to the fourth preset failure number, the following second rollback operation is performed: the reference bootloader stored in the first backup area is written to the first storage area, and an integrity verification operation (i.e., the second reference operation) is performed on the reference bootloader in the first storage area; if the second reference operation passes, a second reference flag is generated; after writing the complete reference bootloader to the first storage area and generating the second reference flag, the embedded system is restarted; after the embedded system restarts, if the second reference flag is detected by the fixed bootloader, it indicates that the reference bootloader rollback is successful, the code of the reference bootloader in the first storage area is read, and the code of the reference bootloader is loaded into the third runtime area for execution.

[0090] Step S73: If the number of upgrade failures of the reference bootloader is greater than the fourth preset number of failures, generate a second upgrade flag.

[0091] For example, when the number of failed upgrade attempts by the reference bootloader exceeds a fourth preset number of failures, a second upgrade flag is generated. This second upgrade flag is used to trigger a switch to the application upgrade path.

[0092] It is understandable that the application upgrade path refers to the path of using the application to upgrade the bootloader. That is, when the fixed bootloader detects the second upgrade flag, it jumps to the reference application and uses the reference application to perform the operation of upgrading the reference bootloader.

[0093] In some implementations, the firmware upgrade method based on storage and operation separation provided in this application further includes steps S81 to S82.

[0094] Step S81: In response to the detection of the second upgrade flag, the target bootloader is stored in the firmware cache.

[0095] Step S82: Perform the following fourth upgrade operation: In response to the seventh verification operation of the target bootloader passing, write the target bootloader in the firmware cache area to the first storage area; In response to the eighth verification operation of the target bootloader passing, generate a second success flag; In response to the second success flag being detected by the fixed bootloader after reboot, load the code of the target bootloader in the first storage area to the third runtime area for execution.

[0096] In this embodiment, the seventh verification operation includes verifying the correctness of the target bootloader version and verifying the integrity of the target bootloader in the firmware cache. It can be understood that the seventh verification operation passes when both the verification of the target bootloader version and the verification of the integrity of the target bootloader in the firmware cache pass. The eighth verification operation verifies the integrity of the target bootloader in the first storage area.

[0097] For example, when the fixed bootloader detects the second upgrade flag, it jumps to the reference application to perform the upgrade of the reference bootloader. Specifically, the target bootloader is stored in the firmware cache, and operations to verify the correctness of the target bootloader version and the integrity of the target bootloader (i.e., the seventh verification operation) are performed on the target bootloader in the firmware cache. If the seventh verification operation of the target bootloader passes, the target bootloader in the firmware cache is written to the first storage area. Then, an eighth verification operation to verify the integrity of the target bootloader is performed on the target bootloader in the first storage area. If the eighth verification operation of the target bootloader passes, a second success flag is generated.

[0098] After writing the complete target bootloader to the first storage area and generating the second success flag, the embedded system is restarted. After the embedded system restarts, if the second success flag is detected using the fixed bootloader, it indicates that the reference bootloader has been successfully upgraded to the target bootloader. The code of the target bootloader in the first storage area is read and loaded into the third runtime area of ​​the internal storage module for execution.

[0099] In some implementations, the firmware upgrade method based on storage and operation separation provided in this application also includes step SA1.

[0100] Step SA1: In response to the detection of a third upgrade flag, perform a repair operation on the reference application.

[0101] In this embodiment, the third upgrade flag is used to indicate that there is an anomaly in the code of the reference application.

[0102] For example, when a third upgrade flag is detected, embodiments of this application utilize a reference bootstrap to perform a repair operation on a reference application to repair the code of the reference application.

[0103] Please refer to it again. Figure 4D In some embodiments, the external storage module 200 further includes a status flag area 250 and a log area 260. The embodiments of this application define multiple firmware upgrade states to ensure that in the event of a power outage or failure, the old version can be accurately restored or the new version can be directly copied and run.

[0104] In some embodiments, the flags / identifiers and descriptions of various firmware upgrade states are shown in Table 1 below.

[0105] Table 1:

[0106] During the firmware upgrade process, the status flags / status identifiers are saved to the status flag area 250. By reading the status flags / status identifiers in the status flag area 250, the upgrade status can be determined in real time.

[0107] Log area 260 is configured to store the embedded system's runtime logs, which record information such as system debugging, upgrade operations, real-time data, fault records, and performance statistics.

[0108] In summary, the embodiments of this application have at least the following beneficial effects.

[0109] 1. The fixed bootloader acts as a hardware-level root of trust, ensuring a minimum level of recovery and boot capability for the embedded system. The reference bootloader supports remote updates and upgrades, resolving the problem of boot failure due to a single bootloader (such as the bootloader) malfunction in traditional solutions.

[0110] 2. Save status flags / identifiers to external storage modules to ensure traceability of upgrade operations. Compared with traditional solutions, this reduces or avoids frequent erasure and writing of internal storage modules, greatly reducing the risk of internal storage modules being erased and damaged, and extending their service life.

[0111] 3. External storage modules, acting as an extension, store the bootloader's executable files (i.e., code) and backup application and bootloader upgrade files. Compared to the microcontroller's internal storage module, this saves over 50% of internal storage space. Internal storage modules for microcontrollers are expensive; doubling their capacity increases the price by 70%-100%. Using external storage modules to store and back up the bootloader and application reduces hardware costs. Furthermore, even if the external storage module fails, the application in the internal storage module can still run normally and report errors. With only a small increase in hardware costs, system software reliability is significantly improved.

[0112] 4. Using the "upgrade-verification-backup" workflow, the new version upgrade data is first received and verified. After the integrity and executability of the upgrade data are verified, the old version of the program that is running normally in the internal storage module is saved as backup data to the backup area. Compared with the traditional solution of directly writing to the backup area or directly copying to the backup area without upgrade verification, the program code in the backup area of ​​this application embodiment is more reliable, ensuring that the code in the backup area is definitely executable code and supports perfect rollback.

[0113] 5. The bootloader code is stored in the external storage module and is loaded as data into the RAM of the internal storage module for execution. This does not consume internal storage module resources, maximizing the utilization of the internal storage module. Furthermore, bootloader upgrades only involve data erasure and write operations on the external storage module, reducing the risk of anomalies or corruption caused by erasing data in the internal storage module and enhancing system reliability.

[0114] This application provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the processor to perform the firmware upgrade method based on storage and operation separation provided in this application, or to perform the steps in any possible implementation of the firmware upgrade method based on storage and operation separation provided in this application.

[0115] Those skilled in the art will understand that the embodiments provided in this application are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0116] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, and of course, it can also be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, CD-ROM, random access memory (RAM), read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0117] It should be noted that the above embodiments are for illustrating the technical concept and features of this application, and are intended to enable those skilled in the art to understand the content of this application and implement it accordingly. They should not be construed as limiting the scope of protection of this application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, modified according to the technical solutions described in the embodiments of this application, or equivalent substitutions can be made to some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should be considered as equivalent changes and modifications made based on the embodiments of this application, all of which should fall within the scope of the claims of this application.

Claims

1. A firmware upgrade method based on storage and operation separation, characterized in that, A microcontroller is used in an embedded system, the embedded system further including an external storage module, the external storage module being communicatively connected to the microcontroller, the external storage module including a first storage area and a first backup area, the first storage area storing a reference boot program, the microcontroller including an internal storage module, the internal storage module storing a fixed boot program and a reference application program, the firmware upgrade method including: Receive firmware upgrade data and store the firmware upgrade data to the external storage module. The firmware upgrade data includes the target application and / or the target bootloader. Perform the following first upgrade operation: In response to the first verification operation of the target application passing, the reference application is written to the external storage module, wherein the first verification operation includes operations to verify the correctness of the version of the target application and operations to verify the integrity of the target application in the external storage module; Write the target application from the external storage module to the internal storage module; In response to the successful completion of the second verification operation of the target application, a first success flag is generated. The second verification operation is an operation to verify the integrity of the target application in the internal storage module. The first success flag is used to indicate that the reference application has been successfully upgraded. Upon restarting, if the first success flag is detected using the fixed startup program, the target application in the internal storage module is run. And / or, perform the following second upgrade operation: In response to the successful completion of the third verification operation of the target bootloader, the reference bootloader is written to the first backup area. The third verification operation includes verifying the correctness of the version of the target bootloader and verifying the integrity of the target bootloader in the external storage module. Write the target boot program from the external storage module to the first storage area; In response to the successful completion of the fourth verification operation of the target bootloader, a second success flag is generated. The fourth verification operation is an operation to verify the integrity of the target bootloader in the first storage area. The second success flag is used to indicate that the reference bootloader upgrade was successful. Upon restarting, if the second success flag is detected using the fixed bootloader, the code of the target bootloader in the first storage area is loaded into the internal storage module for execution.

2. The firmware upgrade method according to claim 1, characterized in that, The internal storage module includes a first running area and a second running area, and the fixed startup program and the reference application program run in the first running area and the second running area respectively. The external storage module also includes a firmware cache area and a second backup area. The step of storing the firmware upgrade data to the external storage module includes: storing the firmware upgrade data in the firmware cache area; The step of writing the reference application to the external storage module includes: writing the reference application to the second backup area; The step of writing the target application in the external storage module to the internal storage module includes: writing the target application in the firmware cache area to the second running area; Running the target application in the internal storage module includes running the target application in the second running area.

3. The firmware upgrade method according to claim 2, characterized in that, The internal storage module further includes a third runtime area, and the step of writing the target boot program from the external storage module to the first storage area includes: Write the target bootloader from the firmware cache into the first storage area; Loading the target bootloader code from the first storage area into the internal storage module for execution includes: Read the code of the target bootloader from the first storage area; The code of the target bootloader is loaded into the third runtime area and executed.

4. The firmware upgrade method according to claim 3, characterized in that, The method further includes: If either the first verification operation or the second verification operation fails, it is determined that the reference application upgrade has failed, and the number of times the reference application upgrade has failed is recorded. If the number of upgrade failures of the reference application is greater than a first preset failure number and less than or equal to a second preset failure number, the following first rollback operation is performed: Write the reference application from the second backup area to the second running area; In response to the first reference operation of the reference application being passed, a first reference flag is generated. The first reference operation is an operation to verify the integrity of the reference application in the second runtime area. The first reference flag is used to indicate that the reference application has been successfully rolled back. Upon restarting, if the first reference flag is detected using the fixed startup program, the reference application in the second runtime area is run. If the number of times the reference application upgrade fails exceeds the second preset number of failures, a first upgrade flag is generated.

5. The firmware upgrade method according to claim 4, characterized in that, The method further includes: In response to detecting the first upgrade flag, the target application is stored in the firmware cache. Perform the following third upgrade operation: In response to the successful completion of the fifth verification operation of the target application, the target application in the firmware cache is written to the second runtime area. The fifth verification operation includes verifying the correctness of the version of the target application and verifying the integrity of the target application in the firmware cache. In response to the successful completion of the sixth verification operation of the target application, a first success flag is generated, wherein the sixth verification operation is an operation to verify the integrity of the target application in the second runtime area; Upon restarting, if the first success flag is detected using the fixed startup program, the target application in the second runtime area is run.

6. The firmware upgrade method according to claim 3, characterized in that, The method further includes: If the third verification operation or the fourth verification operation fails, it is determined that the reference bootloader upgrade has failed, and the number of times the reference bootloader upgrade has failed is recorded; If the number of upgrade failures of the reference bootloader is greater than the third preset failure number and less than or equal to the fourth preset failure number, the following second rollback operation is performed: Write the reference bootloader in the first backup area to the first storage area; In response to the successful completion of the second reference operation of the reference bootstrap, a second reference flag is generated. The second reference operation is an operation to verify the integrity of the reference bootstrap in the first storage area. The second reference flag is used to indicate that the reference bootstrap has been successfully rolled back. Upon restarting, if the second reference flag is detected using the fixed boot program, the code of the reference boot program in the first storage area is loaded into the third runtime area for execution. If the number of times the reference bootloader upgrade fails exceeds the fourth preset number of failures, a second upgrade flag is generated.

7. The firmware upgrade method according to claim 6, characterized in that, The method further includes: In response to the detection of the second upgrade flag, the target bootloader is stored in the firmware cache. Perform the following fourth upgrade operation: In response to the passing of the seventh verification operation of the target bootloader, the target bootloader in the firmware cache is written to the first storage area. The seventh verification operation includes verifying the correctness of the version of the target bootloader and verifying the integrity of the target bootloader in the firmware cache. In response to the successful completion of the eighth verification operation of the target bootloader, a second success flag is generated, wherein the eighth verification operation is an operation to verify the integrity of the target bootloader in the first storage area; Upon restarting, if the second success flag is detected using the fixed bootloader, the code of the target bootloader in the first storage area is loaded into the third runtime area for execution.

8. The firmware upgrade method according to any one of claims 1-7, characterized in that, The method further includes: In response to the detection of a third upgrade flag, a repair operation is performed on the reference application, the third upgrade flag being used to indicate that there is an anomaly in the code of the reference application.

9. A microcontroller, characterized in that, The device includes a processor and an internal storage module. The processor is communicatively connected to the internal storage module, which stores computer program instructions, a fixed boot program, and a reference application program. The processor executes the computer program instructions to cause the microcontroller to perform the firmware upgrade method based on the separation of storage and operation as described in any one of claims 1-8.

10. An embedded system, characterized in that, It includes an external storage module and a microcontroller as described in claim 9, wherein the external storage module is communicatively connected to the microcontroller.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable computer program instructions, which, when executed by the processor, cause the processor to perform the firmware upgrade method based on storage and execution separation as described in any one of claims 1-8.

Images