A method and apparatus for starting an MCU system

Abstract

The application discloses an MCU system starting method and device, and relates to the technical field of electronics. In the method, after the MCU is powered on or reset, a bottom layer boot program in a read-only storage area in the MCU is run. After the bottom layer boot program verifies that a driver upgrade program in an erasable storage area in the MCU is correct, the driver upgrade program is run. After the driver upgrade program verifies that a service program in a scalable storage area in the MCU is correct, the service program is run. The embodiment of the application can improve the safety of MCU starting.

Description

Technical Field

[0001] This invention relates to the field of electronic technology, and specifically to a method and apparatus for starting up an MCU system. Background Technology

[0002] With the development of modern technology, MCU (Microcontroller Unit) systems are now essential for applications in electrical appliances, automobiles, smart terminals, and industries. An MCU integrates a central processing unit, memory, and programmable input / output interfaces onto a single chip, enabling it to independently execute preset control logic and algorithms with extremely low power consumption and cost.

[0003] In related technologies, traditional single-stage boot MCUs have been gradually replaced by more flexible two-stage boot MCUs. Two-stage boot MCUs use two independent boot programs: a firmware boot program and a user-defined boot program. The firmware boot program initializes the MCU and, after initialization, determines whether the second-stage boot program is executable. If executable, it jumps to the user-defined boot program to verify, upgrade, and execute programs, enabling the MCU to have remote upgrade and fault recovery capabilities.

[0004] However, in the two-level jump, complex logic such as firmware upgrade, hardware self-test, and fault repair can only be squeezed into two independent boot programs. The boundaries of these functional modules are blurred and the coupling is high, which makes the security risks of the boot program that mainly carries the business concentrated and easy to be directly attacked and tampered with. Summary of the Invention

[0005] This invention provides an MCU system startup method and apparatus, which can improve the security of MCU startup.

[0006] To address the aforementioned problems, this invention discloses an MCU system startup method, the method comprising: After powering on or resetting the MCU, the low-level boot program in the read-only memory area of ​​the MCU is run; after the low-level boot program successfully verifies the driver upgrade program in the erasable memory area of ​​the MCU, the driver upgrade program is run; after the driver upgrade program successfully verifies the business program in the expandable memory area of ​​the MCU, the business program is run.

[0007] On the other hand, embodiments of the present invention disclose an MCU system startup device, the device comprising: The low-level runtime module is used to run the low-level boot program in the read-only memory area of ​​the MCU after the MCU is powered on or reset.

[0008] The driver execution module is used to call the underlying bootloader to run the driver upgrade program after the driver upgrade program in the erasable and writable memory area of ​​the MCU has been successfully verified.

[0009] The business operation module is used to call the driver upgrade program to run the business program after the business program in the expandable storage area of ​​the MCU has been successfully verified.

[0010] In another aspect, embodiments of the present invention disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to execute the aforementioned method.

[0011] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described above.

[0012] This invention also discloses a computer program product, including a computer program for implementing the above-described MCU system startup method.

[0013] The embodiments of this invention have the following advantages: By isolating the MCU's storage area in three hardware layers, the underlying boot program is placed in the read-only memory area, reducing memory resource consumption and minimizing the risk of tampering with the underlying boot program. The driver upgrade program is placed in the erasable memory area, enabling flexible repair and upgrades, increasing the maintainability of the MCU startup cycle. The business program is placed in the expandable memory area, allowing dynamic adjustment of resource allocation and providing more flexible space for data resources generated during business program operation. When the MCU is powered on, the first layer executes the underlying boot program in the read-only memory area. After execution, the driver upgrade program in the second layer erasable memory area is verified. If the verification passes, the second layer is executed. After execution, the second layer verifies the business program in the third layer expandable memory area, thus realizing a step-by-step MCU startup process. During the startup process, a trust chain for security verification is added, reducing coupling between modules. The addition of the driver upgrade program provides driver isolation between the first-layer underlying boot program and the third-layer business program, separating critical business programs and dispersing security risks. This makes the MCU as a whole less susceptible to direct attack, providing a safe and reliable execution method for the MCU startup process. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below.

[0015] Figure 1This is a schematic diagram of the MCU startup process provided in an embodiment of the present invention; Figure 2 This is a flowchart of the steps of an MCU system startup method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a step-by-step startup process for an MCU system provided in an embodiment of the present invention; Figure 4 This is a block diagram of an MCU system startup device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0019] This application embodiment is applied to an electronic device, which includes an MCU. When the electronic device starts working, it also provides an electrical signal to the MCU, which is powered on. After power-on, the MCU starts up, and the corresponding application program starts up, driving the actuator to perform actions to complete the function of the electronic device.

[0020] Figure 1 This is a schematic diagram of the MCU startup process provided in an embodiment of this application, with reference to... Figure 1 As shown, the MCU internally includes a POR (Power-On Reset) circuit, a CPU (Central Processing Unit), and memory. The POR is a hardware circuit used to monitor voltage. The CPU is the main execution unit, processing each instruction through the arithmetic logic unit (ALU). The memory includes BootROM (Boot Read-Only Memory), Flash Memory, and SRAM (Static Random Access Memory). When the MCU is powered on, external power is supplied, the POR detects the voltage, and once the voltage stabilizes, it releases a reset signal, waking the CPU. The CPU's PC (Program Counter) is forced by hardware to point to the starting address of the BootROM, and the CPU begins fetching instructions from the BootROM to execute the boot code. After the BootROM finishes executing, it guides the CPU to jump to the Flash area. The CPU reads the first two words of the interrupt vector table from the Flash starting address. The first word is loaded into the SP (Stack Pointer), and the second word is loaded into the PC, which points to the function address in the Flash. The CPU then begins executing the application program. During application execution, the CPU frequently reads and writes to SRAM to access the stack, global variables, and temporary data.

[0021] The aforementioned MCU startup process involves directly executing the bootloader in Flash memory upon power-up, completing initialization and verification, and then jumping directly to the application program. This is a fixed startup method uniformly booted by the BootROM. However, this startup method integrates initialization, verification, and business logic, resulting in severe coupling, maintenance difficulties, and complex logic crammed into a single bootloader. The blurred boundaries between functional modules and high coupling concentrate security risks within the bootloader, making it vulnerable to concentrated attacks. Therefore, providing a secure and reliable method for the MCU startup process is crucial.

