CAN (Controller Area Network) bus-based retransmissible ECU (Electronic Control Unit) software online upgrading method

Abstract

The invention provides a CAN (Controller Area Network) bus-based retransmittable ECU (Electronic Control Unit) software online upgrading method, which comprises the following steps of: compiling a new user program to generate a BIN file, reading the to-be-programmed BIN file by upper computer software, adding a file identification head, a file byte length and verification information to the BIN file, calculating the number of blocks of the whole file according to the size of 511 * 8 bytes transmitted by a single block, and updating the number of the blocks of the whole file according to the size of 511 * 8 bytes; the number of bytes of the last block of data, the number of CAN messages of the last block, the data verification value of the whole file and the verification value of each block of data; the BIN file is packaged into a start transmission command, a single block transmission command, a single block transmission end command and a block transmission end command after being subjected to data processing, and compared with the prior art, efficient and safe remote upgrading is realized through an innovative protocol design and a fault-tolerant mechanism on the basis of a low-cost CAN bus, so that the remote upgrading efficiency is improved. A standardized solution is provided for embedded system maintenance, and the method has a wide industrial application prospect.

Description

Technical Field

[0001] This invention relates to the field of embedded control technology, specifically to an online software upgrade method for ECUs based on a CAN bus with retransmittable capabilities. Background Technology

[0002] With the continuous advancement of technology, embedded devices are increasingly widely used in modern society. Along with the continuous improvement of embedded microprocessor performance, the functional requirements of embedded microprocessor software are becoming increasingly complex and diversified, leading to a higher frequency of software updates. Therefore, adopting convenient methods for software upgrades is essential to improve efficiency and reduce costs. Traditional software updates involve programming the software via the JTAG port, which requires removing the microcontroller from the assembly system. However, uploading via a communication bus eliminates the need for removal, saving on update costs. CAN bus communication technology is mature and highly reliable. Utilizing the CAN bus for retransmittable online ECU software upgrades offers greater reliability, convenience, and efficiency. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a CAN bus-based retransmittable online ECU software upgrade method to solve the problems mentioned in the background. This invention features a novel structure, avoids increased software update costs, enhances the reliability of online upgrades, and improves upgrade efficiency. The communication protocol between the host computer software and the slave (ECU) software is a block transmission protocol based on the CAN bus.

[0004] To achieve the above objectives, the present invention provides a method for online upgrade of ECU software based on a CAN bus with retransmittable capabilities, the online upgrade method comprising the following steps:

[0005] (1) After compiling and processing the new user program, a BIN file is generated. The host computer software reads the BIN file to be burned and adds a file identifier header, file byte length and verification information to the BIN file. According to the single block transmission size of 511*8 bytes, the number of blocks in the whole file, the number of bytes of the last block of data, the number of CAN messages in the last block, the data verification value of the whole file and the verification value of each block of data are calculated. After processing the data of the BIN file, the file is packaged into a start transmission command, a single block transmission command, a single block transmission end command and a block transmission end command.

[0006] (2) After the host computer software packages the BIN file, it enters the communication stage with the lower computer. The host computer will first send a start transmission command. After receiving the command, the lower computer will parse the information in the start transmission command to obtain the size of the upgrade data. Then the lower computer will send a start transmission command response. A CAN message has eight bytes. The response status flag of the start transmission command is placed in the second byte. The start transmission command end response contains the prepared response status flag.

[0007] (3) The lower computer verifies the first block of data received. When the verification value is consistent with the verification value in the block transmission end command, it sends a block transmission end command response. The fifth byte of the response message contains the block data verification success flag of the block transmission end command. After the upper computer receives the block transmission end command response, the verification success interface displays that the nth block data transmission is complete and the next block data transmission is performed. Before the data is packaged, the block number is incremented by one. If the verification fails, the current block is retransmitted. This process is repeated until the last block data transmission is completed. When the last block data transmission is completed, the upper computer sends a block end command. The block transmission end command contains the verification value of the entire BIN file data.

[0008] (4) After receiving the block transfer end command, the lower computer will verify the entire upgrade data cached in the memory (Flash, DDR, SDRAM, etc.). If the verification value is consistent with the verification value in the received block transfer end command, the verification is successful. The lower computer will send a block transfer end command response to the upper computer and place the verification success flag in the fifth byte.

