CN117908916A

CN117908916A - STM 32-based method for upgrading IAP by improving Bootloader

Info

Publication number: CN117908916A
Application number: CN202311696308.XA
Authority: CN
Inventors: 曹晋
Original assignee: Shanghai Rongyimai Medical And Health Technology Co ltd
Current assignee: Shanghai Rongyimai Medical And Health Technology Co ltd
Priority date: 2023-12-11
Filing date: 2023-12-11
Publication date: 2024-04-19

Abstract

The application provides a method for upgrading IAP (integrated access point) by improving Bootloader based on STM32, which belongs to the technical field of information processing, and creates an execution region field in RAM (random access memory) to realize the running of a program, wherein the execution region field is operation_context which is respectively defined in the same address of the same. Bss. Noinit field by Bootloader and Application, and related parameters stored when the Bootloader and the Application skip each other are not initialized; the configuration information of the operation_context comprises firmware startup, firmware upgrading and firmware abnormality, and when the configuration information is located in the information, the configuration information is judged to be the initial startup, and the configuration information of the operation_context is set to be the firmware startup. The method solves the problem that Bootloader bootstrap program occupies too much resources, can reduce the read-write times of Flash, and prolongs the service life of Flash.

Description

STM 32-based method for upgrading IAP by improving Bootloader

Technical Field

The invention relates to a method for upgrading IAP by improving Bootloader based on STM32, and belongs to the technical field of information processing.

Background

In the existing Bootloader technology, the technical scheme generally adopted is as follows:

1. The firmware upgrade in Applicatio n is completed by creating a configuration information area in Flas h, and when the jump to Bootloader is completed after the upgrade, the storage of relevant information is carried out;

2. The jump to Bootloader to effect the upgrade when the firmware upgrade is triggered Applicatio n is achieved by integrating the upgrade code of the IAP or OTA in Bootloade r.

The prior art has the defects that:

1. In the scheme of creating the configuration information area Flas h, the minimum unit of the partition of Flas h is a sector, the size of the sector in STM 32 is usually 1KByte s or the configuration information area 2KByte s,Bootloade r does not need such a large space, which results in space waste, the minimum unit of the erasure of Flas h is a sector, if other data is stored in the configuration information area, the other data are erased together when the configuration information of Bootlaode r is modified, the other data need to be read, erased and rewritten, the speed of flash for sector erasure is relatively slow, and the performance of the whole system upgrade is reduced;

2. In the upgrade code scheme of integrated IAP or OTA in Bootloade r, the code of the IA P or OTA upgrade needs to be completed when Bootloade r is developed, and the mode of modifying the application program upgrade after the product release needs to modify not only Applicatio n but also Bootloade r synchronously, and meanwhile, the Bootloader occupies a large part of the storage space of the application program due to the code of the IA P or OTA upgrade.

The market needs to reduce or not need to rewrite or modify bootloader when upgrading the system or firmware, only need to read related instructions, thus not only ensuring that the system can be updated in time, but also not frequently refreshing or modifying bootloader to restart the system, so that the system reduces the rewrite loss of FLASH, prolongs the service life, and always maintains a pure and stable guiding system.

Taking medical EIT (electrical impedance tomography) equipment as an example, the EIT and CT have similar functions, can realize the imaging of the lung, but for CT, a patient must be transported to a CT room, the EIT can dynamically and continuously display the region with the changed lung function,

The device is relatively flexible, can be placed at the bedside of a patient, and can be used for binding the electrode plate on the chest of the patient, so that imaging of the lung can be completed at any time, the continuity and stability of power supply of EIT equipment are required to be maintained, and the equipment cannot be restarted because hardware is required to be upgraded.

Disclosure of Invention

In view of the foregoing deficiencies of the prior art, it is an object of the present invention to provide a method for upgrading IAP based on an improved Bootloader of STM 32.

According to an embodiment of the present invention, there is provided:

A method for upgrading IAP based on improved Bootloader of STM32, comprising,

An execution region field is created in RAM to enable execution of the program,

The execution region field is operation_context and is defined by Bootloader and Application respectively;

The operation_context is respectively defined by Bootloader and Application in the same address of the same. Bss. NoInit field, and related parameters stored when the Bootloader and Application skip each other are not initialized;