[0022] To address the aforementioned issues, this application proposes an MCU system startup method and apparatus. By implementing three-layer hardware isolation of the MCU's storage area, the underlying boot program is placed in the read-only storage area, reducing memory resource consumption and minimizing the risk of tampering with the underlying boot program. The driver upgrade program is placed in the erasable and writable storage area, enabling flexible repair and upgrades and increasing the maintainability of the MCU startup cycle. The business program is placed in the expandable storage area, allowing for dynamic adjustment of resource allocation and providing more flexible space for data resources generated during business program execution. When the MCU is powered on, the first layer executes the low-level boot program in the read-only memory area. After execution, it verifies the driver upgrade program in the second-layer erasable and writable memory area. If the verification passes, the second layer is executed. After the second layer is completed, it verifies the business program in the third-layer expandable memory area. This realizes the step-by-step MCU startup process. During the startup process, the functional layers are clearly defined, the trust chain of security verification is increased, and the coupling between modules is reduced. The addition of the driver upgrade program enables driver isolation between the first-layer low-level boot program and the third-layer business program, separating the critical business programs and dispersing security risks. This makes the MCU as a whole less likely to be directly compromised, providing a safe and reliable execution method for the MCU startup process.

[0023] Figure 2 This is a flowchart illustrating the steps of an MCU system startup method provided in an embodiment of this application, as follows: Figure 2 As shown, the method may include the following steps: S101. After powering on or resetting the MCU, run the low-level boot program in the read-only memory area of ​​the MCU.

[0024] S102. After the underlying bootloader successfully verifies the driver upgrade program in the erasable memory area of ​​the MCU, it runs the driver upgrade program.

[0025] S103. After the driver upgrade program successfully verifies the business program in the expandable storage area within the MCU, it runs the business program.

[0026] Specifically, during MCU programming, the MCU's storage area is divided into three regions. These three regions are physically separated, meaning their addresses, permissions, and operating spaces have no overlap. The three regions are: a read-only memory area, an erasable / writable memory area, and an expandable memory area. The read-only memory area represents the storage area where the MCU's content is fixed at the factory; its content can only be read, not modified or written to. The erasable / writable memory area represents the storage area where the content can be repeatedly modified or new content can be written. The expandable memory area represents the storage area whose storage capacity can be dynamically adjusted according to actual needs. In this application, the read-only memory area corresponds to the BootROM in the MCU and the low-address protection partition in the Flash memory; the erasable / writable memory area corresponds to the area outside the low and high addresses in the on-chip Flash memory of the MCU; and the expandable memory area corresponds to the high-address independent partition in the Flash memory.

[0027] Among them, the low address protection partition in Flash is located at the beginning address of Flash, has hardware-level write protection, and cannot be modified. On-chip Flash refers to the entire Flash inside the MCU itself. The high address independent partition in Flash is located at the later address of Flash and can be freely erased and written.

[0028] The read-only memory area stores the underlying bootloader, which is mainly responsible for the system initialization of the entire MCU. The erasable and rewritable memory area stores the driver upgrade program, which mainly drives the business programs in the next layer. The expandable memory area stores the business programs, which are the application programs responsible for implementing core functions, and their functions can be expanded.

[0029] When the MCU is powered on or reset, the underlying bootloader in the read-only memory area is run first. While the bootloader is running, it reads and verifies the driver upgrade program in the next-level erasable / writable memory area. Once the verification is successful, it jumps to the driver upgrade program to begin execution. While the driver upgrade program is running, it reads and verifies the business logic program in the next-level expandable memory area. Once the verification is successful, it jumps to the business logic program to begin execution.

[0030] When the business program runs, resources are reconfigured. This includes reallocating interrupt priorities based on business needs, enabling necessary communication interfaces and sensor drivers, initializing the application layer protocol stack, and loading factory default parameters and user-defined configurations. Specifically, relocating interrupt priorities involves planning and grouping various interrupt sources according to business requirements to ensure optimal execution of critical tasks. Necessary communication interfaces and sensor drivers include, but are not limited to, various communication peripherals and front-end data acquisition devices. Initializing the application layer protocol stack ensures data exchange capabilities between nodes. Loading factory default parameters and user-defined configurations prioritizes user-defined configurations, using factory default parameters as a fallback to ensure correct device identity after power-on. During business program execution, a main loop is started, performing routine functions such as periodic data acquisition, regular watchdog timer feeding, and real-time monitoring of operational status. The entire operational status is recorded during operation, including but not limited to startup duration, jump records, and exceptions, to ensure data is not lost when the MCU is powered off, facilitating later device debugging, after-sales maintenance, and functional optimization.

[0031] For example, after the MCU is powered on, during startup, the POR confirms that the voltage is stable and then releases the reset signal. The hardware completes the POR reset, the underlying boot program starts to start, the CPU reads the first instruction from the BootROM and executes it, checks the boot environment, and then the CPU jumps from the BootROM to the Flash, reads the interrupt vector table from the Flash, loads the SP and PC, and the PC points to the first instruction. The first instruction is used to initialize the runtime environment of the next-level driver upgrade program.

[0032] After the underlying bootloader completes its run and the driver upgrade program passes verification, the CPU locates the starting address of the driver upgrade program. It first initializes the MCU's peripheral modules sequentially and configures the communication baud rate, filtering parameters, and interrupt priorities. Here, peripheral modules refer to the functional units integrated within the MCU (such as timers, serial ports, etc.), the communication baud rate refers to the data transmission speed, the filtering parameters are settings for filtering received signals, and the interrupt priority refers to the order of priority responses when multiple interrupts occur simultaneously. Next, a hardware self-test is performed, primarily responsible for assessing the MCU's status after startup. Then, the business program in the expandable memory area is read and verified to determine if the program is executable and if the program's operating environment is normal.

