Boot program refresh method based on redundant architecture

Abstract

This invention discloses a bootloader flashing method based on a redundant architecture. The bootloader includes bootloaders in redundant A and B regions. The bootloader flashing method includes the following steps: Step 1, resetting the ECU; Step 2, loading the boot partition startup parameter set from the non-volatile memory area; Step 3, selecting the bootloader in either A or B region to boot according to the startup parameters; Step 4, determining if there is an external reprogramming request. If a request exists, downloading the flashing driver and initiating the flashing process to execute the bootloader flashing. This invention enables stable bootloader flashing and booting.

Description

Technical Field

[0001] This invention relates to the field of EPS application software development technology, and specifically to a bootloader refresh method based on a redundant architecture. Background Technology

[0002] The software bootloader plays a crucial role in embedded system software development. For EPS (Emergency Power Supply), it guides program updates, operation, and maintenance. Currently, with the booming automotive market and the increasing prevalence of smart devices, automobiles have gradually evolved into intelligent platforms with continuously iterating functions and uses, providing drivers and passengers with a superior driving experience. As the safety key of the entire vehicle, the EPS's bootloader program also requires continuous iteration and updates to ensure stable startup of EPS functions and to update EPS applications.

[0003] Traditional flashing architectures store the bootloader permanently in non-volatile memory, which does not support later updates and cannot better adapt to new hardware platforms and software development trends. While non-volatile memory provides a stable storage environment for the bootloader, it also carries potential risks. Specifically, accidental damage or erasure of the bootloader's storage area will prevent the bootloader from properly booting the EPS application and from performing software updates, severely impacting the normal use of the EPS application. Summary of the Invention

[0004] The technical problem to be solved by this invention is how to provide a technical solution that can achieve stable bootloader refresh and startup.

[0005] To address the aforementioned technical problems, this invention provides a bootloader refresh method based on a redundant architecture. The bootloader includes bootloaders in redundant A and B regions. The bootloader refresh method includes the following steps:

[0006] Step 1, reset the ECU;

[0007] Step 2: Load the boot partition startup parameter set from the non-volatile storage area;

[0008] Step 3: Select the boot program in partition A or partition B to boot from according to the boot parameters.

[0009] Step 4: Determine if there is an external reprogramming request. If there is, download the flashing driver and start the flashing process, executing the bootloader to flash.

[0010] Preferably, the boot partition startup parameter set includes the currently running partition, the boot mode, the validity of partitions A and B, and the activation of the new Boot flag.

[0011] Preferably, in step 3, the specific method for selecting the A-zone program or the B-zone program to be started based on the startup parameters is as follows:

[0012] Step c: Determine the loading result of the startup parameter set. If loading fails, proceed to step d; if loading succeeds, proceed to step e.

[0013] Step d: Start the hibernation timer. When the hibernation timer reaches the set time, the ECU enters the shutdown procedure.

[0014] Step e: Detect the boot parameters of the boot partition;

[0015] Condition 1: If the validity of area A is that there is an executable program in area A, and the boot method is to boot from area A, then the boot program in area A is loaded.

[0016] Condition 2: If the validity of partition B is that there is an executable program in partition B, and the boot method is to boot partition B, then the boot program in partition B is loaded.

[0017] If conditions 1 and 2 are not met, proceed to step d.

[0018] Preferably, when condition 1 is met, the currently running partition is set to the currently running A partition boot program.

[0019] Preferably, when condition 2 is met, the currently running partition is set to the currently running B partition boot program.

[0020] Preferably, the specific method of step 4 is as follows:

[0021] Step S1: Start the flashing process based on the reprogramming request;

[0022] Step S2: Perform unified diagnostic services;

[0023] Step S3: Execute driver download;

[0024] Step S4: Determine the value of "currently running partition" to start different partitions and erase the partition to be reprogrammed;

[0025] Step S5: Download Boot data to memory and complete integrity and compatibility checks;

[0026] Step S6: Based on the flashing result, configure the "Boot Partition Boot Parameter Set" and set "Activate New Boot Flag" to True;

[0027] Step S7: Reset the ECU using built-in program commands, re-enter the boot program, and enter the new Boot partition according to the boot partition startup parameter set values;

[0028] Step S8: Determine the "Activate New Boot Flag". If the "Activate New Boot Flag" is "True", set it to "False" and store the boot parameter set in the non-volatile storage area.

