A Dual Boot Startup and Program Flashing System and Method

Abstract

The present invention discloses a dual Boot startup and program flashing system and method. This system includes a first Boot startup program and a second Boot startup program stored on the same storage module. The first Boot startup program corresponds to a first flashing system, and the second Boot startup program corresponds to a second flashing system. The first Boot startup program and the second Boot startup program start the first flashing system or the second flashing system according to the programming request valid flag. The present invention has the advantages of low cost and can improve the efficiency of flashing programs during on-site production and testing, etc.

Description

Technical Field

[0001] The present invention mainly relates to the field of software technology, and particularly relates to a dual Boot startup and program flashing system and method. Background Art

[0002] In recent years, new energy vehicles have developed rapidly under the support of national policies. As one of the key core components of new energy vehicles, the stable working performance of the controller or electric drive system has an important impact on the whole vehicle. Usually, the software of an electric drive system needs to be flashed multiple times before leaving the factory, including in-plant test programs and flashing different programs of different OEM manufacturers to refresh the programs. However, the flashing processes and IDs of each vehicle factory or different vehicle models are different, resulting in low program flashing efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention lies in: aiming at the problems existing in the prior art, the present invention provides a dual Boot startup and program flashing system and method with low cost and high flashing efficiency.

[0004] To solve the above technical problem, the technical solution proposed by the present invention is as follows:

[0005] A dual Boot startup and program flashing system includes a first Boot startup program and a second Boot startup program stored on the same storage module. The first Boot startup program corresponds to a first flashing system, and the second Boot startup program corresponds to a second flashing system. The first Boot startup program and the second Boot startup program start the first flashing system or the second flashing system according to the programming request valid flag.

[0006] As a further improvement of the above technical solution:

[0007] The CAN driver layer and network layer of the first flashing system and the second flashing system are shared, and the activation of the two systems is distinguished by identifying the programming request valid flag during reception and transmission. After the first flashing system or the second flashing system is activated, it enters the corresponding protocol application layer. By configuring the two flashing systems differently, different diagnostic requirements of UDS are realized. After entering the corresponding protocol application layer of different flashing systems, different execution functions are called to realize different functions of the same service. After entering the function application layer to execute the corresponding functions, the corresponding responses are finally replied through the initially recognized flag, completing the implementation of a complete set of flashing systems.

[0008] The diagnostic requirements include diagnostic mode conditions, NRC negative response order, security access levels, and sub-service support and disabling.

[0009] The function application layer executes corresponding functions including service upload address and length calculation, service CRC check, service routine support status, and different operations on the FLASH.

[0010] The first flashing system corresponds to the in-plant system, and the second flashing system corresponds to the OEM system; after obtaining the data through the network layer, the pointer of the corresponding array is taken to obtain the specific data array, the activated system is judged, and the in-plant configuration table or the OEM configuration table is taken.

[0011] When the activated system is the in-plant system, the in-plant configuration table is selected, and corresponding configuration judgment and negative response sequence adjustment are carried out in the in-plant application according to the configuration to meet the configuration requirements of in-plant flashing; finally, at the function configuration, the specific flashing function is executed.

[0012] When the activated system is the OEM system, the OEM configuration table is selected, and corresponding configuration judgment and negative response sequence adjustment are carried out in the OEM application according to the configuration to meet the configuration requirements of OEM flashing; finally, at the function configuration, the specific flashing function is executed.

[0013] The present invention also discloses a method based on the dual Boot startup and program flashing system as described above, including a dual Boot startup method and a flashing preparation method. The dual Boot startup method includes the steps:

[0014] Read the programming request valid flag and perform three processes according to the read value:

[0015] If the in-plant flag is detected to be valid, reply to the in-plant command and stay in the Boot to wait for the in-plant flashing command.

[0016] If the OEM flag is detected to be valid, reply to the OEM command and stay in the Boot to wait for the OEM flashing command.

[0017] If the programming request is detected to be invalid, perform the next condition detection: detect whether the application program is valid.

[0018] If the application program is invalid, stay in the Boot to wait for the flashing command. If it is valid, perform the next condition detection: power-on interception judgment.

[0019] Perform three processes according to the read value. If the in-plant interception mode is detected, reply to the in-plant command and stay in the Boot to wait for the in-plant flashing command. If the OEM interception mode is detected, reply to the OEM command and stay in the Boot to wait for the OEM flashing command. If no interception mode is detected, perform the safety process before jumping, and finally jump to run in the APP.

[0020] As a further improvement of the above technical solution:

