A method, device, electronic equipment and computer program product for intelligently block flashing an ECU

Abstract

The application belongs to the technical field of automobile electronic control units, and provides a method, device, electronic equipment and computer program product for intelligently block-based flashing of an ECU. The method comprises: selecting a corresponding verification mode according to the size of a to-be-flashed file; for a large file, adopting a multi-level verification mechanism of block-based frame-level block-level; and only retransmitting corresponding data that fails verification, without retransmitting the entire file, thereby effectively solving the technical problems of high retransmission cost, inability to locate abnormalities, waste of bandwidth and cache resources, and low flashing efficiency in the prior art. The method has the advantages of being able to adapt to to-be-flashed files of different sizes, enabling fine-grained verification and accurate retransmission during flashing of large files, reducing the amount of retransmitted data after flashing failure, shortening the flashing time, improving the efficiency of flashing operations, accurately locating abnormal positions, reducing the occupation of bus bandwidth and ECU cache resources by invalid data, and adapting to flashing requirements of different file sizes.

Description

Technical Field

[0001] This application belongs to the technical field of automotive electronic control units, and in particular relates to a method, apparatus, electronic device and computer program product for intelligent block-based ECU flashing. Background Technology

[0002] Electronic Control Unit (ECU) flashing is a core step in automotive software iteration and functional expansion. It primarily relies on the on-board diagnostic interface to establish a communication link and completes firmware data updates through a bootloader. With the evolution of automotive intelligence, the size of flashing files has increased significantly. Early systems only needed to process tens of KB of data, while current scenarios such as autonomous driving domain controllers involve file transfers of tens of GB. Traditional flashing processes generally adopt a full packet transmission followed by verification mode, i.e., sending all data frames completely to the ECU and finally performing overall integrity verification. This mode exposes multiple technical bottlenecks when handling large files: when file verification fails, all data must be retransmitted, resulting in a significant increase in time costs; the verification mechanism can only report the overall failure status and cannot accurately pinpoint the specific data location where the anomaly occurred; the data transmission process lacks a real-time verification step, with invalid data continuously occupying bus bandwidth and consuming ECU cache resources; in vehicle production lines or after-sales service scenarios, these defects directly extend flashing waiting times, affecting operational efficiency. Existing technical solutions have failed to effectively address the needs for fine-grained verification and accurate retransmission during large file flashing, necessitating the establishment of a dynamic verification mechanism adaptable to different file sizes. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, electronic device, and computer program product for intelligent block-based ECU flashing to solve the technical problems mentioned in the background art. It has the advantages of being able to adapt to files of different sizes to be flashed, enabling fine-grained verification and accurate retransmission when flashing large files, reducing the amount of retransmission data after flashing failure, shortening the flashing time, improving the efficiency of flashing operations, accurately locating abnormal positions, reducing the occupation of invalid data on bus bandwidth and ECU cache resources, and adapting to flashing needs of different file sizes.

[0004] In a first aspect, this application provides a method for intelligent block-based ECU flashing, the method being executed by an electronic device, the electronic device establishing a communication connection with the ECU to be flashed, the method comprising: Obtain the size S of the file to be written, and compare the size S of the file to be written with a preset threshold T; If the size S of the file to be flashed is not greater than the preset threshold T, then the whole package verification mode is entered, so that the entire file to be flashed is transmitted to the ECU to be flashed and then the whole package verification is performed. If the size S of the file to be written is greater than the preset threshold T, then the block verification mode is entered, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, and generate a block information item for each data block. The block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. Step b: Transmit each data block sequentially according to the block ID; wherein, when transmitting the i-th data block, it is split into multiple data frames, and each data frame carries a frame sequence number, frame data and a frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; wherein i is less than or equal to N; Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, simply retransmit that frame. Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted. Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

[0005] The technical advantages of this application are as follows: The intelligent block-based ECU flashing method provided by this application can select the corresponding verification mode according to the size of the file to be flashed. For large files, a multi-level verification mechanism of block-level, frame-level, and block-level is adopted. Only the corresponding data of the verification failure is retransmitted, without the need to retransmit the entire file. This can effectively solve the technical problems of high retransmission cost, inability to locate anomalies, waste of bandwidth and cache resources, and low flashing efficiency in the prior art when flashing large files. It has the advantages of being able to adapt to different sizes of files to be flashed, achieving fine-grained verification and accurate retransmission when flashing large files, reducing the amount of retransmission data after flashing failure, shortening the flashing time, improving the flashing operation efficiency, accurately locating the anomaly position, reducing the occupation of bus bandwidth and ECU cache resources by invalid data, and adapting to the flashing needs of different file sizes.

[0006] In one embodiment, in the block verification mode, step c further includes: If the retransmission count of a data frame reaches the preset first upper limit threshold and the verification still fails, the entire data block to which the frame belongs is marked as an abnormal block, and the current writing process is terminated.

