Firmware upgrading method and device based on MCU platform

Abstract

The invention relates to the field of embedded technologies, and provides a firmware upgrading method and device based on an MCU platform. The method comprises the following steps: determining a running area based on a preset guide strategy, and running original firmware in the running area; when a firmware downloading command is received, storing the target firmware corresponding to the upgrading in the non-running area; when a pilot run command is received, address ranges of the running area and the non-running area are exchanged, so that the running area is configured as a new non-running area, and the non-running area is configured as a new running area to run the target firmware; when a submission command is received, the operation value corresponding to the new operation area is modified, so that the modified operation value is larger than the operation value corresponding to the old operation area, it is guaranteed that the firmware can normally jump to the new operation area after being upgraded, the firmware upgrading process is greatly simplified, and the firmware upgrading efficiency is improved. The problem that firmware versions in the A area and the B area in the module cannot be mutually independent is solved.

Description

Technical Field

[0001] This invention relates to the field of embedded technology, and in particular to a firmware upgrade method and apparatus based on an MCU platform. Background Technology

[0002] Optical modules are currently used extensively in the optical communication industry. The diverse functions of optical modules make their maintainability increasingly important. Therefore, firmware development for optical modules must consider firmware upgrades.

[0003] For optical modules based on a Micro Controller Unit (MCU) platform, traditional solutions involve upgrading the MCU firmware using a bootloader. In this traditional dual-zone upgrade scheme, the MCU's Flash memory is divided into two independent zones (Zone A and Zone B). When the bootloader is running in the Flash memory zone, it reassigns interrupt vector tables to enable jumps between Zone A and Zone B within the Flash memory, and backs up the required firmware version by copying. Since the firmware is compiled and can only jump between zones using a fixed jump address, the firmware stored in Zone A and Zone B must be the same version.

[0004] However, in most practical application scenarios, comparative testing is usually required between two firmware versions for ease of testing. If Area A and Area B cannot be backed up independently, that is, if the firmware version stored in Area A and the firmware version stored in Area B are interdependent, then during the comparative testing process, each time the firmware version in Area A is upgraded, the firmware version in Area B must also be upgraded, and each time the firmware version in Area B is upgraded, the firmware version in Area A must also be upgraded. This consumes too much time, resulting in poor practicality of the upgrade scheme. Therefore, the traditional scheme does not meet the actual application requirements of optical modules.

[0005] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide a firmware upgrade method and apparatus based on an MCU platform. This invention adopts an address range swapping method to flip the address mapping of two storage spaces, thereby allowing the storage spaces to take turns as the running area to achieve switching between the running area and the non-running area. The running area is used to store the currently running original firmware, and the non-running area is used to receive the target firmware required for subsequent upgrades. Therefore, the firmware in the two storage spaces does not affect each other, achieving the goal of independent firmware versions in the two storage spaces. Furthermore, the running value corresponding to the new running area is greater than the running value corresponding to the old running area to complete the firmware upgrade. This ensures that the module can jump back to the running area before the power failure after power loss, greatly simplifying the firmware upgrade process.

[0007] The present invention adopts the following technical solution:

[0008] In a first aspect, the present invention provides a firmware upgrade method based on an MCU platform, comprising:

[0009] The operating area is determined based on a preset boot strategy, and the original firmware within the operating area is run.

[0010] When a firmware download command is received, the target firmware corresponding to this upgrade is stored in the non-running area;

[0011] When a trial run command is received, the address ranges of the running area and the non-running area are swapped, so that the running area is configured as the new non-running area and the non-running area is configured as the new running area to run the target firmware;

[0012] When a submission command is received, the running value corresponding to the new running area is modified so that the modified running value is greater than the running value corresponding to the old running area.

[0013] Furthermore, the module's memory includes a first storage space and a second storage space. The first storage space stores a first running value and a first verification value, and the second storage space stores a second running value and a second verification value. The first storage space and the second storage space are configured alternately as a running area or a non-running area.

[0014] The module is equipped with a cutting area identifier, which is used to indicate whether a cutting area operation can be performed.

[0015] The firmware upgrade method based on the MCU platform also includes:

[0016] When the trial run command is received, if the partition identifier is 1, then the partition identifier is set to 0, and the address range swap is performed again.

[0017] Furthermore, the step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes:

[0018] Start the module, obtain the first running value and the second running value. If the first running value and the second running value are not both factory default values, initialize the first storage space as the running area, and determine whether the partitioning identifier is 1.

[0019] If the partition identifier is 0, then the partition identifier is set to 1, and the original firmware in the running area is run; if the partition identifier is 1, then it is determined whether the second running value is greater than the first running value.

[0020] If the second running value is greater than the first running value and the second verification value is 0, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area.

[0021] If the second running value is less than the first running value or the second verification value is not 0, then the first storage space is still used as the running area and the second storage space is used as the non-running area.

[0022] Furthermore, the step of determining the running area based on a preset boot strategy and running the original firmware within the running area also includes:

[0023] Start the module, set the first verification value to 0, and obtain the first running value and the second running value;