[0021] The described flashing preparation method includes the steps:

[0022] Identify the flashing command sent by CAN. When receiving the in-plant flashing command, write the in-plant programming request flag; when receiving the OEM flashing command, write the OEM programming request flag; then perform the safety processing before jumping, and finally execute the reset.

[0023] Compared with the prior art, the advantages of the present invention are as follows:

[0024] The present invention relates to embedded Boot startup and program flashing. By identifying the CAN frame ID, it enters two relatively independent flashing processes respectively, realizing a system that supports two sets of flashing processes simultaneously on the same controller; the present invention integrates two sets of flashing processes in the same Boot, combines with the UDS software flashing service rule - ISO14229 (ISO15765) protocol, and realizes the update of the program for the automatic identification process of the new energy vehicle electric drive system software; and solves the problem of automatic identification and startup processing of the two systems when powering on or restarting, which can improve the efficiency of flashing the program during on-site production and testing.

[0025] The present invention can realize relatively independent startup methods for two systems in the same software, including independent flashing reply, jump, and interception methods; the present invention can realize relatively independent program flashing processes for two systems in the same software, including independent requirement condition configuration, response reply, function execution, flashing verification, etc.

[0026] By integrating two sets of flashing processes in the same Boot, the present invention reduces the production demand of the manufacturing department to purchase multiple sets of flashing upper computers due to different in-plant flashing processes, and reduces the production equipment purchase cost. By integrating two sets of flashing processes in the same Boot, in after-sales or other places with software upgrade requirements, the OEM manufacturer can update the program with the OEM diagnostic instrument; and for after-sales personnel regardless of which manufacturer, they only need to use their own upper computer to update the program, reducing economic costs such as software management and software development; by integrating two sets of flashing processes in the same software, sharing the driver layer and network layer, etc., the present invention reduces the code amount, is more suitable for chips with small FLASH space, and reduces the hardware cost of the controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is the overall framework diagram of the system of the present invention in the embodiment.

[0028] Figure 2 It is the architecture block diagram of the system of the present invention in the embodiment.

[0029] Figure 3 It is the flowchart of the dual-Boot startup method of the present invention.

[0030] Figure 4 This is the flowchart of the flashing preparation method of the present invention.

[0031] Figure 5 This is the design block diagram of the network layer of the present invention.

[0032] Figure 6 This is the design block diagram of the protocol layer of the present invention. Detailed implementation manners

[0033] The present invention will be further described below in conjunction with the accompanying drawings of the specification and specific embodiments.

[0034] As Figure 1 shown, the dual Boot startup and program flashing system of the present invention is divided into two processing mechanisms: startup and flashing. The general idea is as Figure 1 shown, specifically including a first Boot startup program and a second Boot startup program stored on the same storage module. The first Boot startup program corresponds to a first flashing system, and the second Boot startup program corresponds to a second flashing system. The first Boot startup program and the second Boot startup program start the first flashing system or the second flashing system according to the programming request valid flag.

[0035] As Figure 2 shown, in terms of the design of the flashing processing mechanism, first, the CAN driver is shared. Compared with a general CAN driver, the activation of the two systems is distinguished by identifying the ID during reception and transmission; at the same time, the data network layer for reception and transmission is shared, that is, the network layer data of the two systems is the same because only one set of IDs is sent at the same time; after the two independent flashing systems identify which system is activated, they enter the corresponding protocol application layer. By configuring the two systems differently, different diagnostic requirements of UDS are realized, such as different requirements for diagnostic mode conditions, NRC negative response order, security access level, sub-service support and disablement, etc.; after entering the corresponding protocol application layer of different systems, different execution functions are called to implement different functions for the same service, and the corresponding functions are executed in the function application layer, such as service upload address and length calculation, service CRC check, service routine support situation, different operations on the FLASH required for the two systems, etc.; finally, the corresponding ID response is replied by identifying the ID at the beginning, and a complete set of flashing systems is implemented.

[0036] As Figure 2 shown, the network layer of the data received and sent by the system architecture design is shared, that is, the network layer data of the two systems is the same because only one set of IDs is sent at the same time; as Figure 5 in the network layer design, the sent CAN frame is received at the CAN driver and judged at the network layer. Figure 5The "judgment of frame type" in it is a way to judge the frame type as an example, which judges whether the received CAN ID is an OEM ID or an in-plant ID; all the received data is processed and stored in the data RpduInfo for use by the application layer; after the application layer response command is processed through the array TpduInfo, the CAN driver sends the data of the OEM ID or the in-plant ID according to the starting "frame type" and the "received CAN ID"; in this way, the use of the same network layer to send and receive different system data is completed.

