Data flashing method and device, electronic equipment and storage medium

Abstract

The invention provides a data flashing method and device, electronic equipment and a storage medium, the method is applied to the technical field of data flashing, and the method comprises the following steps: obtaining to-be-flashed target firmware, and storing the target firmware in a cache region; wherein the version of the target firmware is higher than that of the backup firmware, and the backup firmware is stored in the target area; reading data different from the backup firmware from the cache region as to-be-flashed data; and flashing the to-be-flashed data into the target area. According to the method, the duration required by firmware flashing can be shortened.

Description

Technical Field

[0001] This application relates to the field of data writing technology, and more specifically, to data writing methods, apparatus, electronic devices and storage media in the field of data writing technology. Background Technology

[0002] Currently, the ECU (Electronic Control Unit) is the core control component of a vehicle, responsible for performing various complex control tasks. In order to ensure the continuous improvement of vehicle performance and functional iteration, it is necessary to regularly update and upgrade the software in the ECU control unit.

[0003] ECU software upgrades are primarily achieved through OTA (Over-The-Air) or local methods, which involves flashing the new firmware version to the ECU's storage unit. Currently, most ECUs use an MCU (Microcontroller Unit) as their core processor, which integrates Flash memory (also known as the aforementioned storage unit) to store the firmware.

[0004] As vehicle functions increase, the firmware size of a single ECU also continues to increase. Furthermore, the firmware flashing speed is relatively slow, which directly leads to an extension of the time required for steps such as firmware download, verification, flashing, and rebooting during the upgrade process.

[0005] Therefore, how to shorten the time required for firmware flashing has become an urgent problem to be solved. Summary of the Invention

[0006] This application provides a data flashing method, apparatus, electronic device, and storage medium, which can shorten the time required for firmware flashing.

[0007] Firstly, a data flashing method is provided, which is applied to an electronic control unit. The storage unit of the electronic control unit includes a cache area and a target area. The method includes: obtaining the target firmware to be flashed and storing the target firmware in the cache area; wherein the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area; reading data different from the backup firmware from the cache area as the data to be flashed; and flashing the data to be flashed to the target area.

[0008] The above technical solution reduces the amount of data to be written by setting a cache area and a target area in the electronic control unit, storing the target firmware of a higher version in the cache area first, and then reading the data to be written from the cache area that is different from the backup firmware for writing, instead of writing the entire target firmware. This reduces the time required for firmware writing.

[0009] In conjunction with the first aspect, in some possible implementations, reading data different from the backup firmware from the cache area as the data to be flashed includes: calculating a first verification value based on the target firmware stored in the cache area, and calculating a second verification value based on the backup firmware stored in the target area; and reading data different from the backup firmware from the cache area as the data to be flashed based on the first verification value and the second verification value.

[0010] The above technical solution calculates the first and second verification values ​​based on the target firmware and backup firmware stored in the cache area, and determines the data to be flashed based on these two verification values. This ensures the accuracy of the electronic control unit flashing process and improves the flashing success rate.

[0011] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target firmware is stored in the cache area in units of pages; a first checksum is calculated based on the target firmware stored in the cache area, and a second checksum is calculated based on the backup firmware stored in the target area, including: traversing the data of each page in the cache area in sequence; for the current page that has been traversed, calculating the first checksum of the data of the current page, and calculating the second checksum of the target data in the target area; wherein, the target data is the data in the target area corresponding to the address of the current page; based on the first checksum and the second checksum, reading data different from the backup firmware from the cache area as data to be flashed, including: for the current page that has been traversed, if it is determined that the first checksum and the second checksum are different, then the data of the current page is used as data to be flashed.

[0012] The above technical solution, during the traversal of data on each page of the cache area, calculates a first checksum for the current page's data and a second checksum for the data corresponding to the current page's address in the backup firmware. By comparing the first and second checksums, it determines whether the current page's data can be used as data to be flashed. This method avoids comparing data one by one in the cache area, thus improving the efficiency of determining the data to be flashed.

[0013] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target data is stored in a target sub-region of the target region; if it is determined that the first verification value and the second verification value are different, the method further includes: clearing the target data from the target sub-region; and writing the data to be written to the target region, including: for the current page that has been traversed, after clearing the target data, writing the data of the current page as the data to be written to the target sub-region.

[0014] The above technical solution, when the first checksum and the second checksum are different, first clears the target data, creating a clean and interference-free environment for accurately writing new data later. This avoids the influence of old data on new data, ensuring the accuracy and integrity of the writing process. Data for the current page is read from the cache area and accurately written to the target area corresponding to the current page address. This page-by-page, address-based writing method allows for data operation in relatively independent and ordered units, reducing operational complexity. Simultaneously, address-based writing ensures that data is accurately placed in the target sub-area (i.e., the area in the target area corresponding to the current page address). This writing method not only improves the accuracy and reliability of the writing process but also ensures the stable and reliable operation of the electronic control unit.

