MCU firmware self-update, a reliable and practical method

Click on "Uncle Wheat" above and select "Top/Star Public Account"

Welfare dry goods, delivered as soon as possible

The main function of the car software Boot program is to refresh the App program. In a specific customer project, Boot is also a part of customer requirements, and there are software development plans that follow the project (in order to distinguish it from other Boots, the Boot on the project is called CB, Customer Boot).

For the controller that has been rolled out of the box cover, whether it is tested in the hands of the supplier or the customer, the App can only be refreshed through CB. Additional methods are required if CB self-refresh is required.

specification:

OEMs only have specifications for App program refresh, but not for Boot self-refresh. Because the specification is for mass-produced vehicles, the after-sale service is only responsible for the upgrade of the App program, not the Boot upgrade (and the Boot upgrade is not allowed).

Therefore, Boot's self-refresh only exists in the project development stage, and the solution is provided by the supplier. This paper analyzes the advantages and disadvantages of five Boot self-update methods.

Method 1, SB updates CB:

As shown in Figure 1-a, some software architectures are two-level Boot: SB+CB, Start Boot only checks the minimum CPU system, and has nothing to do with the peripheral circuit of the specific project. It is independent of customer requirements and maintained by the supplier. In the Pilot project It should be developed early. Because the program startup sequence is SB->CB->App, adding refresh logic in SB can update CB. Under normal circumstances, run the CB update App program. In special cases, the program will stay in the SB and update the CB after the program is started.

advantage:

1. The logical structure is simple and clear, and the software division of labor is clear.

2. One refresh, easy to operate.

shortcoming:

1. Larger Flash space is required to store the refresh logic in the SB, and this refresh method must be prohibited after the project SOP, resulting in additional waste.

2. The software is started in three levels, the structure is complex, and the development and maintenance costs are high. It's a burden for controllers that don't need SB.

3. What if SB also needs to be updated? According to this strategy, have to be an SSB? Obviously not realistic.

7a88ca9624dd40ee9827e93b12e07790.png

Method 2, RAM+Flash Reboot update

As shown in Figure 2-a, in the absence of SB, the program startup sequence is CB->App. When you need to refresh the Boot, first download the Reboot program to the unused RAM (Figure 2-b), then run ReBoot in the RAM environment to download the new CB (Figure 2-c)

advantage:

1. No additional Flash space is required, and only a small amount of RAM is required to run the Boot program, so the RAM designed for the App can temporarily save the Reboot program.

2. If the RAM erasing speed is fast, the downloading speed of ReBoot will be very fast.

shortcoming:

If the CPU is powered off during the CB update process, after the power is turned on again, there is no Reboot content, the CB has been damaged, the program cannot be started normally, and the controller is paralyzed. You can only open the cover and use JTAG to program the program.

020a59cb26eef0e68e8d49a7dec02c9a.png

Method 3, RAM+RAM ReBoot update (improvement of method 2)

First download ReBoot (blue) + NewCB ​​(purple) together into RAM (Figure 3-a), then run ReBoot, erase the CB Flash area, and copy the NewCB ​​in RAM to the CB Flash area (this step is done internally) . Finally, after power on and reset, the ReBoot and NewCB ​​in RAM are automatically lost, and the program starts to run from the new CB.

advantage:

 1. Compared with the second method, there is one less refresh (because ReBoot and CB are tied together).

 2. Compared with the second method, the CB update is all executed inside the CPU, free from external interference, and takes less time.

shortcoming:

 1. Compared with the second method, more RAM space is required to store ReBoot+NewCB.

 2. Like the second method, there is a risk that the controller will be paralyzed after the power failure in the CB update phase.

fbea45efd698b718ce87df730ea2b84b.png

Method 4. With the help of App program Flash space

The refresh is divided into three steps: 1. Figure 4-b run the CB, erase the App, and download ReBoot to the App area. 2. Figure 4-c Run ReBoot, erase the old CB, and flash the new CB. 3. Figure 4-d Run the new CB and flash back to the App.