[0037] Such as Figure 2 As shown, the application layer can be divided into a protocol layer and a functional application layer, and each part is independent of each other, so that the configurable differences in the negative response sequence and conditions of the two systems can be met; there are multiple services in the protocol layer of each system, and each service can correspond to different functional application functions, such as Figure 6 The protocol layer design gives an example of service routine control:

[0038] First, after obtaining the data through the network layer, get the pointer of the corresponding array to obtain the specific data array, judge the activated system, and select the in-plant configuration table (UDS diagnostic configuration) or the OEM configuration table;

[0039] When the activated system is an in-plant system, select the in-plant configuration table, and make corresponding configuration judgments and adjustments to the negative response sequence according to the configuration in the in-plant application to meet the configuration requirements of in-plant flashing; finally, at the function configuration, execute the specific flashing function, such as in-plant download data format, data, verification, etc., or the routine service IDs used are 0xfa00 / 0xfa01 / 0xfa02 / 0xfa03, and execute the specific functions of conditional judgment / erasure / data verification / integrity verification defined by the in-plant respectively;

[0040] When the activated system is an OEM system, select the OEM configuration table, and make corresponding configuration judgments and adjustments to the negative response sequence according to the configuration in the OEM application to meet the configuration requirements of OEM flashing; finally, at the function configuration, execute the specific flashing function, such as OEM in-plant download data format, data, verification, etc., or the routine service IDs used are 0x0203 / 0202 / 0204 / 0x0205, and execute the specific functions of conditional judgment / erasure / data verification / integrity verification defined by the OEM specification respectively;

[0041] Similarly, for other services in the flashing process, such as request download, data download, request to exit and other related services, the principle is similar to the example of service routine control to implement the flashing functions of different systems.

[0042] The present invention also discloses a method based on the dual - Boot startup and program flashing system as described above, including a dual - Boot startup method and a flashing preparation method. The dual - Boot startup method includes steps as follows: Figure 3 as shown:

[0043] Since two sets of Boot are integrated in one program, corresponding processing is required during program startup. For example: Figure 3 For the dual - Boot startup function, when the program starts for the first time, after power - on or reset, first perform software and hardware initialization to prepare for program startup; then read the programming request valid flag, and there are 3 processes according to the read value:

[0044] If the in - factory flag is detected to be valid, reply to the in - factory command and stay in the Boot to wait for the in - factory flashing command;

[0045] If the OEM flag is detected to be valid, reply to the OEM command and stay in the Boot to wait for the OEM flashing command;

[0046] If the programming request is detected to be invalid, perform the next condition check: when the programming request flag is invalid, check whether the application program is valid. If it is invalid, stay in the Boot to wait for the flashing command; if it is valid, perform the next condition check; when checking whether the application program is valid, perform power - on interception judgment: there are 3 processes according to the read value. If the in - factory interception mode is detected, reply to the in - factory command and stay in the Boot to wait for the in - factory flashing command; if the OEM interception mode is detected, reply to the OEM command and stay in the Boot to wait for the OEM flashing command; if no interception mode is detected, perform the safety processing before jumping, and finally jump to run in the APP.

[0047] Through the above, the function of dual - Boot startup is completed, and the OEM and in - factory flashing functions are recognized during the startup process. At the same time, the required interception mode is judged to prepare for subsequent program flashing.

[0048] For example: Figure 4 As shown, the flashing preparation method includes: Since two sets of Boot are integrated in one program, corresponding processing of commands is required during program operation. When the program is running normally in the APP, recognize the flashing commands sent by CAN. When receiving the in - factory flashing command, write the in - factory programming request flag; when receiving the OEM flashing command, write the OEM programming request flag; then perform the safety processing before jumping, and finally execute a reset. In this way, the program will perform corresponding system recognition in the process as shown: Figure 3 as shown.

[0049] The present invention relates to embedded Boot startup and program flashing. By identifying the CAN frame ID, it enters two relatively independent flashing processes respectively, realizing a system that supports two sets of flashing processes on the same controller at the same time. The present invention integrates two sets of flashing processes in the same Boot and combines with the UDS software flashing service rule - ISO14229 (ISO15765) protocol to update the program for the automatic identification process of the new energy vehicle electric drive system software; and solves the automatic identification and startup processing of the two systems when powered on or restarted.

