A software refresh anti - mis - flashing method

Abstract

The present invention discloses a software refresh anti-miswriting method, which includes the following steps: S1: Before refreshing the program, identify the starting value of the bin file. S2: Before refreshing the program, identify the file size to be written. S3: When reading the hardware version number, enter the underlying software for reading using the 1002 service, and at the same time compare the hardware version number to avoid the unsuccessful refresh of the TCU software caused by the application layer hardware version number during library flipping. After reading the underlying hardware version number, perform a 1103 reset and then perform software refresh; S4: The 1001 service and the 1003 service are separated by 100 ms to avoid the TCU not responding due to too short an interval between sending commands; S5: When the 36 service transfers data during the writing process, the packet size is 1044. The present invention can improve the writing accuracy while ensuring the refresh efficiency of the controller, and improve the efficiency of software development work.

Description

Technical Field

[0001] The present invention relates to the technical field of automotive transmission software, and particularly to a software refresh anti-error writing method. Background Art

[0002] With the increasing update frequency of the configuration requirements in the automotive market, for vehicle manufacturers, the update of controllers closely related to configurations and functions also needs to improve efficiency to cope with market changes. For the situation where only updating the controller software can meet the configuration or function changes, the controller writing function and upgrade function are the most direct and effective ways. However, in engineering practice, due to non-standard writing, imperfect after-sales processes, and heavy workloads, the software written into the controller often has various errors, and in severe cases, even causes batch accidents, leading to serious complaints from the automobile factory and claims from suppliers. Moreover, due to software problems caused by consumers during use, manual updates are often required. If any problems occur during the upgrade, or there is a possibility of vehicle return, it will lead to a low evaluation of the vehicle manufacturer by consumers, seriously affecting the reputation of the vehicle manufacturer. Therefore, how to improve the accuracy and efficiency of refreshing the controller is an urgent problem for suppliers to solve.

[0003] In the development of automotive electronic products, the ECU has relatively high requirements for safety and reliability indicators. Therefore, software updates may occur during the software download process and after-sales. To facilitate after-sales service, save costs, and avoid damage to the ECU hardware products, the automotive industry uses dedicated diagnostic test equipment according to various standards to update the ECU control program or data through a standard communication interface. The Bootloader is a program that resides in a specific location of the ECU internal flash to complete the above functions. Based on the customer-defined Bootloader mechanism or assisting the user to customize the Bootloader mechanism, according to communication protocols such as UDS, and cooperating with a streamlined underlying driver to complete the development of the Bootloader program to achieve the program functions. Summary of the Invention

[0004] The present invention provides a software refresh anti-error writing method, which can improve the writing accuracy while ensuring the controller refresh efficiency, and improve the efficiency of software development work.

[0005] The technical solutions to solve the above problems are as follows:

[0006] Based on the multi-channel SSPC capacitive load identification method, it includes the following steps:

[0007] A software refresh anti-error writing method includes the following steps:

[0008] S1: Before refreshing the program, identify the starting value of the bin file.

[0009] S2: Before refreshing the program, identify the size of the file to be flashed.

[0010] S3: When reading the hardware version number, enter the underlying software using service 10 02 to read it, and at the same time compare the hardware version number to avoid the unsuccessful refreshing of the TCU software due to the application layer hardware version number during library flipping. After reading the underlying hardware version number, perform a reset using service 11 03 and then perform software refreshing.

[0011] S4: The interval between service 10 01 and service 10 03 is 100 ms to avoid the TCU not responding due to too short an interval between sending commands.

[0012] S5: When transferring data using service 36 during the flashing process, the packet size is 1044.

[0013] S6: For the application layer bin software file, perform verification using CRC32 or CRC16 files to ensure the consistency of controller data flashing.

[0014] S7: Set the reset time of service 11 03 to 3.5 s to increase the probability of successful software refreshing.

[0015] S8: During the entire software refreshing process, use the communication hold method. When the TCU message duration is 4 s without feedback, send the communication hold service 3E 80.

[0016] S9: After software refreshing is completed, read the hardware version, software version, and software part number as needed and display them through the display screen for easy viewing and comparison by the refreshing program personnel.

[0017] S10: Add the function of writing to DID018B, and use service 22 to read the written content to determine whether the ejection function has been added.

[0018] S11: Determine whether to write the handle information according to the requirements, and print the handle information to the corresponding log file.