[0009] (5) After the host computer receives the block transfer end command response, it determines that the received verification success flag indicates that the FLASH erase command was successfully sent;

[0010] (6) After receiving the FLASH erase command, the lower computer erases the FLASH, records the erase result, and then sends an erase command response to the lower computer. The command response contains the FLASH erase result.

[0011] (7) After receiving the FLASH erase command response, the host computer determines whether the erase is successful. If the erase is successful, the interface displays "FLASH erase successful" and then sends the FLASH write command.

[0012] (8) After receiving the write command, the lower-level machine writes the upgrade data into the FLASH, and then reads out the upgrade data for verification. If the verification is successful, it sends a write command response to the upper-level machine. The write command response includes the verification result of reading out the data written into the FLASH for verification.

[0013] (9) After the host computer receives the write command response, it determines whether the verification result in the response is qualified. If qualified, the interface prints that the upgrade is successful and please power off the product.

[0014] Furthermore, according to step (1), the open transmission command contains the length information of the entire BIN file, the data area in the single block transmission command is all BIN file data content, the single block transmission end command contains the check value and single block sequence number of the single block data, and the block transmission end command contains the check value of the entire BIN file data.

[0015] Furthermore, according to step (2), the host computer application PC, CAN board and embedded control unit ECU (containing CAN interface) are connected to the product through CAN bus interface and connected through a dedicated test cable. The CAN board is connected to the PC through PCI bus. The CAN board is directly inserted into the PC. The CAN protocol between the host computer and the slave computer is based on the standard CAN protocol to allocate and set the ID of CAN bus messages.

[0016] Furthermore, according to step (2), each step in the upgrade process of the upgrade data is set up using a one-command-one-response handshake mechanism to improve the reliability and timeliness of the entire upgrade process.

[0017] Furthermore, according to step (2), after the host computer receives the response to the start transmission command, it parses and judges whether the start transmission status is ready. If it is ready, the host computer interface displays the status of the lower computer ready, performs single block (511) data transmission, sends 511 frames of CAN message data, and then sends a single block transmission end command. The single block transmission end command contains the check value and block sequence number information of the single block data.

[0018] Furthermore, according to step (3), the upgrade file of the BIN file is a binary file, and the form used in this invention is .bin file format, and the CAN communication baud rate during the upgrade process is 800Kbps.

[0019] Furthermore, according to step (4), the upgrade process of the upgrade data uses a 32-bit CRC check method to verify the data, including single block transmission data, total upgrade data, data written to FLASH and other data types, to strictly ensure the accuracy of data transmission.

[0020] Furthermore, according to step (4), the memory is an external DDR, SDRAM, or FLASH. During the upgrade process, the received upgrade data is not directly written into the formal area of ​​the FLASH, but is written into a temporary data buffer. After successful verification, it is then written into the formal area of ​​the FLASH.

[0021] Furthermore, according to step (6), the CAN bus has high data transmission reliability. If an error occurs during the upgrade data transmission process, it can support the retransmission of the erroneous single block of data. If the FLASH erase and write operations fail, a retry operation can also be performed, which greatly improves the upgrade efficiency and saves upgrade time and cost.

[0022] Furthermore, according to step (4), the upgrade data does not require disassembling the ECU control unit for upgrade; the upgrade is completed only by transmitting data via the CAN bus, which is applicable to online software upgrades of any ECU control unit containing a CAN communication interface.

[0023] The beneficial effects of this invention are:

[0024] 1. This invention employs block transmission (511 frames / block) and a dual verification mechanism (single-block CRC32 verification + global verification), combined with a retransmission strategy to ensure data integrity and higher reliability. Dynamic progress display and a three-retry mechanism enhance the interactive experience and fault tolerance. Standardized CAN ID allocation (priority / bus number / device node) makes the protocol more standardized. It fully covers the entire process from data transmission and FLASH operation to version rollback.