[0024] If both the first running value and the second running value are factory default values, then the first running value is set to 1 and the second running value is set to 0, so that the first storage space is configured as the running area and the second storage space is configured as the non-running area; and the partition identifier is set to 1 to complete the factory default settings.

[0025] Furthermore, the step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes:

[0026] Modify the hardware pins corresponding to the module to configure the startup position of the MCU of the module to the starting address of the MCU's boot program;

[0027] Reset the MCU, start running the boot program from the boot position, set the first verification value to 0, and obtain the first running value and the second running value;

[0028] If the first running value is greater than the second running value, then the first storage space is initialized as the running area, and the second storage space is initialized as the non-running area;

[0029] If the second running value is greater than the first running value, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area.

[0030] Furthermore, the step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes:

[0031] The first boot program is stored at the starting address of the first storage space, and the second boot program is stored at the starting address of the second storage space.

[0032] The MCU of the module is reset, and the first boot program is started from the starting address of the first storage space. The first verification value is set to 0, and the first running value and the second running value are obtained.

[0033] If the first running value is greater than the second running value, then the first storage space is initialized as the running area, and the second storage space is initialized as the non-running area; and the reset vector address in the interrupt vector table of the MCU is set to the starting address of the application in the running area, so as to jump to the running application in the running area according to the reset vector address;

[0034] If the second running value is greater than the first running value, the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area; the second boot program starts running from the starting address of the second storage space to jump to the application running in the running area.

[0035] Further, before modifying the running value corresponding to the new running area to make the modified running value greater than the running value corresponding to the old running area when the submission command is received, the process includes:

[0036] The target firmware was tested, and the test results were obtained.

[0037] If the test results are problematic, the address ranges of the new running area and the new non-running area are swapped again to switch the address ranges back; or, the MCU of the module is reset.

[0038] If the test results are satisfactory, send a submit command.

[0039] Furthermore, the step of storing the target firmware corresponding to this upgrade to the non-running area when a firmware download command is received includes:

[0040] When a firmware download command is received, and the firmware version in the running area is consistent with the firmware version in the non-running area, the original firmware in the non-running area is erased to ensure that the non-running area can receive the target firmware normally.

[0041] When a verification command is received, a CRC check is performed on the target firmware based on the packet header information of the target firmware to obtain a verification result; when the verification result indicates that the firmware information is correct, the target firmware is stored in the non-running area.

[0042] Secondly, the present invention also provides a firmware upgrade device based on an MCU platform, comprising:

[0043] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the firmware upgrade method based on the MCU platform described in the first aspect.

[0044] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors to perform the firmware upgrade method based on the MCU platform described in the first aspect.

[0045] Fourthly, a chip is provided, comprising: a processor and an interface for calling and running a computer program stored in memory, and performing a firmware upgrade method based on an MCU platform as described in the first aspect.

[0046] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer or processor, causes the computer or processor to perform a firmware upgrade method based on an MCU platform, as described in the first to fourth aspects and any one thereof.

[0047] In a sixth aspect, the present invention also provides a firmware upgrade system based on an MCU platform, including a firmware upgrade device based on an MCU platform as described in the second aspect, and using the firmware upgrade method based on an MCU platform as described in the first aspect to complete the interaction of the firmware upgrade device based on an MCU platform as described in the second aspect.

[0048] Unlike existing technologies, the present invention has at least the following beneficial effects:

[0049] This invention uses an address range swapping method to flip the address mapping of two storage spaces, thereby allowing the storage spaces to take turns as the running area to achieve switching between the running area and the non-running area. The running area is used to store the currently running original firmware, while the non-running area is used to receive the target firmware required for subsequent upgrades. Therefore, the firmware in the two storage spaces does not affect each other, achieving the goal of making the firmware versions in the two storage spaces independent of each other, without the need to compile firmware separately for different storage spaces.

[0050] Furthermore, after the address exchange is completed, the running value corresponding to the new running area is made greater than the running value corresponding to the old running area. This ensures that if abnormal termination or power failure occurs during the firmware upgrade process, the module can normally jump to the running area before the power failure after restarting. This greatly simplifies the firmware upgrade process and has high practicality. Moreover, the firmware upgrade process does not rely on the bootloader, which can save some storage space in the Flash memory, allowing the application to occupy more storage space. Attached Figure Description

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

[0052] Figure 1 This is a flowchart illustrating a firmware upgrade method based on an MCU platform provided in an embodiment of the present invention;

[0053] Figure 2 This is a schematic diagram of a process for determining the operating area after a module is started, provided by an embodiment of the present invention;

[0054] Figure 3 This is a flowchart illustrating step 10 provided in an embodiment of the present invention;

[0055] Figure 4 This is a flowchart illustrating the second step 10 provided in an embodiment of the present invention;

[0056] Figure 5 This is a schematic diagram of the running area and non-running area in a Flash memory provided by an embodiment of the present invention;

[0057] Figure 6 This is a flowchart illustrating the third step 10 provided in an embodiment of the present invention;