[0029] Step S9: Stay in the bootloader and enter the programming session through the UDS service;

[0030] Step S10: Guide the App to start and execute post-programming processing;

[0031] Step S11, complete the flashing process.

[0032] Preferably, in step S3, after executing the driver download, the bytes of the downloaded data are checked using the "Check Programming Integrity" routine.

[0033] Preferably, step S3 further includes data writing, using a data identifier to write "fingerprint" information.

[0034] Preferably, in step S4, if the currently running partition is the currently running A partition boot program, then the validity of B partition is set to "No program can run in B partition"; if the currently running partition is the currently running B partition boot program, then the validity of A partition is set to "No program can run in A partition".

[0035] Preferably, in step S6, if the currently running partition is the currently running A partition boot program, then the validity of B partition is written as B partition has a runnable program; if the currently running partition is the currently running B partition boot program, then the validity of A partition is written as A partition has a runnable program.

[0036] Compared with the prior art, the present invention has the following technical effects:

[0037] 1. To address the potential risks of EPS failing to start or function properly due to Bootloader update failure or storage block corruption, a dual-redundant Bootloader flashing method is proposed. Dual-redundant Bootloader program flashing provides redundancy for the Bootloader, resolving or mitigating the aforementioned risks.

[0038] 2. Selecting the Boot partition for booting allows the boot refresh program to boot from the latest or stable version of the boot program based on the boot parameter set of the corresponding boot partition. This ensures the smooth startup and updates of the EPS software and guarantees the stable implementation of the overall functions.

[0039] 3. No expansion is required for existing EPS storage hardware, making it highly adaptable. It features flash memory space logical block partitioning, enabling a single logical block to be independent of other blocks and reprogrammed, avoiding the need to reprogram and refresh the entire memory. It can be extended to other ECU startup software applications.

[0040] 4. In the preferred embodiment, the hibernation / wake-up mechanism can be implemented after the ECU enters the dual-redundant bootloader PreBoot and successfully initializes. If the boot partition startup parameter set is not successfully loaded or not set, PreBoot will initiate hibernation, shutting down the ECU to ensure the controller operates at the lowest possible power consumption. The ECU will then wake up when it receives the next power-on signal from the KL15. Attached Figure Description

[0041] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0042] Figure 1 This is a schematic diagram of the EPS ECU software architecture using the method of Embodiment 1.

[0043] Figure 2 This is a schematic diagram of the startup parameter set structure in Example 1;

[0044] Figure 3 This is a schematic diagram illustrating the specific method steps of step 3 in Example 1;

[0045] Figure 4 This is a schematic diagram illustrating the specific method steps in step 4 of Example 1. Detailed Implementation

[0046] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can fully understand other advantages and technical effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through different specific embodiments, and the details in this specification can also be applied based on different viewpoints, with various modifications or changes made without departing from the overall design concept of the invention. It should be noted that, unless otherwise specified, the following embodiments and features can be combined with each other. The following exemplary embodiments of the present invention can be implemented in many different forms and should not be construed as being limited to the specific embodiments set forth herein. It should be understood that these embodiments are provided to make the disclosure of the present invention thorough and complete, and to fully convey the technical solutions of these exemplary embodiments to those skilled in the art.

[0047] Example 1

[0048] This embodiment provides a bootloader refresh method based on a redundant architecture. The bootloader includes bootloaders in redundant A and B regions. The bootloader refresh method includes the following steps:

[0049] Step 1, reset the ECU;

[0050] Step 2: Load the boot partition startup parameter set from the non-volatile storage area;

[0051] Step 3: Select the boot program in partition A or partition B to boot from according to the boot parameters.

[0052] Step 4: Determine if there is an external reprogramming request. If there is, download the flashing driver and start the flashing process, executing the bootloader to flash.

[0053] This embodiment illustrates the application of the above method to the EPS ECU of an automotive steering system.

[0054] like Figure 1 As shown, Figure 1 This is a schematic diagram of the EPS ECU software architecture using the method of this embodiment. It mainly includes a diagnostic tool, a PreBoot module, a flash driver, a Boot A / B partition module (i.e., A / B areas), and an App application module. For ease of description, the software that boots the dual-redundant bootloader is referred to as PreBoot (PreBoot is an abbreviation for dual-redundant bootloader boot program).