The configuration information of the operation_context may be firmware start, firmware upgrade, or firmware abnormality, and when the configuration information is not the above information, it is determined that the operation_context is started for the first time, and the configuration information of the operation_context is set as firmware start.

Further, when the operation_context is judged to be a firmware starting mode, the operation is skipped to the Application program partition for execution;

after the IAP or OTA upgrade is carried out by the device Application, the configuration information of the operation_context is adjusted to be in a firmware upgrade mode, and the device is restarted;

The Bootloader performs CRC check on the firmware in the downloaded partition through the configuration information of the operation_context, if the check fails, the failure of upgrading the application firmware at the time is judged, the configuration information of the operation_context is directly modified to enable the application program of the last time to be normally started in a starting mode, if the check succeeds, the application firmware partition is cleared, new firmware in the downloaded partition is copied into the application partition, and the operation_context is set to be the firmware starting mode to trigger restarting;

An irrecoverable error occurs in the operation of Application firmware, at the moment, application sets operation_context as firmware exception and then triggers restarting, bootloader can restore the operation of factory firmware after receiving operation_context as firmware exception and then restarts, and the normal operation state of equipment is ensured.

Further, the condition judgment priority of the firmware start is higher than the priority of the initialization of the Bootloader related driver, so that the running environment is prevented from being damaged after the jump to Application.

The further optimization scheme is that Application firmware partitions are classified, application modules of different functional components are stored in a partitioning mode,

And storing addresses and file information of application modules of different functional component partitions and download partitions in the application firmware partition in a factory reset partition in module information, and sequentially storing contents of each partition in a module sector1 and a module sector2 … ….

Further, the execution region field further comprises a module_Context, the module_Context field is defined in the module_information by a Bootloader, basic function initialization of the device is performed first after the Bootloader is started, then configuration Information module_Context in the module_information is read, and CRC integrity check is performed on each Module to ensure that the Module is not tampered or damaged;

The verified modules are loaded into the application program in a dynamic loading mode, and each different application module forms a complete application program;

In the normal running process of the program, if a module needs to be upgraded by IAP or OTA, the Bootloader firstly uninstalls the module, then backups the double-Bank partition, then upgrades the module by IAP or OTA, and after the upgrade is finished, the module is dynamically loaded into the application program.

The storage medium comprises an internal Flash and an external storage medium, wherein the internal Flash is mainly used for storing Bootloader and core service Application and factor, the external Flash is used for storing Application components of the service and information of Download, the Application components are stored in an ELF file format, the Download is IAP or OTA upgrading and downloading partition is also arranged in the external Flash, the ELF file format is also used for storing, when the Bootloader is started, the external Flash is firstly hung in a file system, and all Application components stored in the current external Flash can be obtained through the file system;

The Bootloader acquires all component information supported by the current application program by retrieving all files in the current file management system, and completes operation through an internally set function instruction;

Component information of the ELF file is obtained by the bl load module function and loaded into the RAM of the device,

All function pointers for the component are obtained by the bl _ enumerate _ module function,

The component is offloaded from RAM by bl _ unlock _ module,

The components are upgraded and backed up by bl_upgrade_module.

Further, when the device receives an IAP or OTA request of the application component, the Bootloader firstly stores the new application component into the external Flash through the file system, and verifies the digital signature and the integrity verification of the application component;

If the verification fails, judging whether the IAP or OTA fails to delete the application component, checking whether the application component is in operation after the verification is successful, if so, unloading the component, and then modifying the file name of the component into backup for backup;

if the backup exists, the new application component is covered, and the new application component is loaded from the new application component and operated, so that the seamless switching of the application component is realized, and the dynamic upgrading is realized;

When the device application component has serious errors and cannot work normally during running, the Bootloader is responsible for unloading the application component to ensure normal work of other functions, checking whether a backup file of the component exists in a file system, if the backup file exists, rolling back the application component, and reloading the application component and running after the rolling back is finished.

Compared with the prior art, the technical scheme provided by the application has the advantage of independent right.

1. The problem that the Bootloade r boot program occupies too much resources, the efficiency is low because the configuration information is partitioned for each upgrade, and the firmware upgrade mode is very flexible to replace, and only the Applicatio n program is required to be modified.

