An OTA flashing method of a CAN-ECU

Abstract

The application provides an OTA flashing method of a CAN-ECU, which can effectively identify the scene of false success of CAN-ECU flashing through the steps of pre-flashing inspection of a target ECU, ECU state reading, part number reading and comparison, version number reading and comparison, CAN-ECU BootLoad flashing and data completion inspection, and performs retry flashing to ensure that the ECU is successfully flashed, improves the success rate of CAN-ECU flashing, and compared with the traditional flashing method, can effectively solve the problem that the ECU function is invalid due to flashing failure, causes vehicle function abnormality, and seriously affects user experience and safety.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to an OTA flashing method for a CAN-ECU. Background Technology

[0002] With the development of vehicle networking, OTA is increasingly used in intelligent connected vehicles. Software-defined vehicles will be the future development direction of intelligent connected vehicles. OTA can realize the iteration of the whole vehicle ECU function, continuously providing car owners with new functions and new experiences, breaking through the traditional car service model. The success rate requirements for OTA upgrades of CAN-ECU are very strict, because CAN-ECU usually does not have A / B partition function. Once the flashing fails, it will cause functional failure, causing abnormal vehicle functions, seriously affecting user experience and safety. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide an OTA flashing method for CAN-ECUs, so as to effectively identify scenarios where CAN-ECU flashing is unsuccessful and retry the flashing process to ensure that the ECU is successfully flashed and improve the success rate of CAN-ECU flashing.

[0004] To achieve the above objectives, this invention provides an OTA flashing method for a CAN-ECU, comprising the following steps:

[0005] Step S1. Pre-flash check: Before performing the actual BT flash, determine whether the ECU APP application is valid and whether the part number and software version number meet the flashing requirements;

[0006] Step S2. Use the 19 02 01 service to read the fault code DTC of the target ECU and determine whether the ECU APP is valid. If the ECU returns a negative response or no response signal, it is considered that the ECU APP application is in a failed state. Then, the comparison environment of part number and version number is skipped and the BT flashing is directly entered. Step S7 is executed; otherwise, step S3 is executed.

[0007] Step S3. Read the part number of the target ECU through the 22 F1 13 service. If the part number fails to be read three times in a row, the ECU returns a negative response or no response signal, and proceed to step S7; if the reading is successful, proceed to step S4.

[0008] Step S4. Compare the read part number. If the part number does not match, exit the flashing state and exit the OTA process; if the part number matches, proceed to step S5.

[0009] Step 5. Read the version number of the target ECU through the 22 F1 18 service. If the version number fails to be read three times in a row, the ECU returns a negative response or no response signal, and proceed to step S7; if the reading is successful, proceed to step S6.

[0010] Step S6. Compare the read version number. If the version numbers match, exit the flashing state and exit the OTA process; if the version numbers do not match, proceed to step S7.

[0011] Step S7. Enter the CAN-ECU BootLoad flashing process to upgrade the software of the target ECU;

[0012] Step S8. After the software upgrade is completed, check the integrity of the target ECU data by physical addressing 31 01 02 02 aa. If the check fails, return to step S7 to re-flash and upgrade the target ECU. If the check passes or fails more than 3 times in a row, proceed to step S9.

[0013] Step S9. Use the 22 F1 18 service to read the version number of the target ECU, verify the flashing and upgrade results of the target ECU, and ensure that the flashing and upgrade of the target ECU is successful;

[0014] Step S10. End.

[0015] Preferably, for scenarios where a target ECU has multiple hardware versions and corresponding software versions, the hardware information of the target ECU can be uniquely identified by reading the part number to ensure the compatibility between the hardware and software versions. The flashing and upgrade can be performed only after the compatibility verification is completed, thus avoiding flashing failure due to hardware version incompatibility.

[0016] Preferably, after the part number verification is completed, the software version number needs to be read and a consistency check is performed to ensure that the software version of the target ECU being upgraded is inconsistent with the current software of the target ECU. If they are consistent, the upgrade process is exited to avoid repeated upgrades.

[0017] Preferably, after the version number comparison is completed, if all preconditions are met, the BootLoad flashing process is initiated; and after the data flashing is completed, an integrity check is performed. If the integrity check passes, the OTA upgrade is considered successful; otherwise, the OTA flashing is considered to have failed, and the BootLoad flashing is repeated 3 times to ensure successful flashing.