[0019] S12: Write the serial number of the gearbox into the controller, use service 22 to read the gearbox serial number, and display the printed log file in decimal form.

[0020] S13: Flash the 4-in-1 bin file into the controller to reduce configuration files and prevent misoperation.

[0021] Preferably, in step S1, identify in advance all the starting values of the software to be refreshed, and identify in advance the software that is not the one intended to be refreshed. If it is identified that it is indeed caused by abnormal software, prompt the flashing failure and the reason for the failure to avoid misflashing software.

[0022] Preferably, in step S3, a function is written through C language programming to identify in advance the sizes and lengths of all files to be flashed, and the length variable is used as a local variable in the written statement. According to the identified length sizes, it can be determined whether the software is repeatedly identified.

[0023] Preferably, before executing step S3, the underlying hardware version number of the controller is read through UDS, which increases the probability of successful software flashing of the hardware version number written in the application layer during library turnover, and determines whether the hardware of the controller to be flashed is the required hardware. If the comparison is correct, the flashing continues; if the comparison fails, a flashing failure and the reason for the failure are prompted to avoid incorrect selection of the control model.

[0024] Preferably, in step S5, the length of the last packet is transmitted according to the actual situation, and the packet splitting is limited to be below the maximum feedback by the TCU, which improves the probability of successful flashing.

[0025] Preferably, in step S11, the mechanical handle or electronic handle is written through the 2E service in the development configuration. If the writing is incorrect, the error problem is printed through the log file.

[0026] The software flashing error prevention development method of the present invention processes the controller, software, and software part numbers in blocks. For the relevant hardware, corresponding software version, corresponding software part number for software flashing, they are added manually in the flashing configuration. If the software to be flashed conforms to the actual situation, the flashing passes; otherwise, it fails. In this way, while ensuring the controller flashing efficiency, the flashing accuracy is improved, and the efficiency of software development work is enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 is a flowchart of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] As Figure 1 shown, a software flashing error prevention method of the present invention includes the following steps:

[0029] S1: Before the flashing program, identify the starting value of the bin file; in this step, identify in advance the starting values of all software to be flashed, and identify in advance the software that is not the one wanted to be flashed into. If it is identified that it is indeed caused by abnormal software, a flashing failure and the reason for the failure are prompted to avoid the situation of incorrect software flashing.

[0030] S2: Before the flashing program, identify the size of the file to be flashed. In this step, a function is written through C language programming to identify in advance the sizes and lengths of all files to be flashed, and the length variable is used as a local variable in the written statement. According to the identified length sizes, it can be determined whether the software is repeatedly identified.

[0031] Before executing step S3, read the underlying hardware version number of the controller through UDS to increase the probability of successful software refresh of the hardware version number written in the application layer during library turnover, and determine whether the hardware of the controller to be refreshed is the required hardware. If the comparison is correct, continue with the flashing; if the comparison fails, prompt the flashing failure and the reason for the failure to avoid incorrect selection of the control model.

[0032] S3: When reading the hardware version number, use service 10 02 to enter the underlying software for reading, and at the same time compare the hardware version number to avoid unsuccessful TCU software refresh caused by the application layer hardware version number during library turnover. After reading the underlying hardware version number, use service 11 03 for reset and perform software refresh;

[0033] S4: The interval between service 10 01 and service 10 03 is 100 ms to avoid TCU non-response caused by too short a command sending interval and avoid flashing failure caused by the controller not having enough time to react due to too short a time interval.

[0034] S5: When transmitting data using service 36 during the flashing process, the packet size is 1044. In this step, the length of the last packet is transmitted according to the actual situation, and the packet is limited to be below the maximum feedback by the TCU to increase the probability of successful refresh.

[0035] S6: Use CRC32 or CRC16 to verify the application layer bin software file to ensure the consistency of controller data flashing. When flashing the driver file and APP file, use the CRC32 or CRC16 algorithm to verify the file to ensure the consistency of data flashing, prevent incorrect software flashing, and at the same time facilitate comparison with other flashing tools to see if the flashed software is the same version.

[0036] S7: Set the 11 03 reset time to 3.5S to increase the probability of successful software refresh. Use service 11 03 for software reset and limit the reset time to 3.5S to improve the flashing ability of the refresh configuration for the software, reduce the number of configuration modifications, and at the same time improve the software refresh time.