[0033] After the driver upgrade program completes its run and the business program passes the verification, the CPU locates the starting address of the business program to execute it, starts the main business loop, and records the startup time, jump records, results, and exception events in real time.

[0034] In this embodiment of the invention, the storage area of ​​the MCU is isolated in three layers at the hardware level. When the MCU is powered on, the first layer executes the low-level boot program in the read-only memory area. After execution, the driver upgrade program in the second-layer erasable and writable memory area is verified. After the verification is passed, the second layer is executed. After the execution is completed, the second layer verifies the business program in the third-layer expandable memory area. This realizes the step-by-step MCU startup process, with clear functional layering. The second-layer driver upgrade program connects the lower-level boot program and the upper-layer business program, separating the key business programs and thus dispersing security risks, making the MCU as a whole less likely to be directly compromised.

[0035] Regarding MCU system startup methods, one related technology, for the widely used two-level jump startup MCU, uses two independent boot programs. When the MCU powers on, the first firmware boot program initializes the MCU and then verifies the executability of the second user boot program. If the verification passes, it jumps to the user boot program for execution, allowing the MCU to be remotely upgraded or repaired via peripherals. However, this solution uses only two boot programs to implement complex logic such as firmware upgrades, hardware self-tests, and fault repair. The functional boundaries are blurred, and the coupling is high, concentrating security risks in a single boot program, making it easy to directly attack and tamper with. This invention addresses this by implementing three layers of hardware-level isolation for the MCU's storage area. The underlying boot program is placed in read-only memory, reducing memory resource consumption and minimizing the risk of tampering. The driver upgrade program is placed in erasable / writable memory, enabling flexible repair and upgrades, increasing the maintainability of the MCU startup cycle. The business program is placed in expandable memory, allowing dynamic adjustment of resource allocation and providing more flexible space for data resources generated during business program execution. When the MCU is powered on, the first layer executes the low-level boot program in the read-only memory area. After execution, it verifies the driver upgrade program in the second-layer erasable and writable memory area. If the verification passes, the second layer is executed. After the second layer is completed, it verifies the business program in the third-layer expandable memory area. This realizes the step-by-step MCU startup process. During the startup process, the functional layers are clearly defined, the trust chain of security verification is increased, and the coupling between modules is reduced. The addition of the driver upgrade program enables driver isolation between the first-layer low-level boot program and the third-layer business program, separating the critical business programs and dispersing security risks. This makes the MCU as a whole less likely to be directly compromised, providing a safe and reliable execution method for the MCU startup process.

[0036] Optionally, the underlying bootloader includes the following processes: system initialization, global security component initialization, driver upgrade program verification, jump control, and first exception handling; wherein, jump control is used to jump to the driver upgrade program; the driver upgrade program includes the following processes: peripheral initialization, hardware self-test, working mode recognition and business program verification, security processing, and second exception handling.

[0037] Specifically, the underlying bootloader mainly includes: system initialization, global security component initialization, driver upgrade program verification, jump control, and first exception handling. System initialization primarily involves configuring the system core clock source to provide a stable clock reference, clearing the reset flag for subsequent fault diagnosis, initializing SRAM to remove residual interference, restoring the default values ​​of the heap pointer and stack pointer in the kernel registers, and the interrupt vector table offset, and then performing basic checks on each power domain to ensure power stability, thus ensuring the MCU's most basic operating conditions through hardware boot. Global security component initialization primarily initializes the operating environment for the next-level driver upgrade program. Driver upgrade program verification verifies the integrity, legality, and untampered state of the driver upgrade program. Jump control is mainly responsible for jumping to the next-level driver upgrade program. First exception handling includes handling exceptions such as data read failure, verification failure, invalid address, and jump instruction execution timeout.

[0038] The driver upgrade program mainly includes: peripheral initialization, hardware self-test, working mode recognition and business program verification, security processing, and secondary exception handling. Among them, peripheral initialization is mainly the unified scheduling and management of peripheral hardware resources. When the driver upgrade program starts running, it first initializes all peripherals in the order from the bottom layer to the top layer and from the basic to the functional. This includes the power management module, IO (Input / Output) ports, timers, watchdog timers, serial ports, CAN (Controller Area Network) controllers, storage read / write units, external expansion peripherals, configuration bus communication baud rate, filtering parameters, and interrupt priority grouping, so as to complete the unified scheduling and management of hardware resources. The power management module supplies power to the MCU and regulates its voltage. The I / O ports are a set of control registers that use the configured physical pins as inputs (read signals) or outputs (write signals). The timer is a counter that generates periodic interrupts. The watchdog timer is a hardware timer inside the MCU that is used to reset the program periodically (feed the watchdog). If it is not fed within a timeout period, a forced reset will be triggered. The serial port is used to transmit and receive data between devices. The CAN controller is used for differential bus data transmission and reception. The external expansion peripherals are functional chips connected to the outside of the MCU. The bus communication baud rate configuration is used to set the data transmission rate of the bus. The filtering parameters are used to shield specific data. The interrupt priority grouping is used to group interrupt sources according to priority and determine the priority response order.

[0039] Hardware self-test mainly performs unified status and fault detection on the entire MCU hardware. This includes: detecting the operating status of the chip core, the range of power supply voltage fluctuations, the health status of each memory area, the connectivity of peripheral paths, communication bus faults, and the cause of abnormal resets. At the same time, the MCU will also collect the operating parameters of multiple hardware modules throughout the process, generate hardware self-test logs based on the hardware operating parameters, and encrypt and store these logs to provide a basis for subsequent fault diagnosis.

[0040] Operating mode identification is the process by which the MCU automatically identifies the current operating mode through hardware pins, hardware registers, peripheral interfaces, and Flash data. The main operating modes include: normal startup mode, remote upgrade mode, local flashing mode, and fault repair mode.

[0041] Business program verification mainly verifies the integrity, legality, and unaltered status of the business program, as well as whether the program's runtime environment is normal. Security handling primarily focuses on in-depth security protection before the driver upgrade program jumps to the business program.