[0015] Combining the first aspect and the above implementation methods, in some possible implementation methods, obtaining the target firmware to be flashed and storing the target firmware in the cache area includes: receiving the target firmware sent by the diagnostic tool; verifying the target firmware; and storing the target firmware in the cache area if the verification of the target firmware passes.

[0016] In the process of acquiring the target firmware to be flashed and storing it in the cache area, the above technical solution first receives the target firmware sent by the diagnostic tool. As a reliable sender, the diagnostic tool ensures the initial integrity and source accuracy of the transmitted target firmware. Then, the target firmware is verified. Verification can promptly detect errors, damage, or tampering that may occur in the target firmware during transmission. Only when the verification passes is the target firmware stored in the cache area, thereby effectively avoiding storing problematic data in the cache area and preventing subsequent flashing failures due to erroneous data.

[0017] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target firmware includes multiple sub-firmware, which are obtained by the diagnostic instrument based on the target data length, which is the maximum length of data that the electronic control unit can receive at one time.

[0018] The above technical solution divides the data based on the maximum length of data that the electronic control unit (ECU) can receive in a single transmission. This division standard closely matches the actual data receiving capability of the ECU. Since the ECU has limitations in data reception, the amount of data it can process in a single transmission is fixed. If a target firmware file is transmitted too large at once, the ECU may not be able to receive and process it correctly, leading to transmission errors. By dividing the target firmware into multiple sub-firmware files, each sub-firmware's size falling within the range of data that the ECU can receive in a single transmission, it can be ensured that each sub-firmware file can be accurately and completely received by the ECU, thereby improving the stability and reliability of data transmission.

[0019] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target firmware is verified, and if the target firmware passes the verification, it is stored in the cache area. This includes: traversing each sub-firmware in turn; for the currently traversed sub-firmware, calculating the third verification value corresponding to the sub-firmware, determining whether the third verification value is equal to the preset verification value corresponding to the sub-firmware, and if the third verification value is equal to the preset verification value, then storing the sub-firmware in the cache area; wherein, the preset verification value is pre-calculated by the diagnostic instrument and sent to the electronic control unit.

[0020] The above technical solution iterates through each sub-firmware sequentially. This step-by-step processing ensures that every part of the data in the target firmware is meticulously checked, leaving no sub-firmware unchecked. For the currently traversed sub-firmware, its corresponding third checksum is calculated and compared to a preset checksum. The preset checksum is pre-calculated by the diagnostic tool and sent to the electronic control unit. If the third checksum equals the preset checksum, it indicates that the data of the current sub-firmware has not been erroneous or corrupted during transmission, and storing it in the cache area is safe and reliable. This verification mechanism effectively filters out problematic sub-firmware, preventing erroneous data from entering the cache area. This ensures that subsequent flashing operations are based on accurate data, thereby improving the stability and success rate of the entire firmware flashing process.

[0021] Secondly, a data flashing device is provided, which is applied to an electronic control unit. The storage unit of the electronic control unit includes a cache area and a target area. The device includes: an acquisition module for acquiring the target firmware to be flashed and storing the target firmware in the cache area; wherein the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area; a reading module for reading data different from the backup firmware from the cache area as the data to be flashed; and a flashing module for flashing the data to be flashed to the target area.

[0022] In conjunction with the second aspect, in some implementations of the second aspect, the reading module is specifically used to: read data different from the backup firmware from the cache area as data to be flashed, including: calculating a first verification value based on the target firmware stored in the cache area, and calculating a second verification value based on the backup firmware stored in the target area; and reading data different from the backup firmware from the cache area as data to be flashed based on the first verification value and the second verification value.

[0023] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the target firmware is stored in a cache area in units of pages; the reading module is specifically used for: calculating a first verification value based on the target firmware stored in the cache area, and calculating a second verification value based on the backup firmware stored in the target area, including: traversing the data of each page in the cache area in sequence; for the current page that has been traversed, calculating the first verification value of the data of the current page, and calculating the second verification value of the target data in the target area; wherein, the target data is the data in the target area corresponding to the address of the current page; and reading data different from the backup firmware from the cache area as data to be flashed based on the first verification value and the second verification value, including: for the current page that has been traversed, if it is determined that the first verification value and the second verification value are different, then the data of the current page is used as data to be flashed.

[0024] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the target data is stored in a target sub-region of the target region; the reading module is specifically used for: if it is determined that the first verification value and the second verification value are different, the method further includes: clearing the target data from the target sub-region; and writing the data to be written to the target region, including: for the current page that has been traversed, after clearing the target data, writing the data of the current page as the data to be written to the target sub-region.

[0025] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the acquisition module is specifically used to: acquire the target firmware to be flashed and store the target firmware in the cache area, including: receiving the target firmware sent by the diagnostic instrument; verifying the target firmware, and storing the target firmware in the cache area if the target firmware passes the verification.