2. The loading framework of the application program module is realized at Bootloade r, and the loading framework comprises a loader and a manager, and is used for processing functions of loading, unloading, upgrading and the like of the application program module. The Bootloade r states a unified module interface that includes functions of function invocation, parameter delivery, and creates a partition of module information for storing all current module configuration information. The function of carrying out IAP or O TA by dynamically loading, running and unloading the application program in the form of a functional module is realized, the function of verifying the integrity of the module, error processing and a rollback mechanism are also included, and when a serious error occurs in a certain functional module, the rollback operation of the module is carried out, and the module is restored to a safe state.

3. Different functional components of Applicatio n are divided, so that only the functional components to be upgraded can be upgraded and backed up, the whole Applicatio n is not required to be erased and rewritten, the reading and writing times are greatly reduced, and the service life of Flash is further prolonged.

4. Meanwhile, as different functional components of application are divided, when the updated component exceeds the space occupied by the original component, the updated component can be marked by module information and written into a module sector supported by the space size, the original occupied space is marked as available space, and the next updated backup is called, so that the space utilization rate is improved.

5. The file system is introduced, so that a good solution is provided for the storage address, backup and size change of the application component, when the file is backed up, only the file name of the current application component is marked, frequent read-write operation of Flash is not involved, when the file is covered, only the file data to be covered is marked as a deleted state, the file system can release the storage space and mark the storage space as an erasable area, and the storage position is required to be used next time; the problems of insufficient space or space waste and the like caused by frequent reading and writing of Flash and change of the size of an application component are greatly avoided. The downloaded upgrade files are also stored in the file system, so that backup of the upgrade files is formed, and meanwhile, the space of flash is not occupied.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Wherein:

FIG. 1 is a schematic diagram of a partition of an internal Flash memory of STM32 in one embodiment;

FIG. 2 is a flowchart of a boot process for implementing Bootloader and a backup process for upgrading firmware;

FIG. 3 is a second partition diagram of an internal Flash memory of STM32 in one embodiment;

FIG. 4 is a boot flow of a Bootloader and an upgrade backup flow for Application different functional components, according to one embodiment;

FIG. 5 is a schematic diagram of a partition of an ELF file storage area in one embodiment;

FIG. 6 is a flow chart of upgrading and backing up information of an application component and download of an external Flash storage service of one embodiment.

Detailed Description

In order that those skilled in the art will better understand the technical solutions of the present application, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The technical terms used in the application are as follows:

bootstrap (Bootloader): a boot program before starting execution of the application program.

Application (Application): project application.

Application upgrade (In Application Programming, IAP): and updating and upgrading the firmware program in the product through the reserved communication interface.

Over-the-Air Technology (OTA): remote application program upgrading of the terminal product is realized through a network or wireless communication technology.

Flash memory (Flas h): is a form of electronically erasable programmable read-only memory that allows memory to be erased or written multiple times during operation for storing boot and application programs.

An ELF file (Executable and Linkable Format, ELF) defines the structure of the executable file, library file, and core file. This format allows the operating system to correctly interpret the machine instructions in the file; the ELF file is in binary format output by a compiler or linker. Such documents may be better analyzed and understood using appropriate tools.

The technical scheme of the application is mainly applied to products with high flexibility and high expansibility of equipment. For example, in a power management product applied to EIT equipment, the EIT equipment and the EIT power management equipment are connected through a communication interface, and the IA P upgrading operation can be performed on the EIT power management equipment in the upper computer software of the EIT equipment, so that the functions of Applicatio n firmware IAP upgrading, checking, copying, monitoring and the like are realized with extremely low resource occupation based on Bootloade r realized by the application. The method realizes the function of online upgrade of the application program component, does not influence the working state of the current component in the upgrade of the application component, has higher use value for medical products and the like, and can bring higher system stability and continuous service availability and a more flexible function updating mechanism.

Example 1