[0058] Figure 7 This is a flowchart illustrating the fourth step 10 provided in an embodiment of the present invention;

[0059] Figure 8 This is a schematic diagram of a firmware upgrade process provided by an embodiment of the present invention;

[0060] Figure 9 This is a flowchart illustrating step 20 provided in an embodiment of the present invention;

[0061] Figure 10 This is a flowchart illustrating step 40 provided in an embodiment of the present invention;

[0062] Figure 11 This is a flowchart illustrating step 40 provided in an embodiment of the present invention;

[0063] Figure 12 This is a schematic diagram of the running area and non-running area in another Flash memory provided by an embodiment of the present invention;

[0064] Figure 13 This is a schematic diagram of the architecture of a firmware upgrade device based on an MCU platform provided in an embodiment of the present invention. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0067] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0068] In the description of this invention, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this disclosure.

[0069] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0070] In describing some embodiments, the terms "coupled," "coupled," and "connected," and their derivative expressions, may be used. For example, the term "connected" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact with each other. Similarly, the term "coupled" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact. However, the terms "connected" or "coupled" may also refer to two or more components that do not have direct contact with each other but still cooperate or interact with each other, such as "optical coupling," "wireless connection," etc. The embodiments disclosed herein are not necessarily limited to the scope of this invention.

[0071] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0072] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0073] Example 1:

[0074] Most optical modules currently need to support continuous service upgrades. The upgrade process of traditional upgrade solutions is generally implemented in the bootloader area. On the one hand, when this method performs area jumps through the interrupt vector table, since the compiled firmware can only perform area jumps with a fixed jump address, the firmware in area A and area B must be upgraded or rolled back at the same time. In actual application scenarios that require comparative testing, the operation is cumbersome, time-consuming, and prone to errors, resulting in poor practicality.

[0075] On the other hand, since the upgrade needs to be implemented in the bootloader area, the application cannot be executed during the upgrade process. When the upgrade takes a long time, some closed-loop controls in the application may lose lock, which may fail to meet business requirements.

[0076] Moreover, most optical modules' controllers prefer a small package design. As a result, the storage space allocated to the code area in the Flash memory is often not very large. Adding the bootloader area will occupy a certain amount of storage space, further reducing the storage space occupied by the application and affecting the storage space available for business code, resulting in poor practicality.

[0077] Other solutions that do not rely on bootloader upgrades, while achieving switching between areas A and B by separating the interrupt vector table from the application, suffer from limitations. Since the starting addresses of the interrupt vector table and the application are compiled and cannot be modified, it's impossible for the same compiled firmware to run in either area A or area B of the same Flash memory. Upgrading area A requires recompiling a firmware version that runs in area A, and upgrading area B requires recompiling a firmware version that runs in area B, failing to achieve complete firmware independence between areas A and B. Furthermore, the firmware upgrade process is cumbersome and complex, resulting in poor practicality. Additionally, if an upgrade error, termination, or power failure occurs during this method, the module cannot recover, leading to boot failure or complete malfunction.

[0078] Furthermore, in most scenarios where customers need to upgrade the firmware of optical modules, only one firmware upgrade file is usually provided to the customer. Using this firmware upgrade file, the customer can upgrade from either area A or area B. However, this method cannot meet the needs of this practical application scenario and has poor practicality.

[0079] To solve the above problems, such as Figure 1 As shown, this embodiment of the invention provides a firmware upgrade method based on an MCU platform, including:

[0080] Step 10: Determine the running area based on the preset boot strategy, and run the original firmware in the running area.

[0081] In this embodiment of the invention, before the firmware upgrade, the firmware versions in the running area and the non-running area are the same, both being the original firmware.

[0082] It should be noted that in this embodiment, the running area and the non-running area each refer to a specific storage space. During the upgrade process, the storage spaces corresponding to the running area and the non-running area will change due to address flipping. For example, before address flipping, the running area refers to the first storage space, and the non-running area refers to the second storage space; after address flipping, the running area refers to the second storage space, and the non-running area refers to the first storage space.

[0083] Step 20: When a firmware download command is received, store the target firmware corresponding to this upgrade in the non-running area.

[0084] Step 30: When a trial run command is received, the address ranges of the running area and the non-running area are swapped so that the running area is configured as the new non-running area and the non-running area is configured as the new running area to run the target firmware.

[0085] The firmware upgrade process in this embodiment is integrated into the application. When the application is running and a trial run command is received, the address ranges of the running area and the non-running area are swapped to complete the switch between the running and non-running areas. During the firmware upgrade process, in addition to erasing and writing the Flash memory, the original control flow of the application can also be executed normally. This solves the problem that traditional upgrade solutions are prone to causing business interruptions, meets business requirements, and has high practicality.

[0086] Step 40: When a submit command is received, modify the running value corresponding to the new running area so that the modified running value is greater than the running value corresponding to the old running area.

[0087] In one embodiment, if the target firmware is problem-free, a commit command is sent. When the commit command is received, the running value corresponding to the new running area is modified and saved to the Flash memory, so that the module can jump to the corresponding running area according to the running value each time it starts up, ensuring that the storage space corresponding to the running area is the same before and after the power failure, so as to complete the firmware upgrade.