[0026] Combining the second aspect and the above implementation methods, in some implementation methods of the second aspect, the target firmware includes multiple sub-firmware, which are obtained by the diagnostic instrument based on the target data length, where the target data length is the maximum length of data that the electronic control unit can receive at one time.

[0027] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the acquisition module is specifically used to: verify the target firmware, and if the target firmware passes the verification, store the target firmware in the cache area, including: traversing each sub-firmware sequentially; for the currently traversed sub-firmware, calculating the third verification value corresponding to the sub-firmware, determining whether the third verification value is equal to the preset verification value corresponding to the sub-firmware, and if the third verification value is equal to the preset verification value, storing the sub-firmware in the cache area; wherein, the preset verification value is pre-calculated by the diagnostic instrument and sent to the electronic control unit.

[0028] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0029] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0030] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0031] Figure 1 This is a schematic flowchart illustrating a data writing method for an electronic control unit provided in an embodiment of this application.

[0032] Figure 2 This is an interactive diagram of a data writing method for an electronic control unit provided in an embodiment of this application.

[0033] Figure 3 This is a schematic diagram of the structure of a data writing device for an electronic control unit provided in an embodiment of this application.

[0034] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0037] Currently, the ECU (Electronic Control Unit) is the core control component of a vehicle, responsible for performing various complex control tasks. In order to ensure the continuous improvement of vehicle performance and functional iteration, it is necessary to regularly update and upgrade the software in the ECU control unit.

[0038] ECU software upgrades are primarily achieved through OTA (Over-The-Air) or local methods, which involves flashing the new firmware version to the ECU's storage unit. Currently, most ECUs use an MCU (Microcontroller Unit) as their core processor, which integrates Flash memory (i.e., storage unit) to store the firmware.

[0039] The aforementioned storage unit may include three storage areas: area A, area B, and a cache area. Area A stores the currently running firmware, which is the firmware currently running in the electronic control unit. Area B stores backup firmware. The cache area is used to temporarily store new firmware versions to be flashed obtained from the diagnostic tool, and to flash the new firmware versions to be flashed to area B when the vehicle is in a safe state.

[0040] When the vehicle's storage unit is initialized and flashed at the factory, the firmware versions stored in areas A and B are the same. During subsequent firmware flashing, areas A and B are flashed alternately in a loop.

[0041] Specifically, if the firmware versions in regions A and B are the same, and the vehicle selects the firmware in region A to run, then region A is the running region, and region B will serve as the backup region. Therefore, the target firmware needs to be flashed to region B. After flashing, the firmware version in region B will be higher than the firmware version in region A. In this case, the vehicle needs to select the firmware in region B to run. At this time, region B is the running region, and region A will serve as the backup region. When flashing firmware again in the future, the higher version firmware needs to be flashed to region A, thus achieving cyclical alternation of flashing.

[0042] Given that the primary reasons for firmware changes are usually bug fixes and the addition of new features, both of which often involve partial model or code modifications, it's worth noting that when compiling models or code to generate new firmware versions, the amount of change in a single firmware version is typically less than 30%. Furthermore, as vehicle functions continue to increase, the firmware size of individual electronic control units is also constantly growing. In addition, firmware flashing is relatively slow. Therefore, if the entire firmware is still completely flashed using existing technology, it will directly lead to a prolonged time required for firmware download, verification, flashing, and rebooting during the upgrade process.

[0043] Therefore, how to shorten the time required for firmware flashing has become an urgent problem to be solved.

[0044] To at least address the aforementioned issues, this application provides a data flashing method for an electronic control unit (ECU), which can shorten the time required for firmware flashing.

[0045] Figure 1 This is a schematic flowchart illustrating a data writing method for an electronic control unit provided in an embodiment of this application.

[0046] For example, such as Figure 1 As shown, the method 100 includes: Step 101: Obtain the target firmware to be flashed and store it in the cache area; wherein, the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area.

[0047] Step 102: Read data from the cache area that is different from the backup firmware as the data to be flashed.

[0048] Step 103: Write the data to be written to the target area.

[0049] In this embodiment, by setting a cache area and a target area in the electronic control unit, storing the target firmware of a higher version in the cache area first, and then reading the data to be flashed from the cache area that is different from the backup firmware for flashing, instead of flashing the entire target firmware, the amount of data to be flashed can be reduced, thereby shortening the time required for firmware flashing.

[0050] The following is about Figure 1 The implementation of each step in the illustrated embodiment will be explained in detail.

[0051] For step 101, it can be understood that the target firmware to be flashed refers to the latest version of the firmware. The version of the target firmware is not only higher than the version of the currently running firmware in the running area, but also higher than the version of the backup firmware in the backup area (i.e., the target area).

