A method and device for flashing an electronic control unit, an electronic device and a medium

Abstract

This application provides a method, apparatus, electronic device, and medium for flashing an electronic control unit. The method includes: during the process of receiving firmware data, updating the hash value of the current segment to be flashed each time a data block is received; after the data reception of the current segment to be flashed is completed, performing signature verification on the current segment to be flashed based on the updated hash value to obtain a verification result; updating a segment flag according to the verification result and a preset flashing order, and continuing or ending the flashing process according to the segment flag, wherein the segment flag indicates the current flashing stage. This application improves the flashing success rate and efficiency while reducing hardware costs.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and more specifically, to a method, apparatus, electronic device, and medium for flashing an electronic control unit. Background Technology

[0002] In current automotive electrical and electronic architectures, firmware flashing for electronic control units (ECUs) is typically based on the Unified Diagnostic Service Protocol (UDP), loading and updating applications or calibration data via the bootloader. To ensure firmware integrity and authenticity, existing flashing methods generally perform a centralized hash calculation on the complete firmware data after data transmission and verify it using a digital signature. However, as firmware size continues to increase, this centralized hash calculation can take several to tens of seconds, far exceeding the P2Server timeout defined by the UDP, which can easily lead to diagnostic tools misjudging communication interruptions and causing flashing failures.

[0003] Furthermore, existing flashing solutions largely rely on the microcontroller's built-in hardware security module to accelerate hash and signature verification calculations, balancing performance and security. However, for low- to mid-range microcontrollers without integrated hardware security modules, implementing security algorithms in pure software further exacerbates the computational time consumption problem of centralized hashing; adding an external security chip significantly increases hardware costs. Additionally, modern electronic control unit firmware is often divided into multiple logical blocks such as application segments and calibration data segments, requiring external platforms to split files and repeatedly restart the electronic control unit to complete multi-segment flashing, further reducing flashing efficiency. Summary of the Invention

[0004] In view of the above, the purpose of this application is to provide a method, apparatus, electronic device and medium for flashing an electronic control unit, so as to overcome at least one of the above-mentioned defects.

[0005] In a first aspect, embodiments of this application provide a method for flashing an electronic control unit. The method includes: during the process of receiving firmware data, updating the hash value of the current segment to be flashed whenever a data block is received; after the data reception of the current segment to be flashed is completed, performing signature verification on the current segment to be flashed based on the updated hash value to obtain a verification result; updating a segment flag according to the verification result and a preset flashing order, and continuing to execute the flashing process or ending the flashing process according to the segment flag, wherein the segment flag is used to indicate the current flashing stage.

[0006] In one optional embodiment of this application, the preset flashing order includes an application segment and a calibration data segment; the step of updating the segment flag according to the verification result and the preset flashing order includes: if the verification is successful and the current flashing stage is the application segment, then the segment flag is updated to indicate entry into the calibration data segment, and the flashing process continues according to the updated segment flag; if the verification is successful and the current flashing stage is the calibration data segment, then the segment flag is updated to indicate flashing completion, and the flashing ends according to the updated segment flag.

[0007] In one optional embodiment of this application, the hash value of the current segment to be written is updated in the following manner: when the first data block of the current segment to be written is received, the hash context is initialized, and the first data block is input to the hash calculation engine for hash update; when each subsequent data block of the current segment to be written is received, the current data block is input to the hash calculation engine, which uses the content of the current data block to iteratively update the intermediate state value in the hash context based on a preset sharding processing algorithm, and saves the updated intermediate state value back to the hash context for hash calculation of subsequent data blocks.

[0008] In one optional embodiment of this application, the signature verification of the current segment to be flashed is performed in the following manner: calling the hash completion function to calculate the complete hash value of the current segment to be flashed based on the intermediate state value stored in the hash context; reading the signature information from a preset location in the firmware data; decrypting the signature information using a pre-stored public key to obtain the decrypted hash value; determining whether the complete hash value is consistent with the decrypted hash value; if the complete hash value is consistent with the decrypted hash value, the verification passes; if the complete hash value is inconsistent with the decrypted hash value, the verification fails.

[0009] In one optional embodiment of this application, the method further includes: during the writing process, storing the hash context and the length of received data in the uninitialized random access memory area of ​​the microcontroller; when the microcontroller is powered on again after an unexpected reset, restoring the hash context and the length of received data from the uninitialized random access memory area, and skipping the transmitted data according to the restored length of received data, and continuing to receive subsequent data blocks.

[0010] In one optional embodiment of this application, firmware data is received and processed in the following manner: address information is received through the request download service of the unified diagnostic service, the current flashing stage is determined based on the address information, and the initial value of the segment flag is set based on the address information; wherein, receiving firmware data through the transmission data service of the unified diagnostic service includes: in each transmission data service, receiving a data block, performing the step of updating the hash value of the current segment to be flashed, and sending a positive response to the diagnostic instrument after the step is completed, wherein the time taken to update the hash value is less than the response timeout time specified by the diagnostic protocol.

[0011] In one optional embodiment of this application, the data transmission service further includes: determining whether the current firmware offset is a starting value; if the current firmware offset is a starting value, initializing the hash context; calling the fragmented hash update function of the software cryptographic library to perform incremental hash calculation on the current data block; and updating the firmware offset; wherein the steps of calling the fragmented hash update function and updating the firmware offset are performed every time a data block is received, regardless of whether the current firmware offset is a starting value.