[0088] This invention uses an address range swapping method to flip the address mapping of two storage spaces, thereby allowing the storage spaces to take turns as the running area to achieve switching between the running area and the non-running area. The running area is used to store the currently running original firmware, while the non-running area is used to receive the target firmware required for subsequent upgrades. Therefore, the firmware in the two storage spaces does not affect each other, achieving the goal of making the firmware versions in the two storage spaces independent of each other, without the need to compile firmware separately for different storage spaces.

[0089] Furthermore, after the address exchange is completed, the running value corresponding to the new running area is made greater than the running value corresponding to the old running area. This ensures that if abnormal termination or power failure occurs during the firmware upgrade process, the module can normally jump to the running area before the power failure after restarting. This greatly simplifies the firmware upgrade process and has high practicality. Moreover, the firmware upgrade process does not rely on the bootloader, which can save some storage space in the Flash memory, allowing the application to occupy more storage space.

[0090] The firmware upgrade process will now be explained in detail:

[0091] In one embodiment, the module's memory includes a first storage space and a second storage space. The first storage space stores a first running value and a first verification value, and the second storage space stores a second running value and a second verification value. The first and second storage spaces are alternately configured as a running area or a non-running area. The module is provided with a partition-splitting identifier, which indicates whether a partition-splitting operation can be performed.

[0092] When the partition flag is 1, it indicates that a partitioning operation can be performed. When the partition flag is 0, it indicates that a partitioning operation cannot be performed. In other embodiments, the partition flag can also be other values ​​to indicate whether a partitioning operation can be performed.

[0093] In this configuration, the physical address of the first storage space is less than the physical address of the second storage space. Both the first and second verification values ​​are used to indicate whether the firmware within the corresponding storage space is valid. When the first storage space contains the first verification value, it indicates whether the firmware within that space is valid. When the second storage space contains the second verification value, it indicates whether the firmware within that space is valid. The partition switching operation refers to performing an address swapping operation to switch between the running and non-running areas.

[0094] This embodiment mainly involves the module's factory setup process. Figure 2 (Right-side process), initialization phase () Figure 2 (Left side process) and upgrade process ( Figure 8Step 10 mainly refers to the initialization phase, while steps 20 to 40 mainly refer to the upgrade process. In the upgrade process, when a trial run command is received, if the partition switching flag is 1, it is set to 0, and then the address range is swapped to avoid duplicate partition switching. After the upgrade process is completed, the module needs to be restarted, and step 10 needs to be executed so that the partition switching flag can be reset to 1 so that the partition switching operation can be performed.

[0095] It should be noted that the physical addresses of the first and second storage spaces remain unchanged, while both are configured with initial virtual addresses. During the process of the first and second storage spaces being alternately configured as the operating area, their virtual addresses continuously flip. After the module restarts, the virtual addresses of the first and second storage spaces revert to their initial virtual addresses. Therefore, each time the module powers on, it needs to undergo power-on initialization to ensure that it can correctly jump to the operating area before the power failure after restarting.

[0096] In this embodiment, after the module starts, since the physical address of the first storage space is smaller than the physical address of the second storage space, the module will first enter the first storage space and use it as the running area. However, in actual use, before the module loses power, it may be the first storage space or the second storage space that is the running area. Therefore, the module needs to determine which storage space is the running area before the power loss based on the relationship between the first running value and the second running value: If the first running value is greater than the second running value, then the first storage space is the running area corresponding to the power loss, and no area switching operation is required; the firmware (including applications, etc.) in the running area (first storage space) is executed. If the second running value is greater than the first running value, then the second storage space is the running area corresponding to the power loss. If the second verification value is 0, it means that the firmware in the second storage space is usable, and an area switching operation needs to be performed to swap the address ranges of the first and second storage spaces. When the first storage space is configured as the non-running area and the second storage space is configured as the running area, the firmware in the running area (second storage space) is executed. For a more detailed process, see [link to documentation]. Figure 1 And related textual descriptions.

[0097] In addition, when the module is started for the first time, it needs to be done as follows: Figure 2 The process shown on the right performs a factory reset, and the specific steps are as follows:

[0098] like Figure 3 As shown, step 10 further includes:

[0099] Step 101a: Start the module, set the first verification value to 0, and obtain the first running value and the second running value.

[0100] Step 102a: If both the first running value and the second running value are factory default values, then set the first running value to 1 and the second running value to 0, so as to configure the first storage space as the running area and the second storage space as the non-running area; and set the partition identifier to 1 to complete the factory default settings.

[0101] The factory default value is determined by those skilled in the art based on the specific usage scenario (e.g., the model of the MCU used); in an optional embodiment, the factory default value can be 0xFFFFFFFF. The partitioning identifier can also be selected by those skilled in the art based on the specific usage scenario; in an optional embodiment, the partitioning identifier can be set to 0xFFFF to indicate that a partitioning operation needs to be performed; the partitioning identifier can be set to 0x0000 to indicate that a partitioning operation does not need to be performed. When both the first running value and the second running value are factory default values, it indicates that the module is being started for the first time.