[0018] Furthermore, if the integrity check still fails after three repeated BootLoad flashing attempts, it indicates that this round of flashing has failed and the system awaits the next flashing task. In this state, the ECU APP is invalid. The next flashing task will check the validity of the ECU APP in the first stage and then directly enter the BT flashing process. This process is repeated to ensure that the ECU flashing is successful.

[0019] Preferably, after checking the integrity of the target ECU data, it is still necessary to restore the ECU's communication and read the ECU software version number, and use the software version number as evidence of successful upgrade, so as to ensure the validity of the successful upgrade information and identify fake flashing cases.

[0020] The advantages of this invention over the prior art are:

[0021] This invention provides an OTA flashing method for CAN-ECU, which can effectively identify scenarios where CAN-ECU flashing is falsely successful and retry the flashing process to ensure that the ECU is successfully flashed, thereby improving the success rate of CAN-ECU flashing. Compared with traditional flashing methods, this invention can effectively solve the problem of ECU malfunction caused by flashing failure, resulting in abnormal vehicle functions and seriously affecting user experience and safety. Attached Figure Description

[0022] Figure 1 This is a flowchart of an OTA flashing method for a CAN-ECU according to the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] like Figure 1 As shown, this invention proposes an OTA flashing method for a CAN-ECU, including the following steps:

[0025] Step S1. Pre-flash check: Before performing the actual BT flash, determine whether the ECU APP application is valid and whether the part number and software version number meet the flashing requirements;

[0026] Step S2. Use the 19 02 01 service to read the fault code DTC of the target ECU and determine whether the ECU APP is valid. If the ECU returns a negative response or no response signal, it is considered that the ECU APP application is in a failed state. Then, the comparison environment of part number and version number is skipped and the BT flashing is directly entered. Step S7 is executed; otherwise, step S3 is executed.

[0027] Step S3. Read the part number of the target ECU through the 22 F1 13 service. If the part number fails to be read three times in a row, the ECU returns a negative response or no response signal, and proceed to step S7; if the reading is successful, proceed to step S4.

[0028] Step S4. Compare the read part number. If the part number does not match, exit the flashing state and exit the OTA process; if the part number matches, proceed to step S5.

[0029] Step 5. Read the version number of the target ECU through the 22 F1 18 service. If the version number fails to be read three times in a row, the ECU returns a negative response or no response signal, and proceed to step S7; if the reading is successful, proceed to step S6.

[0030] Step S6. Compare the read version number. If the version numbers match, exit the flashing state and exit the OTA process; if the version numbers do not match, proceed to step S7.

[0031] Step S7. Enter the CAN-ECU BootLoad flashing process to upgrade the software of the target ECU;

[0032] Step S8. After the software upgrade is completed, check the integrity of the target ECU data by physical addressing 31 01 02 02 aa. If the check fails, return to step S7 to re-flash and upgrade the target ECU. If the check passes or fails more than 3 times in a row, proceed to step S9.

[0033] Step S9. Use the 22 F1 18 service to read the version number of the target ECU, verify the flashing and upgrade results of the target ECU, and ensure that the flashing and upgrade of the target ECU is successful;

[0034] Step S10. End.

[0035] Preferably, for scenarios where a target ECU has multiple hardware versions and corresponding software versions, the hardware information of the target ECU can be uniquely identified by reading the part number to ensure the compatibility between the hardware and software versions. The flashing and upgrade can be performed only after the compatibility verification is completed, thus avoiding flashing failure due to hardware version incompatibility.

[0036] Preferably, after the part number verification is completed, the software version number needs to be read and a consistency check is performed to ensure that the software version of the target ECU being upgraded is inconsistent with the current software of the target ECU. If they are consistent, the upgrade process is exited to avoid repeated upgrades.

[0037] Preferably, after the version number comparison is completed, if all preconditions are met, the BootLoad flashing process is initiated; and after the data flashing is completed, an integrity check is performed. If the integrity check passes, the OTA upgrade is considered successful; otherwise, the OTA flashing is considered to have failed, and the BootLoad flashing is repeated 3 times to ensure successful flashing.