[0012] Secondly, this application also provides a flashing device for an electronic control unit, the device comprising: a hash value update module, used to update the hash value of the current segment to be flashed whenever a data block is received during the process of receiving firmware data; a verification result obtaining module, used to perform signature verification on the current segment to be flashed based on the updated hash value after the data reception of the current segment to be flashed is completed, and obtain a verification result; and a segment flag update module, used to update the segment flag according to the verification result and a preset flashing order, and to continue the flashing process or end the flashing process according to the segment flag, wherein the segment flag is used to indicate the current flashing stage.

[0013] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the method described above are performed.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the method described above.

[0015] The electronic control unit flashing method, apparatus, electronic device, and medium provided in this application update the hash value of the current segment to be flashed each time a data block is received during the firmware data reception process. After the data reception of the current segment to be flashed is completed, the signature verification of the current segment to be flashed is performed based on the updated hash value to obtain the verification result. According to the verification result and the preset flashing order, the segment flag is updated, and the flashing process continues or ends according to the segment flag, which is used to indicate the current flashing stage. This application improves the flashing success rate and efficiency while reducing hardware costs.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the flashing method for the electronic control unit provided in this application embodiment; Figure 2 This is a flowchart of signature verification for the current segment to be written, provided in an embodiment of this application. Figure 3 This is a flowchart of firmware data reception and processing provided in an embodiment of this application; Figure 4 This is a schematic diagram of the electronic control unit writing device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0020] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of automotive technology.

[0021] Research has revealed a systemic contradiction in existing technologies for addressing security verification during the flashing process: a difficulty in simultaneously balancing computational performance, real-time requirements, and multi-segment flashing support. Specifically, solutions relying on hardware security modules are costly and incompatible with low- to mid-range chips, while purely software-based centralized hash calculations are time-consuming, leading to diagnostic timeouts. Furthermore, they lack automatic identification and continuous flashing mechanisms for different logical blocks such as application segments and calibration data segments, necessitating external platforms to split files and repeatedly restart the electronic control unit, severely impacting flashing efficiency and user experience.

[0022] Specifically, the reliance on hardware security modules prevents low- to mid-range microcontrollers from deploying high-security bootloaders, and adding external security chips increases the bill of materials cost. Regarding centralized hash calculations, for large firmware files, pure software SHA-256 calculations can take 5 to 10 seconds, far exceeding the P2Server timeout defined by the unified diagnostic service protocol (50 to 5000 milliseconds), causing diagnostic tools to misdiagnose communication loss and resulting in a high flashing failure rate. For multi-segment flashing, the lack of a segmentation flag management mechanism makes it impossible to distinguish between application segments and calibration data segments within the bootloader, requiring remote upgrade platforms to split the file and repeatedly restart the electronic control unit, reducing flashing efficiency.

[0023] Based on this, embodiments of this application provide a method, apparatus, electronic device, and medium for flashing an electronic control unit, to solve the technical problems in the prior art, such as high cost due to reliance on hardware security modules, diagnostic timeouts caused by centralized hash calculations, and low efficiency due to repeated restarts required for multi-segment flashing. This application achieves the technical effect of distributing hash calculations across each data block reception process to avoid timeouts without the support of a hardware security module, and automatically managing multi-segment continuous flashing through segment flags.

[0024] The embodiments of this application implement a software-based, segmented, and multi-segmented parallel security verification architecture in the bootloader of the electronic control unit. The core includes three major modules: a software cryptographic library adaptation layer, a segmented hash calculation engine, and a multi-segment flag manager.

[0025] To implement the above architecture, the following global variables are predefined in the uninitialized random access memory region of the microcontroller: The segment type flag, used to indicate the current write stage, is stored at address 0xF0100. A value of 0x00 indicates the application segment, and a value of 0x01 indicates the calibration data segment. The hash context is used to store the intermediate state values ​​of the SHA-256 algorithm. It occupies 256 bytes of space and is stored at address 0xF0110. The signature verification initialization flag is used to indicate whether the signature verification has been initialized and is stored at address 0xF0150; The current firmware offset is used to record the cumulative length of received firmware data and is stored at address 0xF0154.

[0026] In addition, a predefined security library configuration structure is provided in the flash constant area. This structure includes the RSA public key context, SHA-256 context, RSA public key modulus, and RSA public key exponent. The RSA public key modulus is 2048 bits, and the RSA public key exponent is preset to 0x10001.

[0027] Please see Figure 1 , Figure 1 This is a flowchart illustrating the flashing method for the electronic control unit provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method for flashing an electronic control unit includes: S101. During the process of receiving firmware data, whenever a data block is received, update the hash value of the current segment to be flashed.

[0028] In this step, the Electronic Control Unit (ECU) is the core control component of the vehicle. Within the vehicle, the ECU is responsible for receiving signals from sensors, performing calculations and processing according to preset control logic, and sending control commands to actuators to achieve precise control of functions such as the engine, transmission, braking system, and in-vehicle entertainment system. It is a fundamental building block in modern automotive electronic architecture and typically interacts with other ECUs via in-vehicle networks (such as the Controller Area Network bus).

[0029] The electronic control unit receives firmware data from the diagnostic tool or cloud server via the unified diagnostic service's data transmission service. Each data block is typically 4KB or smaller to accommodate the maximum transmission unit of the communication link.