[0102] The following example illustrates the factory reset process: Upon first boot, the first storage space is configured as the running zone by setting the first running value to 1 and the second running value to 0. Since the module often connects to external devices, it's also necessary to determine if the external device is running in this running zone. If not, the running zone identifier of the external device is modified to switch it to that zone. For example, if the running zone identifier for external device dev1 is dev_commit1 and for external device dev2 is dev_commit2, reassigning dev_commit1 to 0 and dev_commit2 to 00 allows both external devices dev1 and dev2 to run in this running zone. Finally, the partition switching identifier is set to 1 to indicate that a partition switching operation is required, meaning the module is in a state where firmware upgrades are possible.

[0103] When the module is not being started for the first time, you can follow the steps as follows: Figure 2 The process shown on the left initializes the device upon startup. Specifically, as follows: Figure 4 As shown, step 10 includes:

[0104] Step 101b: Start the module, obtain the first running value and the second running value. If the first running value and the second running value are not both factory default values, initialize the first storage space as the running area, and determine whether the partition identifier is 1.

[0105] If at least one of the first and second running values ​​is not the factory default value, it means that the module is not being started for the first time and has already completed the factory reset. You can directly initialize the running area.

[0106] Step 102b: If the partition identifier is 0, then set the partition identifier to 1 and run the original firmware in the running area; if the partition identifier is 1, then determine whether the second running value is greater than the first running value.

[0107] If the partition switching flag is 0, no partition switching operation is required, and the partition switching flag is reset to 1 so that the module can perform the partition switching operation when it receives new firmware.

[0108] Step 103b: If the second running value is greater than the first running value and the second verification value is 0, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area.

[0109] Step 104b: If the second running value is less than the first running value or the second verification value is not 0, then the first storage space is still used as the running area and the second storage space is used as the non-running area.

[0110] This invention provides a specific example of a first storage space and a second storage space in a Flash memory, such as... Figure 5 As shown, the address range of the first storage space is "0x00000" to "0x80000", and the address range of the second storage space is "0x80000" to "0xFFFFF". The first storage space is initialized as the running area, and the second storage space is initialized as the non-running area, with the first running value being 1 and the second running value being 0. Since the first storage space is initialized as the running area by default after the module starts, when firmware upgrades are performed by swapping address ranges, the address ranges of the running and non-running areas will flip back and forth, resulting in an infinite loop. This prevents firmware upgrades and affects the normal operation of the module.

[0111] In this embodiment of the invention, during the upgrade phase, a partition switching operation is first indicated by a partition switching identifier of 1. When the trial run command is received, if the partition switching identifier is 1, it is set to 0, and then the address range is swapped to avoid duplicate partition switching. Furthermore, the first verification value is set to 0, the version number of the target firmware in the new running area is updated and saved in the corresponding Flash storage area, completing the partition switching.

[0112] In this embodiment of the invention, before swapping address ranges and after determining whether the partition flag is 1, the partition flag needs to be set to 0 to avoid a situation where the address ranges have not been swapped but the partition flag is 0, which would affect normal upgrades. In this way, by setting the partition flag, the problem of getting stuck in an infinite loop due to repeated flipping is solved, ensuring the normal operation of the module.

[0113] In an alternative embodiment, in order to reduce the number of times the Flash memory is erased and written, the cut-out identifier can be written into the electrically erasable programmable read-only memory (EEPROM) or the uninitialized area of ​​the MCU, so that the cut-out identifier can still be accessed after the swap command is executed.

[0114] It should be noted that when the module receives the trial run command, it will set the partition flag to 0; if the module restarts at this time before executing the commit command, such as... Figure 2 As shown, after the module restarts, it first reads the first and second running values ​​from the Flash memory, sets the first verification value to 0, and then checks whether both the first and second running values ​​are factory default values. Since the factory default setting has been completed at this point, it continues to check whether the partition switching flag is 1; since the partition switching flag is 0 at this point, it immediately sets the partition switching flag to 1. Because the time from "module restart" to "immediately setting the partition switching flag to 1" is relatively short, the module often has not yet lost power during this process, so the storage space corresponding to the running area before the module restarts can be guaranteed to be consistent with the storage space corresponding to the running area after the module restarts.

[0115] In rare cases, the module may lose power during the process from "module restart" to "immediately set the partition flag to 1". To eliminate the risk that the module may not be able to jump back to the operating area before the power loss after restarting, in an optional embodiment, the partition flag can be stored in random access memory (RAM) so that the partition flag is set to 1 after the module restarts, at which point it will proceed as follows. Figure 2 The left-hand process, when the partition identifier is 1, determines whether the second running value is greater than the first running value, whether the original firmware in the first storage space is being run, and whether the second verification value is 0. In this way, if the running area before power failure is inconsistent with the running area after restart, the address ranges of the first storage space and the second storage space are swapped to ensure that the module can jump to the running area before power failure normally after restarting; or, if it is determined that the running area before power failure is consistent with the running area after restarting, the firmware in the running area is run directly.