[0025] 2. Economic and Social Benefits of this Invention: Reduced Costs: Online ECU upgrades via CAN bus eliminate the cumbersome hardware disassembly process required for traditional JTAG programming, saving labor and time costs, especially suitable for batch device upgrade scenarios; High Efficiency and Reliability: Employing block transmission, multiple verifications (single-block CRC32 verification + global verification), and retransmission mechanisms ensures data transmission integrity and reliability, reduces upgrade failure risks, and improves production efficiency; Convenient Operation: Users can monitor upgrade progress in real time via a host computer interface (e.g., block transmission completion status, FLASH operation results), simplifying the operation process and reducing reliance on professional personnel; Technical Universality: Compatible with various storage media such as Flash, DDR, and SDRAM, with strong adaptability, it can be widely applied in embedded fields such as automotive electronics and industrial control, promoting intelligent upgrades in the industry; Extended Equipment Lifecycle: Convenient online update functionality supports software function iteration and defect repair, significantly improving equipment service life and market competitiveness.

[0026] 3. Compared with existing technologies, this invention, based on the low-cost CAN bus, achieves efficient and secure remote upgrades through innovative protocol design and fault-tolerance mechanisms, providing a standardized solution for embedded system maintenance and having broad prospects for industrial application. Attached Figure Description

[0027] Figure 1This is a block diagram illustrating the implementation principle of an online ECU software upgrade method based on a CAN bus with retransmittance capability, according to the present invention.

[0028] Figure 2 This is a schematic diagram illustrating the meaning of CAN frame IDs in a retransmittable ECU software online upgrade method based on the CAN bus according to the present invention.

[0029] Figure 3 This is a schematic diagram of the online software upgrade process of the ECU software online upgrade method based on CAN bus retransmittable according to the present invention;

[0030] Figure 4 This is a flowchart illustrating the online software upgrade process of an ECU software upgrade method based on a CAN bus with retransmittable capabilities, according to the present invention.

[0031] Figure 5 This is a flowchart illustrating the steps of an online ECU software upgrade method based on a CAN bus with retransmittable capabilities, according to the present invention. Detailed Implementation

[0032] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0033] Please see Figures 1 to 5 This invention provides a technical solution: an online upgrade method for ECU software based on a CAN bus with retransmittable capabilities, the online upgrade method comprising the following steps:

[0034] (1) After compiling and processing the new user program, a BIN file is generated. The host computer software reads the BIN file to be burned and adds a file identifier header, file byte length and verification information to the BIN file. According to the single block transmission size of 511*8 bytes, the number of blocks in the whole file, the number of bytes of the last block of data, the number of CAN messages in the last block, the data verification value of the whole file and the verification value of each block of data are calculated. After processing the data of the BIN file, the file is packaged into a start transmission command, a single block transmission command, a single block transmission end command and a block transmission end command. The start transmission command contains the length information of the whole BIN file. The data area in the single block transmission command is all the data content of the BIN file. The single block transmission end command contains the verification value and single block sequence number of the single block data. The block transmission end command contains the verification value of the whole BIN file data.

[0035] (2) After the host computer software packages the BIN file, it enters the communication stage with the slave computer. The host computer first sends a start transmission command. After receiving the command, the slave computer parses the information in the start transmission command to obtain the size of the upgrade data. Then, the slave computer sends a start transmission command response. One frame of CAN message has eight bytes. The response status flag of the start transmission command is placed in the second byte. The start transmission command end response contains the ready response status flag. The host computer application PC, CAN board and embedded control unit ECU (containing CAN interface) are connected via a dedicated test cable. The CAN board and PC communicate via a CAN bus interface. PCI bus connection, CAN board directly inserted into PC, CAN protocol between host computer and slave computer is based on standard CAN protocol to allocate and set CAN bus message ID, each step of the upgrade process of the upgrade data adopts one command one answer handshake mechanism to set, improve the reliability and timeliness of the whole upgrade process, after the host computer receives the start transmission command response, it parses and judges whether the start transmission status is ready, if ready, the host computer interface displays the slave computer ready status, performs single block (511) data transmission, sends 511 frames of CAN message data, and then sends single block transmission end command, the single block transmission end command contains the single block data check value and block sequence number information;