[0030] Specifically, the hash value of the current segment to be flushed is updated in the following way: Upon receiving the first data block of the current segment to be written, the hash context is initialized, and this first data block is input into the hash calculation engine for hash update. This context is a data structure used to store the intermediate state of the SHA-256 algorithm, including eight 32-bit hash values ​​and information such as the length of the currently processed data block. After initialization, the content of the first data block is input into the hash calculation engine.

[0031] Upon receiving each subsequent data block of the current segment to be written, the current data block is input into the hash calculation engine. Based on a preset fragmentation algorithm, the hash calculation engine iteratively updates the intermediate state value in the hash context using the content of the current data block, and saves the updated intermediate state value back to the hash context for use in hash calculations of subsequent data blocks. The engine divides the data block into 512-bit groups according to the SHA-256 fragmentation algorithm, performs iterative compression operations on each group, and updates the intermediate state value in the context. After each update, the cumulative length of received data, i.e., the firmware offset, is recorded. This offset is an continuously incrementing counter value used to track the data reception progress of the current segment.

[0032] In this way, hash calculations are evenly distributed across each data transmission service, resulting in extremely short update times (typically less than 10 milliseconds), far below the response timeout specified by the diagnostic protocol. This avoids the prolonged blocking caused by centralized hash calculations only after all data has been received, as is common in traditional solutions, fundamentally eliminating the risk of write failures due to calculation timeouts.

[0033] To achieve secure algorithm operation without hardware security module support, this application performs vehicle-grade lightweight trimming and optimization of the software cryptographic library. Specifically, the RSA signature verification function is functionally trimmed, retaining only the PKCS#1v1.5 verification function. Furthermore, the CRT (Chinese Remainder Theorem) optimization branch is disabled in the code using conditional compilation macros, forcing the use of the basic modular exponentiation algorithm to reduce code size. Simultaneously, Montgomery parameters (R² mod N, etc.) are pre-calculated during system initialization and stored in the constant area for direct use in subsequent modular exponentiation operations, improving the speed of modular exponentiation. The SHA-256 fragment update function is optimized at the low level, processing each 64-byte fragment and directly calling kernel assembly instructions to accelerate computation, achieving 1.2 cycles per byte on the Cortex-M0+ core and 0.8 cycles per byte on the Cortex-M4 core. Through these optimizations, the software cryptographic library code size is controlled to within 32KB, and the signature verification time can be reduced to below 500 milliseconds at a 48MHz clock frequency.

[0034] S102. After the data of the current segment to be written is received, the signature of the current segment to be written is verified based on the updated hash value to obtain the verification result.

[0035] In this step, the electronic control unit (ECU) enters the signature verification stage when it detects that all data blocks of the current flashing segment (e.g., application segment or calibration data segment) have been received. The determination of completion is typically based on comparing the cumulative length of received data with the expected length; if they are equal, it indicates that the current segment's data transmission is complete. At this point, the ECU needs to verify whether the received firmware data is complete and untampered with, and whether it originates from a trusted source.

[0036] For further details, please refer to Figure 2 , Figure 2 The flowchart for signature verification of the current segment to be written, provided in this embodiment of the application, verifies the signature of the current segment to be written in the following manner: S201. Call the hash completion function to calculate the complete hash value of the current segment to be written based on the intermediate state value stored in the hash context.

[0037] The hash context stores intermediate state values ​​accumulated throughout the flashing process, including eight 32-bit hash values ​​compressed through multiple iterations and the length information of the processed data. The hash completion function performs final grouping and padding and length encoding on these intermediate state values, completing the final round of iteration calculation according to the SHA-256 algorithm specification, and outputting a complete 256-bit hash value. This hash value is the unique digital fingerprint of the entire firmware segment data; any byte modification will result in a completely different final hash value. The direct effect of this step is to transform the fragmented, accumulated intermediate states into a standard hash result that can be compared.

[0038] S202: Read signature information from the preset location of firmware data.

[0039] During firmware data generation, the hash value of the original firmware is encrypted using a private key to form RSA signature data, which is stored at a fixed position at the end of the firmware file, such as the last 256 bytes. After completing the firmware data writing, the electronic control unit directly reads the signature information from this preset location in the memory. This signature information is an encrypted data block, and its meaning cannot be directly read; it requires decryption in subsequent steps. This step obtains the original credential used to verify the authenticity of the firmware.

[0040] S203. Use the pre-stored public key to decrypt the signature information and obtain the decrypted hash value.

[0041] The electronic control unit (ECU) is pre-stored with a public key corresponding to the signature private key at the factory or through secure channels. This public key, composed of a modulus and an exponent, is stored in a protected storage area. The RSA signature verification function is called, using this public key to decrypt the read signature information; that is, a modular exponentiation is performed on the signature data to restore the content before encryption. The decrypted result is a fixed-length hash value, which should theoretically be the hash value of the original firmware. This step restores the encrypted signature to a comparable hash value form.

[0042] S204. Determine whether the complete hash value is consistent with the decrypted hash value.

[0043] The complete hash value calculated in S201 is compared byte by byte with the hash value decrypted in S203. Since both hash values ​​are 256 bits of data, the comparison process can be completed using a comparator or by looping through each byte. This step is a logical judgment operation that does not change any data state, but only produces a boolean result for subsequent branch selection in the process.

[0044] S205. If the complete hash value matches the decrypted hash value, the verification is successful.