[0055] Figure 1 The aforementioned flashing driver provides memory interfaces and functions for the Bootloader, Boot, and App programs, ensuring they can communicate correctly with memory. The EPS's ECU memory is protected against accidental erasure or rewrite operations that could cause startup failures. Therefore, a software interlock mechanism is employed; the flashing driver is not stored in the ECU's NVM but is downloaded to the ECU's RAM when software flashing is required. Upon reset after all programs have been flashed, the driver code is automatically removed from the ECU RAM buffer, thus preventing misuse of the flashing driver that could lead to unintended erasure and write operations.

[0056] The boot partition startup parameter set includes the currently running partition, the boot method, the validity of partitions A and B, and a flag to activate the new boot. In this embodiment, the parameter names, data types, data value ranges, and parameter values ​​corresponding to the startup parameter set are detailed below. Figure 2 As shown.

[0057] like Figure 3As shown, in step 3, the specific method for selecting the A-zone program or the B-zone program to start based on the startup parameters is as follows:

[0058] Step c: Determine the loading result of the startup parameter set. If loading fails, proceed to step d; if loading succeeds, proceed to step e.

[0059] Step d: Start the hibernation timer. When the hibernation timer reaches the set time, the ECU enters the shutdown procedure.

[0060] Step e: Detect the boot parameters of the boot partition;

[0061] Condition 1: If the validity of partition A is that there is an executable program in partition A, and the boot mode is to boot partition A (i.e., when "BootableA==0x01&&BootMode==0x00"), the boot program in partition A is loaded;

[0062] Condition 2: If the validity of partition B is that there is an executable program in partition B, and the boot mode is to boot partition B (i.e., when "BootableB==0x01&&BootMode==1"), the boot program in partition B is loaded.

[0063] If conditions 1 and 2 are not met (i.e., “(BootableA==0x00&&BootMode==0x00)&&(BootableB==0x00&&BootMode==0x01)”), proceed to step d.

[0064] When condition 1 is met, the currently running partition is set to the currently running A partition boot program ("Active Slot == 0x00"), and the Bootloader A program is run in the A partition.

[0065] When condition 2 is met, the currently running partition is set to the currently running B partition boot program ("Active Slot == 0x01"), and the Bootloader B program is run in the B partition.

[0066] like Figure 4 As shown, in step 4, the specific method for downloading the flashing driver, starting the flashing process, and executing the bootloader flashing is as follows:

[0067] Step S1: Power on and enter the valid Boot partition, then start the flashing process according to the reprogramming request;

[0068] Step S2: Execute the Unified Diagnostic Service (UDS) to achieve session redirection, secure access, and complete the routine pre-programming processing.

[0069] Step S3: Execute driver download; (34h, 36h, 37h, 31h, 2Eh), download the driver file in this order: request download, transfer data, request transfer, exit download. After downloading, use the "Check Programming Integrity" routine to verify the bytes of the downloaded data to ensure correct transmission. Then, perform data writing, using a data identifier to write "fingerprint" information.

[0070] Step S4: Determine the value of "currently running partition" to start different partitions and erase the partition to be reprogrammed;

[0071] If "ActiveSlot" is A (0x00), then "BootableB" will be written as invalid (0x00).

[0072] If "ActiveSlot" is B (0x01), then "BootableA" will be written as invalid (0x00).

[0073] Step S5: Download Boot data to memory and complete integrity and compatibility checks;

[0074] Step S6: Based on the flashing result, configure the "Boot Partition Boot Parameter Set" and set "Activate New Boot Flag" to True "0x01";

[0075] Step S7: Reset the ECU using built-in program commands, re-enter the boot program, and enter the new Boot partition according to the boot partition startup parameter set values;

[0076] Step S8: Determine the "Activate New Boot Flag". If the "Activate New Boot Flag" is "True", set it to "False" and store the boot parameter set in the non-volatile storage area.

[0077] Step S9: Stay in the bootloader and enter the programming session through the UDS service;

[0078] Step S10: Guide the App to start and execute post-programming processing;

[0079] Step S11, complete the flashing process.