[0037] S8: Adopt a communication hold method during the entire software refresh process. When the TCU message duration is 4S without feedback, send the communication hold service 3E 80. Use service 3E 80 for communication hold to avoid flashing failure caused by non-response when the TCU is offline for a slightly longer time. To avoid this situation, when the TCU message duration is 4S without feedback, send the communication hold service to increase the probability of successful refresh and be compatible with TCUs with different response times.

[0038] S9: After the software refresh is completed, read the hardware version, software version, and software part number as needed and display them on the display screen to facilitate viewing and comparison by the refresh program personnel.

[0039] S10: Add the function of writing to DID018B, and use service 22 to read the written content to determine whether the ejection function is added, providing a judgment basis for the program flashing members.

[0040] S11: Determine whether to write the handle information according to the requirements, and print the corresponding log file for the handle information. In this step, in the development configuration, write the mechanical handle or electronic handle through service 2E. If an error occurs during writing, the error problem will be printed through the log file. According to the actual project requirements, the handle information may not be written, and the operation is flexible and diverse for software refresher use, and the prompt information can also be transmitted in a timely manner.

[0041] S12: Write the serial number of the gearbox into the controller, and use service 22 to read the gearbox serial number. The printed log file is displayed in decimal form. At the beginning of the characteristic data flashing, to facilitate tracking, write the gearbox serial number into the controller, use service 22 to read the gearbox serial number, and at the same time print the log file and display it in decimal form to prevent on-site operators from accidentally flashing the software into the controller.

[0042] S13: Flash the 4-in-1 bin file into the controller, reduce the configuration files, prevent misoperation situations, avoid misconfiguration situations caused by too many configuration files, prevent misflashing problems caused by inventory turnover and sporadic flashing, and at the same time avoid the management chaos brought by the 4bin files in software management.

[0043] During the software flashing process, give positive and negative responses according to the flashing process provided by the vehicle manufacturer and the corresponding positive and negative response codes. The software flashing process is generally divided into three parts: pre-programming, programming, and post-programming. Pre-programming generally uses services 10 03, 10 02, and 10 01 for mode jumps. After the mode jump is completed, perform the formal software refresh and requests, and sequentially request services 10 03, 27 01, 27 02, 22 F1 8A, 22 F089, 22 F1 89, 31 01 02 03, 10 83, 85 82, and 28 83 03.

[0044] Before the service is enabled, use the read function in the configuration file to identify the first data of different bin files. For files in the same series, the first data is the same. If it is different, reply by printing the log. If the bin file is missing, use this as a basis to check whether the required files for refreshing are available. Before the service is enabled, use programming to identify the driver bin, data bin, and size of the configuration file and print them in a log file for developers to check whether the length is correct. If there is an obvious error in the length, the problem can be immediately identified. Of course, each time the flashing tool is started, it should start counting from 0 to prevent the flashing tool from misidentifying the file length and using the value identified for the first time as the first value for the second identification.

[0045] To enable the software to identify the underlying hardware version number, enable the 10 03 service to jump to the 10 02 service, thereby entering the underlying layer to achieve the purpose of reading the underlying hardware version. Compare the read hardware version with the version filled in the configuration to prevent incorrect flashing of files that do not match the hardware version and prompt in a timely manner when problems occur. After reading and comparing the underlying version number, use the 11 03 service to reset. After reset, the normal software flashing process can be carried out.

[0046] During the programming stage, use the 10 01 service, 10 03 service, 10 02 service, 27 01 service, 27 02 service, 22 F1 70 read version information, 22 F1 71 read version information, 2E F1 84 write fingerprint information, 34 00 44 request download, 36 service, 37 service to perform request and feedback process operations. The time limit between the 10 03 and 10 02 services is 100 ms, leaving sufficient time for control feedback and the flashing tool to receive. Improve the transmission of data in the 36 service according to the maximum acceptable range of UDS. Add the first address of the 34 service in a fixed format, and fill the length of the transmitted data with the identified bin file length. Fill different buffer bits by shifting right 24 bits, 16 bits, and 8 bits respectively. Limit the transmission size of the 36 service to 1044, and transmit the last packet according to the actual remaining value. The 37 service exits according to the actual development process.