[0052] To obtain the target firmware to be flashed, the ECU can establish a connection with the diagnostic tool via the CAN bus (Controller Area Network). Once the connection is successfully established, the diagnostic tool sends the target firmware to the ECU based on the UDS (Unified Diagnostic Services) protocol. In practical applications, the diagnostic tool can send the target firmware to the ECU while the vehicle is powered on to ensure accurate reception of the target firmware. When the ECU receives the target firmware, it can temporarily store it in a cache area.

[0053] In some embodiments, obtaining the target firmware to be flashed and storing the target firmware in a cache area includes: receiving the target firmware sent by a diagnostic tool; verifying the target firmware; and storing the target firmware in the cache area if the verification passes.

[0054] Understandably, when the ECU receives the target firmware, it can also verify the target firmware. Only the data in the target firmware that passes the verification can be temporarily stored in the cache area to ensure the consistency between the firmware data sent by the diagnostic tool and the firmware data received by the ECU.

[0055] In the process of acquiring the target firmware to be flashed and storing it in the cache area, the above technical solution first receives the target firmware sent by the diagnostic tool. As a reliable sender, the diagnostic tool ensures the initial integrity and source accuracy of the transmitted target firmware. Then, the target firmware is verified. Verification can promptly detect errors, damage, or tampering that may occur in the target firmware during transmission. Only when the verification passes is the target firmware stored in the cache area, thereby effectively avoiding storing problematic data in the cache area and preventing subsequent flashing failures due to erroneous data.

[0056] In practical applications, considering the limitation of the maximum length of data that an ECU can receive at one time, the target firmware can be divided into multiple sub-firmware, and the diagnostic tool can send one sub-firmware at a time.

[0057] In some embodiments, the target firmware includes multiple sub-firmware, which are obtained by the diagnostic instrument based on the target data length, which is the maximum length of data that the electronic control unit can receive at one time.

[0058] Understandably, the diagnostic tool, based on the UDS protocol, first obtains the maximum length of data that the ECU can receive at a time from the ECU, and then divides the target firmware into multiple sub-firmware based on this maximum length. When the diagnostic tool sends the target firmware to the ECU, it can send one sub-firmware at a time. If the ECU receives multiple sub-firmware, it can link them together according to their address order.

[0059] The following example illustrates how to segment the target firmware based on the maximum length of data that an ECU can receive at one time.

[0060] For example, assuming the overall size of the target firmware is 3MB and the maximum length of data that the ECU can receive at one time is 3968 bytes, by calculating the quotient of 3MB (i.e. 3145728 bytes) and 3968 bytes, it can be calculated that the target firmware needs to be divided into 793 (3145728 / 3968≈793) sub-firmware.

[0061] The aforementioned sub-firmware can also be understood as a firmware block, which refers to a fixed-size data unit in the process of data storage or data transmission.

[0062] The maximum length of data that each ECU can receive at one time is different. In practical applications, this maximum length can be calculated based on the actual parameters of the ECU.

[0063] The above technical solution divides the data based on the maximum length of data that the electronic control unit (ECU) can receive in a single transmission. This division standard closely matches the actual data receiving capability of the ECU. Since the ECU has limitations in data reception, the amount of data it can process in a single transmission is fixed. If a target firmware file is transmitted too large at once, the ECU may not be able to receive and process it correctly, leading to transmission errors. By dividing the target firmware into multiple sub-firmware files, each sub-firmware's size falling within the range of data that the ECU can receive in a single transmission, it can be ensured that each sub-firmware file can be accurately and completely received by the ECU, thereby improving the stability and reliability of data transmission.

[0064] The following section will explain in detail how to verify the data in multiple sub-firmwares separately.

[0065] In some embodiments, verifying the target firmware and storing it in a cache area if the target firmware passes verification includes: traversing each sub-firmware sequentially; for the currently traversed sub-firmware, calculating the third verification value corresponding to the sub-firmware, determining whether the third verification value is equal to the preset verification value corresponding to the sub-firmware, and storing the sub-firmware in the cache area if the third verification value is equal to the preset verification value; wherein the preset verification value is pre-calculated by the diagnostic instrument and sent to the electronic control unit.

[0066] It is understandable that the aforementioned third check value is calculated by the ECU based on the data in the currently traversed sub-firmware; that is, the aforementioned third check value is calculated in the ECU.

[0067] The aforementioned preset verification value is calculated by the diagnostic tool based on the data in each sub-firmware. In other words, the aforementioned preset verification value is calculated in the diagnostic tool, and the diagnostic tool sends the preset verification value corresponding to each sub-firmware together with each sub-firmware to the ECU.

[0068] Both the third verification value and the preset verification value mentioned above can be understood as hash values.

[0069] When the ECU receives multiple sub-firmware, it iterates through them sequentially according to their addresses. For each sub-firmware, a third checksum is calculated, and the third checksum is compared to the preset checksum. If they are equal, it means that no data loss or tampering occurred during transmission, indicating that the sub-firmware received by the ECU is consistent with the one sent by the diagnostic tool. In this case, the sub-firmware can be retained and stored in the buffer area. If they are not equal, it means that data loss or tampering occurred during transmission, indicating that the sub-firmware received by the ECU is inconsistent with the one sent by the diagnostic tool. In this case, the sub-firmware is not retained.