[0042] For example, driver upgrade program verification can employ SHA256 (Secure Hash Algorithm 256-bit) hashing combined with ECDSA (Elliptic Curve Digital Signature Algorithm) encryption and decryption algorithms. During MCU production, the original driver upgrade program image is first signed using an ECDSA algorithm with the private key. This signature, along with the public key, is then burned into the MCU's Flash memory, and the private key is stored securely. Upon power-up, the driver upgrade program image is retrieved, and the hash value H1 corresponding to the image is obtained using the SHA256 encryption algorithm. The signature and public key are retrieved from the pre-stored location in the Flash memory. The signature is then verified using the ECDSA algorithm with the public key to obtain the hash value H2. The values ​​of H1 and H2 are compared; if they are equal, the verification passes, validating the overall integrity of the program.

[0043] For business program verification methods, in addition to verifying program integrity using the methods mentioned above, length verification, cyclic redundancy check, version verification, and permission verification are also used to verify the size, integrity, and version compliance of the business program. Simultaneously, the application partition storage space and read / write status are verified to ensure the normal state of the business program's runtime space. Specifically, length verification checks whether the length recorded in the image file matches the actual length; cyclic redundancy check checks whether the checksum calculated using cyclic redundancy in the image file matches the checksum of the recorded file; version verification checks whether the version number of the recorded file matches the preset version number; permission verification checks whether the hash value calculated based on the image file matches the hash value generated through signature operations; application partition storage space verification checks whether the physical address boundary of the record matches the physical address in the read-only storage area; and read / write status verification checks whether the read and written data matches the original data.

[0044] In this embodiment of the invention, the underlying bootloader configures the MCU's underlying hardware logic through system initialization, global security component initialization, driver upgrade program verification, jump control, and first exception handling. It retains only minimal initialization logic, reducing memory resource consumption, minimizing the risk of the underlying bootloader being tampered with, and laying a solid hardware foundation for the next-layer driver upgrade program. The driver upgrade program performs a series of driver booting and verification processes before jumping to the business program, including peripheral initialization, hardware self-test, working mode identification and business program verification, security processing, and second exception handling. It connects the lower-layer bootloader with the upper-layer business program, separates critical business programs, and disperses security risks.

[0045] Optionally, system initialization includes: configuring the system core clock source, clearing the reset flag, initializing memory, resetting registers, and basic power domain detection; global security component initialization includes: disabling the global interrupt master switch, disabling the VIC (Vectored Interrupt Controller) interrupt channel, disabling the debug interface, disabling the on-chip hardware watchdog, disabling the automatic transfer path of direct memory access DMA, clearing the CPU cache, and clearing the system exception flag.

[0046] Specifically, the system initialization process includes: configuring the system core clock source, clearing the reset flag, initializing memory, resetting registers, and performing basic power domain checks.

[0047] The configuration process for the system's core clock source is as follows: After the external crystal oscillator (HSE, High-Speed ​​External) stabilizes, a phase-locked loop (PLL, Phase-Locked Loop) is configured to multiply the frequency of the external crystal oscillator to the highest frequency allowed by the CPU. Ideally, the system clock source should be switched from each RC oscillator (Resistor-Capacitor Oscillator) of the MCU to the PLL output, so that the CPU and peripherals operate at the optimal frequency.

[0048] The reset flag clearing process is as follows: When the MCU starts up, it first reads the internal reset flag register. If there is a value in the register, all flag bits are cleared to zero. The reset flag register is used to record the reason for the last reset (power-on reset, external pin reset, watchdog reset, software reset, etc.).

[0049] The memory initialization process is as follows: When the MCU starts up, all areas in the SRAM containing uninitialized global variables and static variables are cleared to zero, that is, all unassigned variables are initialized to 0. Then, global variables with initial values ​​are copied from Flash to the corresponding target address in SRAM so that the program can correctly read and write these variables.

[0050] The register reset process is as follows: During MCU startup, the interrupt vector table register points to the interrupt vector table of the driver upgrade program. Then, all interrupt enable functions are disabled, all pending interrupts are cleared, and legacy coprocessors and timers are disabled, thereby restoring the kernel registers to their initial state. Here, kernel registers refer to the registers inside the CPU core used to control interrupts and system behavior. Interrupt enable means that an interrupt source is allowed to send a request to the CPU. An interrupt indicates that the CPU is triggered by an external event request, thus pausing current execution and automatically triggering the handling of the external event.

[0051] The basic power domain detection process is as follows: When the MCU starts up, the current state of each voltage domain is detected through the power control register. If an abnormal voltage is detected, protection measures are executed (such as frequency reduction operation, shutdown of unnecessary peripherals, etc.).

[0052] For example, when the MCU starts up, it first configures the system clock tree, switching the clock source from the internal RC oscillator to an external crystal oscillator that has been multiplied by a PLL, thereby establishing a high-precision working clock. Then, it reads the reset flag register and clears its contents, initializes the SRAM by clearing the .bss segment (Block Started by Symbol) and relocating the .data segment (Initialized Data Segment) from Flash to SRAM. Then, it sets the core key registers such as NVIC (Nested Vectored Interrupt Controller) and SCB (System Control Block) to their default states. Finally, it checks the status of the core and analog voltage domain through the power control register to confirm that the power supply is normal.

[0053] The process of initializing the global security components includes: disabling the global interrupt master switch, disabling the VIC mounted interrupt channel, disabling the debug interface, disabling the on-chip hardware watchdog, disabling the automatic transfer path of direct memory access (DMA), clearing the CPU cache, and clearing the system exception flag.

[0054] The process of disabling the global interrupt master switch is as follows: The CPU's priority mask register is set to 1, causing the CPU to ignore all maskable interrupts and preventing incomplete cleanup and data residue caused by interrupt triggering during initialization. Specifically, setting the priority mask register to 1 means the CPU will ignore all interrupts with configurable priorities and only respond to non-maskable interrupts or hardware errors.

[0055] The VIC interrupt channel disabling process is as follows: Although the above process turns off the main interrupt switch, interrupt enable bits and pending states may still remain. To avoid this, it is necessary to traverse all interrupt enable registers, clear their enable bits one by one, and clear all interrupt pending states. The interrupt enable register is a set of 32-bit registers, where each bit controls an independent interrupt source switch.