[0007] The technical effects of this embodiment are: timely termination of abnormal write operations, avoiding waste of bus resources, and outputting the abnormal block ID to facilitate fault location.

[0008] In one embodiment, in the block verification mode, step d further includes: If block-level verification fails after the number of retransmissions for the entire data block reaches the preset second upper limit threshold, the writing process will be terminated and the block ID and reason for failure will be output.

[0009] The technical effects of this embodiment are: automatic termination of invalid flashing, accurate location of abnormal blocks, and convenient troubleshooting of link or ECU problems.

[0010] In one embodiment, in the block verification mode, the block information item generated in step a further includes the number of frames into which the i-th data block is split and the starting offset address of the i-th data block in the file to be written. After the block information table is sent to the ECU to be flashed, the ECU to be flashed performs the following operations: Based on the number of frames, determine whether all data frames of the i-th data block have been received completely. If the number of received data frames is equal to the number of frames, trigger the block-level verification. The starting position for writing the i-th data block in the Flash memory is determined based on the starting offset address. After the block-level verification passes, the data of the i-th data block is written starting from the starting offset address.

[0011] The technical effects of this embodiment are: the ECU determines the completion of block reception by using a frame number threshold, avoiding premature or delayed verification; the ECU achieves precise Flash writing of the block by using an offset address, ensuring that the data is completely consistent with the original file after recovery.

[0012] In one embodiment, the block verification mode further includes, after all data blocks have been transmitted, the following: The ECU is triggered to perform a full-packet CRC check on all data blocks written to Flash, and the check result returned by the ECU is received.

[0013] The technical effect of this embodiment is to solve the problem that block verification may miss splicing errors or sequence errors between blocks, and further improve the reliability of large file writing.

[0014] In one embodiment, before entering the block verification mode, the method further includes: The available cache size of the ECU to be flashed is queried. If the cache of the ECU to be flashed is smaller than the preset block size B, the preset block size B is reduced according to the cache of the ECU to be flashed, or the system is downgraded to the full package verification mode.

[0015] The technical effects of this embodiment are: dynamically adapting to ECU cache resources, maintaining the advantage of saving retransmissions through block verification as much as possible without degradation; and only degrading to full packet mode when the cache is extremely small to ensure basic availability.

[0016] In one embodiment, the method further includes: In response to a user-inputted threshold adjustment command, the preset threshold T is adjusted.

[0017] The technical advantages of this embodiment are: it achieves a quantitative match between block size B and ECU buffer capacity, balancing transmission success rate and protocol efficiency, while retaining the flexibility of user-defined thresholds. Secondly, this application also provides an intelligent block-based ECU flashing device, comprising: The comparison module is used to obtain the size S of the file to be written and compare the size S of the file to be written with a preset threshold T. The whole package verification module is used to enter the whole package verification mode if the size S of the file to be flashed is not greater than the preset threshold T, so that the whole file to be flashed is transmitted to the ECU to be flashed and then the whole package verification is performed. The block verification module is used to enter the block verification mode if the size S of the file to be written is greater than the preset threshold T, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, and generate a block information item for each data block. The block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. Step b: Transmit each data block sequentially according to the block ID; wherein, when transmitting the i-th data block, it is split into multiple data frames, and each data frame carries a frame sequence number, frame data and a frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; wherein i is less than or equal to N; Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, simply retransmit that frame. Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted. Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

[0018] Thirdly, this application also proposes an electronic device, including: a storage unit for storing a file to be written and a preset threshold T; The communication interface is used to establish a diagnostic communication connection with the ECU to be flashed. A processing unit, connected to the storage unit and the communication interface, is configured to execute the intelligent block-based ECU flashing method as described in the first aspect.

[0019] Fourthly, this application also proposes a computer program product storing a computer program, which is executed by a processor as described in the first aspect, using the intelligent block-based ECU flashing method.

[0020] It is understandable that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This application provides a schematic diagram of the main process of an intelligent analysis method for automotive diagnostic data. Figure 2 This is a schematic flowchart of another embodiment of the intelligent analysis method for vehicle diagnostic data provided in this application; Figure 3 This is a structural block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0026] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0027] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0028] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0029] Understandably, during the flashing process of vehicle electronic control units, as the size of the flashing file increases significantly, the traditional whole-packet transmission and verification mechanism exposes several technical defects. Specifically, when the flashing file exceeds a certain size, the retransmission operation caused by the failure of whole-packet verification requires repeating the transmission of all data, resulting in a serious waste of time resources; at the same time, the verification mechanism can only determine the overall transmission failure and cannot accurately locate the specific location of the anomaly, making the fault diagnosis process more complicated; in addition, the lack of a real-time verification step during transmission means that invalid data continuously occupies bus bandwidth and electronic control unit cache resources, further reducing system efficiency.