[0070] The following section will continue to use the example of the target firmware being divided into 793 sub-firmware units to explain in detail how to verify the sub-firmware units.

[0071] For example, suppose the diagnostic tool sends 793 sub-firmware units and their corresponding preset check values ​​to the ECU. Therefore, the ECU theoretically also receives the 793 sub-firmware units and their corresponding preset check values. In this case, the ECU can check the 793 sub-firmware units in address order.

[0072] When the ECU verifies the first sub-firmware, it calculates the hash value (i.e. the third verification value) corresponding to the first sub-firmware, and determines whether the third verification value is equal to the preset verification value corresponding to the first sub-firmware. If they are equal, the first sub-firmware is stored in the cache area; if they are not equal, the first sub-firmware is not stored in the cache area. When the ECU verifies the second sub-firmware, it calculates the hash value (i.e. the third verification value) corresponding to the second sub-firmware, and determines whether the third verification value is equal to the preset verification value corresponding to the second sub-firmware. If they are equal, the second sub-firmware is stored in the cache area; if they are not equal, the second sub-firmware is not stored in the cache area. Repeat the above operation until 793 sub-firmware verifications are completed. After verification, the verified sub-firmware are stored in the cache area in address order.

[0073] The above technical solution iterates through each sub-firmware sequentially. This step-by-step processing ensures that every part of the data in the target firmware is meticulously checked, leaving no sub-firmware unchecked. For the currently traversed sub-firmware, its corresponding third checksum is calculated and compared to a preset checksum. The preset checksum is pre-calculated by the diagnostic tool and sent to the electronic control unit. If the third checksum equals the preset checksum, it indicates that the data of the current sub-firmware has not been erroneous or corrupted during transmission, and storing it in the cache area is safe and reliable. This verification mechanism effectively filters out problematic sub-firmware, preventing erroneous data from entering the cache area. This ensures that subsequent flashing operations are based on accurate data, thereby improving the stability and success rate of the entire firmware flashing process.

[0074] For step 102, it is understood that after multiple sub-firmwares are stored in the cache area, the ECU reads data that is different from the backup firmware from the cache area and uses this different data as the data to be flashed.

[0075] In some embodiments, reading data different from the backup firmware from the cache region as data to be flashed includes: calculating a first verification value based on the target firmware stored in the cache region, and calculating a second verification value based on the backup firmware stored in the target region; and reading data different from the backup firmware from the cache region as data to be flashed based on the first verification value and the second verification value.

[0076] Understandably, the ECU calculates a first checksum based on the target firmware stored in the cache area, and a second checksum based on the backup firmware. Then, based on the first and second checksums, it determines the data to be flashed. Both the first and second checksums can be understood as hash values.

[0077] The above technical solution calculates the first and second verification values ​​based on the target firmware and backup firmware stored in the cache area, and determines the data to be flashed based on these two verification values. This ensures the accuracy of the electronic control unit flashing process and improves the flashing success rate.

[0078] In some embodiments, the target firmware is stored in a cache area in units of pages; calculating a first checksum based on the target firmware stored in the cache area and calculating a second checksum based on the backup firmware stored in the target area includes: sequentially traversing the data of each page in the cache area; for the current page being traversed, calculating the first checksum of the data of the current page and calculating the second checksum of the target data in the target area; wherein, the target data is the data in the target area corresponding to the address of the current page; and reading data different from the backup firmware from the cache area as data to be flashed based on the first checksum and the second checksum, including: for the current page being traversed, if it is determined that the first checksum and the second checksum are different, then the data of the current page is used as data to be flashed.

[0079] Understandably, in practical applications, the target firmware mentioned above needs to be stored in the cache area in units of pages. That is, the target firmware is divided into multiple fixed-size pages, and each page is stored in the cache area as an independent unit.

[0080] During the process of determining the data to be flashed, each page in the cache area is traversed sequentially. For each page traversed, the first checksum of the current page's data is calculated, and the second checksum of the data corresponding to the current page's address in the backup firmware (i.e., the target data) is also calculated. The first and second checksums are then compared to determine if they are equal. If they are equal, it means that the data of the current page in the cache area is consistent with the data corresponding to the current page's address in the backup firmware. To reduce the flashing workload, it is not necessary to flash the data of the current page to the area corresponding to the current page's address in the target area. Therefore, the data of the current page is not considered as the data to be flashed. If they are not equal, it means that the data of the current page in the cache area is inconsistent with the data corresponding to the current page's address in the backup area. In this case, the data of the current page is flashed to the area corresponding to the current page's address in the target area. Therefore, the data of the current page is considered as the data to be flashed.

[0081] The following section will continue to use the example of the target firmware being divided into 793 sub-firmware to explain in detail how to determine the data to be flashed.