[0056] The process of disabling the debug interface involves switching the pins of the JTAG (Joint Test Action Group) and SWD (Serial Wire Debug) debug interfaces from debug mode to general-purpose GPIO (General-Purpose Input / Output) mode, or directly disabling the debug interface. Here, JTAG represents the chip debug and programming interface, and SWD represents a simplified debug interface based on JTAG.

[0057] The on-chip hardware watchdog timer shutdown process is as follows: Configure the watchdog control register to disable both the independent watchdog and the window watchdog. The independent watchdog is driven by an internal low-speed clock and only needs to be fed before the counter reaches zero; it is used to detect and reset serious faults (such as program crashes). The window watchdog is driven by the system clock and needs to be fed strictly according to a specific window time; it is used to detect logical errors in the program (such as execution timing anomalies).

[0058] The automatic transfer path disabling process for Direct Memory Access (DMA) is as follows: disable all DMA (Direct Memory Access) controllers, turn off the enable bits of each data stream / channel, and clear interrupt flags such as transfer completion and transfer error to prevent incomplete DMA transfers before jumping to the driver upgrade program. DMA is a data transfer engine that runs independently of the CPU.

[0059] The CPU cache clearing process involves executing a cache clearing instruction to empty all contents of the instruction cache and data cache, preventing residual instructions from being misread.

[0060] The system exception flag clearing process is as follows: clear the residual states in the system exception control register, such as exception suspension, exception return, etc., and clear the flag bits in the fault status register to prevent residual flag bits from triggering new exceptions.

[0061] For example, when the MCU starts up, after the system initialization is completed, the priority mask register is set to 1, and all interrupt sources are traversed, their enable bits and pending states are cleared one by one, then the option byte or GPIO multiplexing register is configured, the JTAG / SWD pin is switched to normal GPIO mode, the watchdog is fed once, the watchdog enable bit is cleared, all DMA data streams (DMA1, DMA2, DMA3) are disabled, the transfer completion and error interrupt flags are cleared, the buffer is cleared, and all flag bits in the fault status register (CFSR, HFSR, MMFAR, BFAR) are cleared.

[0062] In this embodiment of the invention, by configuring the system core clock source, the CPU's operating speed and the timer's timing accuracy are ensured. By clearing the reset flag, the correct determination of the next reset source is ensured. Memory initialization ensures the logical correctness of the program. By resetting registers, the stability of program operation is ensured. By detecting the power supply, the reliability of program operation is ensured, establishing a stable and reliable underlying hardware operating environment for the next-layer driver upgrade program. Initialization operations using global security components avoid any state interference during startup that could affect the subsequent driver upgrade program's operation, ensuring that the subsequent operation takes place in a clean, residue-free hardware environment.

[0063] Optionally, the jump control includes: Set the stack pointer in the MCU to the temporary safe stack, which is used to initialize the runtime environment of the driver upgrade program; set the program counter of the MCU to the address of the driver upgrade program in the erasable memory area.

[0064] Specifically, when the underlying bootloader jumps to the driver upgrade program, the stack pointer in the MCU is changed from its current value (the old stack, containing previous return addresses, local variables, etc.) to point to the top of a predefined temporary safe stack. This temporary safe stack is a pre-allocated independent memory area in the MCU used to initialize the runtime environment for the next driver upgrade program. The switched stack space is an independent, empty stack without data, ensuring that all execution actions are not interfered with by residual data from the old stack before switching to the final application stack. The initialization program is executed in the temporary safe stack. After initialization, the stack pointer switches to the final stack, and the program counter jumps from the currently executing instruction address to the new address, thus executing the program at the new address, which is the address of the driver upgrade program in the erasable memory area.

[0065] For example, before the switch, the stack space is occupied by the underlying bootloader. The old stack contains the return address and local variables. After the switch, the stack top changes from SP=0x20007FC0 to SP=0x20004000. The new stack has no data, and the program counter points to the address of the driver upgrade program.

[0066] In this embodiment of the invention, by directing the stack pointer to a temporary safe stack when the underlying bootloader jumps to the driver upgrade program, it is ensured that the operation of the underlying bootloader will not fail due to old stack overflow or data corruption in the final stage before the jump, thus ensuring the correct alignment of the stack pointer, effectively realizing the safe isolation of the stack, and guaranteeing the reliability of environment initialization.

[0067] Optionally, the first exception handling includes: When an exception occurs in the underlying bootloader, perform at least one cold reset retry; after N cold reset retry attempts fail, lock the system running state and peripheral outputs, where N is an integer greater than or equal to 1.

[0068] Specifically, during the execution of the underlying bootloader, if an abnormal situation occurs, the corresponding underlying fault code is recorded, and a cold reset is performed for retry. If the abnormal situation persists after N cold resets, a lock is triggered. The locked objects include the system operating status and peripheral outputs. Simultaneously with the lock, a corresponding fault log and abnormal message are generated based on the aforementioned underlying fault code. The log is retained, and an alarm is triggered, which can be triggered by hardware indicator lights or other methods. Here, N is a set value representing the maximum number of cold resets that can be performed; its value is greater than or equal to 1, ensuring that at least one cold reset is performed to restore the system when an abnormality occurs.

[0069] For example, during MCU startup, the underlying bootloader verifies the driver upgrade program. If data reading fails during verification, a cold reset is performed for retry. If a cold reset fails three times consecutively, a lock is triggered. If all three cold reset retries fail, the system's operating status and peripheral outputs are locked. The corresponding underlying fault code and fault log are recorded, and hardware indicator lights illuminate as an alarm.

[0070] In this embodiment of the invention, the handling of exceptions by the underlying bootloader increases the overall fault tolerance of the MCU. The limited number of cold reset retries is set to prevent repeated invalid cold resets. This allows the CPU to capture, record and safely handle exceptions in a timely manner when it detects an abnormal situation, preventing system crashes or physical damage.

[0071] Optionally, the first exception handling also includes: After the driver upgrade program fails to be verified, the reason for the failure is recorded in the spare partition of the erasable memory area, and the spare driver upgrade program in the spare partition is run. The spare driver upgrade program is used to repair the driver upgrade program based on the reason for the failure in the spare partition.