[0030] For example, in software update scenarios for autonomous driving domain controllers, the file size for flashing typically reaches tens of gigabytes. When using traditional whole-packet transmission, if a data verification error is detected at the end of the transmission, the entire large file must be retransmitted, significantly increasing the flashing time. Furthermore, because the specific frame or data block where the error occurred cannot be identified, engineers struggle to quickly determine whether the problem stems from communication link interference or an internal processing fault in the electronic control unit, increasing diagnostic complexity. The continuous transmission of invalid data not only prolongs the vehicle network occupancy period but can also lead to communication delays in other critical systems.

[0031] If the above issues are not resolved, retransmission operations after a failed flash will significantly extend the time spent in vehicle production or repair bays, affecting the overall production line cycle time. Simultaneously, vague fault indications make it difficult to trace the root cause of the problem, potentially delaying software update implementation and even impacting vehicle delivery cycles. Furthermore, continuous invalid data transmission will exacerbate the load on the in-vehicle network, potentially interfering with the real-time communication of other critical systems, thus posing a systemic risk to the reliability and timeliness of vehicle software iterations.

[0032] Example 1 In response to this, firstly, this application proposes a method for intelligent block-based ECU flashing, which is executed by an electronic device that establishes a communication connection with the ECU to be flashed. The method includes: Step S1: Obtain the size S of the file to be written and compare the size S of the file to be written with the preset threshold T; As can be understood, an ECU (Electronic Control Unit) is an embedded system in a car used to control various electronic systems; it receives sensor inputs, executes pre-programmed algorithms, and controls actuators to achieve specific functions of the vehicle, such as engine management, braking system control, and body electronics. The files to be flashed are software or firmware data that need to be transferred to the ECU and written into its memory (usually Flash memory). These files typically contain program code, configuration data, or calibration parameters used to update the ECU's functionality, fix defects, or extend its features.

[0033] The preset threshold T can be a pre-defined file size limit; this threshold is used to determine whether the file to be written should be transmitted and verified using the whole packet verification mode or the block verification mode.

[0034] Step S2-1: If the size S of the file to be flashed is not greater than the preset threshold T, then enter the whole package verification mode to transfer the entire file to be flashed to the ECU to be flashed and then perform whole package verification. It is understandable that the whole package verification mode can be a data transmission and verification strategy. In this mode, the entire file to be flashed is transmitted to the target ECU as a whole. After the transmission is completed, the integrity of the entire file is verified once. The block verification mode described below can be a strategy that splits a large file to be written into multiple smaller data blocks for transmission and verification. Each data block can be transmitted and verified independently, thereby improving transmission efficiency and error recovery capabilities.

[0035] Step S2-2: If the size S of the file to be written is greater than the preset threshold T, then enter the block verification mode, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, generate a block information item for each data block, and the block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. It should be noted that the preset block size B is the preset data size used to split the file to be written into data blocks in the block verification mode. The data block is a logical unit after the file to be written has been split. Each data block contains a part of the file's data and has independent identification and verification information. The block information item is a data structure describing the metadata of a single data block; it includes at least a block ID, actual block length, and a block CRC32 value, used to identify, locate, and verify the corresponding data block. The block ID represents a unique identifier for the data block, used to distinguish different data blocks and determine their order within the entire file. The actual block length represents the number of bytes of actual valid data in the data block. The block CRC32 value represents a 32-bit cyclic redundancy check value calculated from the data block content, used to verify the integrity and accuracy of the data block after transmission or storage. The block information table can be a collection of block information items containing all data blocks. This table is sent to the ECU before the start of block-level transmission as a reference for the ECU to perform block-level verification.

[0036] Step b: Transmit each data block sequentially according to the block ID; when transmitting the i-th data block, split it into multiple data frames, and each data frame carries a frame sequence number, frame data and frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; where i is less than or equal to N. It should be noted that, in the communication protocol, a data frame represents a smaller data transmission unit into which a data block is further subdivided. Each data frame typically contains a frame sequence number, frame data, and a frame check bit. The frame sequence number is a unique identifier for the data frame, used to indicate its order within its data block. The frame data represents the actual valid data carried in the data frame. The frame check bit represents a check value (e.g., CRC8) calculated from the data frame content, used at the receiving end to verify the integrity of the data frame.

[0037] Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, only retransmit the frame. If the verification still fails after the number of retransmissions of a data frame reaches the preset first upper limit threshold, mark the entire data block to which the frame belongs as an abnormal block and terminate the current flashing process.

[0038] It should be noted that the frame-level verification result can be understood as the result returned by the ECU after receiving a single data frame and verifying it, indicating whether the frame was received correctly.