[0082] For example, when the ECU calculates the hash value (i.e., the first check value) of the data on the first page of the first sub-firmware in the cache area, the ECU also needs to calculate the hash value (i.e., the second check value) of the target data in the backup firmware, and determine whether the first check value is equal to the second check value. If they are equal, the data on the first page of the first sub-firmware in the cache area will not be used as the data to be flashed. If they are not equal, the data on the first page of the first sub-firmware in the cache area will be used as the data to be flashed. When the ECU calculates the hash value (i.e., the first check value) of the data on the second page of the first sub-firmware in the cache area, the ECU also needs to calculate the hash value (i.e., the second check value) of the target data in the backup firmware, and determine whether the first check value is equal to the second check value. If they are equal, the data on the second page of the first sub-firmware in the cache area will not be used as the data to be flashed. If they are not equal, the data on the second page of the first sub-firmware in the cache area will be used as the data to be flashed. Repeat the above operation until the data judgment for each page of the 793 sub-firmware is completed.

[0083] The above technical solution, during the traversal of data on each page of the cache area, calculates a first checksum for the current page's data and a second checksum for the data corresponding to the current page's address in the backup firmware. By comparing the first and second checksums, it determines whether the current page's data can be used as data to be flashed. This method avoids comparing data one by one in the cache area, thus improving the efficiency of determining the data to be flashed.

[0084] For step 103, it is understood that in order to ensure the successful completion of the flashing operation, the data to be flashed must be written to the target area while the vehicle is in a safe state (e.g., stationary).

[0085] In some embodiments, the target data is stored in a target sub-region within the target region; if it is determined that the first verification value and the second verification value are different, the method further includes: clearing the target data from the target sub-region; and writing the data to be written to the target region, including: for the current page that has been traversed, after clearing the target data, writing the data of the current page as the data to be written to the target sub-region.

[0086] Understandably, if the first checksum and the second checksum are different, the data corresponding to the address of the current page in the backup firmware must be cleared first, then the data of the current page must be read from the cache area, and finally the data of the current page must be written to the target sub-area (i.e., the area in the target area corresponding to the address of the current page).

[0087] If the first checksum is determined to be the same as the second checksum, then the data of the current page will not be written to the target sub-area as the data to be written.

[0088] The following section will continue to use the example of the target firmware being divided into 793 sub-firmware to detail the specific flashing operation.

[0089] For example, for the data of the first page in the first sub-firmware in the cache area, if it is determined that the first check value and the second check value are different, the data of the first page in the first sub-firmware in the target area is cleared, and the data of the first page in the first sub-firmware in the cache area is read, and then the data of the first page in the first sub-firmware in the cache area is written to the target sub-area. For the data on page 2 of the first sub-firmware in the cache area, if it is determined that the first check value and the second check value are different, the data on page 2 of the first sub-firmware in the target area is cleared, and the data on page 2 of the first sub-firmware in the cache area is read, and then the data on page 2 of the first sub-firmware in the cache area is written to the target sub-area. Repeat the above operation until the data for each page of the 793 sub-firmware is completely written.

[0090] After the flashing process is complete, the ECU needs to be restarted to ensure that the ECU firmware upgrade is finished.

[0091] Furthermore, after rebooting the ECU, the firmware region needs to be switched to ensure the vehicle runs with the latest firmware version. Specifically, assuming the vehicle selects firmware from region A before flashing, region A is the running region, and region B serves as the backup region. In this case, the target firmware needs to be flashed to region B. After flashing, the firmware version in region B will be higher than that in region A. Therefore, after rebooting the ECU, the vehicle must select firmware from region B. Region B will then be the running region, and region A will serve as the backup region. Subsequent firmware flashes will require flashing a higher version of the firmware to region A.

[0092] The above technical solution, when the first checksum and the second checksum are different, first clears the target data, creating a clean and interference-free environment for accurately writing new data later. This avoids the influence of old data on new data, ensuring the accuracy and integrity of the writing process. Data for the current page is read from the cache area and accurately written to the target area corresponding to the current page address. This page-by-page, address-based writing method allows for data operation in relatively independent and ordered units, reducing operational complexity. Simultaneously, address-based writing ensures that data is accurately placed in the target sub-area (i.e., the area in the target area corresponding to the current page address). This writing method not only improves the accuracy and reliability of the writing process but also ensures the stable and reliable operation of the electronic control unit.

[0093] Figure 2 This is an interactive diagram of a data writing method for an electronic control unit provided in an embodiment of this application.

[0094] For example, such as Figure 2 As shown, the method 200 includes: Step 201: The ECU sends the maximum length of data that the ECU can receive in a single transaction to the diagnostic tool.

[0095] Step 202: Based on the maximum length of data that the ECU can receive at one time, the diagnostic tool performs block processing on the target firmware to obtain multiple sub-firmware.