[0072] Specifically, when the MCU leaves the factory, its corresponding erasable and writable memory area is directly divided into two partitions: a primary partition and a backup partition. During normal MCU startup, the driver upgrade program executes in the primary partition. If the underlying bootloader fails to verify the driver upgrade program, it switches to the backup partition to retrieve the backup driver upgrade program, re-verifies it, and performs a jump, recording the reason for the verification failure in the backup partition. When the backup driver upgrade program executes normally after the jump, it retrieves the reason for the verification failure left by the underlying bootloader in the backup partition and repairs the driver upgrade program based on the reason. Upon the next MCU startup, the repaired driver upgrade program in the primary partition can then be executed.

[0073] For example, during MCU startup, the underlying bootloader verifies the driver upgrade program. The erasable and writable memory area corresponding to the driver upgrade program includes area A and area B. Verification is performed before the underlying bootloader jumps to area A. If the verification fails, the bootloader jumps to retrieve the backup driver upgrade program in area B for verification. If the verification passes, the bootloader jumps directly to area B to execute the backup driver upgrade program normally and leaves the verification failure reason in area B. During the execution of area B, the bootloader will read the verification failure reason and then repair area A according to its description.

[0074] In this embodiment of the invention, by designing a dual-partition for the erasable and writable storage area where the driver upgrade program is located, the redundancy of physical storage space reduces the probability of program crashes. At the same time, it can repair itself according to the reason for verification failure, giving the MCU an automated fault recovery capability, reducing the later maintenance cost. In addition, the dual partition also adds a backup strategy, which can also automatically roll back in case of failure, thus improving the overall availability of the system program.

[0075] Optionally, the second exception handling includes: The driver upgrade program will rerun or jump to the underlying boot program in the preset running state. The preset running state includes at least one of the following: upgrade state, parameter calibration state, and fault state.

[0076] Specifically, during driver upgrade program operation, in addition to the normal operating state, some other states may occur, including but not limited to upgrade state, parameter calibration state, and fault state. These abnormal operating states are collectively referred to as preset operating states. When the driver upgrade program is in a preset operating state, it indicates that the driver upgrade program has encountered an abnormal situation and needs to be rerun. Since the driver upgrade program is in the boot intermediate layer, when it needs to be rerun, it needs to determine whether to run in place based on the preset operating state. When encountering an operating state that requires a cold reset, such as the upgrade state, the driver upgrade program needs to jump back to the underlying bootloader, and the underlying bootloader performs a cold reset and restart to update and upgrade. When the preset operating state is that the driver upgrade program's main partition is faulty or that the parameters related to the driver upgrade program need to be calibrated, and the initialization parameters in the underlying bootloader do not need to be changed, the driver upgrade program can be directly rerun to repair itself.

[0077] For example, the underlying bootloader performs a verification before jumping to area A. If the verification fails, it will jump to the backup driver upgrade program in area B for verification. If the verification passes, it will jump directly to area B to execute the backup driver upgrade program normally and leave the verification failure reason in area B. During the execution of area B, the verification failure reason will be read and area A will be repaired according to its description. At this time, the driver upgrade program can directly re-run itself after repairing area A.

[0078] In this embodiment of the invention, the driver upgrade program, under a preset running state, can jump back to the underlying bootloader to trigger a cold reset and restart, flexibly connecting with the underlying bootloader and allowing for flexible module jumps based on the status, thus improving the flexibility of the layered architecture. It can also re-run itself, enabling the MCU to have automated fault recovery capabilities, reducing subsequent maintenance costs, and improving the overall availability of the system program.

[0079] Optionally, the second exception handling also includes: After the driver upgrade program fails to verify the business program, it switches to the business program in the spare partition of the expandable storage area and / or reports the reason for the verification failure.

[0080] Specifically, a spare partition also exists within the expandable storage area where the business application resides. When the driver upgrade program fails to verify the business application due to issues such as image corruption or version mismatch, unlike its own error handling described above, the driver upgrade program will not directly rerun or jump to the underlying bootloader to trigger a cold reset. Instead, it will first attempt to switch to the spare partition to retrieve the business application and then re-verify it. Simultaneously, it can selectively report the verification failure reason to the OTA (Over-The-Air) initiator. If the re-verification succeeds, the business application in the spare partition will start and execute normally. If the re-verification still fails, the reason for the failure needs to be reported, and the system will wait for repair. The system will not proceed further but will remain resident in the driver upgrade program until the initiator repairs the issue, at which point a new business application upgrade package will be pushed over, and execution will restart.

[0081] In another scenario, the driver upgrade program is set to wait for a fixed period of time upon startup when the MCU is shipped. After the driver upgrade program verifies the business program and jumps, it waits for the fixed period of time before continuing to start and execute. If a stop instruction is received from the initiator during the waiting period, the system will passively reside in the driver upgrade program until the initiator's continue instruction appears.

[0082] In this embodiment of the invention, after the driver fails to verify the business program, it can switch to the backup partition for execution, which reduces the probability of program crashes, increases the flexibility of program switching, reports the reason for verification failure, makes the fault traceable, and improves the overall availability of the system program.

[0083] Optionally, the security procedures include: Disabling peripheral connections in the MCU, terminating transmission tasks, disabling peripheral clocks, resetting the system stack pointer to the independent application stack, clearing cache, and locking access permissions to unauthorized memory areas of the MCU.

[0084] Specifically, the deep security protection before the driver upgrade program jumps to the business program mainly includes: disabling peripheral connections in the MCU, terminating the transmission task, disabling the peripheral clock, resetting the system stack pointer to the independent application stack, clearing the cache, and locking access permissions to the MCU's unauthorized storage area.

[0085] The process of disabling peripheral connections in the MCU is as follows: actively disconnect the peripherals currently connected to the MCU (such as RF links, host USB connections, etc.) to avoid peripherals waiting for a response indefinitely and the communication bus being suspended.

[0086] The process for terminating a transfer task is as follows: stop all ongoing DMA transfers and other tasks. When a data transfer is in progress, wait for the transfer to complete before disabling it to avoid the occurrence of useless data that has been transferred in the middle.

