AB backup method for realizing OTA upgrade by single Flash Bank

Abstract

The invention discloses an AB backup method for realizing OTA upgrade by a single Flash Bank, which ensures that a system can automatically recover to a previous stable version without staying in a BOOT boot area under the condition that the OTA upgrade fails. The problem that the ECU can only execute a firmware upgrading function and cannot work normally after the traditional OTA upgrading fails is avoided, so that continuous operation of core functions of the ECU is guaranteed, the driving experience of a user and the stability of a system are improved, and in addition, the method has the advantages that fault tolerance and recovery capacity of double Flash Banks similar to that of a high-end MCU are achieved on a single Flash Bank of a common MCU. Thus, an automobile manufacturer (OEM) does not need to use a more expensive special MCU for supporting an AB backup function, hardware cost is greatly reduced, and feasibility and economical efficiency of the method are improved.

Description

Technical Field

[0001] The invention belongs to the field of backup methods, and in particular relates to an AB backup method for realizing OTA upgrade with a single Flash Bank. Background Art

[0002] With the rapid development of automotive electronic technology, electronic control units (ECUs) are increasingly used in automobiles. With the development of informatization, more and more ECUs need to upgrade firmware after sales (OTA) to achieve software maintenance and new function expansion of automotive parts.

[0003] During the OTA process, the success rate is not 100% due to various external or internal conditions. After the traditional OTA fails, the software stays in the BOOT boot area, and the ECU can only perform the firmware upgrade function. The normal function of the ECU is completely lost, affecting the user's driving. To solve this problem, car manufacturers require the ECU to have a rollback function or an AB backup function. The rollback function can solve the problem of not losing functions after the firmware data update fails, but there are security issues such as not being able to flash without feeling and data loss. In order to better solve the above pain points, MCU manufacturers perform Flash upgrades on the chip. The AB backup function can be achieved through multiple FlashBanks, but the cost is significantly increased. Chips with multiple Flash Bank functions are generally high-end MCUs.

[0004] Memory layout of single Flash Bank rollback method ( Figure 1 ) is divided into BOOT area, running area and backup area. Figure 2 As shown in the boot process flow chart, after the MCU is powered on or reset, it first checks whether there is a flash mark. If not, it determines whether the running area is valid. If it is valid, it executes the running area firmware. If not, it checks whether the backup area is valid. If it is valid, it releases the backup area data to the running area and restarts the MCU after the data release is completed. If the backup area data is invalid, it stays in the BOOT area. If there is a flash mark, it directly enters the BOOT area. The flash process is performed in the BOOT area, and the MCU is restarted if the flash is completed. This solution only supports flashing in the BOOT area, that is, it does not support flashing during runtime. It can only monitor whether the flash mark is received during runtime. If it is, it writes the flash mark and restarts ( Figure 3 ). When flashing in the BOOT area, according to the flashing instruction, if the flashing instruction is received, the backup area data is erased and the running area data is written to the erased backup area. After the writing is completed, the running area data is erased, and then the new firmware data is written to the running area. After the writing is completed, the data is verified. If it passes, the MCU is restarted. The MCU executes the new firmware data after startup. Otherwise, the data area is erased again. After the erasing is completed, the backup area data is written to the running area and restarted. This time the new firmware data update fails ( Figure 4 ).

[0005] The memory layout in the multi-Flash Bank AB backup method is divided into operation area A and operation area B ( Figure 5 ), compared with single Flash Bank, this method has no BOOT area in the memory layout, and the chip MCU itself provides the UFB flag. In this method, the startup process is to judge the UFB flag when power is on. If UFB=0, the operation area A data in Flash Bank1 is executed; otherwise, if UFB=1, the operation area B data in Flash Bank2 is executed ( Figure 6 ). In operation area A or operation area B, if a flash request is received, the UFB flag is judged. If UFB=1, the data in Flash Bank1 is erased, the new firmware data is written into Flash Bank1 and verified. If it fails to pass the verification, it returns to the running state and waits for a request to re-flash the judgment. If it passes the verification, the MCU is restarted. If UFB=0, the data in Flash Bank2 is erased, the new firmware data is written into Flash Bank2 and verified. If it fails to pass the verification, it returns to the running state and waits for a request to re-flash the judgment. If it passes the verification, the MCU is restarted. ( Figure 7 ).