[0039] Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted; wherein, if the number of retransmissions of the entire data block reaches the preset second upper limit threshold and the block-level verification still fails, the flashing process is terminated and the block ID and failure reason of the data block are output. It should be noted that the preset first upper limit threshold can be understood as the maximum limit set for the number of retransmissions of a single data frame; the preset second upper limit threshold can be understood as the maximum limit set for the number of retransmissions of a single data block.

[0040] The block-level verification result can be understood as the result returned by the ECU after receiving and assembling all the data frames of a data block and performing integrity verification on the entire data block, indicating whether the data block has been received correctly; in a specific implementation, the block information item generated in step a also includes the number of frames that the i-th data block is split into and the starting offset address of the i-th data block in the file to be flashed. After the block information table is sent to the ECU to be flashed, the ECU performs the following operations: determines whether all data frames of the i-th data block have been received completely based on the number of frames; if the number of received data frames is equal to the number of frames, the block-level verification is triggered; determines the starting position for writing the i-th data block in the Flash memory based on the starting offset address; and writes the data of the i-th data block starting from the starting offset address after the block-level verification passes.

[0041] Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

[0042] For example, this embodiment provides a method for intelligent block-based ECU flashing. In a specific implementation, this method is executed by an electronic device that establishes a communication connection with the ECU to be flashed. This electronic device can be a diagnostic instrument, a computer, or any host computer system capable of data interaction with the ECU. The electronic device establishes a connection with the ECU through a standard diagnostic communication protocol (e.g., the UDS protocol), thereby enabling it to send flashing commands and data to the ECU and receive the ECU's response.

[0043] The method in this embodiment first obtains the size S of the file to be flashed and compares it with a preset threshold T. The file size S can be obtained by reading metadata information from the file system, such as through the file attribute query interface provided by the operating system. The preset threshold T can be a fixed value, such as 10MB, or a value configured according to the actual application scenario or the performance parameters of the ECU. This comparison operation is a crucial step in determining the subsequent flashing strategy.

[0044] If the size S of the file to be flashed is not greater than the preset threshold T, then the entire file is transferred to the ECU for verification. In this mode, the electronic device sends all the data of the file to be flashed as a continuous data stream to the ECU. After receiving all the data, the ECU calculates the checksum (e.g., CRC32) of the entire file and compares it with the checksum provided by the electronic device or a pre-calculated checksum to confirm the integrity of the data. For example, the electronic device can package the entire file's data into a series of data packets and send them sequentially.

[0045] If the size S of the file to be written exceeds the preset threshold T, then the block verification mode is entered. This mode aims to optimize the efficiency and reliability of writing large files.

[0046] In the block verification mode, step a is performed first: the file to be flashed is split into N data blocks according to the preset block size B. A block information item is generated for each data block, containing at least the block ID, actual block length, and block CRC32 value. All block information items are compiled into a block information table and sent to the ECU to be flashed. The preset block size B can be a fixed value, such as 4MB, or it can be dynamically adjusted based on factors such as the ECU's cache capacity and communication bandwidth. The file can be split into fixed-size blocks, with the last block potentially smaller than the preset block size. Generating block information items involves uniquely identifying each data block (block ID), recording its actual data volume in the file (actual block length), and calculating its integrity check value (block CRC32 value). These block information items are then compiled into a block information table and sent to the ECU to be flashed as metadata for the flashing process before data block transmission. For example, the electronic device can pre-calculate the CRC32 values ​​of all data blocks and encapsulate this information, along with the block ID and length, into a data structure, which is then sent to the ECU via a diagnostic command.

[0047] Next, step b is executed: each data block is transmitted sequentially according to its block ID. When transmitting the i-th data block, it is split into multiple data frames, each carrying a frame sequence number, frame data, and a frame checksum. These multiple data frames of the i-th data block are sent frame by frame to the ECU to be flashed, following the order of their frame sequence numbers. Here, i is less than or equal to N. Data block transmission is performed in ascending order of their block IDs. To accommodate communication protocol limitations and improve transmission granularity, each data block is further split into smaller data frames. Each data frame contains a unique frame sequence number for sorting and identification within the data block; it contains the actual frame data; and a frame checksum for fast verification by the receiving end. The electronic device sends these data frames one by one to the ECU to be flashed, following the order of their frame sequence numbers. For example, a 4MB data block can be split into thousands of 4KB data frames, each carrying its relative sequence number within the 4MB block and a CRC8 checksum.