[0116] However, the above partitioning method still has the following problems: Since the module initially uses the first storage space as the running area after startup, and performs partitioning using the firmware in the first storage space to jump to the running area before the power failure, if the firmware in the first storage space is corrupted, partitioning cannot be performed, affecting the normal operation of the module. For example, during a firmware upgrade, after the first storage space switches from the running area to the non-running area, the original firmware in the first storage space has been erased, but the target firmware has not yet been copied to the first storage space. If the module unexpectedly loses power and restarts, there will be no firmware in the first storage space, making partitioning impossible and preventing a jump to the running area before the power failure. This not only prevents firmware upgrades but also affects the normal operation of the module.

[0117] This invention provides two solutions to this problem: one is to use the MCU's built-in bootloader to guide the partitioning process; such as... Figure 6 As shown, step 10 includes:

[0118] Step 101c: Modify the hardware pins corresponding to the module to configure the startup position of the MCU of the module to the starting address of the MCU's boot program.

[0119] Step 102c: Reset the MCU, start running the boot program from the startup position, set the first verification value to 0, and obtain the first running value and the second running value.

[0120] Step 103c: If the first running value is greater than the second running value, then initialize the first storage space as the running area and initialize the second storage space as the non-running area.

[0121] Step 104c: If the second running value is greater than the first running value, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area.

[0122] The following example uses the ADcuM410 MCU: After configuring the MCU's boot address as the starting address of the bootloader, the module is started normally via a pull-down pin. After the MCU resets, it reads the first and second running values. If the first running value is greater than the second running value, the first memory space is initialized as the running area, and the second memory space is initialized as the non-running area, and the MCU starts from the running area. If the second running value is greater than the first running value, the address ranges of the first and second memory spaces are swapped, so that the second memory space is the running area and the first memory space is the non-running area, and the MCU starts from the running area. This replaces the previous method of segmenting memory regions in the application. When entering the application again, after determining the running area based on the relationship between the first and second running values, there is no need to perform segmentation operations again, and the firmware in the running area can be executed normally. The application does not need to be modified to be compatible with both modes.

[0123] The first approach requires modifying the module's hardware pins. When the hardware pins cannot be modified, this embodiment of the invention provides a second approach: implementing the jump function by developing a custom bootloader program. Figure 7 As shown, step 10 includes:

[0124] Step 101d: Store the first boot program at the starting address of the first storage space, and store the second boot program at the starting address of the second storage space.

[0125] The first and second bootloader programs are both bootloader programs developed by those skilled in the art. The corresponding bootloader programs need to retain the functions of performing partition switching operations, jumping between partition A and partition B, and basic upgrades.

[0126] Step 102d: Reset the MCU of the module, start running the first boot program from the starting address of the first storage space, set the first verification value to 0, and obtain the first running value and the second running value.

[0127] Step 103d: If the first running value is greater than the second running value, then the first storage space is initialized as the running area, and the second storage space is initialized as the non-running area; and the reset vector address in the interrupt vector table of the MCU is set to the starting address of the application in the running area, so as to jump to the running application in the running area according to the reset vector address.

[0128] Step 104d: If the second running value is greater than the first running value, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area; the second boot program starts running from the starting address of the second storage space to jump to the application running in the running area.

[0129] The second approach is not limited by the state of hardware pins, and developing a custom bootloader is safer and more controllable. However, its drawbacks are that the first and second bootloaders will occupy a certain amount of storage space in the Flash memory, reducing the storage space available for the corresponding applications, and development takes time. Therefore, it is a less desirable option.

[0130] like Figure 8 The diagram illustrates the firmware upgrade process according to an embodiment of the present invention. Figure 9 As shown, step 20 includes:

[0131] Step 201: When a firmware download command is received, and the firmware version in the running area is consistent with the firmware version in the non-running area, the original firmware in the non-running area is erased to ensure that the non-running area can receive the target firmware normally.

[0132] It should be noted that if the firmware version in the running area is inconsistent with the firmware version in the non-running area, and a power outage occurs during the firmware upgrade process, the non-running area may be erased and corrupted, resulting in the module's firmware being unrecoverable. The first and second running values ​​are read to determine the non-running area. Once the non-running area is determined, the original firmware within it is erased to ensure that the area is clean and can receive the target firmware, preventing data mixing between the old and new firmware, which could lead to upgrade failure or system instability.

[0133] Step 202: When a verification command is received, perform a CRC check on the target firmware based on the packet header information of the target firmware to obtain a verification result; when the verification result indicates that the firmware information is correct, store the target firmware in the non-running area.