[0047] After the 37 service exits, use 31 01 FF 01 to check the validity and integrity of the data. After the 36 service is completed or perform CRC16 calculations on the driver and APP files. The flashing tool internally feedbacks the CRC check value according to the calculated result and automatically compares it with the value feedback by the TCU. If the comparison is successful, enter the subsequent service request. Generate TXT format data from the values feedback by the flashing tool and the TCU. When the comparison is unsuccessful, it is convenient to find the difference between the compared data and the data feedback by the TCU to find the cause of the failure.

[0048] In the post-programming stage, services 11 03, 10 03, 28 80 03, 85 81, and 10 81 are adopted. In the reset of service 11 03, a delay function is used to set the time to 3.5S to improve the flashing efficiency, and service 28 85 is used to enable data sending and transmission. During the software refresh process, after pre-programming 10 83, communication 3E 80 is started with an interval of 4S, and communication is kept closed in service 85 81 of the post-programming step.

[0049] After the program refresh is completed for writing the characteristic data, service 2E is used for writing. The DID and the length of each data are pre-filled using an array and then written in this way. Before writing the characteristic data, the gearbox serial number is first written. By identifying the length and position of the gearbox serial number, service 2E is called for writing. After writing is completed, service 22 is used to read the written DID, and the data is converted according to the actual situation into data that is more conducive to the operator's identification. Generally, the data read using the UDS command is in ASCII code, and ASCII code is not conducive to viewing and technical communication. It is converted from ASCII to decimal and output in a TXT file for easy reference and communication.

[0050] According to the actual engineering requirements, service 2E is used to write the handle information value. The handle information has different requirements in special scenarios, and by configuring different values of the handle information, it can be artificially selected whether to write the handle information. To better manage the number of refresh software, using a single bin method is more convenient than the 4-bin method. By identifying the start address and length of the bin file that combines 4 bins into one, only one bin file is flashed, thus efficiently realizing file management.

[0051] The specific operation process of the present invention is as follows:

[0052] 1) Read function, pointing to the corresponding bin file, identifying the corresponding start address, and determining whether it is the required file.

[0053] 2) While loop function, using the while loop to identify the size of the corresponding bin file, which is reflected by the variable memsize.

[0054] 3) Request session mode service 10 03, diagnostic ID: 0X7E1, length 0X02.

[0055] 4) Request default session mode 10 02, diagnostic ID: 0X7E1, length 0X02.

[0056] 5) Request 22 F0 89 to read the hardware version number, diagnostic ID: 0X7E1, length 0X03.

[0057] 6) Configure the Param content, identify the hardware version in advance and use an if statement to check whether the version content is consistent.

[0058] 7) Request the session mode 10 03 service, diagnostic ID: 0X7E1, length 0X02.

[0059] 8) Request the session mode 28 85 service, diagnostic ID: 0XDF, length 0X02.

[0060] 9) Request the 3E 80 service, diagnostic ID: 0X7DF, length 0X02.

[0061] 10) Request the reset 11 03 service, diagnostic ID: 0X7E1, length 0X02.

[0062] 11) Request the session mode 10 01 service, diagnostic ID: 0X7E1, length 0X02.

[0063] 12) Request the session mode 10 03 service, diagnostic ID: 0X7E1, length 0X02.

[0064] 13) Set the delay function time to the delay 100ms function.

[0065] 14) Request the session mode 10 02 service, diagnostic ID: 0X7E1, length 0X02.

[0066] 15) Request the 34 service download, address 34800, diagnostic ID: 0X7E1, length 0X11, transmission buffer txbuffer[8]>> 24, txbuffer[9]>>16, txbuffer

[10] >>8, txbuffer

[11] .

[0067] 16) Request the 36 service, diagnostic ID: 0X7E1, length 0X02, packet size 1044, padding method 15 10 36 0X.

[0068] 17) Request the 31 01 FF 01 service, diagnostic ID: 0X7E1, length 0X04.

[0069] 18) CRC16 algorithm.

[0070] 19) The CRC value reception buffer Rxbuffer[] = Rxbuffer[] function automatically judges.

[0071] 20) Please request the 11 03 service, diagnostic ID: 0X7E1, length 0X02.

[0072] 21) Request service 85 81, Diagnostic ID: 0X7E1, Length 0X02.

[0073] 22) Request session mode 22 F1 89 service, Diagnostic ID: 0X7E1, Length 0X03.