[0045] If the two hash values ​​are exactly the same, it proves that the current firmware segment data has not been tampered with during transmission and storage, and its source is trustworthy, because only a legitimate publisher holding the correct private key can generate a signature that can be correctly decrypted using the pre-stored public key. At this point, the electronic control unit confirms that the firmware segment can be used securely.

[0046] S206. If the complete hash value is inconsistent with the decrypted hash value, the verification fails.

[0047] If the two hash values ​​are different, it indicates that the firmware data may have been tampered with, an error occurred during transmission, or the signatures may not match. In this case, the electronic control unit should mark the firmware segment as invalid and take appropriate security measures, such as triggering a rollback operation or reporting an error status.

[0048] Through the above signature verification process, the electronic control unit completes the dual verification of firmware integrity and authenticity in a purely software manner without relying on hardware security modules, providing a reliable guarantee for subsequent firmware activation and secure operation.

[0049] S103. Based on the verification results and the preset writing order, update the segment flag, and continue or end the writing process according to the segment flag. The segment flag is used to indicate the current writing stage.

[0050] In this step, the preset flashing sequence includes the application segment and the calibration data segment. The electronic control unit updates a special segment flag variable based on the verification results obtained in the previous step and the system's preset flashing sequence. This segment flag is stored in the microcontroller's uninitialized random access memory area and retains its value after an unexpected reset.

[0051] The preset flashing order is determined by the address information in the external flashing request. For example, when the diagnostic tool sends the starting address and length through the request download service, the electronic control unit determines whether the segment to be flashed is an application segment or a calibration data segment based on the address range, and sets the initial value of the segment flag accordingly.

[0052] Specifically, if the verification passes and the current segment flag indicates that it is an application segment, the segment flag is updated to the calibration data segment, indicating that calibration data needs to be flashed next; if the verification passes and the current segment flag is the calibration data segment, the segment flag is updated to the flashing completed status.

[0053] Based on the updated segment flag, the electronic control unit (ECU) determines the subsequent action: if the segment flag indicates entry into the next stage, it automatically prepares to receive the next segment of firmware data and continues the flashing process; if the segment flag indicates flashing is complete, the entire flashing process ends. In this way, continuous automatic flashing of multiple firmware segments is achieved through a simple flag, without external intervention or restarting the ECU, significantly shortening the total flashing time while improving the automation and robustness of the flashing process.

[0054] In this embodiment of the application, during routine control service, the electronic control unit determines the type of firmware segment to be verified based on the current value of the segment flag. If the current segment flag indicates an application segment, the signature information is read from a position offset forward 256 bytes from the end of the application segment firmware; if the current segment flag indicates a calibration data segment, the signature information is read from a position offset forward 256 bytes from the end of the calibration data segment firmware.

[0055] After reading the signature information, the hash completion function is called to calculate the complete hash value of the current segment to be written based on the intermediate state value stored in the hash context, and the signature information is verified using RSA. If the verification fails, the corresponding firmware block is marked as an invalid block according to the current segment type. For example, the application segment is marked as invalid block 0 or the calibration data segment is marked as invalid block 1, and a negative response is sent to the diagnostic tool.

[0056] If the signature verification is successful and the current segment is an application segment, the segment flag is updated to the calibration data segment, ready to receive the next segment of firmware data; if the signature verification is successful and the current segment is the calibration data segment, the segment flag is reset to the application segment, and the firmware offset is cleared to zero, indicating that the entire flashing process is complete.

[0057] Specifically, this application also includes: During the write process, the hash context and the length of the received data are stored in the microcontroller's uninitialized random access memory area.

[0058] In this step, the electronic control unit continuously maintains two key pieces of data throughout the firmware reception process: the hash context and the length of received data. The hash context is a set of intermediate states during the incremental calculation process of the SHA-256 algorithm, including eight 32-bit hash working variables (A, B, C, D, E, F, G, H), the partial content of the currently processed data block, and the total number of bits of processed data. The length of received data is a 32-bit or 64-bit counter value that records the number of bytes successfully received and written to memory in the current flash segment, i.e., the firmware offset.

[0059] After each data block reception, hash update, and flash write is completed, the electronic control unit immediately writes the latest hash context and the updated length of received data to the microcontroller's uninitialized random access memory (RAM) area. Uninitialized RAM is a special memory area that, after a system reset or power failure and restart, retains its original values ​​from before the reset, provided that power or backup power is available. This area is chosen for storage to ensure that these critical write progress states survive in the event of an unexpected reset.

[0060] This real-time persistence operation ensures that the intermediate state during the flashing process is securely saved, preparing data for potential breakpoint resumption. The direct benefit of this step is transforming the flashing progress from a volatile runtime state to a persistent storage state, making the flashing task resilient to unexpected interruptions.

[0061] When power is restored after an unexpected reset, the hash context and the length of received data are restored from the uninitialized random access memory area, and the transmitted data is skipped according to the restored length of received data to continue receiving subsequent data blocks.

[0062] In this step, when the electronic control unit is unexpectedly reset and powered on again due to power fluctuations, watchdog timeouts, or other anomalies, the bootloader will first check the validity of flag bits or data in the uninitialized random access memory area during the normal initialization process. By verifying specific identifiers or checksums in this area, it determines whether the stored hash context and the length of received data are valid and belong to an incomplete flashing session.