[0006] In view of the problem that the single Flash Bank rollback method does not support senseless flashing, has low reliability, and has high cost and does not support common MCUs due to multiple Flash Banks, the present invention is proposed. Summary of the invention

[0007] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide an AB backup method for implementing OTA upgrade with a single Flash Bank, which solves the problems raised in the above background technology. To solve the above technical problems, the technical method adopted by the present invention is as follows:

[0008] This method divides the memory layout into BOOT area, operation area 1 and operation area 2 in a single Flash Bank. Figure 8 ).

[0009] After the MCU is powered on or reset, it enters the BOOT area to determine whether there is a flash flag. If there is no flash flag, the operating area is determined according to the startup process, the operating area is selected and the corresponding firmware is executed; if there is a flash flag, the system enters the flash process. After entering the startup process, first determine whether only operating area 1 is valid. If so, execute the firmware in operating area 1; if not, determine whether only operating area 2 is valid. If so, execute the firmware in operating area 2; if not, determine whether both operating area 1 and operating area 2 are valid. If so, select the corresponding operating area according to the UFB identifier. Specifically, if the UFB identifier is 0, execute the firmware in operating area 1; if the UFB identifier is 1, execute the firmware in operating area 2. Otherwise, it is determined that there is no program in the MCU and it stays in the BOOT area ( Fig. 9 ).

[0010] During the waiting period in the BOOT area or during the operation of the running area 1 or during the operation of the running area 2, after receiving the flash mark, first determine the UFB mark, select the erase area according to the UFB mark, write the new firmware to the erase area after the erasure is completed and verify, then write the UFB mark, and finally restart. Specifically, after receiving the flash mark while waiting in the BOOT area or running area 2, determine the UFB mark. If UFB=1, erase the data in the running area 1, and write the new firmware data to the running area 1. After the new firmware data is written, perform a data check on the running area 1. If the check passes, set UFB to 0 and restart the MCU, otherwise stay in the BOOT area waiting or running area 2; After receiving the flash mark while waiting in the BOOT area or running area 1, determine the UFB mark. If UFB=0, erase the data in the running area 2, and write the new firmware data to the running area 2. After the new firmware data is written, perform a data check on the running area 2. If the check passes, set UFB to 1 and restart the MCU, otherwise stay in the BOOT area waiting or running area 1 ( Fig.10 ).

[0011] After adopting the above technical method, the present invention has the following beneficial effects compared with the prior art. Of course, any product implementing the present invention does not necessarily need to achieve all the advantages described below at the same time:

[0012] 1. The method of this application ensures that in the event of an OTA upgrade failure, the system can automatically recover to the previous stable version instead of staying in the BOOT boot area. This avoids the problem that the ECU can only perform the firmware upgrade function and cannot work normally after the traditional OTA upgrade fails, thereby ensuring the continuous operation of the core functions of the ECU and improving the user's driving experience and system stability.

[0013] 2. The method of the present application achieves similar fault tolerance and recovery capabilities on ordinary MCUs. In this way, automobile manufacturers (OEMs) do not need to use more expensive special MCUs to support AB backup functions, which greatly reduces hardware costs and improves the feasibility and economy of the method.

[0014] 3. The method of this application realizes non-sensing flashing on ordinary MCU. In this way, when the new firmware is upgraded, the ECU still has full functional capabilities, ensuring that the system can maintain functional continuity and security under any circumstances. This not only meets the needs of automobile manufacturers for high reliability and stability of OTA systems, but also improves the safety of vehicle use.