[0036] (3) The lower-level machine verifies the first block of data received. When the verification value is consistent with the verification value in the block transmission end command, it sends a block transmission end command response. The fifth byte of the response message contains the block data verification success flag of the block transmission end command. After the upper-level machine receives the block transmission end command response, the verification success interface displays that the nth block data transmission is complete and proceeds to the transmission of the next block data. Before data is packaged, the block number is incremented by one. If the verification fails, the current block is retransmitted. This process is repeated until the last block data transmission is completed. When the last block data transmission is completed, the upper-level machine sends a block end command. The block transmission end command contains the verification value of the entire BIN file data. The upgrade file of the BIN file is a binary file. In this invention, the form used is the .bin file format. The CAN communication baud rate during the upgrade process is 800Kbps.

[0037] (4) After receiving the block transmission end command, the lower computer will verify the entire upgrade data cached in the memory (Flash, DDR, SDRAM, etc.). If the verification value is consistent with the verification value in the received block transmission end command, the verification is successful. The lower computer will send a block transmission end command response and place a verification success flag in the fifth byte. In the upgrade process of the upgrade data, the data is verified by a 32-bit CRC verification method, including single block transmission data, total upgrade data, data written to FLASH and other data types, to strictly ensure the accuracy of data transmission. The memory is an external DDR, SDRAM or FLASH. During the upgrade process, the received upgrade data is not directly written to the formal area of ​​FLASH, but is written to a temporary data buffer. After successful verification, it is written to the formal area of ​​FLASH. The upgrade data does not need to be disassembled for upgrade. The upgrade is completed by transmitting data through the CAN bus. It is suitable for online upgrade of software of any ECU control unit with CAN communication interface.

[0038] (5) After the host computer receives the block transfer end command response, it determines that the received verification success flag indicates that the FLASH erase command was successfully sent;

[0039] (6) After receiving the FLASH erase command, the lower-level machine erases the FLASH, records the erase result, and then sends an erase command response to the lower-level machine. The command response includes the FLASH erase result. The CAN bus has high data transmission reliability. If an error occurs during the upgrade data transmission process, it can support the retransmission of the erroneous single block of data. If the FLASH erase and write operations fail, a retry operation can also be performed, which greatly improves the upgrade efficiency and saves upgrade time and cost. The CAN bus has high data transmission reliability. If an error occurs during the upgrade data transmission process, it can support the retransmission of the erroneous single block of data. If the FLASH erase and write operations fail, a retry operation can also be performed, which greatly improves the upgrade efficiency and saves upgrade time and cost.

[0040] (7) After receiving the FLASH erase command response, the host computer determines whether the erase is successful. If the erase is successful, the interface displays "FLASH erase successful" and then sends the FLASH write command.

[0041] (8) After receiving the write command, the lower-level machine writes the upgrade data into the FLASH, and then reads out the upgrade data for verification. If the verification is successful, it sends a write command response to the upper-level machine. The write command response includes the verification result of reading out the data written into the FLASH for verification.

[0042] (9) After the host computer receives the write command response, it determines whether the verification result in the response is qualified. If qualified, the interface prints that the upgrade is successful and please power off the product.

[0043] In this embodiment, as Figure 1 As shown, the CAN ports of the host computer and the slave computer are connected via dedicated test cables. After reading the .bin file to be upgraded, the host computer packages the upgrade data and sends it to the slave computer. The slave computer filters and receives the CAN messages, parses the received messages, and caches the upgrade data in a temporary area of ​​DDR, SDRAM, or FLASH. The FLASH is erased according to the erase command, and the upgrade data is written to the designated area of ​​the FLASH according to the write command. The CAN messages in the whole process mainly involve start transmission command, start transmission command response, single data frame, single transmission end command, block transmission end command, and block transmission end command response.

[0044] In this embodiment, the CAN message ID format throughout the CAN communication process is as follows: Figure 2 As shown, in terms of binary bits, message priorities can be divided into 00: Level 1 control, 01: Level 2 control, 10: Level 1 test, and 11: Level 2 test. The bus number for data transmission occupies 1 bit, indicating that a maximum of 2 buses can be identified. The data frame number can be used to record 511 data frame numbers. The message device contains the node IDs of the source and destination devices. The start transmission command, start transmission command response, single data frame, single transmission end command, block transmission end command, and block transmission end command response all have their fixed CAN message IDs, which comply with the above CAN ID meanings.