[0063] As a specific implementation, a fixed magic number (e.g., 0x5A5A5A5A) is stored at the starting address of the uninitialized random access memory region as a valid identifier. Subsequently, a copy of the hash context and the length of the received data is stored, along with a CRC32 checksum calculated based on the aforementioned data. Upon recovery, the magic number is first checked for a match, then the CRC32 is recalculated and compared with the stored checksum. If both matches pass, the data is considered valid.

[0064] If the determination is valid, the electronic control unit (ECU) directly loads the previously saved hash context from the uninitialized random access memory area, restoring it to the current state of the hash calculation engine. Simultaneously, it reads the length of the received data to determine how many bytes of data the current write segment has successfully processed. Based on this restored length of received data, the ECU skips the already received data portion in subsequent data transmission services and directly requests the diagnostic tool to resume sending subsequent data blocks from the point of interruption. For example, if the restored length of received data indicates that 1MB of data has been successfully received, the ECU, after re-establishing communication, will instruct the diagnostic tool to continue transmission from the first byte after 1MB.

[0065] After restoring the hash context, subsequent new data blocks can be directly input into the hash calculation engine, which is now in a correct intermediate state, to continue incremental hash calculations without having to recalculate the hash value of the entire firmware segment from scratch. This allows for a seamless flashing process, eliminating the need to repeatedly receive and process data that has already been transmitted and verified for integrity. The direct effect of this step is to achieve true breakpoint resume functionality, significantly improving the robustness of flashing in harsh automotive environments. It avoids the predicament of a single unexpected interruption causing the entire flashing process to fail and requiring a restart, thereby significantly improving the success rate of flashing and the user experience.

[0066] During the power-on initialization process of the electronic control unit, the status of the signature initialization flag and the current firmware offset is checked first. If the signature initialization flag is valid and the current firmware offset is greater than zero, an unexpected reset is determined to have occurred, and the incomplete flashing session needs to be resumed.

[0067] The electronic control unit loads the previously saved hash context from the uninitialized random access memory area, restoring it to the current state of the hash calculation engine, and simultaneously reads the restored firmware offset. After the state restoration is complete, it can directly continue receiving subsequent data transmission services without re-initializing the hash context, thus enabling breakpoint resume.

[0068] If the signature initialization flag is invalid or the current firmware offset is zero, it is determined to be a normal power-on or a new flashing session. At this time, the signature initialization flag is set to invalid, the firmware offset is cleared to zero, the segment flag is set to the default application segment, and it waits to receive a new flashing request.

[0069] For further details, please refer to Figure 3 , Figure 3 The flowchart for receiving and processing firmware data provided in this application embodiment describes how firmware data is received and processed in the following manner: S301. Receive address information through the request download service of the unified diagnostic service, determine the current writing stage based on the address information, and set the initial value of the segment flag based on the address information.

[0070] In this step, the electronic control unit receives a 0x34 service request (request for download service) from the diagnostic tool. This request message carries two key parameters: the starting address of the data to be written and the data length. The starting address is a 32-bit or longer memory address value that specifies the target storage location of the data to be written in memory; the data length specifies the total number of bytes of data to be written.

[0071] The electronic control unit (ECU) internally stores an address range mapping table for different firmware segments. For example, the application segment occupies the address space from 0x80010000 to 0x800BFFFF, while the calibration data segment occupies the address space from 0x80280000 to 0x8029FFFF. By comparing the received starting address with these preset address ranges, the ECU can determine which firmware segment is about to be received: if the starting address falls within the application segment range, it is identified as the application segment; if it falls within the calibration data segment range, it is identified as the calibration data segment.

[0072] Based on the identification results, the electronic control unit sets the initial value of the segment flag. The segment flag is a single-byte variable stored in the uninitialized random access memory area, used to indicate the current flashing stage. If the segment is identified as an application segment, the segment flag is set to 0x00; if the segment is identified as a calibration data segment, the segment flag is set to 0x01. This segment flag will be used throughout the entire flashing process, guiding subsequent process control and state switching. Through this step, the electronic control unit can automatically identify the firmware type of the current flashing task without external intervention, laying the foundation for subsequent multi-segment continuous flashing.

[0073] S302. Receive firmware data through the transmission data service of the unified diagnostic service, including: in each transmission data service, receive a data block, perform the step of updating the hash value of the current segment to be written, and send a positive response to the diagnostic instrument after the completion of the step, wherein the time taken to update the hash value is much less than the response timeout time specified by the diagnostic protocol.

[0074] In this step, the electronic control unit (ECU) receives the actual firmware data via service 0x36 (Transfer Data Service). During each transfer data service, the diagnostic tool sends a data block, which can be up to 4096 bytes long, containing a sequence number byte followed by the firmware payload. The ECU extracts the payload portion of the message, i.e., the firmware data to be written to memory.

[0075] Upon receiving each data block, the electronic control unit immediately executes the step of updating the hash value of the current segment to be written. This step includes: if the current frame is the first data block of the current segment, initializing the hash context; otherwise, inputting the current data block into the hash calculation engine, iteratively updating the intermediate state values ​​in the hash context based on a preset fragmentation processing algorithm, and saving the updated state values ​​back to the hash context. Simultaneously, the length of received data (i.e., firmware offset) is updated, recording the total number of bytes successfully received in the current segment.