[0048] Then, step c is executed: The frame-level verification result returned by the ECU to be flashed for each data frame is received. If a data frame fails verification, only that frame is retransmitted. If a data frame still fails verification after the number of retransmissions reaches a preset first upper limit threshold, the entire data block to which that frame belongs is marked as an abnormal block, and the current flashing process is terminated. During data frame transmission, the ECU performs frame-level verification immediately upon receiving each data frame. If the verification passes, the ECU returns a success response; if the verification fails, the ECU returns a failure response, indicating the sequence number of the failed frame. Upon receiving a failure response, the electronic device only retransmits the failed data frame, not the entire data block or the entire file. To prevent infinite retransmissions, a preset first upper limit threshold is set, for example, 3 times. If a data frame still cannot be successfully transmitted after reaching this threshold, the data block is considered to have a serious problem, the entire flashing process will be terminated, and the data block will be marked as abnormal. For example, if the verification of data frame with frame number 50 fails, the electronic device will retransmit data frame with frame number 50, instead of sending the entire data block from the beginning.

[0049] After step c is completed, step d is executed: If all data frames of the i-th data block have been transmitted, the block-level verification result returned by the ECU to be flashed is received. This block-level verification result is obtained by the ECU performing an integrity check on the i-th data block based on the corresponding block CRC32 value in the block information table of the i-th data block. If the block-level verification fails, the entire i-th data block is retransmitted. If the block-level verification still fails after the number of retransmissions of the entire data block reaches a preset second upper limit threshold, the flashing process is terminated, and the block ID and failure reason of the data block are output. When all data frames of a data block are successfully transmitted and received by the ECU, the ECU assembles these data frames into a complete data block and calculates the actual CRC32 value of the data block. The ECU compares this calculated value with the block CRC32 value of the corresponding block ID in the previously received block information table. If they match, the block-level verification passes; otherwise, the block-level verification fails. If the verification fails, the electronic device will only retransmit the entire data block instead of starting the flashing process from scratch. Similarly, to avoid infinite retransmissions, a preset second upper limit threshold is set, such as 3 times. If a data block still fails the block-level verification after reaching this threshold, the flashing process will be terminated, and the block ID of the data block and the specific reason for failure will be output to facilitate troubleshooting. For example, if the CRC32 verification of the data block with block ID 1 fails after assembly inside the ECU, the electronic device will retransmit all data frames with block ID 1.

[0050] Finally, execute step e: Repeat steps b through d until all data blocks have been transferred, thus completing the flashing of the ECU using the file to be flashed. This step ensures that all data blocks are transferred and verified according to the frame-level and block-level verification mechanisms described above. Only when all data blocks have been successfully transferred and verified is the entire file to be flashed considered complete and correctly written to the ECU, thereby completing the ECU flashing operation.

[0051] Based on the above examples, the intelligent block-based ECU flashing method proposed in this embodiment demonstrates a significant technical contribution in solving the problems of low efficiency in flashing large files, high retransmission costs, and difficulty in fault location in the prior art.

[0052] The technical advantage of this application lies in the following: In the prior art, regardless of the file size, the file to be written (using a 50MB file as an example) is transmitted and verified as a whole packet. This means that even if a tiny data frame fails during transmission, the entire 50MB file needs to be retransmitted, resulting in extremely high retransmission costs and significantly increased time consumption. For example, in the above example, if a data frame fails verification, the traditional method will have to retransmit the entire 50MB of data, which will cause a huge waste of time and resources in cases of unstable communication links or large file sizes.

[0053] In contrast, this embodiment introduces an intelligent mode selection mechanism, which compares the size S of the file to be written with a preset threshold T to dynamically adjust the writing strategy. For small files (S not greater than T), the whole packet verification mode is used, avoiding the additional protocol overhead caused by block segmentation; for large files (S greater than T), the block verification mode is automatically enabled. This intelligent judgment mechanism ensures that the optimal writing strategy can be adopted in different file size scenarios.

[0054] More importantly, this embodiment introduces a dual verification mechanism of frame-level and block-level verification in the block-based verification mode, combined with a refined retransmission strategy. As shown in the example, when a single data frame fails verification, only that frame needs to be retransmitted, rather than the entire data block or the entire file. When the verification of an entire data block fails, only that data block needs to be retransmitted as well. This "retransmission on demand" strategy greatly reduces the amount of data to be retransmitted, thereby significantly reducing the recovery time after a write failure. For example, retransmitting a 4KB data frame is far more efficient than retransmitting a 50MB file or a 4MB data block.

[0055] Furthermore, by using the block ID in the block information table and the frame sequence number returned when frame-level verification fails, this method can accurately locate the transmission anomaly. In existing technologies, once the entire packet verification fails, only a vague result of "entire packet failed" can be obtained, making it difficult to quickly identify which part of the data has a problem. However, this embodiment can clearly indicate which frame in which block has a problem, which is of great guiding significance for fault diagnosis and problem investigation, and can effectively shorten the fault location time.