As shown in FIG. 1, the internal Flas h storage area of STM 32 is shown to be partitioned, first Bootloade r partition with a starting address of 0x0800000 0, representing the system starting execution by Bootloade r at system power-up or reset, partition sizes from 0x0800000 0 to 0x0800080 0 with size 2KByte s,Factor y being factory-reset partition for system, applicatio n being application firmware partition, downloa d being IAP or OTA upgrade download partition, the sizes of the three being dependent on the specific size of the application program and the embedded model selected.

According to the technical scheme, a execution regio n (execution area) field is created in the RA M to realize that a variable existing in the field can not be initialized in the running process of a program, so that the variable stored by the bypass NoIni t can not be initialized when the program jumps between Bootloade r and Applicatio n, meanwhile, operations such as firmware storage, upgrading, checking and factory setting recovery are only carried out at Bootloade r, and the IA P or OTA upgrading is completed by Applicatio n, so that the problems that the Bootloade r boot program occupies too much resources, the efficiency is lower because the partition operation of configuration information is required for each upgrading are solved, and the method is very flexible when a firmware upgrading mode is replaced, and only the application program is required to be modified.

The relevant data is saved when the Bootloader and the Application jump, so that the Flash is prevented from being frequently erased, the Bootloader is responsible for checking firmware in a download partition after the IAP or OTA upgrading is finished and upgrading the firmware into an Application partition, meanwhile, a factory partition is reserved for reserving factory firmware, factory setting can be restored after upgrading failure, system upgrading functions can be flexibly realized in the Application instead of being limited to a default interface in factory, meanwhile, the size of the Bootloader is greatly reduced, more space is reserved for an Application program, and the current Bootloader only occupies 2KBytes under the gcc compiler-o 3 optimization level.

The Bootloader of this scheme has a start-up flow as shown in fig. 2 below.

The operation_context is respectively defined by Bootloader and Application in the same address of the same. Bss. NoInit field, related parameters stored when the Bootloader and Application jump mutually are not initialized, and meanwhile, the condition judgment priority of firmware start is higher than the priority of Bootloader related drive initialization, so that the running environment is prevented from being damaged after jumping to Application.

When the device runs for the first time, the configuration information of the operation_context is not any configuration of firmware start, firmware upgrade and firmware abnormality, so that the program can judge that the device is started for the first time, the initialization configuration of the operation_context can be modified into a firmware start mode, the device is restarted, and at the moment, the judgment of the operation_context is carried out again, the operation_context is judged to be in a firmware start mode, and the operation Application program is jumped to partition execution.

After the IAP or OTA upgrade is performed by the device Application, the configuration information of the operation_context is adjusted to be in a firmware upgrade mode, the device is restarted, the Bootloader performs CRC (cyclic redundancy check) on the firmware in the downloaded partition through the configuration information of the operation_context, if the verification fails, the failure of the upgrade of the Application firmware is judged, the configuration information of the operation_context is directly modified to be the last Application program normally started in a starting mode, if the verification succeeds, the Application firmware partition is cleared, new firmware in the downloaded partition is copied to the Application partition, and the operation_context is set to be the firmware starting mode to trigger the restarting.

Irrecoverable errors, such as segment errors or hardware errors, occur in the operation of Application firmware, at this time, application will set operation_context as firmware exception and then trigger restarting, and Bootloader will perform operations of restoring factory firmware after receiving operation_context as firmware exception and then restart, so as to ensure the normal operation state of equipment.

It should be noted that, the present solution provides a Bootloader commonly used by STM32, and IAP or OTA upgraded Bootloader support can be added to a product quickly only by modifying corresponding internal Flash partition tables according to different models, meanwhile, because the RAM is used to store configuration information of firmware upgrade, the write-in times of Flash are saved, and the service life of Flash is prolonged. Meanwhile, firmware upgrading is realized in Application and is not limited to a default interface in factory, so that the flexibility of the system is improved. The extremely low system resource occupation of Bootloader releases more Flash space for Application, which is particularly important for embedded systems with limited resources.

Example two

In order to further reduce the erasing times of flash in firmware upgrading, the invention provides a loading framework of an application program module in a Bootloader, which is used for processing functions of loading, unloading, upgrading and the like of the application module. The Bootloader declares a unified module interface, which contains functions of function calling and parameter transferring, and creates a partition of module information for storing all current module configuration information. The function of carrying out IAP or OTA by dynamically loading, running and unloading the application program in the form of a functional module is realized, and meanwhile, the function of verifying the integrity of the module, error processing and a rollback mechanism are also included, when a serious error occurs in a certain functional module, the rollback operation of the module is carried out, and the module is restored to a safe state.