[0076] Unlike existing technologies, the electronic control unit (ECU) sends a positive response to the diagnostic tool immediately after completing the hash update and data write, without waiting for all data in the entire firmware segment to be received. This means that the response time for a single data transmission service only includes the time spent on data reception, hash incremental update, and flash write, typically less than 10 milliseconds, far below the P2Server timeout time specified in the diagnostic protocol (50 to 5000 milliseconds). In this way, hash calculation is evenly distributed across each data transmission service, completely avoiding the long-term blocking caused by centralized hash calculation and ensuring that the flashing process is not mistakenly identified as a communication interruption by the diagnostic tool due to timeout.

[0077] In the data transmission service, the electronic control unit extracts the payload data from the diagnostic message, located after the serial number byte. Before performing incremental hash calculation, it first checks whether the current firmware offset is zero: if the current firmware offset is zero, it initializes the SHA-256 hash context, sets the SHA-256 mode, and sets the signature initialization flag to a valid state.

[0078] The software cryptographic library's fragmented hash update function is invoked to input the current data block's content into the hash calculation engine for incremental updates. If an error occurs during the hash update process, an error status flag is set, a negative response is sent to the diagnostic tool, and the current flashing process is terminated. After a successful hash update, the length of the current data block is added to the firmware offset to record the total length of received data.

[0079] After completing the above operations, the electronic control unit performs a flash memory write operation and does not wait for the hash calculation to complete before sending a positive response to the diagnostic instrument, ensuring that the response time of a single data transmission service meets the diagnostic protocol requirements.

[0080] S303. Perform signature verification through the routine control service of the unified diagnostic service.

[0081] In this step, after all data blocks of the entire firmware segment have been received through the data transmission service, the diagnostic tool sends a 0x31 service request (routine control service). Its sub-function is usually 0x01, indicating the start of a routine, and the routine identifier indicates that this is a verification routine. After receiving this request, the electronic control unit enters the signature verification process.

[0082] The electronic control unit first obtains the final hash value from the continuously maintained hash context by calling the hash completion function, which calculates the complete 256-bit hash value of the segment to be written based on the intermediate state values ​​stored in the hash context. Next, it reads the signature information from a preset location in the firmware data, typically located in the last 256 bytes of the firmware, which stores the RSA signature data generated after hashing and encrypting the original firmware using a private key.

[0083] The electronic control unit internally stores a public key corresponding to the signature private key, including the modulus and exponent. This public key is used to decrypt the signature information, yielding a decrypted hash value. The calculated complete hash value is then compared byte-by-byte with the decrypted hash value: if they match, the verification passes, indicating that the firmware data is complete and of a reliable origin; if they do not match, the verification fails, indicating that the firmware may have been tampered with or corrupted.

[0084] The entire signature verification process is completed in the routine control service. Its time depends on the computing power of the microcontroller. With the support of an optimized software cryptographic library, it can be controlled within 500 milliseconds. By centralizing the signature verification in the routine control service, both security and time-consuming operations during data transmission are avoided, thus preventing them from affecting real-time performance.

[0085] The data transmission service also includes: Determine if the current firmware offset is the starting value; if the current firmware offset is the starting value, initialize the hash context; call the fragmented hash update function of the software cryptographic library to perform incremental hash calculation on the current data block; update the firmware offset; the steps of calling the fragmented hash update function and updating the firmware offset are executed every time a data block is received, regardless of whether the current firmware offset is the starting value.

[0086] In the above steps, each time the electronic control unit receives a data block via the data transmission service, it first reads the currently maintained firmware offset. The firmware offset is a counter value stored in an uninitialized random access memory area, recording the total number of data bytes successfully received and processed in the current flash segment. Before the flash begins, this offset is initialized to 0; during the flash process, the offset is incremented by the actual length of the current data block for each received data block.

[0087] The electronic control unit determines whether the current firmware offset is the starting value, i.e., whether the value is equal to 0. If the current firmware offset is 0, it indicates that this is the first data block received in the current segment to be flashed, and at this time, the hash context initialization operation needs to be performed. Hash context initialization includes setting the initial hash value of the SHA-256 algorithm (i.e., eight fixed 32-bit constants), clearing the current data block buffer, and setting the processed bit count counter to zero. After initialization, the hash calculation engine is in a ready state and can begin receiving the input of the first data block.

[0088] Regardless of whether the current firmware offset is the initial value, the electronic control unit (ECU) calls the fragmented hash update function of the software cryptographic library to perform incremental hash calculations on the currently received data block. The software cryptographic library is a lightweight, tailored, and optimized encryption algorithm implementation specifically adapted for microcontrollers without hardware security modules. The fragmented hash update function takes the content of the current data block as input and iteratively updates the intermediate state values ​​stored in the hash context based on the SHA-256 fragmentation algorithm. This function processes the input data byte by byte, executing a compression function after processing every 512 bits of data, updating the intermediate state values, and recording the processing progress in the context.

[0089] After the hash update is completed, the electronic control unit immediately updates the firmware offset, adding the length of the current data block to the original firmware offset to obtain the new total length of received data. The updated firmware offset is saved back to the uninitialized random access memory area so that the flashing progress can be accurately restored after subsequent data block reception or accidental reset.

