MCU (Microprogrammed Control Unit) starting method and device, electronic equipment and storage medium
By introducing a fault recovery application during the MCU startup process, the problem of the MCU entering an abnormal state under attack is solved, thereby improving stability and reliability and ensuring normal startup and fault recovery of the MCU.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING JINGWEI HIRAIN TECH CO INC
- Filing Date
- 2026-01-05
- Publication Date
- 2026-05-15
AI Technical Summary
In existing technologies, MCUs are prone to entering abnormal states when attacked by sophisticated technical means, affecting their stability and reliability, and lack effective fault recovery mechanisms.
A fault recovery application is introduced during the MCU startup process. The validity of the system core security storage area, PBL, and application is verified. If a failure occurs, the fault recovery application is started, and the invalid file is overwritten with the target file. The MCU is then restarted until it succeeds.
It reduces the risk of the MCU entering an infinite loop, provides fault recovery capabilities, and ensures the stability and reliability of the MCU.
Smart Images
Figure CN122044949A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of MCU security protection technology, and in particular to a startup method, device, electronic device and storage medium for an MCU. Background Technology
[0002] In the automotive industry, which heavily relies on intelligent and automated control, the safety of MCUs (Microcontroller Units) is particularly important. Failure or malfunction of a core MCU function can lead to extremely serious and significant consequences.
[0003] Related technologies typically focus on effectively mitigating potential attacks, employing a series of preventative measures to ensure the legitimacy and integrity of software to a certain extent, preventing unauthorized tampering. However, if an attacker successfully breaches these defenses using sophisticated techniques or exploiting weaknesses in security mechanisms, the MCU may enter an abnormal state, impacting its stability and reliability. Summary of the Invention
[0004] To address the aforementioned technical problems, this application provides a method, apparatus, electronic device, and storage medium for starting up an MCU.
[0005] According to a first aspect of this application, a method for starting up an MCU is provided, the method comprising: After the MCU is powered on, the executable file of the MCU application is executed to check whether the system core secure memory is valid; if the system core secure memory is invalid, it enters the Dead state; if the system core secure memory is valid, the chip firmware program is started. In the chip firmware program, the validity of PBL (Primary Bootloader) is verified. If PBL is valid, the PBL program is started, and in the PBL program, the validity of the first application APP1 is checked. If APP1 is valid, start APP1 and check if the second application APP2 is valid within APP1; if APP2 is valid, start APP2 and confirm that the MCU has started successfully. If PBL, APP1, or APP2 is invalid, the corresponding startup failure information is determined, and the fault recovery application is started; the fault recovery application does not support modification. In the fault recovery application, obtain the target file corresponding to the startup fault information; The target file is used to overwrite the invalid file in the executable file, the MCU is restarted, and the process of executing the executable file of the MCU application is repeated after the MCU is powered on until the MCU starts successfully.
[0006] Optionally, the MCU startup method further includes: Before launching the fault recovery application, verify that the fault recovery application is effective; If the fault recovery application is valid, then perform the step of launching the fault recovery application; If the fault recovery application fails, an infinite loop will occur.
[0007] Optionally, obtaining the target file corresponding to the startup failure information includes: The system reports the startup failure information to the system-on-a-chip and receives the flashing command issued by the system-on-a-chip. The system responds to the flash command and receives the target file corresponding to the startup fault information issued by the system-on-a-chip.
[0008] Optionally, the startup failure information includes: partition information that failed verification, level information that failed verification, and the last write time of the executable file.
[0009] According to a second aspect of this application, a startup device for an MCU is provided, comprising: The first verification module is used to execute the executable file of the MCU application after the MCU is powered on to check whether the system core secure storage area is valid; if the system core secure storage area is invalid, it enters the Dead state; if the system core secure storage area is valid, it starts the chip firmware program. The second verification module is used to verify the validity of the PBL in the chip firmware program. If the PBL is valid, the PBL program is started. The third verification module is used in the PBL program to check whether the first application APP1 is valid; if APP1 is valid, then APP1 is started. The fourth verification module is used in APP1 to check whether the second application APP2 is valid; if APP2 is valid, then APP2 is started and the MCU is confirmed to have started successfully. The fault recovery application startup module is used to determine the corresponding startup fault information and start the fault recovery application if PBL, APP1, or APP2 is invalid; the fault recovery application does not support modification. The fault recovery application execution module is used to obtain the target file corresponding to the startup fault information in the fault recovery application; use the target file to overwrite the invalid file in the executable file, restart the MCU, return to the first verification module, and continue until the MCU starts successfully.
[0010] Optionally, the MCU startup device further includes: The fault recovery application verification module is used to verify whether the fault recovery application is effective; The fault recovery application startup module is specifically used to determine the corresponding startup fault information and start the fault recovery application if PBL is invalid, or APP1 is invalid, or APP2 is invalid, and the fault recovery application is valid. The infinite loop module is used to enter an infinite loop if the fault recovery application is ineffective.
[0011] Optionally, the fault recovery application execution module is specifically used to obtain the target file corresponding to the startup fault information through the following steps: The system reports the startup failure information to the system-on-a-chip and receives the flashing command issued by the system-on-a-chip. The system responds to the flash command and receives the target file corresponding to the startup fault information issued by the system-on-a-chip.
[0012] Optionally, the startup failure information includes: partition information that failed verification, level information that failed verification, and the last write time of the executable file.
[0013] According to a third aspect of this application, an electronic device is provided, comprising: a processor for executing a computer program stored in a memory, wherein the computer program, when executed by the processor, implements the MCU startup method described in the first aspect.
[0014] According to a fourth aspect of this application, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the MCU startup method described in the first aspect.
[0015] According to a fifth aspect of this application, a computer program product is provided that, when the computer program product is run on a computer, causes the computer to execute the MCU startup method described in the first aspect.
[0016] The technical solution provided in this application has the following advantages compared with the prior art: A fault recovery application is added during the MCU startup process. Specifically, if the PBL, APP1, or APP2 is determined to be invalid, the fault recovery application is activated. Because the fault recovery application is not modifiable and remains in a trusted state, it ensures successful startup even if other applications fail. The fault recovery application retrieves the target file corresponding to the startup fault information. It then overwrites any invalid files in the executable file with the target file, restarts the MCU, and re-executes the MCU startup process using the updated executable file until the MCU starts successfully. This reduces the risk of the chip entering an infinite loop and provides fault recovery capabilities, ensuring the stability and reliability of the MCU. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a schematic diagram of a startup method for an MCU in related technologies; Figure 2 This is a schematic diagram of a startup method for an MCU in an embodiment of this application; Figure 3 This is a flowchart of a startup method for an MCU in an embodiment of this application; Figure 4 This is a flowchart of the fault recovery application in the embodiments of this application; Figure 5 This is a schematic diagram of a MCU startup device in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device in an embodiment of this application. Detailed Implementation
[0020] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.
[0021] Many specific details are set forth in the following description in order to provide a full understanding of this application, but this application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some embodiments of this application, and not all embodiments.
[0022] See Figure 1 , Figure 1 This is a schematic diagram of an MCU startup method in related technologies. After the MCU is powered on, it first executes ROM BOOT (ROM boot program), and then checks whether the system core secure storage area (e.g., SFlash) is valid. If valid, it starts the chip firmware program, such as the Flash Boot program. If invalid, it enters the Dead state, and the faulty chip cannot be recovered. In the chip firmware program, the validity of PBL is checked. If PBL is valid, the PBL program is started. If PBL is invalid, it executes while(1), that is, it enters an infinite loop and no longer executes downwards. The chip will remain in the chip firmware program.
[0023] In the PBL program, the validity of the first application APP1 is checked. If APP1 is valid, it is started; if APP1 is invalid, while(1) is executed, which enters an infinite loop and stops executing further, remaining in the PBL program. In APP1, the validity of the second application APP2 is checked. If APP2 is valid, it is started; if APP2 is invalid, while(1) is executed, which enters an infinite loop and stops executing further, remaining in APP1. If APP2 starts successfully, the MCU is confirmed to have started successfully. Failure of any process will cause the application to completely or partially fail, which will seriously affect the functionality of the MCU.
[0024] In this embodiment, after the application fails to start, a fault recovery application is introduced. This application attempts to restore the MCU to its normal application software state by flashing and rewriting the MCU. See also... Figure 2 , Figure 2This is a schematic diagram of the MCU startup method in an embodiment of this application. After the MCU powers on, it first executes ROM BOOT, then checks whether the system core secure storage area is valid. If valid, the chip firmware program is started; if invalid, it enters a Dead state, and the faulty chip cannot be recovered. In the chip firmware program, the validity of PBL is verified. If PBL is valid, the PBL program is started; if PBL is invalid, the fault recovery application program is started. In the PBL program, the validity of APP1 is checked. If APP1 is valid, APP1 is started; if APP1 is invalid, the fault recovery application program is started. In APP1, the validity of APP2 is verified. If APP2 is valid, APP2 is started; if APP2 is invalid, the fault recovery application program is started. If APP2 starts successfully, the MCU startup is confirmed to be successful.
[0025] It can be seen that the MCU startup process is similar to... Figure 1 The difference in the startup process shown is that when PBL, APP1, or APP2 is invalid, the while (1) loop is no longer executed; instead, the fault recovery application is started. This reduces the chance of the chip entering the while (1) loop. By executing the fault recovery application, the MCU is flashed, attempting to restore the MCU to normal application software. This embodiment of the application can reduce the risk of the chip entering an infinite loop and provides fault recovery capability, ensuring the stability and reliability of the MCU.
[0026] See Figure 3 , Figure 3 This is a flowchart of a method for starting up an MCU according to an embodiment of this application, which may include the following steps: Step S302: After the MCU is powered on, execute the executable file of the MCU application to check whether the system core secure storage area is valid; if the system core secure storage area is invalid, proceed to step S304; if the system core secure storage area is valid, proceed to step S306.
[0027] In this embodiment of the application, the MCU can be started by executing the executable file of the MCU application. For example, it can achieve the following: Figure 1 The startup process of the MCU is shown.
[0028] Step S304: Enter Dead state.
[0029] Step S306: Start the chip firmware program.
[0030] Step S308: Verify the validity of the PBL in the chip firmware program.
[0031] If the PBL is valid, proceed to step S310; if the PBL is invalid, proceed to step S320.
[0032] Step S310: Start the PBL program.
[0033] Step S312: In the PBL program, check whether APP1 is valid.
[0034] If APP1 is valid, proceed to step S314; if APP1 is invalid, proceed to step S320.
[0035] Step S314: Launch APP1.
[0036] Step S316: In APP1, check if APP2 is valid.
[0037] If APP2 is valid, proceed to step S318; if APP2 is invalid, proceed to step S320.
[0038] S318, start APP2 and confirm that the MCU has started successfully.
[0039] Step S320: Determine the corresponding startup fault information and start the fault recovery application; the fault recovery application does not support modification.
[0040] Invalid PBL, invalid APP1, and invalid APP2 represent three different faults. Therefore, when a fault occurs during MCU startup, the MCU can determine the corresponding startup fault information. Subsequently, based on the different startup fault information, the corresponding target file can be obtained for flashing the executable file. Optionally, the startup fault information may include: partition information of the failed verification, level information of the failed verification (e.g., invalid PBL, invalid APP1, and invalid APP2 belong to three different levels), and the previous flashing time of the executable file. During MCU startup, when a fault occurs, the executable file will be flashed, and the executable file may be flashed multiple times. Therefore, the startup fault information can record the previous flashing time.
[0041] The fault recovery application is injected directly into the Code Flash during the production shutdown phase. This application is protected by memory units and can no longer be modified. Therefore, the fault recovery application remains in a trusted state after shutdown. It can be guaranteed to start normally even if other applications fail.
[0042] Optionally, the fault recovery application can be pre-signed, and its validity can be verified before it is launched. If the fault recovery application is valid, the steps to launch it are executed; if it is invalid, it cannot be launched, resulting in an infinite loop.
[0043] Step S322: In the fault recovery application, obtain the target file corresponding to the startup fault information.
[0044] It should be noted that if PBL, APP1, and APP2 are invalid, it indicates that during the execution of the executable file, anomalies in the Code Flash or human attacks may have caused invalid files to be generated within the executable file, ultimately leading to an error during MCU startup. Therefore, the target file corresponding to the startup failure information can be obtained, and subsequently, the invalid file can be overwritten using the target file to re-execute the executable file, thereby ensuring the normal startup of the MCU.
[0045] Optionally, the MCU can report boot failure information to the system-on-a-chip (SoC) via a protocol. Upon receiving the boot failure information from the MCU, the SoC first records it as a safety log, then initiates a recovery process by sending a flash command to the MCU. The MCU can receive and respond to the flash command from the SoC. After receiving the response, the SoC sends the target file corresponding to the boot failure information, which the MCU can then receive.
[0046] Step S324: Overwrite the invalid file in the executable file with the target file, restart the MCU, and return to step S302.
[0047] After overwriting the invalid file in the executable file with the target file, the MCU is restarted and returned to step S302 to re-execute the executable file. Through one or more loops, the MCU is eventually restored to the normal application software state.
[0048] The MCU startup method in this application incorporates a fault recovery application during the MCU startup process. Specifically, when it is determined that the PBL, APP1, or APP2 is invalid, the fault recovery application is activated. Since the fault recovery application is not modifiable and remains in a trusted state, it ensures successful startup even if other applications fail. The fault recovery application retrieves the target file corresponding to the startup fault information. The target file overwrites any invalid files in the executable file, the MCU is restarted, and the MCU startup process is re-executed using the updated executable file until the MCU starts successfully. This reduces the risk of the chip entering an infinite loop and provides fault recovery capabilities, ensuring the stability and reliability of the MCU.
[0049] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.
[0050] This application also provides a startup device for an MCU, see [link to relevant documentation]. Figure 5 The MCU startup device 500 includes: The first verification module 502 is used to execute the executable file of the MCU application after the MCU is powered on to check whether the system core secure storage area is valid; if the system core secure storage area is invalid, it enters the Dead state; if the system core secure storage area is valid, it starts the chip firmware program. The second verification module 504 is used to verify the validity of the PBL in the chip firmware program. If the PBL is valid, the PBL program is started. The third verification module 506 is used to check whether APP1 is valid in the PBL program; if APP1 is valid, then APP1 is started. The fourth verification module 508 is used to check whether APP2 is valid in APP1; if APP2 is valid, then APP2 is started and the MCU is confirmed to have started successfully. The fault recovery application startup module 510 is used to determine the corresponding startup fault information and start the fault recovery application if PBL, APP1, or APP2 is invalid; the fault recovery application does not support modification. The fault recovery application execution module 512 is used to obtain the target file corresponding to the startup fault information in the fault recovery application; use the target file to overwrite the invalid file in the executable file, restart the MCU, return to the first verification module, until the MCU starts successfully.
[0051] Optionally, the MCU startup device 500 further includes: The fault recovery application verification module is used to verify whether the fault recovery application is effective. The fault recovery application startup module 510 is specifically used to determine the corresponding startup fault information and start the fault recovery application if PBL is invalid, or APP1 is invalid, or APP2 is invalid, but the fault recovery application is valid. The Infinite Loop module is used to enter an infinite loop if the fault recovery application fails.
[0052] Optionally, the fault recovery application execution module 512 is specifically used to obtain the target file corresponding to the startup fault information through the following steps: Report startup failure information to the system-on-a-chip (SoC) and receive flashing instructions from the SoC; It responds to flash commands and receives the target file corresponding to the startup fault information issued by the system-on-a-chip.
[0053] Optionally, the startup failure information includes: partition information where verification failed, level information where verification failed, and the last write time of the executable file.
[0054] The specific details of each module or unit in the above-mentioned device have been described in detail in the corresponding methods, so they will not be repeated here.
[0055] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0056] This application also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the MCU startup method described in this example embodiment.
[0057] Reference Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device.
[0058] like Figure 6 As shown, the electronic device may include: a processor 602, a communication interface 604, a memory 606, and a communication bus 608.
[0059] The processor 602, communication interface 604, and memory 606 communicate with each other via communication bus 608.
[0060] Communication interface 604 is used for communication with other electronic devices or servers.
[0061] The processor 602 is used to execute program 610, specifically to perform the relevant steps in the above method embodiments.
[0062] Specifically, program 610 may include program code that includes computer operation instructions.
[0063] Processor 602 may be a central processing unit, a specific integrated circuit, or one or more integrated circuits configured to implement the embodiments of this application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.
[0064] Memory 606 is used to store program 610. Memory 606 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0065] Specifically, program 610 can be used to cause processor 602 to execute the steps in the above-described MCU startup method embodiment.
[0066] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.
[0067] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described MCU startup method.
[0068] It should be noted that the computer-readable storage medium shown in this application can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, radio frequency, etc., or any suitable combination thereof.
[0069] In this embodiment of the application, a computer program product is also provided, which, when run on a computer, causes the computer to execute the above-described MCU startup method.
[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0071] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for starting up an MCU, characterized in that, The method includes: After the microcontroller unit (MCU) is powered on, the executable file of the MCU application is executed to check whether the system core secure memory is valid; if the system core secure memory is invalid, it enters the Dead state; if the system core secure memory is valid, the chip firmware program is started. In the chip firmware program, the validity of the primary bootloader PBL is verified. If the PBL is valid, the PBL program is started, and in the PBL program, the validity of the first application APP1 is checked. If APP1 is valid, start APP1 and check if the second application APP2 is valid within APP1; if APP2 is valid, start APP2 and confirm that the MCU has started successfully. If PBL, APP1, or APP2 is invalid, the corresponding startup failure information is determined, and the fault recovery application is started; the fault recovery application does not support modification. In the fault recovery application, obtain the target file corresponding to the startup fault information; The target file is used to overwrite the invalid file in the executable file, the MCU is restarted, and the process of executing the executable file of the MCU application is repeated after the MCU is powered on until the MCU starts successfully.
2. The method according to claim 1, characterized in that, The method further includes: Before launching the fault recovery application, verify that the fault recovery application is effective; If the fault recovery application is valid, then perform the step of launching the fault recovery application; If the fault recovery application fails, an infinite loop will occur.
3. The method according to claim 1, characterized in that, The step of obtaining the target file corresponding to the startup failure information includes: The system reports the startup failure information to the system-on-a-chip and receives the flashing command issued by the system-on-a-chip. The system responds to the flash command and receives the target file corresponding to the startup fault information issued by the system-on-a-chip.
4. The method according to claim 1, characterized in that, The startup failure information includes: partition information that failed verification, level information that failed verification, and the last write time of the executable file.
5. A startup device for an MCU, characterized in that, The device includes: The first verification module is used to execute the executable file of the MCU application after the microcontroller unit (MCU) is powered on, in order to check whether the system core secure storage area is valid; if the system core secure storage area is invalid, it enters the Dead state; if the system core secure storage area is valid, it starts the chip firmware program. The second verification module is used to verify the validity of the primary bootloader (PBL) in the chip firmware program. If the PBL is valid, the PBL program is started. The third verification module is used in the PBL program to check whether the first application APP1 is valid; if APP1 is valid, then APP1 is started. The fourth verification module is used in APP1 to check whether the second application APP2 is valid; if APP2 is valid, then APP2 is started and the MCU is confirmed to have started successfully. The fault recovery application startup module is used to determine the corresponding startup fault information and start the fault recovery application if PBL, APP1, or APP2 is invalid; the fault recovery application does not support modification. The fault recovery application execution module is used to obtain the target file corresponding to the startup fault information in the fault recovery application; use the target file to overwrite the invalid file in the executable file, restart the MCU, return to the first verification module, and continue until the MCU starts successfully.
6. The apparatus according to claim 5, characterized in that, The device further includes: The fault recovery application verification module is used to verify whether the fault recovery application is effective; The fault recovery application startup module is specifically used to determine the corresponding startup fault information and start the fault recovery application if PBL is invalid, or APP1 is invalid, or APP2 is invalid, and the fault recovery application is valid. The infinite loop module is used to enter an infinite loop if the fault recovery application is ineffective.
7. The apparatus according to claim 5, characterized in that, The fault recovery application execution module is specifically used to obtain the target file corresponding to the startup fault information through the following steps: The system reports the startup failure information to the system-on-a-chip and receives the flashing command issued by the system-on-a-chip. The system responds to the flash command and receives the target file corresponding to the startup fault information issued by the system-on-a-chip.
8. The apparatus according to claim 5, characterized in that, The startup failure information includes: partition information that failed verification, level information that failed verification, and the last write time of the executable file.
9. An electronic device, characterized in that, include: A processor for executing a computer program stored in a memory, wherein the computer program, when executed by the processor, implements the method of any one of claims 1-4.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-4.