[0015] The specific implementation modes of the present invention are further described in detail below in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described below are only some embodiments. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0017] Figure 1 The memory layout in the single Flash Bank rollback method;

[0018] Figure 2 This is a flowchart of the startup process in the single Flash Bank rollback method;

[0019] Figure 3 A flowchart of flashing the running area in the single Flash Bank rollback method;

[0020] Figure 4 A flowchart of the process of receiving a flash request in the running area in the single Flash Bank rollback method;

[0021] Figure 5 Memory layout in multi-Flash Bank AB backup method;

[0022] Figure 6 It is a flowchart of the startup process in the multi-Flash Bank AB backup method;

[0023] Figure 7 It is a flowchart of the flash writing process in the multi-Flash Bank AB backup method;

[0024] Figure 8 The memory layout of the method of the present invention for a single Flash Bank;

[0025] Fig. 9 It is a flowchart of the startup process in the method of the present invention for a single Flash Bank;

[0026] Fig.10 It is a flowchart of the flash writing process in the method of the present invention for a single Flash Bank;

[0027] It should be noted that these drawings and textual descriptions are not intended to limit the conceptual scope of the present invention in any way, but are intended to illustrate the concept of the present invention for those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0028] The present invention will now be described in further detail with reference to the accompanying drawings.

[0029] See also Figure 8-10 As shown, in this embodiment, a single Flash Bank is provided to implement an AB backup method for OTA upgrade. This method is to divide the memory layout into a BOOT area, an operation area 1 and an operation area 2 ( Figure 8 ).

[0030] After the MCU is powered on or reset, it enters the BOOT area to determine whether there is a flash flag. If there is no flash flag, the operating area is determined according to the startup process, the operating area is selected and the corresponding firmware is executed; if there is a flash flag, the system enters the flash process. After entering the startup process, first determine whether only operating area 1 is valid. If so, execute the firmware in operating area 1; if not, determine whether only operating area 2 is valid. If so, execute the firmware in operating area 2; if not, determine whether both operating area 1 and operating area 2 are valid. If so, select the corresponding operating area according to the UFB identifier. Specifically, if the UFB identifier is 0, execute the firmware in operating area 1; if the UFB identifier is 1, execute the firmware in operating area 2. Otherwise, it is determined that there is no program in the MCU and it stays in the BOOT area ( Fig. 9 ).

[0031] During the waiting period in the BOOT area or during the operation of the running area 1 or during the operation of the running area 2, after receiving the flash mark, first determine the UFB mark, select the erase area according to the UFB mark, write the new firmware to the erase area after the erasure is completed and verify, then write the UFB mark, and finally restart. Specifically, after receiving the flash mark while waiting in the BOOT area or running area 2, determine the UFB mark. If UFB=1, erase the data in the running area 1, and write the new firmware data to the running area 1. After the new firmware data is written, perform a data check on the running area 1. If the check passes, set UFB to 0 and restart the MCU, otherwise stay in the BOOT area waiting or running area 2; After receiving the flash mark while waiting in the BOOT area or running area 1, determine the UFB mark. If UFB=0, erase the data in the running area 2, and write the new firmware data to the running area 2. After the new firmware data is written, perform a data check on the running area 2. If the check passes, set UFB to 1 and restart the MCU, otherwise stay in the BOOT area waiting or running area 1 ( Fig.10 ).

[0032] This example method divides the Flash area into BOOT area, operation area 1 and operation area 2 in a single Bank Flash. It does not require two or more Flash areas. This method can be applied to ordinary MCUs.

[0033] The UFB identifier of the present invention is that the method actively sets the UFB identifier in the program, and indicates whether the firmware executed by the current program is in running area 1 or running area 2 according to the UFB identifier. It is particularly noted that UFB is the abbreviation of User Flash Bank. UFB is a special identifier of high-end MCUs with multiple Flash Banks, which is built into the MCU chip itself.