[0090] It's important to note that the steps of calling the fragment hash update function and updating the firmware offset are performed every time a data block is received, regardless of whether the current firmware offset is the initial value. In other words, even if the current offset is 0 (the first data block), incremental hash calculation and offset update are still required after initialization; when the offset is not 0, incremental hash calculation and offset update are performed directly without repeated initialization. This design ensures that every data block participates in the hash calculation, and the progress record always remains consistent with the amount of data processed, providing an accurate data foundation for subsequent breakpoint resume and signature verification.

[0091] In the first embodiment, the execution flow of fragment hashing in the data transmission service is as follows: In the scenario of flashing 18MB application firmware, each frame transmits a 4KB data block. When the electronic control unit receives the first frame data transmission service request, it detects that the current firmware offset is zero and initializes the hash context. It calls the software cryptographic library's fragmented hash update function to perform incremental hash calculation on the 4KB data block, while the hardware CRC32 module performs data integrity verification in parallel, taking approximately 1 millisecond. Simultaneously, while writing the data to the flash memory, the central processing unit updates the SHA-256 context in the background, taking approximately 3 milliseconds. The total time for a single data transmission service is less than 10 milliseconds. After completing the above operations, a positive response is immediately sent to the diagnostic tool without waiting for the hash calculation of the entire firmware segment to complete. This process is repeated approximately 4500 times until all 18MB firmware data is transmitted and the firmware offset accumulates to 18MB. Compared to the approximately 9.2 seconds taken by centralized hash calculation in existing technologies, the fragmented hash scheme of this application has no diagnostic timeout risk, and the total flashing time only increases by approximately 9 seconds.

[0092] In the second embodiment, the two-segment continuous writing process of the application segment and the calibration data segment is as follows: During the first phase of flashing the application segment, the remote upgrade platform sends a 12MB flashing request starting at address 0x80010000 via the request download service. The electronic control unit (ECU) sets the segment flag to the application segment based on the address information. After the application segment data transmission is complete, the remote upgrade platform sends a routine control service request. The ECU reads the signature information from the end of the application segment firmware (0x800BFF00) based on the segment flag and performs signature verification. Upon successful signature verification, the segment flag is updated to the calibration data segment, and a positive response is returned.

[0093] During the second stage of flashing the calibration data segment, the remote upgrade platform does not need to restart the electronic control unit (ECU). It directly sends a flashing request with a starting address of 0x80280000 and a size of 2MB. The ECU automatically clears the firmware offset to zero and sets the segment flag to the calibration data segment based on the address information. After the calibration data segment is transmitted, a routine control service request is sent again. The ECU reads the signature information from the end of the calibration data segment firmware at 0x8029FE00 for verification. After successful signature verification, the segment flag is reset to the application segment, indicating that the entire flashing process is complete.

[0094] In the third embodiment, the security handling after signature verification failure is as follows: In the event of application segment signature verification failure, the electronic control unit detects an error code returned by the RSA signature verification function, determines the application segment failure based on the current segment flag, and performs an invalid block marking operation, marking the firmware block corresponding to the application segment as invalid. If the current active area is the primary active area, it automatically switches to the backup area for startup and sets the signature initialization flag to an invalid state, preventing subsequent flashing operations. Simultaneously, it sends a negative response code 0x24 (Request Sequence Error) to the diagnostic tool and records the diagnostic fault code 0xB100 (Firmware Signature Verification Failure). This mechanism prevents the electronic control unit from being in a half-successful flashing state, ensuring the system can be rolled back to a secure version.

[0095] Compared with existing multi-segment flashing methods that rely on hardware security modules and employ centralized hash calculations, the electronic control unit flashing method, apparatus, electronic device, and medium provided in this application avoid diagnostic timeout risks by distributing hash calculations to the reception process of each data block. Simultaneously, by automatically managing the flashing order of application segments and calibration data segments using segment flags, continuous multi-segment flashing without restarting is achieved. Furthermore, combined with a breakpoint resume mechanism for uninitialized random access memory regions, the flashing success rate, efficiency, and robustness are significantly improved without the support of hardware security modules, effectively reducing hardware costs.

[0096] The core technologies of this application include: implementing commercial-grade RSA signature verification and SHA-256 hash algorithm on a microcontroller without a hardware security module by performing vehicle-grade lightweight trimming of the software cryptographic library; embedding the fragmented hash mechanism into the data transmission service, incrementally updating the hash value during each data transmission to avoid diagnostic timeouts caused by centralized hash calculation; automatically identifying application segments and labeled data segments through segment flags to achieve continuous writing and independent verification of multiple segments; and using the microcontroller's uninitialized random access memory to store the hash context and the length of received data to achieve breakpoint resumption after an unexpected reset.

[0097] The technical solutions provided in this application can solve the following technical problems: By implementing security algorithms in software, the reliance on hardware security modules is eliminated, enabling microcontrollers without hardware security modules to deploy high-security bootloaders, effectively reducing hardware costs; by employing fragmented hashing technology, hash calculations are distributed across the data transmission service, avoiding the diagnostic timeout risk caused by centralized hash calculations; by automatically identifying application segments and calibration data segments through segment flags, segmented independent verification and continuous writing are achieved without external intervention or restarting the electronic control unit; and by lightweight trimming and optimization of the software cryptographic library, it is adapted to low-computing-power microcontrollers, reducing resource consumption.

