Remote upgrading method and system for boot loader of vehicle control unit

Abstract

The invention relates to a remote upgrading method and system for a vehicle control unit boot loader. The method comprises the following steps: setting a to-be-upgraded existing boot loader in a reserved area of an application program, and setting a boot loader flashing program in an initialization program of an actual use area of the application program; the method comprises the following steps of: firstly, receiving an over-the-air downloading technology upgrading instruction by a vehicle control unit, and executing resetting after an application program is upgraded, namely performing an upgrading process of a bootstrap loader; if upgrading fails, waiting for upgrading triggering; afterwards, when the application program is started, under the condition that the vehicle control unit receives an active instruction request for entering the boot loader, an upgrade triggering process is carried out, and the upgrade process of the boot loader is carried out again. Compared with the prior art, the method has the advantages that batch remote upgrading of the vehicle control unit boot loader is supported, the failure scene recognition capability is high, the safety coefficient is improved, and the perceptibility of a vehicle owner is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of boot loader upgrade, and in particular to a remote upgrade method and system for a boot loader of a vehicle controller. Background Art

[0002] With the continuous development of new energy vehicles, the requirements for the software quality of the core components of the vehicle are getting higher and higher. Faced with the current situation where the functions of multiple control components are becoming more complex, the software upgrade frequency is high, but the development cycle is getting shorter and shorter, all vehicle manufacturers and parts suppliers are faced with the problem of how to upgrade the controller software effectively, quickly and at low cost. The method of remotely upgrading different controller software through over-the-air download technology is a program update method recognized by all parties.

[0003] Over-the-air download technology is a technology that remotely manages the data of mobile terminal devices through the air interface of mobile communications, and can also provide mobile new business download functions. In terms of conventional remote upgrades of application software, over-the-air download technology has been relatively mature and widely used in vehicles on the market. However, for remote upgrades of bootloaders, many factors need to be considered in combination with actual usage scenarios, and there are currently few applications in the market.

[0004] On the one hand, for bootloader upgrades, if the upgrade fails and causes the controller bootloader to be abnormal, the subsequent application programs of multiple nodes cannot be upgraded; in serious cases, the controller freezes, which will cause the vehicle to be abnormal and unusable. On the other hand, for the necessity of bootloader upgrades, if the existing bootloader of the controller has critical problems, appropriate means are needed to perform batch updates, otherwise the known problems will continue to exist.

[0005] For example, the invention patent with publication number CN112527371B discloses a boot loader upgrade method, which obtains the upgrade file of the second program if the boot loader needs to be upgraded when the first program or the operating system kernel is in working state; the second program is upgraded based on the upgrade file to upgrade the boot loader. However, it does not consider a variety of abnormal scenarios, resulting in a relatively large risk in the boot loader upgrade process under its method. Summary of the invention

[0006] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a remote upgrade method and system for the boot loader of a vehicle controller.

[0007] The purpose of the present invention can be achieved by the following technical solutions:

[0008] According to one aspect of the present invention, a remote upgrade method for a vehicle controller boot loader is provided, characterized in that the method sets the existing boot loader to be upgraded in a reserved area of ​​the application program, and sets the boot loader program flashing program at the initialization program of the actual use area of ​​the application program;

[0009] When the vehicle controller receives the OTA upgrade instruction, it will perform the application upgrade process and execute the reset instruction after the upgrade is completed. After that, the program will run to the initialization program of the actual use area of ​​the application to perform the boot loader upgrade process. If the upgrade process is successful, the application will continue to run. If one of the preset upgrade failure situations occurs, resulting in the failure of the upgrade process, the upgrade process will be exited, the application will continue to run, and wait for the upgrade trigger;

[0010] Thereafter, when the application is started, if the vehicle controller receives an active command request to enter the bootloader, the upgrade trigger process is performed, and the bootloader upgrade process is performed again; in other cases, the upgrade trigger process is skipped;

[0011] Among them, the upgrade process includes an upgrade pre-judgment process, an upgrade processing process and an upgrade verification process; when one of the preset abnormal situations occurs during the upgrade process, it jumps to the abnormal code reporting process.

[0012] As a preferred technical solution, the specific process of triggering the upgrade is: after the vehicle controller receives an active command request to enter the boot loader, the upgrade flag is set to 1, and the vehicle controller is restarted, that is, jumping to the upgrade process;

[0013] Among them, the active command request is automatically issued during the air download technology upgrade process, or manually issued using a diagnostic instrument, and the active command request includes a request in a unified diagnostic service, or the network status is a boot loader; among them, the request in the unified diagnostic service includes 0x1002 or 0x1082.

[0014] As a preferred technical solution, the upgrade pre-judgment process is: determine in turn whether the upgrade permission flag is 1, whether the BMHD running address is the starting address of the boot loader, whether the existing boot loader is complete, whether the original boot loader is valid, and whether the existing and original loader versions are consistent. If the above judgment results are all yes, then jump out of the upgrade process and jump back to continue executing the subsequent logic of the application;

[0015] In the process of judging whether the upgrade permission flag is 1, if the judgment result is no, continue to judge the upgrade status bit. If the upgrade status bit is 0, jump to judge whether the BMHD running address is the starting address of the boot loader; if the upgrade status bit is 1, jump to the abnormal code reporting process; if the upgrade status bit is not 0 and not 1, jump out of the upgrade process and jump back to continue to execute the subsequent logic of the application;

[0016] In the process of judging whether the BMHD running address is the starting address of the boot loader, judging whether the original boot loader is valid, and judging whether the existing and original boot loader versions are consistent, if the judgment result is no, jump to the upgrade process;

[0017] In the process of determining whether the existing boot loader is complete, if the determination result is no, the upgrade process is exited and the subsequent logic of the application is continued to be executed.

[0018] As a preferred technical solution, the upgrade process includes:

[0019] A1, set the upgrade status position to 1 and store it in the data flash memory;

[0020] A2. Perform a second judgment before upgrading;

[0021] A3, decompress the driver. If the decompression fails, the decompression process is repeated in step A3 until three failures have occurred. The process then jumps to the abnormal code reporting process. If the decompression succeeds, the process continues in step A4.

[0022] A4, determine whether the BMHD running address is the starting address of the boot loader, if so, update the BMHD running address to the starting address of the application, if not, directly jump to step A5;

[0023] A5, add 1 to the total number of erase and write times of BMHD, and store it in the data flash memory;

[0024] A6, determine whether the delivery assembly part number in the original boot loader exists, if yes, read the delivery assembly part number and store it in the data flash memory; if no, directly jump to step A7;

[0025] A7, increase the number of executions of the upgrade process by 1, and store it in the data flash memory; erase the original boot loader, write the existing boot loader, and write the original delivery assembly part number;

[0026] A8. Jump to the upgrade verification process.

[0027] As a preferred technical solution, the second judgment before upgrading in step A2 is to judge whether the first event to the fourth event occur;

[0028] Among them, the first event is that the number of executions of the upgrade process exceeds the preset allowed number of cyclic executions; the second event is that the total number of BMHD erases is less than or equal to the preset total number of erases; the third event is that a diagnostic fault code is reported and a freeze frame is recorded; the fourth event is that the upgrade permission flag is 1; if both the first event and the second event occur, and either the third event or the fourth event occurs, the upgrade processing process will continue to be executed. If not satisfied, the abnormal code reporting process will be jumped.

[0029] As a preferred technical solution, the upgrade verification process is:

[0030] B1, determine whether the redundancy check of the existing and original boot loader programs is successful. If not, loop through step B1 until three failures are accumulated, and jump to the abnormal code reporting process. If yes, jump to step B2;

[0031] B2. Reset the trust list. If the reset fails, repeat step B2 until three failures have occurred. Then, jump to the abnormal code reporting process. If the reset succeeds, continue to step B3.

[0032] B3, change the BMHD address back to the bootloader start address, and increase the total number of BMHD erase and write times by 1, and store it in the data flash memory;

[0033] B4, clear the driver, and set the upgrade process execution times to 0, the upgrade permission flag position to 0, and the upgrade status position to 2;

[0034] B5. Exit the upgrade process and jump back to continue executing the subsequent logic of the application.

[0035] As a preferred technical solution, the specific process of the redundancy check of the existing and original boot loaders in step B1 is: respectively calculating the cyclic redundancy check codes of the existing boot loader in the application reserved area and the existing boot loader in the original boot loader area, and comparing the two to see if they are consistent. If they are consistent, the check is successful.

[0036] As a preferred technical solution, abnormal situations include: the driver decompression, cyclic redundancy check or trust list reset cycle flashing fails for a total of 3 times, and the upgrade status bit is 1 due to abnormal power outage or power jitter.

[0037] As a preferred technical solution, during the abnormal reporting process, it is first determined whether it meets the abnormal situation. If it does, the corresponding diagnostic fault code is reported and the freeze frame is recorded. If it does not meet the requirements, the corresponding diagnostic fault code is cleared.

[0038] According to another aspect of the present invention, a remote upgrade system for a vehicle controller boot loader is provided. The system is applied in a remote upgrade method for a vehicle controller boot loader as described above. The system includes an upgrade trigger module, an upgrade pre-judgment module, an upgrade processing module, an upgrade verification module and an abnormal code reporting module.

[0039] Among them, the upgrade trigger module is used to perform the upgrade trigger process when the vehicle controller receives an active command request to enter the boot loader. The vehicle controller restarts, and the program runs to the initialization program in the actual use area of ​​the application to perform the upgrade process; the upgrade pre-judgment module, the upgrade processing module and the upgrade verification module are used to jointly execute the upgrade process; the exception reporting module is used to execute the exception reporting process after an abnormal situation occurs during the upgrade process.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] 1. In the present invention, the existing boot loader to be upgraded is set in the reserved area of ​​the application, and the boot loader flashing program is set at the initialization program of the actual application area; first, the vehicle controller receives the upgrade instruction of the over-the-air download technology, and performs a reset after the application upgrade is completed, that is, the upgrade process of the boot loader is performed; if the upgrade fails, wait for the upgrade trigger; thereafter, when the application is started, when the vehicle controller receives an active instruction request to enter the boot loader, the upgrade trigger process is performed, and the boot loader upgrade process is performed again. The present invention supports the remote batch upgrade of the vehicle controller boot loader by updating the boot loader in the process of upgrading the application using the over-the-air download technology, which can meet the remote upgrade of vehicles in the market for mass production projects.

[0042] 2. In the present invention, when one of the preset abnormal situations occurs during the upgrade process, it jumps to the abnormal reporting process. Among them, the abnormal situations include: the situation where the driver decompression, cyclic redundancy check or trust list reset cycle flashing fails for a total of 3 times, and the upgrade status bit is 1 due to abnormal power outage or power jitter. In the abnormal reporting process, first determine whether it meets the abnormal situation. If it does, the diagnostic fault code is reported and the freeze frame is recorded. If it does not meet the requirements, the diagnostic fault code is cleared. This method allows diagnostic fault code reporting for multiple possible upgrade abnormal scenarios, and has a strong ability to identify failure scenarios, so that the over-the-air download technology background and the car owner can understand the upgrade results in a timely manner. The cause of the abnormality can be located through the reporting content for subsequent investigation.

[0043] 3. In the upgrade pre-judgment process of the present invention, it is judged in turn whether the upgrade flag is 1, whether the BMHD running address is the starting address of the boot loader, whether the existing boot loader is complete, whether the original boot loader is valid, and whether the existing and original loader versions are consistent. If the above judgment results are all yes, the upgrade process is jumped out and the subsequent logic of the application is continued to be executed. Through the upgrade pre-judgment process, the upgrade environment is ensured to be correct, repeated upgrades are prevented, and the upgrade efficiency is improved.