[0045] In this embodiment, each of the above-mentioned command frames is communicated in the form of CAN messages. The specific meaning of the CAN IDs can be found in [link to documentation]. Figure 2 ,like Figure 3 and Figure 4As shown, the upgrade process is as follows: The host computer sends a start transmission command. Bytes b4-b7 (5th to 8th bytes) of this command data represent the length of the .bin file data. After receiving the start transmission command, the slave computer prepares its state. Once ready, it sends a start transmission command response. If ready, 0x55 is set in byte b0 (first byte) of this response data; otherwise, other values ​​are used, indicating that the state is not ready. The host computer receives and parses the start transmission command response from the slave computer. If ready, it sends a single data frame to transmit the .bin file data. A single data frame contains a maximum of 511 CAN messages. After each single data frame is transmitted, a single transmission end command is sent. This command includes the CRC32 checksum of the data block, located in bytes b0-b3 (1st to 4th bytes), and the block sequence number, located in bytes b6-b7 (7th to 8th bytes). The block sequence number starts from 0. The slave computer receives the single transmission command data... After receiving the response frame, the system performs a check on all data in the single-block transmission data frame. If the check value matches the CRC32 checksum in the single-block transmission end command, then byte b4 (the 5th byte) in the response data of the sent single-block transmission end command is set to 0x55, indicating that the check is correct. Otherwise, this byte is not set to 0x55. After receiving the single-block transmission end command response, the host computer parses it. If the check value comparison result (byte b4: the 5th byte) in the single-block transmission end command is 0x55, then the lower-level computer has made a correct comparison, and the host computer will start transmitting the next block of data from the block sequence number. Otherwise, the data in the block will be retransmitted.This process repeats until the last single data frame is transmitted. After the entire single data frame has been transmitted, the host computer sends a block transmission end command. This command contains the CRC32 checksum of all single data frames, located in bytes b0~b3 (bytes 1 to 4) of the data. The slave computer receives the block transmission end command, parses it, and calculates the checksum of all cached upgrade data. If it matches the CRC32 checksum in the block transmission end command, the checksum is successful, and byte b4 (byte 5) of the data in the block transmission command is set to 0x55. Otherwise, this byte is not set to 0x55, and the slave computer sends a block transmission end command response to the host computer. The host computer receives the block transmission end command response and checks whether the checksum is successful (whether byte b4: byte 5 is 0x55). If successful, it sends an FLA. The SH erase command is received by the lower-level device. Upon receiving the command, it executes the FLASH erase operation and sends the erase result (byte b4: byte 5 is 0x55, erase successful) in the FLASH erase command response to the upper-level device. The upper-level device receives the FLASH erase command response from the lower-level device and determines whether the erase result was successful. If successful, it sends a FLASH write command. Upon receiving the write command, the lower-level device executes the write operation to the FLASH and then verifies the data written to the FLASH. The verification result (byte b4: byte 5 is 0x55, verification successful) is sent to the upper-level device in the FLASH write command response. The upper-level device receives the FLASH write command response from the lower-level device and determines whether the verification result was successful. If successful, it displays "upgrade successful" and powers off the product. If a single-chip transmission fails, it will be re-uploaded. FLASH erase and write failures will be retried up to 3 times.

[0046] The foregoing has shown and described the basic principles and main features of the present invention and its advantages. It will be apparent to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or basic features of the present invention.