[0056] In summary, the method described in this embodiment effectively solves the problems of high retransmission costs, difficult fault location, resource waste, and low efficiency in large file flashing by employing intelligent mode selection, block transmission, frame-level and block-level dual verification, and a refined retransmission mechanism. This method significantly improves the efficiency and reliability of ECU flashing while ensuring data integrity, and its technological advancements are particularly prominent in large file flashing scenarios.

[0057] Furthermore, in some of the embodiments described above in this application, frame-level and block-level verification are proposed to ensure the accuracy of data transmission and writing in a block-based verification mode. However, in its implementation, these verifications mainly target the integrity of individual data frames or data blocks, and cannot completely rule out overall data corruption caused by problems with the storage medium itself, data block splicing errors, or abnormal internal processing of the ECU after all data blocks have been transmitted and written to the Flash memory of the ECU to be flashed. In this case, the lack of a final, global integrity check may lead to flashing failure or ECU malfunction, and the problem may be difficult to locate.

[0058] In response, this application further proposes that, in the block verification mode, after all data blocks have been transmitted, the following steps are also included: triggering the ECU to perform a full-packet CRC fallback verification on all data blocks written to Flash, and receiving the fallback verification result returned by the ECU.

[0059] In this embodiment, triggering the ECU to perform a full-packet CRC fallback check on all data blocks written to Flash means that the electronic device sends a command to the ECU to be flashed to initiate a comprehensive cyclic redundancy check (CRC) on all data blocks written to its Flash memory. This check aims to verify the final integrity of the entire flash file stored within the ECU. As one possible implementation, the electronic device can send a specific diagnostic service request via a diagnostic communication protocol (e.g., the Unified Diagnostic Service (UDS) protocol), which includes command words or parameters for triggering the full-packet check. After receiving and parsing this request, the ECU to be flashed will initiate its internally preset check program. Another possible implementation is that the electronic device sends a predefined control message via a specific communication bus (e.g., a CAN bus), the identifier or data field of which instructs the ECU to perform the full-packet check operation. The firmware of the ECU to be flashed has pre-configured response logic for this control message. Receiving the fallback check result returned by the ECU means that the electronic device obtains the final result of the aforementioned full-packet CRC check operation from the ECU to be flashed. This result is used to determine whether the integrity of the entire flash file in the ECU's internal Flash memory matches expectations. As one possible implementation, after completing the full package CRC check, the ECU to be flashed can send a diagnostic response message via a diagnostic communication protocol (e.g., UDS protocol), containing a status code (e.g., success or failure) for the check result. Another possible implementation is that the ECU to be flashed sends a status frame via a communication bus (e.g., CAN bus), where specific bits or fields indicate the result of the full package check. Upon receiving this status frame, the electronic device parses its contents to obtain the check result.

[0060] In the aforementioned block-level verification mode, although frame-level and block-level verification have meticulously verified the data transmission and the integrity of individual data blocks, these local verifications cannot completely cover the final, overall integrity of the entire flash file in the Flash memory of the ECU to be flashed. To address this issue, the solution in this application introduces a global, full-packet CRC fallback check after all data blocks have been transmitted and their respective block-level verifications have been completed. Specifically, the electronic device actively triggers the ECU to be flashed to perform a comprehensive cyclic redundancy check on all data blocks successfully written to the Flash memory. After internally calculating the CRC value of the entire flash file, the ECU compares it with the expected CRC value and returns the comparison result to the electronic device. In this way, this solution provides a final, high-level integrity guarantee, ensuring that the final storage state of the entire flash file within the ECU is completely consistent with the original file, thereby effectively avoiding overall integrity issues missed by local verifications and significantly improving the reliability of the flashing process.

[0061] Through the above technical solution, in the block verification mode, after all data blocks have been transmitted, a final, global data integrity verification is provided by triggering the ECU to be flashed to perform a full-packet CRC fallback check on all data blocks written to Flash and receiving the returned verification results. This effectively compensates for the shortcomings of only performing frame-level and block-level verification. For example, even if each data block is verified successfully individually, it cannot completely rule out overall data corruption caused by problems with the storage medium itself, data block splicing errors, or ECU internal processing abnormalities after the data blocks are written to the Flash memory. This fallback check ensures the final, complete, and accurate accuracy of the entire flashing file in the Flash memory of the ECU to be flashed, significantly improving the reliability and security of the flashing process. If the fallback check fails, the electronic device can promptly detect and terminate the flashing process, preventing ECU malfunctions due to incomplete or incorrect flashing, thereby reducing flashing risks and increasing the flashing success rate.

[0062] Furthermore, in some other embodiments, before entering the block verification mode, the following steps are also included: The available cache size of the ECU to be flashed is queried. If the cache size of the ECU to be flashed is smaller than the preset block size B, the preset block size B is reduced according to the cache size of the ECU to be flashed, or the system is downgraded to the full packet verification mode. This embodiment can dynamically adapt to ECU cache resources, maintaining the advantage of block verification in saving retransmissions as much as possible without downgrading; it only downgrades to the full packet mode when the cache is extremely small to ensure basic availability.