advantage:

1. No additional Flash and RAM resources are required.

2. Stable and reliable, through the optimized design, it can be ensured that the power is suddenly cut off at any step, and it can continue to operate after the power is turned on, and the controller will not be brushed to death. (Please refer to the appendix for the detailed design method)

3. A little modification of CB can become a Reboot program, and the development is fast.

shortcoming:

1. There are many steps. In order to update the CB, you must first erase the App, and then restore the App at least three times. It is easy to be confusing for operators unfamiliar with the procedure.

2. The overall refresh time will be longer, two Boots + one App

5ead26ec587f86074a1845f3f01f9526.png

Method 5. With the help of additional Flash space

Compared with method 4, an additional Flash space of the same size as CB is required, and the refresh is divided into three steps:

  1. Figure 5-b, run CB, flash ReBoot to extra Flash.

  2. Figure 5-c, run ReBoot to update CB.

  3. Run a new CB, destroy the ReBoot (wipe all, or just wipe the ReBoot validity flag)

Advantages: Compared with method 4, there is no need to destroy the App program, and this part of the update time is also saved.

Disadvantage: Compared with Mode 4, additional Flash space is required, and it must be an independent Block.

31afdbfa2b5a1c85cf424e72b7ace9ee.png

summary:

Essentially there are only three:

  1. Relying on the startup program SB (method 1), this method is the most time-saving when the CPU's Flash resources are abundant and the project requires two levels of Boot.

  2. With the help of RAM (methods 2 and 3) 3. With the help of Flash (methods 4 and 5). When only a single-stage Boot (CB) is needed, it is more convenient to use the second and third methods when the time, manpower, and material cost of opening the controller due to Boot refresh paralysis can be tolerated.

  3. When only a single-stage Boot (CB) is required, it is not allowed or inconvenient for the controller to open the cover, but it is most reliable to use methods 4 and 5 when it can tolerate a large number of Boot update steps and a long time.

To sum up, engineers need to comprehensively consider a Boot self-refresh method suitable for their own products and projects based on cost factors such as the overall software architecture, CPU resources, time, manpower and materials.

appendix:

"The specific implementation method of Boot self-refresh method four (with the help of Flash)"

background:

For mode 4, use Flash to refresh [there is no risk of flashing dead, the controller suddenly loses power in any step, and can continue to operate after power-on. ] The conclusion is conditional. The author gives this conclusion from the most ideal premise, that is, as long as there is at least one Boot in the controller (even if one is bad), the program can start and run from any normal Boot. Here is a question, how does the CPU determine which Boot is good and which is bad? Now analyze the situation and several countermeasures of the risk of the controller being brushed to death.

Two-level startup address introduction:

As shown in the figure below, after the CPU is powered on, the program checks the validity of the BootSector in the order of addresses. If the BOOT_ID is valid, the execution starts from the specified address, otherwise, the next BootSector is checked.

24a9d925a46c19a2c2c6518fd0f98f99.png

Consider the case where the CPU has at least two boot addresses, as shown in Figure 1-a, if and only when the boot address 1 is valid (App is empty), the program will automatically enter Boot after startup. As shown in Figure 1-b, if and only if the startup address 2 is valid (without the Boot test), the program will automatically enter the App after startup. As shown in Figure 1-c, when both startup addresses 1 and 2 are active, the program starts from address 1 first. When checking the validity of the App program in Boot, the jump instruction is used to jump to the startup address 2 to start running the App.

9510f48b6bb8702797ffd1543e2054e8.png

0f061fc01236fea8d037e27229522f11.png

Method 4 Analysis of the situation of the controller being brushed to death:

As shown in Figure 2-a, the power is cut off while running Reboot to update the CB. After powering on again, as shown in Figure 2-b, since the content of the boot address 1 is updated at the beginning of the refresh, it is valid, and the program will enter the CB to run, but the CB is incomplete, and there must be an error in the operation, and the program will not jump into ReBoot , so that it can no longer be refreshed (that is, brushed to death). Assuming that the time from erasing the old CB to the completion of flashing the new CB is 10S, the possibility of power failure during this period cannot be ignored.

9b4ba288ebf341fd639b1e48db2749f0.png

Countermeasure 1. The Boot validity flag coincides with the startup address

Considering the most common situation, the CPU can only erase the entire block (16K, 32K, 64K...), and can write at least 4-byte units. There is no sequence limit. Now CB only uses one block. Now adjust the refresh sequence: after the erasure is successful, refresh the orange area first, and refresh the validity flag (gray area) of the startup address 1 in the last step. This way, even if the power is lost during the update of the orange area.

After the power is turned on again, the program still starts to run from the startup address 2, that is, re-run Reboot and continue to wait for the refresh CB command, as shown in Figure 3-a. There is no need to change the download process during the specific operation. Use the $34,36 service to transfer data from the host computer to the CPU in sequence. First put the validity flag of the startup address 1 into the RAM. After downloading the orange area to the Flash, Then write the validity flag of the startup address 1 into the Flash from the RAM (this step can be completed within 10ms, and the possibility of power failure during this time can be completely ignored)

If the boot address 1 is refreshed successfully in the last step, after the power is turned on again, the program starts to run a new Boot from the boot address 1. That is, the boot address 1 plays the role of the Boot validity flag (the first erase, the last write), as shown in Figure 3-b.

228ad04da3cfb03e59ef3be580e4b459.png

Countermeasure 2. The Boot validity flag is independently tailed, and the Boot validity check logic is added.

As shown in Figure 4-a, the Boot is divided into two segments. Only a small amount of startup self-checking logic is stored in Sec1. When it detects that the CB_ValidFlg placed at the end of Sec2 is invalid, it is considered that the Boot is incomplete, and the program control jumps Continue to run ReBoot to the startup address 2, and refresh the Boot again.

As shown in Figure 4-b, when the logic of Sec1 detects that CB_ValidFlg is valid, it is considered that the Boot refresh is completed, and the program control jumps into Sec2. At this time, since the App_ValidFlg at the end of App (ReBoot) is invalid, the program will not jump Transfer to ReBoot, and then you can flash the new App.

This method only needs to make some adjustments to the logic and segment allocation of the CB, and does not need to change the refresh order. The startup self-checking logic in Sec1 can be made as small as possible. As long as the power is not lost during the refresh of the Sec1 segment, the controller will not be flashed dead, which greatly reduces the risk. However, for mass-produced software, it is unreasonable to directly jump into the App after checking that CB_ValidFlg is invalid, so when the Boot is finalized, the jump logic should be turned off.

80737953e468a8018cf9162ea5e97247.png

summary:

Countermeasure 1 is simple and reliable, and has been verified by actual tests, which can fully meet the requirements of stable refresh ECU.

原文地址:https://blog.csdn.net/weixin_40137252/article/details/111054011
转自公众号:技术让梦想更伟大
版权声明:本文来源网络,版权归原作者所有。版权问题,请联系删除。
—— The End ——

						
							
									往期推荐

						
							
								
								
									
										如何成为高手?嵌入式开发进阶之路...

								
							
								
									
										单片机高负载串口通信,如何设计可靠的方案?

								
							
								
									
										量子充电,9秒充满一辆车!这是玄学?

								
							
								
									
										GD32替换STM32,有哪些区别?这些坑你别踩...

								
							
								
									
										高效解析单片机通讯协议,最实用的一个方法

								
							
								
									
										最适合单片机的通信协议,如何设计?

								
							
点击下方名片关注我

Guess you like

Origin blog.csdn.net/u010632165/article/details/123887931