In the technical scheme of this embodiment, the partitions of the internal Flash storage area of the STM32 are shown in fig. 3 as follows:

Classifying applications, and storing different functional components in a partition mode, wherein the functions are set as APP1, APP2 and … …;

And (3) restoring the factory setting partition by using the factor y, wherein addresses and file information of downloading partitions of different functional components APP 1, APP 2, … … and Downloa d in the Applicatio n application firmware partition are stored in module informatio n, and contents of the partitions are sequentially stored in a module sector1 and a module sector2 … ….

The Bootloader startup flow is shown in fig. 4 as follows:

The execution regio n field also includes Module_Contex, which is defined by Bootloade r in Module_ Informatio n, after Bootloade r the basic functions of the device are initialized, then the configuration information Module_Contex in Module_ Informatio n is read, and after each CRC integrity check is performed, it is ensured that the module is not tampered or damaged,

The verified modules are loaded into the application program in a dynamic loading mode, and each different application module forms a complete application program.

In the normal running process of the program, if a module needs to be upgraded by IAP or OTA, the Bootloader firstly uninstalls the module, then backups the double-Bank partition, then upgrades the module by IAP or OTA, and after the upgrade is finished, the module is dynamically loaded into the application program. Backup of dual Bank partitions is an effective technique to prevent backup loss or corruption.

It should be noted that, according to the scheme, on the basis of embodiment 1, different functional components of Application are divided, so that only the functional components to be upgraded can be upgraded and backed up, the whole Application is not required to be erased and rewritten, the reading and writing times are greatly reduced, and the service life of Flash is further prolonged.

Meanwhile, as different functional components of application are divided, when the updated component exceeds the space occupied by the original component, the updated component can be marked by module information and written into a module sector supported by the space size, the original occupied space is marked as available space, and the updated component is called in the next updating backup.

Example III

In the technical scheme of the embodiment, the partition diagram of the ELF file storage area is shown in fig. 5.

The storage medium includes an internal part Flas h and an external storage medium, the internal part Flas h is mainly used for storing Bootloade r and core services Applicatio n and Factor y, the external part Flas h is used for storing information of application components and downloa d of the services, the application components are stored in an EL F file format, the downloading partition of Downloa d for IA P or OTA is also arranged at the external part Flas h, the EL F file format is also used for storing, when Bootloade r is started, the external part Flas h is firstly hung in a file system at the same time, and all application components stored in the current external part Flas h can be obtained through the file system. The ELF header contains information such as header offset, entry address, etc.

The following will only describe the upgrade backup operation performed by each application component stored in the file management system in the format of the E LF file, where the steps and the flow of the upgrade backup in the internal Flash are consistent with those of the second embodiment, and will not be described again.

The startup procedure of Bootloade r and the information of the application component and downloa d of the external Flas h storage service of the present scheme are updated and backed up as shown in fig. 6

The dynamic loading, unloading and upgrading functions of different functional components of Applicatio n are realized through Bootloade r by an application component dynamic management framework matched with a file management system. Each application component is stored in the file management system in the format of an E LF file, bootloade r obtains all component information supported by the current application by retrieving all files in the current file management system,

The component is offloaded from RAM via bl _ unlock _ module and the occupied RAM resources are released,

The components are upgraded and backed up by bl _ upgrade _ module,

All function pointers in the component are remapped into the RAM of the device by the bl_remap_module function.

It should be noted that, each application component is stored in the file management system in the format of an E LF file, and the present invention also supports other storage media such as SD cards and EMMc by taking external Flash as an example.

When the device receives an IAP or OTA request of an application component, the Bootloader firstly stores the new application component into an external Flash through a file system, verifies the digital signature and integrity verification of the application component, judges that the IAP or OTA fails to delete the application component if the verification fails, checks whether the application component is in operation or not after the verification is successful, firstly uninstalls the component if the application component is in operation, and then modifies the file name of the component into backup; and if the backup exists, the backup is used for covering, and a new application component is loaded from the new application component and operated, so that seamless switching and dynamic upgrading of the application component are realized.