[0080] The method of this invention establishes a bootloader fault tolerance mechanism, implemented through the bootloader's boot judgment program. The PreBoot software checks the boot flag of the boot partition to ensure it always boots from a stable and valid partition of the bootloader software, thus guaranteeing subsequent app startup or updates. The bootloader software partition validity judgment module mainly uses a set of boot parameters defined internally by the ECU to identify the bootloader's startup parameters. This parameter set sets the validity of software reprogramming and allows the bootloader software to run. Simultaneously, when the flag is invalid, the system can remain in PreBoot and record the invalid fault, sending it to the diagnostic tool. For active boot partition startup, the diagnostic service routine modifies the corresponding startup parameter set to select the partition to boot, ensuring the bootloader can perform version rollback functionality.

[0081] The present invention has been described in detail above through specific embodiments and examples, but these are not intended to limit the invention. Many modifications and improvements can be made by those skilled in the art without departing from the principles of the invention, and these should also be considered within the scope of protection of the present invention.

Claims

1. A bootloader refresh method based on a redundant architecture, characterized in that, The bootloader includes redundant bootloaders in partitions A and B, and the bootloader refresh method includes the following steps: Step 1, reset the ECU; Step 2: Load the boot partition startup parameter set from the non-volatile storage area; Step 3: Select the boot program in area A or area B to boot according to the boot parameters; specifically: Step c: Determine the loading result of the boot parameter set. If loading fails, proceed to step d; if loading succeeds, proceed to step e. Step d: Start the hibernation timer. When the hibernation timer reaches the set time, the ECU enters the shutdown procedure. Step e: Detect the boot parameters of the boot partition; Condition 1: If the validity of area A is that there is an executable program in area A, and the boot method is to load the boot program in area A when booting area A; Condition 2: If the validity of partition B is that there is an executable program in partition B, and the boot method is to load the boot program in partition B when booting partition B; If conditions 1 and 2 are not met, proceed to step d; When condition 1 is met, the currently running partition is set as the currently running bootloader A, and the Bootloader A program is run in partition A. When condition 2 is met, the currently running partition is set as the currently running boot program in partition B, and the Bootloader B program is run in partition B. Step 4: Determine if there is an external reprogramming request. If there is, download the flashing driver and start the flashing process, executing the bootloader to flash.

2. The bootloader refresh method based on redundant architecture according to claim 1, characterized in that, The boot partition startup parameter set includes the currently running partition, the boot method, the validity of partitions A and B, and the activation of the new boot flag.

3. The bootloader refresh method based on redundant architecture according to claim 1, characterized in that, The specific method for step 4 is as follows: Step S1: Start the flashing process based on the reprogramming request; Step S2: Perform unified diagnostic services; Step S3: Execute driver download; Step S4: Determine the value of "currently running partition" to start different partitions and erase the partition to be reprogrammed; Step S5: Download Boot data to memory and complete integrity and compatibility checks; Step S6: Based on the flashing result, configure the "Boot Partition Boot Parameter Set" and set "Activate New Boot Flag" to True; Step S7: Reset the ECU using built-in program commands, re-enter the boot program, and enter the new Boot partition according to the boot partition startup parameter set values; Step S8: Determine the "Activate New Boot Flag". If the "Activate New Boot Flag" is "True", set it to "False" and store the boot parameter set in the non-volatile storage area. Step S9: Stay in the bootloader and enter the programming session through the UDS service; Step S10: Guide the App to start and execute post-programming processing; Step S11, complete the flashing process.

4. The bootloader refresh method based on redundant architecture according to claim 3, characterized in that, In step S3, after the driver download is executed, the bytes of the downloaded data are checked using the "Check Programming Integrity" routine.

5. The bootloader refresh method based on redundant architecture according to claim 4, characterized in that, Step S3 also involves writing data, using a data identifier to write "fingerprint" information.

6. The bootloader refresh method based on redundant architecture according to claim 3, characterized in that, In step S4, if the currently running partition is the currently running A partition boot program, then the validity of B partition is set to "No programs can run in B partition"; if the currently running partition is the currently running B partition boot program, then the validity of A partition is set to "No programs can run in A partition".

7. The bootloader refresh method based on redundant architecture according to claim 3, characterized in that, In step S6, if the currently running partition is the currently running A partition boot program, then the validity of B partition is written as B partition has a runnable program; if the currently running partition is the currently running B partition boot program, then the validity of A partition is written as A partition has a runnable program.

Images