[0074] 22) Request session mode 22 F0 89 service, Diagnostic ID: 0X7E1, Length 0X03.

[0075] 22) Request mode 22 F1 88 service, Diagnostic ID: 0X7E1, Length 0X03.

[0076] 22) Request session mode 10 03 service, Diagnostic ID: 0X7E1, Length 0X02.

[0077] 23) Request to close service 3E 80, Diagnostic ID: 0X7DF, Length 0X02.

[0078] 24) Request service 2E 01 87, Diagnostic ID: 0X7E1, Length 0X02.

[0079] 25) Convert ASCII code.

[0080] 26) Request service 2E 01 83, Diagnostic ID: 0X7E1, Length 0X02.

[0081] 27) 4-bin combined request for flashing with different starting addresses of 34 00 44, gradually completing the flashing of all bin files.

[0082] To make the objectives, technical solutions, and advantages of the present invention clearer, in combination with the accompanying drawings in the embodiments of the present invention, the technical solutions in the embodiments of the present invention are described in more detail. The described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. The embodiments described by referring to the accompanying drawings are exemplary and are intended to explain the present invention, and should not be simply construed as a limitation of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative efforts fall within the scope of protection of the present invention.

Claims

1. A software refresh anti-miswriting method, characterized in that, It includes the following steps: S1: Before refreshing the program, identify the starting value of the bin file; S2: Before refreshing the program, identify the size of the file to be flashed; S3: When reading the hardware version number, enter the underlying software for reading using service 10 02, and at the same time compare the hardware version number to avoid unsuccessful TCU software refreshing caused by the application layer hardware version number during library flipping. After reading the underlying hardware version number, perform a reset using service 11 03 and then perform software refreshing; S4: The interval between service 10 01 and service 10 03 is 100 ms to avoid non - response of the TCU caused by too short a command sending interval; S5: When service 36 transfers data during the flashing process, the packet size is 1044; S6: Use CRC32 or CRC16 files to verify the application layer bin software file to ensure the consistency of controller data flashing; S7: Set the reset time of service 11 03 to 3.5 s to increase the probability of successful software refreshing; S8: Adopt a communication hold method during the entire software refreshing process. When the TCU message duration is 4 s without feedback, send the communication hold service 3E 80; S9: After software refreshing is completed, read the hardware version, software version, and software part number as needed and display them through the display screen for convenient viewing and comparison by the program refreshing personnel; S10: Add the function of writing to DID018B and use service 22 to read the written content to determine whether the ejection function has been added; S11: Determine whether it is necessary to write the handle information according to the requirements and print the handle information to the corresponding log file; S12: Write the serial number of the gearbox into the controller, use service 22 to read the obtained gearbox serial number, and display the printed log file in decimal form; S13: Flash the 4 - in - 1 bin file into the controller to reduce configuration files and prevent misoperation; 2. The software refresh anti-miswriting method according to claim 1, characterized in that, In step S1, identify in advance the starting values of all software to be refreshed. Identify in advance software that is not the one intended to be refreshed. If it is identified that it is indeed caused by abnormal software, prompt the flashing failure and the reason for the failure to avoid mis - flashing software; 3. A software refresh anti-miswriting method according to claim 1, characterized in that, In step S2, write a function through C - language programming to identify in advance the size and length of all files to be flashed, and use the length variable as a local variable in the written statement. According to the identified length size, it can be judged whether the software is repeatedly identified; 4. A software refresh anti-miswriting method according to claim 1, characterized in that, Before executing step S3, read the underlying hardware version number of the controller through UDS to increase the probability of successful software refreshing with the hardware version number written in the application layer during library flipping, and judge whether the hardware of the controller to be refreshed is the required hardware. If the comparison is correct, continue with the flashing. If the comparison fails, prompt the flashing failure and the reason for the failure to avoid incorrect selection of the control model; 5. A software refresh anti-miswriting method according to claim 1, characterized in that, In step S5, the length of the last packet is transmitted according to the actual situation, and the packet is limited to below the maximum feedback by the TCU to increase the probability of successful refreshing; 6. The software refresh anti-miswriting method according to claim 1, wherein In step S11, in the development configuration, write the mechanical handle or electronic handle through service 2E. If the writing is incorrect, print the error problem through the log file;

Images