[0096] Step 203: The diagnostic instrument calculates the preset verification value corresponding to each sub-firmware in sequence.

[0097] Step 204: The diagnostic tool sends each sub-firmware and its corresponding preset verification value to the ECU.

[0098] Step 205: The ECU traverses each sub-firmware and calculates the third check value corresponding to each sub-firmware.

[0099] Step 206: For the currently traversed sub-firmware, the ECU determines whether the third verification value is equal to the preset verification value. If yes, proceed to step 207; otherwise, proceed to step 208.

[0100] Step 207: The ECU stores the currently traversed sub-firmware in the cache area.

[0101] Step 208: The ECU determines whether the currently traversed sub-firmware is the last sub-firmware. If so, proceed to step 209; otherwise, proceed to step 205.

[0102] Step 209: The ECU iterates through the data of each page in the cache area in turn.

[0103] Step 210: For the current page that is traversed, the ECU calculates the first check value of the data on the current page and calculates the second check value of the target data in the backup firmware; wherein, the target data is the data in the backup firmware corresponding to the address of the current page.

[0104] Step 211: For the current page being traversed, the ECU determines whether the first checksum and the second checksum are the same. If they are, proceed to step 213; otherwise, proceed to step 212.

[0105] Step 212: The ECU clears the target data, reads the data of the current page from the cache area, and writes the data of the current page to the area in the target area corresponding to the address of the current page.

[0106] Step 213: The ECU determines whether the current page is the last page in the cache area. If so, proceed to step 214; otherwise, proceed to step 210.

[0107] Step 214, restart the ECU.

[0108] In summary, the data writing method for an electronic control unit provided in this application has the following beneficial effects: First, the diagnostic tool divides the target firmware into multiple sub-firmware based on the maximum length of data received by the ECU in a single transmission. This measure fully considers the ECU's data receiving capabilities, ensuring that each sub-firmware can be effectively received by the ECU and avoiding reception failure due to excessive data volume. The ECU sequentially traverses each sub-firmware and calculates its corresponding third checksum, comparing it with a preset checksum. This verification process accurately determines whether data errors or corruption have occurred in the sub-firmware during transmission. Only sub-firmware that passes the verification is stored in the cache area, effectively ensuring the accuracy and integrity of the data in the cache area. Subsequently, the ECU traverses each page of data in the cache area and calculates the first checksum of the current page's data and the second checksum of the corresponding target data in the backup firmware. By comparing these two checksums, the ECU can determine whether the current page's data is consistent with the target data in the backup firmware. If they are consistent, no flashing operation is required, avoiding unnecessary repetitive operations and improving processing efficiency. If they are inconsistent, the ECU first clears the target data and then reads the current page's data from the cache area for flashing, ensuring the accuracy of the data in the target area. This method effectively improves the stability and success rate of ECU firmware flashing, ensuring the normal operation of the ECU.

[0109] Figure 3 This is a schematic diagram of the structure of a data writing device for an electronic control unit provided in an embodiment of this application.

[0110] For example, such as Figure 3 As shown, the device 300 includes: The acquisition module 301 is used to acquire the target firmware to be flashed and store the target firmware in the cache area; wherein the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area.

[0111] The read module 302 is used to read data that is different from the backup firmware from the cache area as the data to be flashed.

[0112] The flashing module 303 is used to flash the data to be flashed to the target area.

[0113] In one possible implementation, the reading module is specifically used to: read data different from the backup firmware from the cache area as the data to be flashed, including: calculating a first verification value based on the target firmware stored in the cache area, and calculating a second verification value based on the backup firmware stored in the target area; and reading data different from the backup firmware from the cache area as the data to be flashed based on the first verification value and the second verification value.

[0114] In one possible implementation, the target firmware is stored in a cache area in units of pages. The reading module is specifically used for: calculating a first checksum based on the target firmware stored in the cache area, and calculating a second checksum based on the backup firmware stored in the target area, including: sequentially traversing the data of each page in the cache area; for the current page being traversed, calculating the first checksum of the data on the current page, and calculating the second checksum of the target data in the target area; wherein the target data is the data in the target area corresponding to the address of the current page; and reading data different from the backup firmware from the cache area as data to be flashed based on the first checksum and the second checksum, including: for the current page being traversed, if it is determined that the first checksum and the second checksum are different, then the data of the current page is used as data to be flashed.

[0115] In one possible implementation, the target data is stored in a target sub-region within the target region; the reading module is specifically used to: if it is determined that the first verification value and the second verification value are different, the method further includes: clearing the target data from the target sub-region; and writing the data to be written to the target region, including: for the current page that has been traversed, after clearing the target data, writing the data of the current page as the data to be written to the target sub-region.

[0116] In one possible implementation, the acquisition module is specifically used to: acquire the target firmware to be flashed and store the target firmware in a cache area, including: receiving the target firmware sent by the diagnostic tool; verifying the target firmware, and storing the target firmware in the cache area if the verification passes.