[0063] In another embodiment, the user can also adjust the preset threshold T while retaining the flexibility of user-defined thresholds.

[0064] Example 2 In some other embodiments, reference is made to Figure 3 This application proposes an electronic device including a storage unit 71, a communication interface 73, and a processing unit 74. The storage unit is used to store a file 72 to be flashed and a preset threshold T; the communication interface 73 is used to establish a diagnostic communication connection with the ECU to be flashed; the processing unit is connected to the storage unit and the communication interface and is configured to execute the above-described intelligent block flashing method for the ECU.

[0065] For example, the electronic device in this embodiment can be a diagnostic instrument, a computer, or any host computer system capable of interacting with the ECU. The electronic device establishes a connection with the ECU to be flashed via a standard diagnostic communication protocol (e.g., the UDS protocol), thereby enabling it to send flashing commands and data to the ECU and receive responses from the ECU.

[0066] This embodiment combines the storage unit, communication interface, and processing unit in a specific architecture, enabling the electronic device to intelligently select a flashing strategy based on the size of the file to be flashed. Specifically, the processing unit is configured to obtain the size S of the file to be flashed and compare it with a preset threshold T. When S is not greater than T, a whole-packet verification mode is used; when S is greater than T, a block-based verification mode is automatically enabled. This design effectively solves the technical problems of extremely high retransmission costs, ambiguous fault location, and serious resource waste during large file flashing in the background art. In the block-based verification mode, the electronic device achieves precise management of data blocks by generating a block information table. Each data block contains key information such as block ID, actual block length, and block CRC32 value, enabling the ECU to independently verify individual data blocks.

[0067] This technical solution significantly optimizes flashing efficiency through a dual verification mechanism. During data transmission, the processing unit controls the communication interface to transmit data blocks sequentially by block ID, and splits each data block into data frames carrying frame sequence number, frame data, and frame check bits. When the ECU returns a frame-level verification failure, only the abnormal frame is retransmitted, not the entire data block; when a block-level verification fails, only the abnormal data block is retransmitted, not the entire file. This refined retransmission strategy reduces the amount of retransmitted data to 1%~10%, while achieving rapid location of transmission anomalies through precise marking of block ID and frame sequence number. For example, when a frame verification failure reaches a preset first upper limit threshold, the processing unit immediately marks the corresponding data block as an abnormal block and terminates the process; when a data block verification failure reaches a preset second upper limit threshold, the block ID of the data block and the reason for failure are output, providing a clear basis for troubleshooting.

[0068] Compared to traditional full-packet transmission, this electronic device demonstrates significant advantages in large file flashing scenarios. Since it eliminates the need to retransmit all data, the time consumed after a large file flashing failure only increases by 1% to 10%, resulting in an overall flashing efficiency improvement of over 50%. The intelligent decision-making mechanism of this processing unit avoids the additional protocol overhead in small file scenarios. When the file size does not exceed a preset threshold T (e.g., 10MB), the full-packet verification mode is used to ensure optimal resource utilization. Furthermore, this solution is based on an extension of the existing UDS protocol, requiring minimal modification to the ECU's underlying communication stack for the storage unit and communication interface configuration, thus simplifying engineering implementation. In vehicle production lines or after-sales scenarios, this electronic device effectively improves production efficiency by reducing the consumption of bus bandwidth and ECU cache by invalid data, resolving the delivery delay issues caused by large file flashing failures in existing technologies.

[0069] Furthermore, this embodiment also proposes an intelligent block-based ECU flashing device, comprising: The comparison module is used to obtain the size S of the file to be written and compare the size S of the file to be written with a preset threshold T. The whole package verification module is used to enter the whole package verification mode if the size S of the file to be flashed is not greater than the preset threshold T, so that the whole file to be flashed is transmitted to the ECU to be flashed and then the whole package verification is performed. The block verification module is used to enter the block verification mode if the size S of the file to be written is greater than the preset threshold T, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, and generate a block information item for each data block. The block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. Step b: Transmit each data block sequentially according to the block ID; wherein, when transmitting the i-th data block, it is split into multiple data frames, and each data frame carries a frame sequence number, frame data and a frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; wherein i is less than or equal to N; Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, simply retransmit that frame. Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted. Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

[0070] It can be understood that the intelligent block-based ECU flashing device in this embodiment can be understood as a virtual program or integrated circuit chip in the above-mentioned electronic device, and its operating principle and technical effects are the same as those in the aforementioned method embodiments.

[0071] Furthermore, this application also provides a computer program product that, when run on the aforementioned electronic device, enables the electronic device to implement the steps described in the various method embodiments.