[0134] Since the storage area of ​​the first running value, second running value, first verification value, and second verification value in the Flash memory is generally determined by the MCU manufacturer and cannot be customized by developers, and firmware upgrades often require knowledge of the firmware version in the non-running area, it is necessary to store the firmware version information of both the running and non-running areas in an area accessible to both firmware versions. In an optional embodiment, in the absence of external memory, the firmware version information of the running and non-running areas can also be stored in the on-chip Flash memory of the MCU. The corresponding firmware version information can be stored in the area near the corresponding value, and the firmware version information of other upgradable peripheral devices can also be stored for indication. For example, when the upgrade of the module includes firmware upgrades of the MCU, external device A, external device B, and parameter tables, this embodiment of the invention stores the same information structure in symmetrical areas in the running and non-running areas. In an optional embodiment, a specific example of the information structure that needs to be stored in a module is as follows:

[0135] typedef struct

[0136] {

[0137] uint32_t key1_value; / / key1 for each zone

[0138] uint32_t key2_value; / / key2 for each zone

[0139] uint32_t block; / / Which region does it belong to?

[0140] uint32_t swap_flag; / / Bits 0 to 7 represent the operating area of ​​external device A, bits 7 to 15 represent the operating area of ​​external device B, and bits 16 to 31 represent the swap flag (i.e., the flag bits below).

[0141] uint32_t commit_value;

[0142] uint32_t version; / *MCU firmware version* /

[0143] uint32_t versionRES1; / * Firmware version of external device A * /

[0144] uint32_t versionRES2; / * External device B firmware version * /

[0145] uint32_t versionRES3; / * Version of the parameter list * /

[0146] }KEY_INFO_Type;

[0147] To address the issue of firmware version rollback not being possible during firmware upgrades, such as... Figure 10 As shown, the procedure preceding step 40 includes:

[0148] Step 401a: Test the target firmware and obtain the test results.

[0149] Step 402a: When there is a problem with the test result, the address range of the new running area and the new non-running area are swapped again to switch the address range back; or, the MCU of the module is reset.

[0150] If the target firmware encounters problems during testing, this embodiment of the invention provides two solutions for quickly rolling back to the state before the partition switching: First, directly perform the partition switching operation again, switching the running and non-running areas back to their pre-split states. This eliminates the need for another firmware upgrade as described in existing technologies, achieving rapid firmware version rollback. Second, directly reset the MCU, defaulting to the state before the address range swap and booting from the corresponding running area. This also eliminates the need for another firmware upgrade.

[0151] Step 403a: If there are no problems with the test results, send a submission command.

[0152] In step 40, as Figure 11 As shown, to prevent module power loss during firmware upgrades, when a commit command is received, the running value corresponding to the new running area is modified so that the modified running value is greater than the running value corresponding to the old running area. After the module restarts, because the second running value is greater than the first running value, an address range swap needs to be performed, as follows: Figure 11 The unrunnable area shown is configured as the running area. If the running values ​​corresponding to the new running area are not modified, after the module restarts, both the second and first running values ​​will be 0, and the module will start from the unrunnable area. Figure 11 Once the operating zone shown is started, it is impossible to return to the state before the power failure. It should be noted that the starting zone is determined based on the relationship between the first and second operating values ​​only when the module starts; during the normal operation of the module, the zone switching operation is not determined based on the relationship between the first and second operating values.

[0153] In one alternative embodiment, the running value corresponding to the old running area can be incremented by one to obtain the modified running value.

[0154] like Figure 12 As shown, after step 40, the following steps are also included:

[0155] Step 401b: When a copy command is received, determine whether the firmware version in the new running area is consistent with the firmware version in the new non-running area.

[0156] Step 402b: When the firmware version in the new running area is inconsistent with the firmware version in the new non-running area, copy the target firmware in the new running area to the new non-running area to ensure that the firmware version in the new running area is consistent with the firmware version in the new non-running area.

[0157] The firmware upgrade is complete when both the firmware version in the new running area and the firmware version in the new non-running area are the target firmware.

[0158] Example 2:

[0159] like Figure 13 The diagram shown is an architectural schematic of a firmware upgrade device based on an MCU platform according to an embodiment of the present invention. The firmware upgrade device based on an MCU platform in this embodiment includes one or more processors 21 and a memory 22. Figure 13 Take a processor 21 as an example.

[0160] Processor 21 and memory 22 can be connected via a bus or other means. Figure 13 Taking the example of a connection between China and Israel via a bus.

[0161] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the firmware upgrade method based on the MCU platform in this embodiment. The processor 21 executes the firmware upgrade method based on the MCU platform by running the non-volatile software programs and instructions stored in the memory 22.

[0162] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0163] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they perform the firmware upgrade method based on the MCU platform in the above embodiments, for example, performing each step of the firmware upgrade method based on the MCU platform described in the above embodiments of the present invention.

[0164] This invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 13 A processor 21 enables one or more of the processors to execute the firmware upgrade method based on the MCU platform in the specific embodiments of the present invention, for example, to execute the various steps of the firmware upgrade method based on the MCU platform described in the embodiments of the present invention above; it can also implement... Figure 13 The various modules and units mentioned above; or the firmware upgrade method based on the MCU platform in the specific embodiments of the present invention, for example, executing the various steps of the firmware upgrade method based on the MCU platform in the embodiments of the present invention described above; can also achieve Figure 13 The various modules and units mentioned above.