[0117] In one possible implementation, the target firmware includes multiple sub-firmware, which are obtained by the diagnostic instrument based on the target data length, which is the maximum length of data that the electronic control unit can receive at one time.

[0118] In one possible implementation, the acquisition module is specifically used to: verify the target firmware, and if the target firmware passes the verification, store the target firmware in a cache area, including: traversing each sub-firmware sequentially; for the currently traversed sub-firmware, calculating the third verification value corresponding to the sub-firmware, determining whether the third verification value is equal to the preset verification value corresponding to the sub-firmware, and if the third verification value is equal to the preset verification value, storing the sub-firmware in the cache area; wherein, the preset verification value is pre-calculated by the diagnostic instrument and sent to the electronic control unit.

[0119] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0120] For example, such as Figure 4As shown, the electronic device 400 includes a memory 401 and a processor 402. The memory 401 stores executable program code 6011, and the processor 402 is used to call and execute the executable program code 4011 to perform a data writing method.

[0121] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a data writing method provided in embodiments of this application.

[0122] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0123] When each functional module is divided according to its corresponding function, the device may also include an acquisition module, a reading module, and a writing module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0124] It should be understood that the apparatus provided in this embodiment is used to execute the above-described data writing method, and therefore can achieve the same effect as the above-described implementation method.

[0125] When using integrated units, the device may include a processing module and a storage module. When applied to an electronic device, the processing module can be used to control and manage the operation of the electronic device. The storage module can be used to support the execution of relevant program code by the electronic device.

[0126] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0127] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a data writing method provided in the above embodiments.

[0128] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement a data writing method provided in the above embodiment.

[0129] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a data writing method provided in the above embodiment.

[0130] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0131] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0133] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included 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 writing data to an electronic control unit, characterized in that, The storage unit of the electronic control unit includes a cache area and a target area, and the method includes: Obtain the target firmware to be flashed and store the target firmware in the cache area; wherein the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area; Read data that is different from the backup firmware from the cache area as the data to be flashed; The data to be written is written to the target area.

2. The method according to claim 1, characterized in that, The step of reading data different from the backup firmware from the cache area as the data to be flashed includes: Calculate a first verification value based on the target firmware stored in the cache area, and calculate a second verification value based on the backup firmware stored in the target area; Based on the first verification value and the second verification value, data different from the backup firmware is read from the cache area as the data to be flashed.

3. The method according to claim 2, characterized in that, The target firmware is stored in the cache area in units of pages; The step of calculating a first verification value based on the target firmware stored in the cache area, and calculating a second verification value based on the backup firmware stored in the target area, includes: The data of each page in the cache area is traversed sequentially; For the current page that is traversed, calculate the first check value of the data on the current page, and calculate the second check value of the target data in the target area; wherein, the target data is the data in the target area corresponding to the address of the current page; The step of reading data different from the backup firmware from the cache area as the data to be flashed, based on the first verification value and the second verification value, includes: For the current page that is traversed, if it is determined that the first verification value is different from the second verification value, then the data of the current page is used as the data to be refreshed.

4. The method according to claim 3, characterized in that, The target data is stored in a target sub-region within the target region; if it is determined that the first verification value and the second verification value are different, the method further includes: Remove the target data from the target sub-region; The step of writing the data to be written to the target area includes: For the current page that is traversed, after clearing the target data, the data of the current page is written to the target sub-region as the data to be written.

5. The method according to claim 1, characterized in that, The step of obtaining the target firmware to be flashed and storing the target firmware in the cache area includes: Receive the target firmware sent by the diagnostic instrument; The target firmware is verified, and if the target firmware passes the verification, the target firmware is stored in the cache area.

6. The method according to claim 5, characterized in that, The target firmware includes multiple sub-firmware, which are obtained by the diagnostic instrument based on the target data length. The target data length is the maximum length of data that the electronic control unit can receive at one time.

7. The method according to claim 6, characterized in that, The step of verifying the target firmware and storing the target firmware in the cache area if the verification passes includes: Each of the sub-firmware is traversed sequentially; For the currently traversed sub-firmware, calculate the third check value corresponding to the sub-firmware, and determine whether the third check value is equal to the preset check value corresponding to the sub-firmware. If the third check value is equal to the preset check value, then store the sub-firmware in the cache area; wherein, the preset check value is pre-calculated by the diagnostic instrument and sent to the electronic control unit.

8. A data writing device for an electronic control unit, characterized in that, The storage unit of the electronic control unit includes a cache area and a target area, and the device includes: An acquisition module is used to acquire the target firmware to be flashed and store the target firmware in the cache area; wherein the version of the target firmware is higher than the version of the backup firmware, and the backup firmware is stored in the target area; The reading module is used to read data that is different from the backup firmware from the cache area as data to be flashed; The write module is used to write the data to be written to the target area.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform 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, implements the method as described in any one of claims 1 to 7.

Images