[0044] 4. The upgrade process of the present invention is as follows: first, the upgrade status position is set to 1, and it is stored in the data flash memory; then, the second judgment before the upgrade is performed; the driver is decompressed, and it is judged whether the BMHD running address is the starting address of the boot loader, and then it is judged whether the delivery assembly part number in the original boot loader exists, and then the number of executions of the upgrade process is increased by 1, and it is stored in the data flash memory; the original boot loader is erased, the existing boot loader is written, and the original delivery assembly part number is written. The upgrade process is completed through the upgrade process. In the process, the second judgment before the upgrade is performed to improve the success rate of the upgrade and the stability of the system, and the judgment by the BMHD running address improves the startup success rate of the system, which generally improves the security and stability of the upgrade.

[0045] 5. In the present invention, the upgrade verification is performed, and the process is as follows: first determine whether the redundancy check of the existing and original boot loaders is successful, then reset the trust list, and change the BMHD address back to the boot loader start address, and add 1 to the total number of BMHD erases and writes, and store it in the data flash memory; then clear the driver, and set the number of upgrade process executions to 0, the upgrade permission flag position to 0, and the upgrade status position to 2. After the upgrade verification, the integrity of the boot loader is guaranteed, thereby improving the stability of the upgrade.

[0046] 6. In the present invention, during the decompression of the driver, if the decompression fails, the decompression is repeated in a loop until three failures are accumulated, and the process jumps to the abnormal code reporting process. During the redundant verification of the existing and original boot loaders, if it fails, the verification is repeated in a loop until three failures are accumulated, and the process jumps to the abnormal code reporting process. During the resetting of the trust list, if the reset fails, the reset is repeated in a loop until three failures are accumulated, and the process jumps to the abnormal code reporting process. That is, after the first update fails, two more upgrade attempts can be made, and the upgrade is prohibited after more than three attempts or after power is restarted, unless an active command request to enter the boot loader is received again. It has a complete failure recovery mechanism to maximize the safety factor and reduce the owner's perception.

[0047] 7. In the present invention, the upgrade triggering process is performed only when an active command request to enter the boot loader is received, that is, the upgrade is allowed only for specified scenarios (over-the-air download technology or after-sales diagnostic instrument), thereby reducing the failure probability caused by accidental interruption and the owner's perception. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A schematic diagram of the steps of the boot loader remote upgrade method of the present invention;

[0049] Figure 2 A schematic diagram showing the relationship between the modules of the boot loader remote upgrade system of the present invention;

[0050] Figure 3 This is a schematic diagram of the internal logic of the upgrade trigger module in the present invention;

[0051] Figure 4 This is a schematic diagram of the internal logic of the upgrade pre-judgment module in the present invention;

[0052] Figure 5 This is a schematic diagram of the internal logic of the upgrade processing module in the present invention;

[0053] Figure 6 This is a schematic diagram of the internal logic of the upgrade verification module in the present invention;

[0054] Figure 7 The figure is a schematic diagram of the internal logic of the abnormal code reporting module in the present invention. DETAILED DESCRIPTION

[0055] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0056] With the continuous development of new energy vehicles, the requirements for the software quality of the core components of the vehicle are getting higher and higher. Faced with the current situation where the functions of multiple control components are becoming more complex, the software upgrade frequency is high, but the development cycle is getting shorter and shorter, all vehicle manufacturers and parts suppliers are faced with the problem of how to upgrade the controller software effectively, quickly and at low cost. The method of remotely upgrading different controller software through over-the-air download technology is a program update method recognized by all parties.

[0057] Over-the-air download technology is a technology that remotely manages the data of mobile terminal devices through the air interface of mobile communications, and can also provide mobile new business download functions. In terms of conventional remote upgrades of application software, over-the-air download technology has been relatively mature and has been widely used in vehicles on the market. However, for remote upgrades of boot loaders, many factors need to be considered in combination with actual usage scenarios, and there are currently few applications in the market. On the one hand, for boot loader upgrades, once the upgrade fails and the controller boot loader is abnormal, the subsequent applications of multiple nodes cannot be upgraded; in severe cases, the controller freezes, which will cause the vehicle to be abnormal and unusable. On the other hand, for the necessity of boot loader upgrades, if there are key problems with the existing boot loader of the controller, appropriate means are required for batch updates, otherwise the known problems will continue to exist.

[0058] Based on the above, the purpose of this application is to provide a remote upgrade method design for the boot loader program for the vehicle controller. This method triggers the flashing of the boot loader program during the process of remotely upgrading the application program through over-the-air download technology, which can meet the needs of vehicle manufacturers for remote upgrades of the boot loader program of the vehicle controller. At the same time, this application has been fully tested on the bench and actual vehicles, and has security and robustness. It has certain practical application significance for batch updates of boot loaders of market vehicles.

[0059] Example 1

[0060] In this embodiment, a remote upgrade method for a vehicle controller boot loader is applied, which sets the existing boot loader to be upgraded in a reserved area of ​​the application program, and sets the boot loader flashing program at the initialization program of the actual use area of ​​the application program;

[0061] When the vehicle controller receives the OTA upgrade instruction, it will perform the application upgrade process and execute the reset instruction after the upgrade is completed. After that, the program will run to the initialization program of the actual use area of ​​the application to perform the boot loader upgrade process. If the upgrade process is successful, the application will continue to run. If one of the preset upgrade failure situations occurs, resulting in the failure of the upgrade process, the upgrade process will be exited, the application will continue to run, and wait for the upgrade trigger;