[0050] The present invention can realize relatively independent startup methods for two systems in the same software, including independent flashing reply, jump and interception methods; the present invention can realize relatively independent program flashing processes for two systems in the same software, including independent requirement condition configuration, response reply, function execution, flashing verification, etc.

[0051] By integrating two sets of flashing processes in the same Boot, the present invention reduces the production demand of the manufacturing department for purchasing multiple sets of flashing upper computers due to different flashing processes of manufacturers, and reduces the production equipment purchase cost. By integrating two sets of flashing processes in the same Boot, in after-sales or other places where software upgrade is required, the OEM manufacturer can update the program with the OEM diagnostic instrument; and after-sales personnel, regardless of which manufacturer, only need to use their own upper computer to update the program, reducing economic costs such as software management and software development; by integrating two sets of flashing processes in the same software and sharing the driver layer and network layer, etc., the present invention reduces the code amount, is more suitable for chips with small FLASH space, and reduces the hardware cost of the controller.

[0052] The above is only the preferred implementation mode of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, several improvements and refinements made without departing from the principle of the present invention should be regarded as the protection scope of the present invention.

Claims

1. A dual-Boot startup and program flashing system, characterized in that It includes a first Boot startup program and a second Boot startup program stored on the same storage module. The first Boot startup program corresponds to a first flashing system, and the second Boot startup program corresponds to a second flashing system. The first Boot startup program and the second Boot startup program start the first flashing system or the second flashing system according to the programming request valid flag. The CAN driver layer and network layer of the first flashing system and the second flashing system are shared. During reception and transmission, the activation of the two systems is distinguished by identifying the programming request valid flag. After the first flashing system or the second flashing system is activated, it enters the corresponding protocol application layer. By configuring the two flashing systems differently, different diagnostic requirements of UDS are realized. After entering the corresponding protocol application layer of different flashing systems, different execution functions are called to implement different functions of the same service. After entering the function application layer to execute the corresponding functions, the corresponding responses are finally replied through the initially identified flag, completing the implementation of a complete set of flashing systems. The application layer is divided into a protocol layer and a function application layer, and each part is independent of each other. The first flashing system corresponds to the in-plant system, and the second flashing system corresponds to the OEM system. After obtaining the data through the network layer, the pointer of the corresponding array is used to obtain the specific data array, and the activated system is judged, and the in-plant configuration table or the OEM configuration table is selected. When the activated system is the in-plant system, the in-plant configuration table is selected, and the corresponding configuration judgment and the adjustment of the negative response order are carried out in the in-plant application according to the configuration to meet the configuration requirements of in-plant flashing. Finally, at the function configuration, the specific flashing function is executed. When the activated system is the OEM system, the OEM configuration table is selected, and the corresponding configuration judgment and the adjustment of the negative response order are carried out in the OEM application according to the configuration to meet the configuration requirements of OEM flashing. Finally, at the function configuration, the specific flashing function is executed.

2. The dual Boot startup and program flashing system according to claim 1, wherein The diagnostic requirements include diagnostic mode conditions, NRC negative response order, security access level, and sub-service support and disablement.

3. The dual Boot startup and program flashing system according to claim 1, characterized in that, The functions executed by the function application layer include service upload address and length calculation, service CRC check, service routine support situation, and different operations on the FLASH.

4. A method for a dual Boot startup and program flashing system according to any one of claims 1-3, characterized in that, It includes a dual Boot startup method and a flashing preparation method. The dual Boot startup method includes the steps: Read the programming request valid flag and perform three processes according to the read value: If the in-plant flag is detected to be valid, reply the in-plant command and stay in the Boot waiting for the in-plant flashing command. If the OEM flag is detected to be valid, reply the OEM command and stay in the Boot waiting for the OEM flashing command. If the programming request is detected to be invalid, perform the next condition check: check whether the application program is valid. If the application program is invalid, stay in the Boot waiting for the flashing command. If it is valid, perform the next condition check: power-on interception judgment. According to the read value, it is processed in three ways. If the in-factory interception mode is detected, the in-factory command is replied and it stays in Boot waiting for the in-factory flashing command; if the OEM interception mode is detected, the OEM command is replied and it stays in Boot waiting for the OEM flashing command; if no interception mode is detected, the safety processing before jumping is performed, and finally it jumps to run in the APP.

5. The method according to claim 4, wherein The flashing preparation method includes the steps: Identify the flashing command sent by CAN. When receiving the in-factory flashing command, write the in-factory programming request flag; when receiving the OEM flashing command, write the OEM programming request flag; Then perform the safety processing before jumping, and finally execute the reset.

Images