[0087] The process of shutting down the peripheral clock is as follows: by operating the reset and clock control registers, the clock source to the peripheral module is directly cut off, thereby reducing the MCU's sleep power consumption.

[0088] The process of resetting the system stack pointer to an independent application stack is as follows: the stack pointer is switched from the currently running stack to an independent and safe memory area to ensure that the subsequent business program execution process has a clean stack environment.

[0089] The process of clearing the cache and locking access permissions for unauthorized memory areas of the MCU is as follows: perform cache invalidation, discard invalid prefetch instructions in the cache, and ensure that the CPU cannot read old invalid instructions later; set the Flash area not allocated to the business program or the specific area containing the key to "unreadable, unwritable and unexecutable", so that even if a buffer overflow or other situation occurs later, external attacks will not be able to access these protected areas.

[0090] In this embodiment of the invention, all peripheral-related business programs are safely stopped by disconnecting the connection and terminating the transmission, the clock is turned off to reduce power consumption, and the unauthorized memory access permissions of the MCU are locked by resetting the stack pointer, clearing the cache, and locking the MCU's unauthorized memory access permissions, thereby establishing a secure and controllable hardware environment for the startup of the business programs and ensuring the security of the next startup.

[0091] The method further includes: When the business program is in a preset running state, it sends a reset request to the driver upgrade program so that the driver upgrade program resets the business program; after resetting the business program, it returns to the step of running the underlying boot program in the read-only memory area of ​​the MCU.

[0092] Specifically, when the business program is in the above-mentioned preset running state, regardless of which state it is in, it needs to be reset to update the state. At this time, a reset request needs to be sent to the driver upgrade program. After receiving the reset request, the driver upgrade program determines the reset method according to the preset running state in the request.

[0093] For example, when a business application only needs to calibrate parameters or other operational states, it sends a soft reset request to the driver upgrade program. The business application then jumps back to the driver upgrade program and restarts directly via soft reset according to the upgrade package. When a business application requires a complete upgrade, affecting the initialization of the entire MCU, a cold reset restart is required. In this case, the business application sends a cold reset request to the driver upgrade program, which then jumps to the underlying bootloader and performs a cold reset restart in the same manner as described above to update and upgrade, running the steps of the underlying bootloader in the MCU's read-only memory area.

[0094] In this embodiment of the invention, the business program in a preset running state sends a request to the driver upgrade program to achieve coordinated linkage between the business program and the driver upgrade program. At the same time, the coordinated linkage between the driver upgrade program and the underlying boot program is also triggered simultaneously according to the state. The overall orderly linkage of the three-layer program is realized, so that the system can run normally in any state.

[0095] Reference Figure 3 This illustrates a step-by-step startup process for an MCU system provided by an embodiment of the present invention, as shown below. Figure 3 As shown, the MCU's storage area is divided into three regions: a read-only memory (ROM), an erasable / writable (ERW) memory, and an expandable memory. The ROM stores the underlying bootloader, the EW memory stores the driver upgrade program, and the expandable memory stores the application programs. When the MCU is powered on, the underlying bootloader in the ROM first runs. While the bootloader is running, it reads and verifies the driver upgrade program from the EW memory. Once the verification is successful, it jumps to the driver upgrade program to begin execution. Similarly, while the driver upgrade program is running, it reads and verifies the application programs from the expandable memory. Once the verification is successful, it jumps to the application programs to begin execution. If the application programs are in an abnormal operating state, such as an upgrade state, parameter calibration state, or fault state, a system soft reset can be triggered, allowing the system to jump back to the driver upgrade program to complete the corresponding operation.

[0096] Reference Figure 4 The diagram illustrates a block diagram of an MCU system startup device according to an embodiment of the present invention, such as... Figure 4 As shown, the device 200 includes: The underlying operation module 201 is used to run the underlying boot program in the read-only memory area of ​​the MCU after the MCU is powered on or reset.

[0097] The driver execution module 202 is used to call the underlying boot program to run the driver upgrade program after the driver upgrade program in the erasable and writable memory area of ​​the MCU has been successfully verified.

[0098] The business operation module 203 is used to call the driver upgrade program to run the business program after the business program in the expandable storage area of ​​the MCU is successfully verified.

[0099] Optionally, the underlying runtime module 201 is also used for: system initialization, global security component initialization, driver upgrade program verification, jump control, and first exception handling; wherein, jump control is used to jump to the driver upgrade program.

[0100] The driver operation module 202 is also used for: peripheral initialization, hardware self-test, working mode recognition and business program verification, security processing and second exception processing.

[0101] Optionally, the underlying runtime module 201 is also used for: System core clock source configuration, reset flag clearing, memory initialization, register reset, and power domain basic detection; global security component initialization, including: global interrupt master switch off, VIC mounted interrupt channel disabled, debug interface off, on-chip hardware watchdog off, automatic transfer path of direct memory access DMA disabled, CPU cache cleared, and system exception flag cleared.

[0102] Optionally, the underlying runtime module 201 is also used for: Set the stack pointer in the MCU to the temporary safe stack, which is used to initialize the runtime environment of the driver upgrade program; set the program counter of the MCU to the address of the driver upgrade program in the erasable memory area.

[0103] Optionally, the underlying runtime module 201 is also used for: When an exception occurs in the underlying bootloader, perform at least one cold reset retry; after N cold reset retry attempts fail, lock the system running state and peripheral outputs, where N is an integer greater than or equal to 1.

[0104] Optionally, the underlying runtime module 201 is also used for: After the driver upgrade program fails to be verified, the reason for the failure is recorded in the spare partition of the erasable memory area, and the spare driver upgrade program in the spare partition is run. The spare driver upgrade program is used to repair the driver upgrade program based on the reason for the failure in the spare partition.

[0105] Optionally, the driver operation module 202 is also used for: The driver upgrade program is invoked to rerun the driver upgrade program or jump to the underlying boot program in a preset running state. The preset running state includes at least one of the following: upgrade state, parameter calibration state, and fault state.

[0106] Optionally, the driver operation module 202 is also used for: After the driver upgrade program fails to verify the business application, it switches to the business application in the spare partition of the expandable storage area and / or reports the reason for the verification failure.