[0072] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for intelligent block-based ECU flashing, characterized in that, The method is executed by an electronic device, which establishes a communication connection with the ECU to be flashed. The method includes: Obtain the size S of the file to be written, and compare the size S of the file to be written with a preset threshold T; If the size S of the file to be flashed is not greater than the preset threshold T, then the whole package verification mode is entered, so that the entire file to be flashed is transmitted to the ECU to be flashed and then the whole package verification is performed. If the size S of the file to be written is greater than the preset threshold T, then the block verification mode is entered, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, and generate a block information item for each data block. The block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. Step b: Transmit each data block sequentially according to the block ID; wherein, when transmitting the i-th data block, it is split into multiple data frames, and each data frame carries a frame sequence number, frame data and a frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; wherein i is less than or equal to N; Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, simply retransmit that frame. Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted. Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

2. The method as described in claim 1, characterized in that, In the block verification mode, step c further includes: If the retransmission count of a data frame reaches the preset first upper limit threshold and the verification still fails, the entire data block to which the frame belongs is marked as an abnormal block, and the current writing process is terminated.

3. The method as described in claim 1, characterized in that, In the block verification mode, step d further includes: If block-level verification fails after the number of retransmissions for the entire data block reaches the preset second upper limit threshold, the writing process will be terminated and the block ID and reason for failure will be output.

4. The method according to claim 1, characterized in that, In the block verification mode, the block information item generated in step a also includes the number of frames that the i-th data block is split into and the starting offset address of the i-th data block in the file to be written. After the block information table is sent to the ECU to be flashed, the ECU to be flashed performs the following operations: Based on the number of frames, determine whether all data frames of the i-th data block have been received completely. If the number of received data frames is equal to the number of frames, trigger the block-level verification. The starting position for writing the i-th data block in the Flash memory is determined based on the starting offset address. After the block-level verification passes, the data of the i-th data block is written starting from the starting offset address.

5. The method as described in claim 1, characterized in that, In the block verification mode, after all data blocks have been transmitted, the following is also included: The ECU is triggered to perform a full-packet CRC check on all data blocks written to Flash, and the check result returned by the ECU is received.

6. The method as described in claim 1, characterized in that, Before entering the block verification mode, the following is also included: The available cache size of the ECU to be flashed is queried. If the cache of the ECU to be flashed is smaller than the preset block size B, the preset block size B is reduced according to the cache of the ECU to be flashed, or the whole package verification mode is entered.

7. The method as described in claim 1, characterized in that, The method further includes: In response to a user-inputted threshold adjustment command, the preset threshold T is adjusted.

8. An intelligent block-based ECU flashing device, characterized in that, include: The comparison module is used to obtain the size S of the file to be written and compare the size S of the file to be written with a preset threshold T. The whole package verification module is used to enter the whole package verification mode if the size S of the file to be flashed is not greater than the preset threshold T, so that the whole file to be flashed is transmitted to the ECU to be flashed and then the whole package verification is performed. The block verification module is used to enter the block verification mode if the size S of the file to be written is greater than the preset threshold T, including: Step a: Divide the file to be flashed into N data blocks according to the preset block size B, and generate a block information item for each data block. The block information item shall at least include the block ID, the actual length of the block, and the CRC32 value of the block. Organize all the block information items into a block information table and send it to the ECU to be flashed. Step b: Transmit each data block sequentially according to the block ID; wherein, when transmitting the i-th data block, it is split into multiple data frames, and each data frame carries a frame sequence number, frame data and a frame check bit; send the multiple data frames of the i-th data block frame by frame to the ECU to be flashed according to the frame sequence number; wherein i is less than or equal to N; Step c: Receive the frame-level verification result returned by the ECU to be flashed for each data frame. If the verification of a data frame fails, simply retransmit that frame. Step d: After all data frames of the i-th data block have been transmitted, receive the block-level verification result returned by the ECU to be flashed; wherein, the block-level verification result is obtained by the ECU to be flashed after performing integrity verification on the i-th data block according to the corresponding block CRC32 value in the block information table of the i-th data block; if the block-level verification fails, only the entire i-th data block is retransmitted. Step e: Repeat steps b to d until all data blocks are transferred to complete the flashing of the ECU to be flashed using the file to be flashed.

9. An electronic device, characterized in that, include: Storage unit, used to store the file to be written and the preset threshold T; The communication interface is used to establish a diagnostic communication connection with the ECU to be flashed. A processing unit, connected to the storage unit and the communication interface, is configured to perform the intelligent block-based ECU flashing method as described in any one of claims 1-7.

10. A computer program product, said computer program product storing a computer program, characterized in that, The computer program is executed by the processor using the intelligent block-based ECU flashing method as described in any one of claims 1-7.

Images