[0038] Furthermore, if the integrity check still fails after three repeated BootLoad flashing attempts, it indicates that this round of flashing has failed and the system awaits the next flashing task. In this state, the ECU APP is invalid. The next flashing task will check the validity of the ECU APP in the first stage and then directly enter the BT flashing process. This process is repeated to ensure that the ECU flashing is successful.

[0039] Preferably, after checking the integrity of the target ECU data, it is still necessary to restore the ECU's communication and read the ECU software version number, and use the software version number as evidence of successful upgrade, so as to ensure the validity of the successful upgrade information and identify fake flashing cases.

[0040] In summary, compared with traditional flashing methods, this invention can effectively solve the problem of ECU malfunction caused by flashing failure, resulting in abnormal vehicle functions and seriously affecting user experience and safety.

[0041] The above description is merely a preferred embodiment of the present invention and does not constitute any limitation on the structure of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention shall fall within the scope of the technical solution of the present invention.

Claims

1. An OTA flashing method for a CAN-ECU, characterized in that, Includes the following steps: Step S1. Pre-flash check: Before performing the actual BootLoad flash, determine whether the ECU APP application is valid and whether the part number and software version number meet the flashing requirements; Step S2. Use the 19 02 01 service to read the fault code DTC of the target ECU and determine whether the ECU APP is valid. If the ECU returns a negative response or no response signal, it is considered that the ECU APP application is in a failed state. Then, the comparison environment of part number and version number is skipped and the BootLoad flashing is directly entered. Step S7 is executed. Otherwise, step S3 is executed. Step S3. Read the part number of the target ECU through the 22 F1 13 service. If the part number fails to be read 3 times in a row, the ECU returns a negative response or no response signal, and proceed to step S7. If the read is successful, proceed to step S4; Step S4. Compare the read part number. If the part number does not match, exit the flashing state and exit the OTA process. If the part numbers match, proceed to step S5; Step S5. Read the version number of the target ECU through the 22 F1 18 service. If the version number fails to be read three times in a row, the ECU returns a negative response or no response signal, and proceed to step S7; if the reading is successful, proceed to step S6. Step S6. Compare the read version number. If the version numbers match, exit the flashing state and exit the OTA process; if the version numbers do not match, proceed to step S7. Step S7. Enter the CAN-ECU BootLoad flashing process to upgrade the software of the target ECU; Step S8. After the software upgrade is completed, check the integrity of the target ECU data by physical addressing 31 01 02 02 aa. If the check fails, return to step S7 to re-flash and upgrade the target ECU. If the check passes or fails more than 3 times in a row, proceed to step S9. Step S9. Use the 22 F1 18 service to read the version number of the target ECU, verify the flashing and upgrade results of the target ECU, and ensure that the flashing and upgrade of the target ECU is successful; After the version number comparison is completed, if all the preconditions are met, the BootLoad flashing process will be entered to flash the data. After the data flashing is completed, an integrity check will be performed. If the integrity check passes, the OTA upgrade will be successful. Otherwise, the OTA flashing will be considered a failure, and the BootLoad flashing will be repeated 3 times to ensure that the flashing is successful. If the integrity check still fails after three repeated BootLoad flashing attempts, it means that this round of flashing has failed and the process will wait for the next flashing task. In this state, the ECU APP is invalid. The next flashing task will check the validity of the ECU APP in the first step and then directly enter the BootLoad flashing process. This process is repeated to ensure that the ECU flashing is successful. Step S10. End.

2. The OTA flashing method for a CAN-ECU according to claim 1, characterized in that, For scenarios where a target ECU has multiple hardware versions and corresponding software versions, the hardware information of the target ECU is uniquely identified by reading the part number to ensure the compatibility between the hardware and software versions. The flashing and upgrade are performed only after the compatibility verification is completed to avoid flashing failure due to hardware version incompatibility.

3. The OTA flashing method for a CAN-ECU according to claim 1, characterized in that, After the part number comparison is completed, the software version number needs to be read and a consistency check needs to be performed to ensure that the software version of the target ECU being upgraded is inconsistent with the current software of the target ECU. If they are consistent, the upgrade process is exited to avoid repeated upgrades.

4. The OTA flashing method for a CAN-ECU according to claim 1, characterized in that, After checking the integrity of the target ECU data, it is still necessary to restore the ECU's communication and read the ECU software version number. The software version number is used as evidence of a successful upgrade to ensure the validity of the upgrade success information and identify fake flashing cases.

Images