[0107] Optionally, the driver operation module 202 is also used for: Disabling peripheral connections in the MCU, terminating transmission tasks, disabling peripheral clocks, resetting the system stack pointer to the independent application stack, clearing cache, and locking access permissions to unauthorized memory areas of the MCU.

[0108] Optionally, the business operation module 203 is also used for: The business program, in its preset running state, sends a reset request to the driver upgrade program to reset the business program; after resetting the business program, it returns to the step of running the underlying boot program in the read-only memory area within the MCU.

[0109] In summary, the MCU system startup device provided in this embodiment of the invention isolates the MCU's storage area in three hardware layers. By setting the underlying boot program in the read-only storage area, the occupation of memory resources is reduced and the risk of the underlying boot program being tampered with is minimized. The driver upgrade program is set in the erasable storage area, which enables flexible repair and upgrade, increasing the maintainability of the MCU startup cycle. The business program is set in the expandable storage area, which enables dynamic adjustment of resource allocation size, providing more flexible space for the data resources generated during the operation of the business program. When the MCU is powered on, the first layer executes the low-level boot program in the read-only memory area. After execution, it verifies the driver upgrade program in the second-layer erasable and writable memory area. If the verification passes, the second layer is executed. After the second layer is completed, it verifies the business program in the third-layer expandable memory area. This realizes the step-by-step MCU startup process. During the startup process, the functional layers are clearly defined, the trust chain of security verification is increased, and the coupling between modules is reduced. The addition of the driver upgrade program enables driver isolation between the first-layer low-level boot program and the third-layer business program, separating the critical business programs and dispersing security risks. This makes the MCU as a whole less likely to be directly compromised, providing a safe and reliable execution method for the MCU startup process.

[0110] Reference Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. For example... Figure 5 As shown, the electronic device includes: a processor 302, a memory 301, a communication interface 304, and a communication bus 303.

[0111] The processor, memory, and communication interface communicate with each other via a communication bus; the memory stores at least one executable instruction, which causes the processor to execute the code optimization method described in the preceding embodiments. The executable instructions can form a program.

[0112] This invention provides a machine-readable medium storing instructions that, when executed by one or more processors, enable the processors to perform the code optimization method described in the foregoing embodiments. The machine-readable medium may be one or more processors.

[0113] This invention also discloses a computer program product, including a computer program for implementing the above-described MCU system startup method.

[0114] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0115] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0116] It should be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0117] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0120] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0121] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0122] Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device 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 terminal device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0123] The present invention has been described in detail above as a method, an apparatus, an electronic device, and a readable medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for starting an MCU system, characterized in that, include: After powering on or resetting the MCU, the low-level boot program in the read-only memory area of ​​the MCU is run; After the underlying bootloader successfully verifies the driver upgrade program in the erasable memory area within the MCU, it runs the driver upgrade program. After the driver upgrade program successfully verifies the business program in the expandable storage area within the MCU, it runs the business program.

2. The method according to claim 1, characterized in that, The underlying bootloader includes the following processes: system initialization, global security component initialization, driver upgrade program verification, jump control, and first exception handling; wherein, the jump control is used to jump to the driver upgrade program; The driver upgrade program includes the following processes: peripheral initialization, hardware self-test, working mode identification and business program verification, security processing and second anomaly handling.

3. The method according to claim 2, characterized in that, The system initialization includes: configuring the system core clock source, clearing the reset flag, initializing memory, resetting registers, and basic power domain detection; The global security component initialization includes: disabling the global interrupt master switch, disabling the VIC-mounted interrupt channel, disabling the debug interface, disabling the on-chip hardware watchdog, disabling the automatic transfer path of direct memory access (DMA), clearing the CPU cache, and clearing the system exception flag.

4. The method according to claim 2, characterized in that, The jump control includes: The stack pointer in the MCU is set to a temporary secure stack, which is used to initialize the runtime environment of the driver upgrade program; Set the program counter of the MCU to the address of the driver upgrade program in the erasable memory area.

5. The method according to claim 2, characterized in that, The first exception handling includes: If the underlying bootloader encounters an error, at least one cold reset retry will be performed; After N cold reset retries fail, the system operating state and peripheral outputs are locked, where N is an integer greater than or equal to 1.

6. The method according to claim 2, characterized in that, The first exception handling includes: After the driver upgrade program fails to be verified, the reason for the verification failure is recorded in the spare partition of the erasable and rewritable storage area, and the spare driver upgrade program in the spare partition is run. The spare driver upgrade program is used to repair the driver upgrade program according to the reason for the verification failure in the spare partition.

7. The method according to claim 2, characterized in that, The second exception handling includes: The driver upgrade program, under a preset running state, either re-runs the driver upgrade program or jumps to the underlying boot program. The preset running state includes at least one of the following: upgrade state, parameter calibration state, and fault state.

8. The method according to claim 2, characterized in that, The second exception handling includes: After the driver upgrade program fails to verify the business program, it switches to the business program in the spare partition of the expandable storage area and / or reports the reason for the verification failure.

9. The method according to claim 2, characterized in that, The security procedures include: The system disables peripheral connections in the MCU, terminates transmission tasks, disables peripheral clocks, resets the system stack pointer to the independent application stack, clears the cache, and locks access permissions to the MCU's unauthorized storage area.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: When the business program is in a preset running state, it sends a reset request to the driver upgrade program so that the driver upgrade program resets the business program. After resetting the business program, return to the step of running the underlying boot program in the read-only memory area within the MCU.

11. A startup device for an MCU system, characterized in that, include: The underlying runtime module is used to run the underlying boot program in the read-only memory area of ​​the MCU after the MCU is powered on or reset; The driver execution module is used to call the underlying bootloader to run the driver upgrade program after the driver upgrade program in the erasable and writable memory area of ​​the MCU has been successfully verified. The business operation module is used to call the driver upgrade program to run the business program after the business program in the expandable storage area of ​​the MCU has been successfully verified.

12. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store executable instructions that cause the processor to perform the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, It stores instructions that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1 to 10.

Images