[0098] Based on the above technical solution, this application can achieve the following beneficial effects: In terms of security, by using RSA signature verification and SHA-256 hash algorithm, a high level of security is achieved, and the anti-tampering capability is comparable to that of hardware security module solutions; in terms of real-time performance, fragmented hashing makes the data service time for a single transmission extremely short, effectively avoiding diagnostic timeouts and significantly improving the success rate of writing; in terms of efficiency, continuous writing of application segment and calibration data segment can be achieved without restarting, greatly shortening the total time; in terms of cost, the pure software solution eliminates the need for an external security chip, effectively reducing the bill of materials cost.

[0099] Based on the same inventive concept, this application also provides an electronic control unit flashing device corresponding to the electronic control unit flashing method. Since the principle of the device in this application is similar to the above-mentioned electronic control unit flashing method in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0100] Please see Figure 4 , Figure 4 This is a schematic diagram of the electronic control unit writing device provided in an embodiment of this application. Figure 4 As shown, the electronic control unit's writing device 400 includes: The hash value update module 401 is used to update the hash value of the current segment to be flashed whenever a data block is received during the process of receiving firmware data. The verification result acquisition module 402 is used to perform signature verification on the current segment to be written based on the updated hash value after the data reception of the current segment to be written is completed, and obtain the verification result. The segment flag update module 403 is used to update the segment flag according to the verification result and the preset writing order, and to continue or end the writing process according to the segment flag. The segment flag is used to indicate the current writing stage.

[0101] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 500 includes a processor 510, a memory 520, and a bus 530.

[0102] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 and the memory 520 communicate via the bus 530. When the machine-readable instructions are executed by the processor 510, they can perform the operations described above. Figure 1 The steps of the electronic control unit flashing method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0103] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the electronic control unit flashing method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0104] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0106] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0108] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, 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 covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for flashing an electronic control unit, characterized in that, include: During the process of receiving firmware data, the hash value of the current segment to be flashed is updated whenever a data block is received. After the data of the current segment to be written is received, the signature of the current segment to be written is verified based on the updated hash value to obtain the verification result; Based on the verification results and the preset flashing order, update the segment flag, and continue or end the flashing process according to the segment flag. The segment flag is used to indicate the current flashing stage.

2. The method according to claim 1, characterized in that, The preset writing order includes the application segment and the calibration data segment; The step of updating the segment flag based on the verification result and the preset write order includes: If the verification is successful and the current flashing stage is the application segment, the segment flag is updated to indicate entry into the calibration data segment, and the flashing process continues according to the updated segment flag. If the verification is successful and the current writing stage is the calibration data segment, then the segment flag is updated to indicate that the writing is complete, and the writing ends according to the updated segment flag.

3. The method according to claim 1 or 2, characterized in that, Update the hash value of the current segment to be flushed in the following way: Upon receiving the first data block of the current segment to be flushed, initialize the hash context and input the first data block into the hash calculation engine for hash update; Upon receiving each subsequent data block of the current segment to be written, the current data block is input into the hash calculation engine. The hash calculation engine, based on a preset sharding processing algorithm, uses the content of the current data block to iteratively update the intermediate state value in the hash context, and saves the updated intermediate state value back into the hash context for use in hash calculation of subsequent data blocks.

4. The method according to claim 3, characterized in that, The signature verification of the current segment to be written is performed in the following manner: Call the hash completion function to calculate the complete hash value of the current segment to be written based on the intermediate state value stored in the hash context; Read signature information from a preset location in the firmware data; The signature information is decrypted using a pre-stored public key to obtain the decrypted hash value; Determine whether the complete hash value is consistent with the decrypted hash value; If the complete hash value matches the decrypted hash value, the verification is successful. If the complete hash value does not match the decrypted hash value, the verification fails.

5. The method according to claim 4, characterized in that, Also includes: During the writing process, the hash context and the length of the received data are stored in the uninitialized random access memory area of ​​the microcontroller; When power is restored after an unexpected reset, the hash context and the length of received data are restored from the uninitialized random access memory area, and the transmitted data is skipped according to the restored length of received data to continue receiving subsequent data blocks.

6. The method according to claim 5, characterized in that, Firmware data is received and processed in the following ways: The unified diagnostic service requests and downloads address information, determines the current writing stage based on the address information, and sets the initial value of the segment flag based on the address information. Among them, receiving firmware data through the transmission data service of the unified diagnostic service includes: receiving a data block in each transmission data service, performing the step of updating the hash value of the current segment to be written, and sending a positive response to the diagnostic instrument after the step is completed, wherein the time taken to update the hash value is less than the response timeout time specified by the diagnostic protocol; The signature verification is performed through the routine control service of the unified diagnostic service.

7. The method according to claim 6, characterized in that, The data transmission service also includes: Determine if the current firmware offset is the starting value; If the current firmware offset is the starting value, then initialize the hash context; Call the software cryptographic library's fragment hash update function to perform incremental hash calculation on the current data block; Update the firmware offset; The steps of calling the fragment hash update function and updating the firmware offset are executed every time a data block is received, regardless of whether the current firmware offset is the initial value.

8. A writing device for an electronic control unit, characterized in that, include: The hash value update module is used to update the hash value of the current segment to be flashed whenever a data block is received during the process of receiving firmware data. The verification result acquisition module is used to perform signature verification on the current segment to be written based on the updated hash value after the data reception of the current segment to be written is completed, and obtain the verification result. The segment flag update module is used to update the segment flag according to the verification result and the preset flashing order, and to continue or end the flashing process according to the segment flag. The segment flag is used to indicate the current flashing stage.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 7.

Images