[0062] Thereafter, when the application is started, if the vehicle controller receives an active command request to enter the bootloader, the upgrade trigger process is performed, and the bootloader upgrade process is performed again; in other cases, the upgrade trigger process is skipped;

[0063] In this embodiment, the upgrade process includes an upgrade pre-judgment process, an upgrade processing process and an upgrade verification process; when one of the preset abnormal situations occurs during the upgrade process, it jumps to the abnormal code reporting process.

[0064] The steps of this method are as follows Figure 1 As shown, the steps include:

[0065] S101, based on the application program embedded in the existing boot loader and the boot loader flashing code block, flashing the boot loader to be upgraded in the original boot loader area;

[0066] S102, after the boot loader is successfully upgraded, continue to run the application;

[0067] S103, after the boot loader upgrade fails, continue to run the application program when the startup address is the application program, and wait for the next boot loader upgrade;

[0068] S104: When receiving a request to actively enter the boot loader program, the boot loader program is upgraded again.

[0069] In this embodiment, after the vehicle controller receives the active command request to enter the boot loader, the upgrade permission flag is set to 1, and the vehicle controller is restarted, that is, jumping to the upgrade process;

[0070] Among them, the active command request is automatically issued during the air download technology upgrade process, or manually issued using a diagnostic instrument, and the active command request includes a request in a unified diagnostic service, or the network status is a boot loader; among them, the request in the unified diagnostic service includes 0x1002 or 0x1082.

[0071] In this embodiment, the upgrade trigger is as follows: Figure 3 As shown, the specific steps are:

[0072] S201, receiving a request to enter a boot loader program;

[0073] S202, determine whether it is a function addressing request; if so, jump to S203; if not, jump to S204;

[0074] S203, routing to a child node;

[0075] S204, setting the upgrade permission flag position to 1;

[0076] S205: Restart the vehicle controller.