[0165] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0166] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0167] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A firmware upgrade method based on an MCU platform, characterized in that, include: The operating area is determined based on a preset boot strategy, and the original firmware within the operating area is run. When a firmware download command is received, the target firmware corresponding to this upgrade is stored in the non-running area; When a trial run command is received, the address ranges of the running area and the non-running area are swapped, so that the running area is configured as the new non-running area and the non-running area is configured as the new running area to run the target firmware; When a submission command is received, the running value corresponding to the new running area is modified so that the modified running value is greater than the running value corresponding to the old running area.

2. The firmware upgrade method based on an MCU platform according to claim 1, characterized in that, The module's memory includes a first storage space and a second storage space. The first storage space stores a first running value and a first verification value, and the second storage space stores a second running value and a second verification value. The first storage space and the second storage space are configured alternately as a running area or a non-running area. The module is equipped with a cutting area identifier, which is used to indicate whether a cutting area operation can be performed. The firmware upgrade method based on the MCU platform also includes: When the trial run command is received, if the partition identifier is 1, then the partition identifier is set to 0, and the address range swap is performed again.

3. The firmware upgrade method based on the MCU platform according to claim 2, characterized in that, The step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes: Start the module, obtain the first running value and the second running value. If the first running value and the second running value are not both factory default values, initialize the first storage space as the running area, and determine whether the partitioning identifier is 1. If the partition identifier is 0, then the partition identifier is set to 1, and the original firmware in the running area is run; if the partition identifier is 1, then it is determined whether the second running value is greater than the first running value. If the second running value is greater than the first running value and the second verification value is 0, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area. If the second running value is less than the first running value or the second verification value is not 0, then the first storage space is still used as the running area and the second storage space is used as the non-running area.

4. The firmware upgrade method based on the MCU platform according to claim 3, characterized in that, The step of determining the running area based on a preset boot strategy and running the original firmware within the running area further includes: Start the module, set the first verification value to 0, and obtain the first running value and the second running value; If both the first running value and the second running value are factory default values, then the first running value is set to 1 and the second running value is set to 0, so that the first storage space is configured as the running area and the second storage space is configured as the non-running area; and the partition identifier is set to 1 to complete the factory default settings.

5. The firmware upgrade method based on the MCU platform according to claim 2, characterized in that, The step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes: Modify the hardware pins corresponding to the module to configure the startup position of the MCU of the module to the starting address of the MCU's boot program; Reset the MCU, start running the boot program from the boot position, set the first verification value to 0, and obtain the first running value and the second running value; If the first running value is greater than the second running value, then the first storage space is initialized as the running area, and the second storage space is initialized as the non-running area; If the second running value is greater than the first running value, then the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area.

6. The firmware upgrade method based on an MCU platform according to claim 2, characterized in that, The step of determining the running area based on a preset boot strategy and running the original firmware within the running area includes: The first boot program is stored at the starting address of the first storage space, and the second boot program is stored at the starting address of the second storage space. The MCU of the module is reset, and the first boot program is started from the starting address of the first storage space. The first verification value is set to 0, and the first running value and the second running value are obtained. If the first running value is greater than the second running value, then the first storage space is initialized as the running area, and the second storage space is initialized as the non-running area; and the reset vector address in the interrupt vector table of the MCU is set to the starting address of the application in the running area, so as to jump to the running application in the running area according to the reset vector address; If the second running value is greater than the first running value, the address ranges of the first storage space and the second storage space are swapped, so that the second storage space is used as the running area and the first storage space is used as the non-running area; the second boot program starts running from the starting address of the second storage space to jump to the application running in the running area.

7. The firmware upgrade method based on an MCU platform according to any one of claims 1-6, characterized in that, Before modifying the running value corresponding to the new running area to make the modified running value greater than the running value corresponding to the old running area when a submission command is received, the following steps are included: The target firmware was tested, and the test results were obtained. If the test results are problematic, the address ranges of the new running area and the new non-running area are swapped again to switch the address ranges back; or, the MCU of the module is reset. If the test results are satisfactory, send a submit command.

8. The firmware upgrade method based on an MCU platform according to any one of claims 1-6, characterized in that, The step of storing the target firmware corresponding to this upgrade to the non-running area when a firmware download command is received includes: When a firmware download command is received, and the firmware version in the running area is consistent with the firmware version in the non-running area, the original firmware in the non-running area is erased to ensure that the non-running area can receive the target firmware normally. When a verification command is received, a CRC check is performed on the target firmware based on the packet header information of the target firmware to obtain a verification result; when the verification result indicates that the firmware information is correct, the target firmware is stored in the non-running area.

9. A firmware upgrade device based on an MCU platform, characterized in that, The firmware upgrade device based on the MCU platform includes at least one processor and a memory, which are connected via a data bus. The memory stores instructions that can be executed by the at least one processor. After being executed by the processor, the instructions are used to implement the firmware upgrade method based on the MCU platform according to any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the firmware upgrade method based on the MCU platform as described in any one of claims 1-8.

Images