[0034] The UFB identifier of the present invention is a UFB identifier that indicates whether the firmware executed by the current program is in operating area 1 or operating area 2. In addition to having the function of the UFB identifier in the high-end MCU, the UFB identifier can also be switched through a diagnostic command. In terms of operating area switching, it has more practical application value than the AB backup of the existing high-end MCU.

[0035] The present invention can update the firmware data of another operation area while the firmware is running, that is, the method can achieve a senseless firmware update.

[0036] The present invention can keep the system online after the firmware data update fails. It is particularly emphasized that the method has no influence on the realization of the function during the whole process.

[0037] The present invention is not limited to the above-mentioned implementation modes. Anyone should be aware of the layout and implementation method changes made under the enlightenment of the present invention. All the same or similar technical methods as the present invention fall within the protection scope of the present invention. The technology, shape, and structure parts not described in detail in the present invention are all known technologies.

Claims

1. An AB backup method for implementing OTA upgrade with a single Flash Bank, characterized in that: In a single Flash Bank, the Flash area is divided into two or more Flash areas: BOOT area, operation area 1 and operation area 2. The steps to implement the firmware flashing, verification and recovery operations in a single Flash Bank architecture are as follows: S1: When the MCU is powered on or reset, the system first enters the BOOT area and determines whether there is a flashing flag in the BOOT area. According to the judgment criteria, the system enters the startup process or the flashing process; S2: After entering the startup process, the system first determines whether the operating area 1 is valid. If the operating area 1 is valid, the firmware in the operating area 1 is executed; if the operating area 1 is invalid, it continues to determine whether the operating area 2 is valid. If the operating area 2 is valid, the firmware in the operating area 2 is executed; if both the operating area 1 and the operating area 2 are valid, the operating area to be executed is selected according to the UFB identifier; S3: During the waiting period in the BOOT area, during the operation of the running area 1, or during the operation of the running area 2, after receiving the flashing mark, first determine the UFB mark, select the erase area according to the UFB mark, write the new firmware to the erase area and verify it after the erasure is completed, then write the UFB mark bit, and finally restart.

2. According to claim 1, the AB backup method for implementing OTA upgrade with a single Flash Bank is characterized in that: When S1 determines whether there is a flashing flag bit, if there is no flashing flag bit, it determines the running area according to the startup process, selects the running area and executes the corresponding firmware; If the flash flag exists, the system enters the flash process.

3. According to claim 1, the AB backup method for implementing OTA upgrade with a single Flash Bank is characterized in that: When S2 selects the execution zone according to the UFB identifier, if the UFB identifier is 0, the firmware in the execution zone 1 is executed; If the UFB flag is 1, the firmware in the running area 2 is executed; if both the running area 1 and the running area 2 are invalid, the system cannot start and stays in the BOOT area.

4. According to claim 1, the AB backup method for implementing OTA upgrade with a single Flash Bank is characterized in that: In step S3, after receiving the flash mark when the BOOT area is waiting or the running area 2 is in operation, the UFB mark is judged. If UFB=1, the data in the running area 1 is erased, and the new firmware data is written into the running area 1. After the new firmware data is written, the data of the running area 1 is verified. If the verification passes, UFB is set to 0 and the MCU is restarted, otherwise it stays in the BOOT area waiting or running area 2; after receiving the flash mark when the BOOT area is waiting or the running area 1 is in operation, the UFB mark is judged. If UFB=0, the data in the running area 2 is erased, and the new firmware data is written into the running area 2. After the new firmware data is written, the data of the running area 2 is verified. If the verification passes, UFB is set to 1 and the MCU is restarted, otherwise it stays in the BOOT area waiting or running area 1.

5. The AB backup method for implementing OTA upgrade with a single Flash Bank according to claim 1, characterized in that: The UFB flag is actively set in the program, and is used to indicate whether the firmware executed by the current program is in the running area 1 or the running area 2.

Images