[0077] In this embodiment, the upgrade pre-judgment process is: determine in sequence whether the upgrade permission flag is 1, the boot configuration information (BOOT Mode In the process of judging whether the upgrade permission flag is 1, if the judgment result is no, then continue to judge the upgrade status bit. If the upgrade status bit is 0, then jump to judge whether the BMHD running address is the starting address of the boot loader; if the upgrade status bit is 1, then jump to the abnormal code reporting process; if the upgrade status bit is not 0 and not 1, then jump out of the upgrade process and jump back to continue to execute the subsequent logic of the application; in the process of judging whether the BMHD running address is the starting address of the boot loader, judging whether the original boot loader is valid and judging whether the existing and original loader versions are consistent, if the judgment result is no, then jump to the upgrade processing process; in the process of judging whether the existing boot loader is complete, if the judgment result is no, then jump out of the upgrade process and jump back to continue to execute the subsequent logic of the application.

[0078] In this embodiment, the upgrade pre-judgment is as follows Figure 4 As shown, the specific steps are:

[0079] S301, determine whether the permission flag is 1; if so, proceed to step S304; if not, jump to step S302;

[0080] S302, determine whether the upgrade status bit is 0; if so, jump to step S305; if not, proceed to step S303;

[0081] S303, determine whether the upgrade status bit is 1; if so, jump to the abnormal code reporting module; if not, jump out of the upgrade process and jump to the subsequent logic of the application;

[0082] S304, determine whether the BMHD running address is the starting address of the boot loader; if so, proceed to step S305; if not, jump to the upgrade process;

[0083] S305, determine whether the existing boot loader is complete; if so, jump to step S306; if not, jump to the upgrade process;

[0084] S306, determine whether the original boot loader is valid; if so, jump to step S307; if not, jump to the upgrade process;

[0085] S307, determine whether the existing and original boot loader versions are consistent; if so, jump out of the upgrade process and jump to the subsequent logic of the application; if not, jump to the upgrade processing process.

[0086] In this embodiment, the upgrade process is as follows: Figure 5 As shown, the specific steps include:

[0087] S401, set the upgrade status position to 1 and store it in the data flash memory;

[0088] S402, determine whether the second judgment before upgrading is passed; if so, proceed to step S403; if not, jump to the abnormal code reporting module;

[0089] S403, decompress the driver and determine whether the driver decompression is successful; if so, jump to step S404, if not, loop step S403 again to decompress until 3 failures have accumulated, and jump to the abnormal code reporting process.

[0090] S404, determine whether the BMHD running address is the starting address of the boot loader, if so, proceed to step S405, if not, jump to step S406;

[0091] S405, update the BMHD running address to the application start address;

[0092] S406, adding 1 to the total number of erase and write times of BMHD, and storing it in the data flash memory;

[0093] S407, determine whether the delivery assembly part number in the original boot loader exists, if yes, proceed to step S408; if not, jump to step S409;

[0094] S408, read the delivery assembly part number and store it in the data flash memory;

[0095] S409, increase the number of execution times of the upgrade process by 1;

[0096] S410, erasing the original boot loader;

[0097] S411, writing the existing boot loader;

[0098] S412. Write the original delivery assembly part number.

[0099] In this embodiment, the two judgments before upgrading are to determine whether the first event to the fourth event occur; the first event is that the number of executions of the upgrading process exceeds the preset allowed number of cyclic executions; the second event is that the total number of BMHD erases is less than or equal to the preset total number of erases; the third event is that a diagnostic fault code is reported and a freeze frame is recorded; the fourth event is that the upgrade permission flag is 1; if both the first event and the second event occur, and either the third event or the fourth event occurs, the upgrading process continues to be executed; if not, the abnormal code reporting process is jumped.

[0100] In this embodiment, the upgrade verification process is as follows: Figure 6 As shown, the specific steps are:

[0101] S501, determine whether the redundancy check of the existing and original boot loader programs is successful; if so, jump to step S502; if not, loop through step S501 until accumulating 3 failures, and jump to the abnormal code reporting process;

[0102] S502, reset the trust list;

[0103] S503, determine whether the reset of the trust list is successful; if so, proceed to step S504; if not, loop step S503 until three failures are accumulated, and jump to the abnormal code reporting process;

[0104] S504, clear the driver;

[0105] S505: Set the upgrade process execution times to 0, set the upgrade permission flag to 0, and set the upgrade status to 2.

[0106] In this embodiment, the specific process of the redundancy check of the existing and original boot loaders is: respectively calculating the cyclic redundancy check codes of the existing boot loader in the application reserved area and the existing boot loader in the original boot loader area, and comparing whether the two are consistent. If they are consistent, the check is successful.

[0107] In this embodiment, the upgrade failure situations include:

[0108] The upgrade judgment results are all yes. At this time, the upgrade judgment includes: judging whether the upgrade-allowed flag is 1, judging whether the BMHD running address is the starting address of the boot loader, judging whether the existing boot loader is complete, judging whether the original boot loader is valid, and judging whether the existing and original loader versions are consistent; the upgrade-allowed flag is not 1, the upgrade status bit is neither 0 nor 1; and the existing boot loader is incomplete.

[0109] In this embodiment, abnormal situations include: the driver decompression, cyclic redundancy check or trust list reset cycle flashing fails for a total of 3 times, and the upgrade status bit is 1 due to abnormal power outage or power jitter.

[0110] In this embodiment, the abnormal code reporting process is as follows: Figure 7 As shown, the specific steps are:

[0111] S601, determine whether the reporting code conditions are met; if so, jump to step S603; if not, proceed to step S602;

[0112] S602, clear diagnostic fault codes;

[0113] S603, diagnose fault code reporting and freeze frame recording.

[0114] In summary, when the method receives an active command request to enter the bootloader, it triggers the upgrade process, that is, the upgrade is allowed only for the specified scenario (air download technology or after-sales diagnostic instrument), reducing the failure probability and owner perception caused by accidental interruption. The method can diagnose fault codes for multiple possible upgrade abnormal scenarios, and has a strong ability to identify failure scenarios, so that the air download technology background and the owner can understand the upgrade results in time, and the abnormal cause can be located through the code content for subsequent investigation.

[0115] Example 2

[0116] In this embodiment, the existing boot loader to be upgraded is placed in the reserved area of ​​the application program to update the original boot loader program; and the flash code segment of the boot loader program is placed in the initialization code segment of the actual application program usage area. In this embodiment, a remote upgrade system for the boot loader program of a vehicle controller is applied. Figure 2 As shown, it includes an upgrade trigger module, an upgrade pre-judgment module, an upgrade processing module, an upgrade verification module and an abnormal code reporting module.

[0117] In this embodiment, the internal logic of the upgrade trigger module is as follows: Figure 3 As shown, the specific process is:

[0118] S201, receiving a request to enter a boot loader program;

[0119] S202, determine whether it is a function addressing request; if so, jump to S203; if not, jump to S204;

[0120] S203, routing to a child node;

[0121] S204, setting the upgrade permission flag position to 1;

[0122] S205: Restart the vehicle controller.

[0123] The upgrade trigger module is used to trigger the upgrade process after the vehicle controller receives an active command request to enter the boot loader. The vehicle controller restarts, and the program runs to the initialization program of the actual use area of ​​the application to perform the upgrade process. Usually, the vehicle controller receives the command to enter the boot loader under the application as a request in the unified diagnostic service, that is, 0x 1002, or 0x 1082, or the network status is the boot loader. Receiving any of the above instructions will allow the upgrade flag position to be 1, and then restart to enter the boot loader. After entering the application from the boot loader, the rest of the modules of the boot loader flash code segment are executed in the application initialization code segment.

[0124] In this embodiment, the internal logic of the upgrade pre-judgment module is as follows: Figure 4 As shown, the specific steps are:

[0125] S301, determine whether the permission flag is 1; if so, proceed to step S304; if not, jump to step S302;

[0126] S302, determine whether the upgrade status bit is 0; if so, jump to step S305; if not, proceed to step S303;

[0127] S303, determine whether the upgrade status bit is 1; if so, jump to the abnormal code reporting module; if not, jump out of the upgrade process and jump to the subsequent logic of the application;

[0128] S304, determine whether the BMHD running address is the starting address of the boot loader; if so, proceed to step S305; if not, jump to the upgrade process;

[0129] S305, determine whether the existing boot loader is complete; if so, jump to step S306; if not, jump to the upgrade process;

[0130] S306, determine whether the original boot loader is valid; if so, jump to step S307; if not, jump to the upgrade process;

[0131] S307, determine whether the existing and original boot loader versions are consistent; if so, jump out of the upgrade process and jump to the subsequent logic of the application; if not, jump to the upgrade processing process.

[0132] In this embodiment, the upgrade pre-judgment module is used to process pre-judgments including determining whether the upgrade allowed flag is 1, determining the upgrade status bit value, whether BMHD is the boot loader starting address, whether the existing boot loader is complete, whether the original boot loader is valid, and whether the existing boot loader and the original boot loader versions are consistent.

[0133] In this embodiment, BMHD stands for BOOT Mode Headers, which is startup configuration information used to determine the address where the program starts running, and is usually the starting address of the boot loader program under running conditions.

[0134] In the process of determining whether the upgrade flag is 1, if it is not 1, continue to determine the upgrade status bit value; if it is 1, skip the upgrade status bit value determination and execute the BMHD running address determination. In the process of determining the upgrade status bit value, if the upgrade status bit is 0, jump to determine whether the BMHD running address is the starting address of the boot loader; if the upgrade status bit is 1, jump to the abnormal code reporting process; if the upgrade status bit is not 0 and not 1, jump out of the upgrade process and jump back to continue executing the subsequent logic of the application. In the process of determining whether the BMHD is the starting address of the boot loader. If so, continue with other determinations; if not, directly execute the upgrade processing module.

[0135] In the process of determining whether the existing boot loader is complete, if so, continue with other determinations; if not, skip the upgrade processing module and do not perform the upgrade.

[0136] In the process of determining whether the original boot loader is valid, if yes, continue with other determinations; if not, directly execute the upgrade processing module.

[0137] In the process of determining whether the existing boot loader and the original boot loader versions are consistent, if yes, the upgrade processing module is skipped and no upgrade is required; if no, the upgrade processing module is executed.

[0138] In this embodiment, the internal logic of the upgrade processing module is as follows: Figure 5 As shown, the specific process is:

[0139] S401, set the upgrade status position to 1 and store it in the data flash memory;

[0140] S402, determine whether the second judgment before upgrading is passed; if so, proceed to step S403; if not, jump to the abnormal code reporting module;

[0141] S403, decompress the driver and determine whether the driver decompression is successful; if so, jump to step S404, if not, loop step S403 again to decompress until 3 failures have accumulated, and jump to the abnormal code reporting process.

[0142] S404, determine whether the BMHD running address is the starting address of the boot loader, if so, proceed to step S405, if not, jump to step S406;

[0143] S405, update the BMHD running address to the application start address;

[0144] S406, adding 1 to the total number of erase and write times of BMHD, and storing it in the data flash memory;

[0145] S407, determine whether the delivery assembly part number in the original boot loader exists, if yes, proceed to step S408; if not, jump to step S409;

[0146] S408, read the delivery assembly part number and store it in the data flash memory;

[0147] S409, increase the number of execution times of the upgrade process by 1;

[0148] S410, erasing the original boot loader;

[0149] S411, writing the existing boot loader;

[0150] S412. Write the original delivery assembly part number.

[0151] The upgrade processing module is used to handle the processes including updating and storing the upgrade status bit, secondary judgment before upgrading, driver decompression processing and judgment, updating BMHD and total erase and write times, reading and storing the original delivery assembly part number, updating the upgrade process execution times, erasing the original boot loader, writing the existing boot loader and writing the original part number.

[0152] In this embodiment, the delivery assembly part number is the version number in the vehicle manufacturer's database, which is strongly related to the hardware and cannot be changed. The boot loader upgrade needs to retain the data of the original vehicle's version number.

[0153] Among them, the specific process of updating and storing the upgrade status bit includes: setting the upgrade status bit to 1 and storing it in the data flash memory; the initial value of the status bit is 0. If an abnormal power outage occurs during the upgrade process, the flag bit remains 1, which serves as a basis for judging the subsequent identification failure type.

[0154] The specific process of the second judgment before upgrading includes: judging whether the upgrade process is executed less than or equal to 3 times, whether the total number of BMHD erasures is less than or equal to 99, whether there are diagnostic fault codes reported and freeze frame records, and whether the upgrade permission flag is 1.

[0155] In this embodiment, event A is set to be that the number of executions of the upgrade process is less than or equal to 3 times, that is, it is set that the upgrade processing module is allowed to execute cyclically at most 3 times.

[0156] Set event B to a total BMHD erase and write times of less than or equal to 99. In this embodiment, the main chip used by the vehicle controller is Infineon TC387, and the chip manual recommends that the total BMHD erase and write times should not exceed 100.

[0157] Set event C to have a diagnostic trouble code reported and a freeze frame recorded. This event is judged by the diagnostic trouble code status bit. If yes, the judgment condition is met; if no, it is not met.

[0158] Set the event D to allow upgrade flag bit to 1. When the allow upgrade flag bit is 1, the judgment condition is met; when it is 0, upgrade is not allowed. It is only set to 1 in the upgrade trigger module.

[0159] If the contents of the second judgment before the upgrade satisfy A.&B.&(C.||D.), the execution will continue in sequence; if not, the exception reporting module will be executed.

[0160] In this embodiment, the specific process of driver decompression and judgment is as follows: to prevent the program from running away to the driver code segment, the driver is compressed, and it is decompressed and used after it is determined to meet the upgrade conditions, and cleared after the upgrade is completed. If the decompression is successful, the following sequence will be continued; if the decompression fails, the abnormal code reporting module will be executed.

[0161] In this embodiment, the specific process of updating BMHD and the total number of erase and write times includes BMHD judgment and update. When BMHD is judged to be the starting address of the application, the BMHD update is skipped and the execution continues in sequence. When BMHD is judged to be the starting address of the boot loader, BMHD is updated to the starting address of the application, and the total number of erase and write times of BMHD is increased by 1 and stored in the data flash memory.

[0162] In this embodiment, the specific process of reading and storing the original delivery assembly part number is: reading the storage block where the number is located and storing it in the data flash memory.

[0163] In this embodiment, the specific process of updating the upgrade process execution times is: the upgrade process execution times is increased by 1.

[0164] In this embodiment, the specific process of erasing the original boot loader is: erasing the original boot loader in units of software partitions, and the whole process needs to be fed to the dog.

[0165] In this embodiment, the specific process of writing the existing boot loader program is: copying the existing boot loader program to the original boot loader program area, and the whole process needs to be fed to the dog.

[0166] In this embodiment, the specific process of writing the original delivery assembly part number is: erasing the partition where the delivery assembly part number is located and replacing it with the read data.

[0167] In this embodiment, the internal logic of the upgrade verification module is as follows: Figure 6 As shown, the specific process is:

[0168] S501, determine whether the redundancy check of the existing and original boot loader programs is successful; if so, jump to step S502; if not, loop through step S501 until accumulating 3 failures, and jump to the abnormal code reporting process;

[0169] S502, reset the trust list;

[0170] S503, determine whether the reset of the trust list is successful; if so, proceed to step S504; if not, loop step S503 until three failures are accumulated, and jump to the abnormal code reporting process;

[0171] S504, clear the driver;

[0172] S505: Set the upgrade process execution times to 0, set the upgrade permission flag to 0, and set the upgrade status to 2.

[0173] The upgrade verification module is used to process cyclic redundancy check of the existing boot loader, trust list reset of the existing boot loader, BMHD address rollback, driver clearing, and several status bits and flag bits.

[0174] In this embodiment, the trust list is reset to information security related requirements, and the verification ensures that the software source is reliable.

[0175] In this embodiment, the specific process of the cyclic redundancy check of the existing boot loader is as follows: after removing the partition where the delivery assembly part number is located, the cyclic redundancy check codes of the existing boot loader in the application reserved area and the existing boot loader in the original boot loader area are calculated respectively, and the two are compared to see if they are consistent. If they are consistent, the execution continues in sequence; if they are inconsistent, the upgrade processing module jumps back to the second judgment step before the upgrade and executes again.

[0176] In this embodiment, the specific process of resetting the trust list of the existing boot loader is: reset the trust list of the existing boot loader, and if the reset is successful, continue to execute in sequence; if it is inconsistent, jump back to the second judgment step before the upgrade of the upgrade processing module and execute again.

[0177] In this embodiment, the specific process of BMHD address rollback is: changing BMHD back to the boot loader starting address, and adding 1 to the total number of BMHD erase and write times and storing it in the data flash memory.

[0178] In this embodiment, the driver program clearing specifically means clearing the driver program after the upgrade is completed.

[0179] In this embodiment, the specific process of clearing several status bits and flag bits is: setting the number of execution times of the upgrade process to 0, setting the upgrade-allowed flag bit to 0, and setting the upgrade status bit to 2.

[0180] In this embodiment, the internal logic of the abnormal reporting module is as follows: Figure 7 As shown, the specific process is:

[0181] S601, determine whether the reporting code conditions are met; if so, jump to step S603; if not, proceed to step S602;

[0182] S602, clear diagnostic fault codes;

[0183] S603, diagnose fault code reporting and freeze frame recording.

[0184] In this embodiment, during the upgrade of the existing boot loader, if an abnormal situation causes the flashing failure, a diagnostic fault code is reported. If the upgrade trigger module is successfully re-upgraded, the code is cleared.

[0185] Among them, the triggering conditions for reporting diagnostic fault codes under abnormal conditions include:

[0186] If the flashing failure is caused by the failure of driver decompression, cyclic redundancy check or trust list reset, you can try to flash the device up to 3 times. After 3 failed attempts, the corresponding fault record will be stored;

[0187] If the flashing fails due to abnormal power failure or power jitter, the upgrade status bit is 1.

[0188] In this embodiment, the upgrade failure situations include:

[0189] The upgrade judgment results are all yes. At this time, the upgrade judgment includes: judging whether the upgrade-allowed flag is 1, judging whether the BMHD running address is the starting address of the boot loader, judging whether the existing boot loader is complete, judging whether the original boot loader is valid, and judging whether the existing and original loader versions are consistent; the upgrade-allowed flag is not 1, the upgrade status bit is neither 0 nor 1; and the existing boot loader is incomplete.

[0190] In this embodiment, there are two execution logics: the first upgrade and the subsequent upgrade after the first upgrade fails.

[0191] When upgrading the existing bootloader for the first time, the over-the-air download technology will execute the reset command after the application is upgraded to run the upgraded application. First, the initialization code segment is run to execute the bootloader flashing program. The upgrade pre-judgment module and the upgrade processing module determine whether the existing bootloader flashing conditions are met. If they are met, the upgrade is performed in the upgrade processing module and the upgrade verification module. After the upgrade is successful, the subsequent code segments of the application continue to be executed; if they are not met, the bootloader flashing program is skipped and the subsequent code segments of the application continue to be executed.

[0192] Under normal software operation conditions, such as entering the application from the boot loader after the program is started, the boot loader flashing program is not allowed to execute. Ensure that the existing boot loader will not be flashed during normal use of the vehicle to avoid affecting the normal use of the vehicle and reduce the failure rate of boot loader flashing on vehicles on the market. However, considering that the boot loader upgrade fails and needs to be tried again later, when an active command request to enter the boot loader is received (generally issued during the over-the-air download technology upgrade or manually issued using a diagnostic instrument), the upgrade trigger module is executed, the boot loader flashing flag is set, and the boot loader flashing program is triggered to execute. Once the previous flashing fails, the boot loader flashing conditions are met and the flashing is performed.

[0193] In summary, by integrating the existing bootloader and bootloader flashing code in the application used for over-the-air download technology upgrade, the bootloader of the vehicle controller of the market user can be remotely upgraded.

[0194] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A remote upgrade method for a vehicle controller boot loader, characterized in that: The method sets the existing bootloader to be upgraded in the reserved area of ​​the application program, and sets the bootloader flashing program at the initialization program of the actual use area of ​​the application program; When the vehicle controller receives the OTA upgrade instruction, it performs the application upgrade process and executes the reset instruction after the upgrade is completed. After that, the program runs to the initialization program of the actual use area of ​​the application to perform the boot loader upgrade process; If the upgrade process is successful, continue running the application; If one of the preset upgrade failure situations occurs, causing the upgrade process to fail, the upgrade process will be exited, the application will continue to run, and wait for the upgrade to be triggered; Thereafter, when the application is started, if the vehicle controller receives an active command request to enter the bootloader, an upgrade trigger process is performed, and the bootloader upgrade process is performed again; In other cases, the upgrade triggering process is skipped; The upgrade process includes an upgrade pre-judgment process, an upgrade processing process and an upgrade verification process; When one of the preset abnormal situations occurs during the upgrade process, jump to the abnormal code reporting process.

2. A remote upgrade method for a vehicle controller boot loader according to claim 1, characterized in that: The specific process of the upgrade trigger is: after the vehicle controller receives an active command request to enter the boot loader, the upgrade flag is set to 1, and the vehicle controller is restarted, that is, jumping to the upgrade process; The active command request is automatically issued during the air download technology upgrade process, or manually issued using a diagnostic instrument; the active command request includes a request in a unified diagnostic service, or the network status is a boot loader; wherein the request in the unified diagnostic service includes 0x1002 or 0x1082.

3. A remote upgrade method for a vehicle controller boot loader according to claim 1, characterized in that: The upgrade pre-judgment process is: determine in sequence whether the upgrade permission flag is 1, whether the BMHD running address is the starting address of the boot loader, whether the existing boot loader is complete, whether the original boot loader is valid, and whether the existing and original loader versions are consistent. If the above judgment results are all yes, then jump out of the upgrade process and jump back to continue executing the subsequent logic of the application; In the process of determining whether the upgrade permission flag is 1, if the determination result is no, then continue to determine the upgrade status bit, if the upgrade status bit is 0, then jump to determine whether the BMHD running address is the starting address of the boot loader; If the upgrade status bit is 1, jump to the abnormal code reporting process; If the upgrade status bit is neither 0 nor 1, the upgrade process is exited and the subsequent logic of the application is continued to be executed; In the process of judging whether the BMHD running address is the starting address of the boot loader, judging whether the original boot loader is valid, and judging whether the existing and original boot loader versions are consistent, if the judgment result is no, then jump to the upgrade process; In the process of determining whether the existing boot loader is complete, if the determination result is no, the upgrade process is exited and the process is switched back to continue executing the subsequent logic of the application program.

4. A remote upgrade method for a vehicle controller boot loader according to claim 1, characterized in that: The upgrade process includes: A1, set the upgrade status position to 1 and store it in the data flash memory; A2. Perform a second judgment before upgrading; A3, decompress the driver. If the decompression fails, the decompression process is repeated in step A3 until three failures have occurred. The process then jumps to the abnormal code reporting process. If the decompression succeeds, the process continues in step A4. A4, determine whether the BMHD running address is the starting address of the boot loader, if so, update the BMHD running address to the starting address of the application, if not, directly jump to step A5; A5, add 1 to the total number of erase and write times of BMHD, and store it in the data flash memory; A6, determine whether the delivery assembly part number in the original boot loader exists, if yes, read the delivery assembly part number and store it in the data flash memory; if no, directly jump to step A7; A7, increase the number of executions of the upgrade process by 1, and store it in the data flash memory; erase the original boot loader, write the existing boot loader, and write the original delivery assembly part number; A8. Jump to the upgrade verification process.

5. A remote upgrade method for a vehicle controller boot loader according to claim 4, characterized in that: The second judgment before upgrading in step A2 is to judge whether the first event to the fourth event occur; The first event is that the number of executions of the upgrade process exceeds the preset allowed number of cyclic executions; the second event is that the total number of BMHD erase and write times is less than or equal to the preset total number of erase and write times; The third event is the reporting of a diagnostic fault code and a freeze frame record; the fourth event is the upgrade permission flag being 1; if both the first event and the second event occur, and either the third event or the fourth event occurs, the upgrade process continues to be executed; if not, the exception reporting process is jumped.

6. A remote upgrade system for a vehicle controller boot loader according to claim 1, characterized in that: The upgrade verification process is as follows: B1, determine whether the redundancy check of the existing and original boot loader programs is successful. If not, loop through step B1 until three failures are accumulated, and jump to the abnormal code reporting process. If yes, jump to step B2; B2. Reset the trust list. If the reset fails, repeat step B2 until three failures have occurred. Then, jump to the abnormal code reporting process. If the reset succeeds, continue to step B3. B3, change the BMHD address back to the bootloader start address, and increase the total number of BMHD erase and write times by 1, and store it in the data flash memory; B4, clear the driver, and set the upgrade process execution times to 0, the upgrade permission flag position to 0, and the upgrade status position to 2; B5. Exit the upgrade process and jump back to continue executing the subsequent logic of the application.

7. A remote upgrade system for a vehicle controller boot loader according to claim 6, characterized in that: The specific process of the redundancy check of the existing and original boot loaders in step B1 is: respectively calculating the cyclic redundancy check codes of the existing boot loader in the application reserved area and the existing boot loader in the original boot loader area, and comparing them to see if they are consistent. If they are consistent, the check is successful.

8. A remote upgrade system for a vehicle controller boot loader according to claim 1, characterized in that: The abnormal situations include: the driver decompression, cyclic redundancy check or trust list reset cycle flashing fails for a total of 3 times, and the upgrade status bit is 1 due to abnormal power outage or power jitter.

9. A remote upgrade system for a vehicle controller boot loader according to claim 1, characterized in that: In the abnormal reporting process, it is first determined whether it meets the abnormal situation. If it does, the corresponding diagnostic fault code is reported and the freeze frame is recorded. If it does not meet the abnormal situation, the corresponding diagnostic fault code is cleared.

10. A remote upgrade system for a vehicle controller boot loader, characterized in that: The system is applied in a remote upgrade method of a vehicle controller boot loader as described in any one of claims 1 to 9, wherein the system comprises an upgrade trigger module, an upgrade pre-judgment module, an upgrade processing module, an upgrade verification module and an abnormal code reporting module; The upgrade trigger module is used to trigger the upgrade process when the vehicle controller receives an active command request to enter the boot loader program, the vehicle controller restarts, and the program runs to the initialization program in the actual use area of ​​the application program to perform the upgrade process; The upgrade pre-judgment module, the upgrade processing module and the upgrade verification module are used to jointly execute the upgrade process; The abnormality reporting module is used to execute the abnormality reporting process after an abnormal situation occurs during the upgrade process.

Images