[0047] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for online ECU software upgrade based on CAN bus retransmittable, characterized in that: The online upgrade method includes the following steps: (1) After compiling and processing the new user program, a BIN file is generated. The host computer software reads the BIN file to be burned and adds a file identifier header, file byte length and verification information to the BIN file. According to the single block transmission size of 511*8 bytes, the number of blocks in the whole file, the number of bytes of the last block of data, the number of CAN messages in the last block, the data verification value of the whole file and the verification value of each block of data are calculated. After processing the data of the BIN file, the file is packaged into a start transmission command, a single block transmission command, a single block transmission end command and a block transmission end command. (2) After the host computer software packages the BIN file, it enters the communication stage with the lower computer. The host computer will first send a start transmission command. After receiving the command, the lower computer will parse the information in the start transmission command to obtain the size of the upgrade data. Then the lower computer will send a start transmission command response. A CAN message has eight bytes. The response status flag of the start transmission command is placed in the second byte. The start transmission command end response contains the prepared response status flag. (3) The lower computer verifies the first block of data received. When the verification value is consistent with the verification value in the block transmission end command, it sends a block transmission end command response. The fifth byte of the response message contains the block data verification success flag of the block transmission end command. After the upper computer receives the block transmission end command response, the verification success interface displays that the nth block data transmission is complete and the next block data transmission is performed. Before the data is packaged, the block number is incremented by one. If the verification fails, the current block is retransmitted. This process is repeated until the last block data transmission is completed. When the last block data transmission is completed, the upper computer sends a block end command. The block transmission end command contains the verification value of the entire BIN file data. (4) After receiving the block transfer end command, the lower computer will verify the entire upgrade data cached in the memory (Flash, DDR, SDRAM, etc.). If the verification value is consistent with the verification value in the received block transfer end command, the verification is successful. The lower computer will send a block transfer end command response to the upper computer and place the verification success flag in the fifth byte. (5) After the host computer receives the block transfer end command response, it determines that the received verification success flag is a successful FLASH erase command; (6) After receiving the FLASH erase command, the lower computer erases the FLASH, records the erase result, and then sends an erase command response to the lower computer. The command response contains the FLASH erase result. (7) After receiving the FLASH erase command response, the host computer determines whether the erase is successful. If the erase is successful, the interface displays "FLASH erase successful" and then sends the FLASH write command. (8) After receiving the write command, the lower-level machine writes the upgrade data into the FLASH, and then reads out the upgrade data for verification. If the verification is successful, it sends a write command response to the upper-level machine. The write command response includes the verification result of reading out the data written into the FLASH for verification. (9) After the host computer receives the write command response, it determines whether the verification result in the response is qualified. If qualified, the interface prints that the upgrade is successful and please power off the product.

2. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (1), the open transmission command contains the length information of the entire BIN file, the data area in the single block transmission command is all BIN file data content, the single block transmission end command contains the check value and single block sequence number of the single block data, and the block transmission end command contains the check value of the entire BIN file data.

3. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (2), the host computer application PC, CAN board and embedded control unit ECU (containing CAN interface) are connected to the product through CAN bus interface. The CAN board is connected to the PC through PCI bus. The CAN board is directly inserted into the PC. The CAN protocol between the host computer and the slave computer is based on the standard CAN protocol to allocate and set the ID of CAN bus messages.

4. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (2), each step in the upgrade process of the upgrade data is set up using a one-to-one handshake mechanism to improve the reliability and timeliness of the entire upgrade process.

5. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (2), after the host computer receives the response to the start transmission command, it parses and judges whether the start transmission status is ready. If it is ready, the host computer interface displays the ready status of the slave computer, performs single block (511) data transmission, sends 511 frames of CAN message data, and then sends a single block transmission end command. The single block transmission end command contains the check value and block sequence number information of the single block data.

6. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (3), the upgrade file of the BIN file is a binary file. In this invention, the form used is .bin file format, and the CAN communication baud rate during the upgrade process is 800Kbps.

7. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (4), the upgrade process of the upgrade data uses a 32-bit CRC check method to verify the data, including single block transmission data, total upgrade data, data written to FLASH and other data types, to strictly ensure the accuracy of data transmission.

8. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (4), the memory is an external DDR, SDRAM or FLASH. During the upgrade process, the received upgrade data is not directly written into the formal area of ​​FLASH, but is written into a temporary data buffer. After successful verification, it is written into the formal area of ​​FLASH.

9. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (4), the upgrade data does not require disassembling the ECU control unit for upgrade. The upgrade is completed by transmitting data through the CAN bus, which is applicable to online software upgrades of any ECU control unit with a CAN communication interface.

10. The online upgrade method for ECU software based on CAN bus retransmittable according to claim 1, characterized in that: According to step (6), the CAN bus has high data transmission reliability. If an error occurs during the upgrade data transmission process, it can support the retransmission of the erroneous single block of data. If the FLASH erase and write operations fail, a retry operation can also be performed, which greatly improves the upgrade efficiency and saves upgrade time and cost.

Images