There is no need to manage the memory address of the old firmware and the memory address of the new firmware.

Bootloader is completed through an internally set function instruction;

The bl_load_module function is used for analyzing the ELF file header to obtain the basic information such as the file type, the offset address of the interrupt vector table and the like. The node position can be found through the node table offset to obtain the layout and information of each node.

The bl_remap_ moudle function is used to reposition (locate) bits and link application components and to obtain function entries and offset address tables for all functions by reading the repositioned information contained in the section in the ELF file. And repositioning the symbols of the application component when the application component is loaded so as to ensure normal operation in the process of dynamically loading the application program, acquiring the address of the designated entry point in the file header, acquiring the address offset table of all the current functions by executing the entry function, and remapping the address offset table for normal use of the application program.

The bl_load_module function is used to release the relevant information defined by bl_load_module and bl_remap_ moudle and stop all calls to the application component in the current application.

The bl_upgrade_module function is used for upgrading the application component, and after receiving an upgrade request of the application component IAP or OTA, the upgrade file is saved in the file system. And after the application component receives the data, the digital signature and the integrity check of the application component are carried out.

All function pointers for the component are obtained by the bl_ enumerate _module function.

It should be noted that, because the file system is introduced, a good solution is provided for the storage address, backup and size change of the application component, when the file is backed up, only the file name of the current application component is marked, frequent read-write operation of Flash is not involved, when the file is covered, only the file data to be covered is marked as a deleted state, the file system releases the storage space, and the storage space is marked as an erasable area, and the storage position is required to be used next time; the problems of insufficient space or space waste and the like caused by frequent reading and writing of Flash and change of the size of an application component are greatly avoided. The downloaded upgrade files are also stored in the file system, so that backup of the upgrade files is formed, and meanwhile, the space of flash is not occupied.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims

1. A method for upgrading IAP by improving Bootloader based on STM32 is characterized in that,

An execution region field is created in RAM to enable execution of the program,

The operation_context is defined by Bootloader and Application respectively at the same. Bss.

In the same address of NoInit fields, related parameters stored when Bootloader and Application jump to each other are not initialized;

2. The method of upgrading an IAP based on an STM32 modified Bootloader of claim 1,

When the operation_context is judged to be a firmware starting mode, jumping to an Application program partition for execution;

3. The method of performing IAP upgrades based on the modified Bootloader of STM32 of claim 2,

The condition judgment priority of firmware start is higher than the priority of Bootloader related driver initialization, so that the running environment is prevented from being destroyed after the jump to Application.

4. The method of upgrading an IAP based on an STM32 modified Bootloader of claim 1,

Classifying Application firmware partitions, storing Application modules of different functional components in partition,

5. The method of upgrading an IAP based on an STM32 modified Bootloader of claim 4,

The execution region field also comprises a Module_Context, the Module_Context field is defined in Module_information by a Bootloader, basic function initialization of equipment is performed first after the Bootloader is started, then configuration Information Module_Context in the Module_information is read, and CRC integrity check is performed on each Module, so that the Module is ensured not to be tampered or damaged;

6. The method of performing IAP upgrades based on the modified Bootloader of STM32 of claim 4, comprising:

The storage medium comprises an inner part Flas h and an outer storage medium, wherein the inner part Flas h is mainly used for storing Bootloade r and core services Applicatio n and Factor y, the outer part Flas h is used for storing information of application components and downloa d of the services, the application components are stored in an EL F file format, downloa d is an IA P or OTA upgrading and downloading partition and is also arranged on the outer part Flas h, the EL F file format is also used for storing, when Bootloade r is started, the outer part Flas h is firstly hung in a file system at the same time, and all application components stored in the current external Flash can be obtained through the file system;

The component is offloaded from RAM by bl _ unlock _ module,

The components are upgraded and backed up by bl_upgrade_module.

7. The method of IAP upgrades based on an improved Bootloader of STM32 of claim 6, comprising:

When the device receives an IAP or OTA request of an application component, the Bootloader firstly stores the new application component into an external Flash through a file system, and verifies the digital signature and integrity check of the application component;