ECU firmware upgrade method, apparatus, and system, vehicle, and storage medium

Abstract

The present application provides an ECU firmware upgrade method, apparatus, and system, a vehicle, and a computer readable storage medium. Data in a firmware package is divided into multiple data blocks, and each data block corresponds to an address segment of one storage block in a storage space of an ECU. The method comprises: writing each data block into the corresponding storage block in the storage space; receiving a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier; determining whether a write exception occurs to the storage block; and if it is determined that a write exception occurs to the storage block, determining a target data block on the basis of the storage block identifier in the storage response message, and re-writing the target data block into the storage block pointed to by the storage block identifier. According to the present application, when the writing process is interrupted, a storage block where the breakpoint is located can be determined, allowing for rewriting to the storage block and of subsequent data, thereby achieving breakpoint resume.

Description

ECU firmware upgrade method, device, system, vehicle, and storage medium Technical Field

[0001] The present application relates to the technical field of firmware upgrade, and in particular to an ECU firmware upgrade method, device, system, automobile, and computer-readable storage medium. Background Art

[0002] OTA (Over the Air, firmware over-the-air upgrade technology) is a technology that obtains firmware packages from cloud servers for firmware upgrades. Users can use OTA technology to update the vehicle's ECU (Electronic Control Unit) firmware anytime and anywhere, without having to drive the vehicle to a 4S store and return it to the manufacturer. Manufacturers can also use OTA technology to complete operations such as integrating new functions into the device, upgrading existing functions, and fixing problems, saving costs. However, in cases where the user's communication environment is poor or the user actively stops the firmware upgrade, the firmware upgrade process will be interrupted. The existing solution is to re-initiate the upgrade request and transmit the firmware package from the beginning, which cannot achieve breakpoint resumption. This will increase the time it takes for the device to upgrade the firmware through OTA technology, seriously affecting the user experience and even user safety.

[0003] Summary of the Invention

[0004] To overcome the problems existing in the related art, the present application provides an ECU firmware upgrade method, device, system, automobile and computer-readable storage medium.

[0005] According to a first aspect of an embodiment of the present application, a method for upgrading ECU firmware is provided, wherein data in a firmware package is divided into a plurality of data blocks, each data block corresponding to an address segment of a storage block in a storage space of the ECU, the method comprising:

[0006] Writing the data block into the corresponding storage block in the storage space;

[0007] receiving a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier;

[0008] Determining whether a write exception occurs in the storage block, wherein the write exception includes: a write exception determined based on the storage response message;

[0009] If it is determined that a write exception occurs in the storage block, a destination data block is determined based on the storage block identifier in the storage response message, and the destination data block is rewritten into the storage block pointed to by the storage block identifier.

[0010] According to a second aspect of an embodiment of the present application, a car is provided, wherein the car has an OTA master control and at least one ECU node, the ECU node has a storage space, the storage space includes multiple storage blocks, and the OTA master control is used to execute the method described in the first aspect.

[0011] According to a third aspect of an embodiment of the present application, an ECU firmware upgrade device is provided, wherein data in a firmware package is divided into multiple data blocks, each data block corresponding to an address segment of one of the storage blocks in the storage space of the ECU, and the device includes:

[0012] A data writing module, configured to write the data block into a corresponding storage block in the storage space;

[0013] A message receiving module, configured to receive a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier;

[0014] an abnormality detection module, configured to determine whether a write abnormality occurs in the storage block, wherein the write abnormality includes: a write abnormality determined based on the storage response message;

[0015] The breakpoint resume module is used to determine the destination data block based on the storage block identifier in the storage response message if it is determined that a write exception occurs to the storage block, and rewrite the destination data block into the storage block pointed to by the storage block identifier.

[0016] According to a fourth aspect of an embodiment of the present application, there is provided an ECU firmware upgrade system, the system comprising an OTA master control device and at least one ECU node, the ECU node having a storage space, the storage space comprising a plurality of storage blocks;

[0017] The OTA master control device includes:

[0018] processor;

[0019] A memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method according to the first aspect is implemented.

[0020] According to a fifth aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a program is stored, and when the program is executed by a processor, the operations in the method of the first aspect are implemented.

[0021] The technical solutions provided by the embodiments of the present application may have the following beneficial effects:

[0022] In an embodiment of the present application, the firmware package is first divided into multiple data blocks, and a correspondence between the data blocks and the storage blocks is established, and then the data blocks are written to the corresponding storage blocks in the storage space; thereafter, a storage response message returned by the storage space is received, and the storage response message carries a storage block identifier, which can be used to determine the storage block to which the breakpoint belongs and the corresponding data block; then, it is determined whether a write exception occurs in the storage block, wherein the write exception includes a write exception determined based on the storage response message; after determining that a write exception occurs and determining the location of the exception point, the destination data block can be determined based on the storage block identifier, and the destination data block can be rewritten into the storage block pointed to by the storage block identifier to achieve breakpoint resumption.

[0023] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0025] FIG1 is a flowchart of an ECU firmware upgrade method according to an exemplary embodiment of the present application.

[0026] FIG1A is an executable file shown in accordance with an exemplary embodiment of the present application.

[0027] FIG. 1B shows a programming status information file according to an exemplary embodiment of the present application.

[0028] FIG1C is a description information document shown in accordance with an exemplary embodiment of the present application.

[0029] FIG2 is a structural block diagram of a car according to an exemplary embodiment of the present application.

[0030] FIG3 is a block diagram of an apparatus for upgrading ECU firmware according to an exemplary embodiment of the present application.

[0031] FIG4 is a structural block diagram of an ECU firmware upgrade system according to an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0032] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0033] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0034] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0035] Next, the embodiments of the present application are described in detail.

[0036] Firmware refers to the device "driver" stored within a device. Through firmware, the operating system can implement specific machine operations according to standard device drivers. The firmware upgrade process refers to the process of upgrading the driver to improve device functionality. Typically, an ECU refers to an in-vehicle control unit, which generally consists of a microcontroller (MCU), memory (ROM, RAM), input / output interfaces (I / O), an analog-to-digital converter (A / D), and large-scale integrated circuits such as shaping and drivers. For users, upgrading the firmware of devices such as ECUs is very troublesome, and they can only take the device to a 4S store or return it to the manufacturer for a firmware upgrade. Therefore, the current common practice is to upgrade the firmware of in-vehicle devices based on OTA technology. This way, the firmware upgrade can be completed without significantly affecting the user's normal use.

[0037] However, if the user's communication environment is poor or the user actively stops the firmware upgrade, the firmware upgrade process will be interrupted. The existing solution is to re-initiate the upgrade request and transmit the firmware package from the beginning, which cannot achieve breakpoint resumption. This will increase the time it takes to upgrade the device's firmware through OTA technology, seriously affecting the user experience and even user safety.

[0038] Based on this, the present application proposes an ECU firmware upgrade method, as shown in FIG1 , which is a flowchart of an ECU firmware upgrade method according to an exemplary embodiment of the present application. The data in the firmware package is divided into multiple data blocks, each data block corresponding to an address segment of one of the storage blocks in the storage space of the ECU. The ECU firmware upgrade method disclosed in the present application may include the following S101-S104:

[0039] S101, writing a data block into a corresponding storage block in a storage space;

[0040] In this step, the firmware package can be obtained from the cloud server in advance. The firmware package is divided into multiple data blocks according to the size of the storage block and the writing order. The data blocks in the firmware package are then written into the storage blocks of the storage space accordingly. In order to better control the firmware upgrade process, a controller specifically used to control the firmware upgrade process is generally provided on the vehicle, which is called the OTA master. The OTA master can obtain the firmware package from the cloud server. Of course, the execution subject of obtaining the firmware package in this step can also be other devices on the vehicle that can communicate with the cloud server, and this application does not limit this.

[0041] According to one embodiment of the present application, the process of dividing the firmware package into multiple data blocks can be to directly establish a correspondence between any data and a storage block within the firmware package, and treat all data corresponding to the same storage block as a data block. The firmware package can also be divided into multiple small firmware packages, each of which can correspond to one or more storage blocks; when each small firmware package corresponds to multiple storage blocks, each small firmware package can be divided into multiple data blocks, each of which corresponds to a storage block. In this way, the data that needs to be written during each transmission process can be reduced by breaking the whole into parts, reducing the time required for a single write process and reducing the probability of interruption during the write process.

[0042] It is understood that each storage block corresponds to an address segment containing multiple addresses, and multiple data can be stored under each address. The above-mentioned "establishing a correspondence between any data and a storage block" can be: establishing a correspondence between any data and a storage block by specifying the storage address of the data. Therefore, the memory used in this application can be a storage space, which can be Flash or other non-volatile storage media that can specify the storage address of data, and this application does not impose any restrictions.

[0043] For example, the firmware package used in the method of the present application may include the executable file Hex as shown in Figure 1A. Wherein, Sector ID is the identifier of the storage block of the storage space such as the internal Flash of the MCU, and all data corresponding to the same storage block is a data block.

[0044] In the figure, Addr is the address of the storage block. As can be seen from the figure, one storage block corresponds to multiple Addrs. The multiple Addrs corresponding to the same storage block are the address segments of the corresponding storage block. Each address can be 16 bytes or 8 bytes. This application does not limit the space size of each address.

[0045] Data is the data carried in the firmware package for firmware upgrade. For example, Data in the figure is hexadecimal data. It can be understood that since the size of the firmware package is usually not an integer multiple of the storage block size, it is generally impossible to completely fill the last storage block. According to one embodiment of the present application, the vacancies can be filled with meaningless data (i.e., the data in the last two rows and the third to last row in the figure, for example, "FF" is used as meaningless data in the figure). It can be seen that the present application aligns the storage blocks by specifying the address of the data storage, and fills the vacancies with meaningless data to facilitate the division of data blocks, the generation of check codes or the performance of other operations.

[0046] It can be understood that the data corresponding to the Sector ID, Addr, Data, etc. shown in the figure are all exemplary. Those skilled in the art can freely determine the storage block number, address segment, data, etc. corresponding to the firmware package, and the specific content of the firmware package shown in the figure should not be regarded as a limitation to this application.

[0047] S102: Receive a storage response message returned by the storage space, where the storage response message carries a storage block identifier;

[0048] In this step, the storage response message includes at least a storage block identifier, and may also include other information that is helpful in determining whether the transmission is interrupted and the breakpoint location. This application does not impose any restrictions on this part of the content.

[0049] S103: Determine whether a write exception occurs in the storage block, wherein the write exception includes: a write exception determined based on a storage response message;

[0050] In this step, the OTA master can determine whether a write exception occurs based on the storage response message. Of course, the OTA master can also determine whether a write exception occurs based on other messages such as user operation requests. For example, it determines that a write exception occurs when it detects that the write process is interrupted by the user.

[0051] According to an embodiment disclosed in the present application, the storage response message carries at least any one of the following: a response duration or a first check code. The first check code is generated based on the data written to the storage block and is used to indicate that a write error has occurred in the storage block. Correspondingly, the anomaly determined based on the storage response message includes at least: the response duration of the storage response message exceeds a preset value or a write error has occurred in the storage block. The write error may further include: an error in the data written to the storage block or the storage block is not fully written.

[0052] According to an embodiment disclosed in the present application, in order to determine whether a storage block is not fully written, the programming status information ProgramInfo as shown in FIG1B can be stored outside the storage space of the ECU, such as in a memory such as EEPROM, DFLASH, etc. For each storage block, the above-mentioned programming information at least includes a Valid Flag and the above-mentioned first check code (the CRC check code is taken as an example in the figure). Among them, the Valid Flag is a special sequence used to characterize that the current storage block is fully written. By detecting the status of the storage block and whether the special sequence of the Valid Flag is present, it can be determined whether the storage block is fully written. When this storage block is full of data, the first check code corresponding to the current storage block is calculated and written into the above-mentioned programming status information file.

[0053] It is well known to those skilled in the art that a CRC check code is not the only check code that can be used to determine whether a write error has occurred in a storage block. The first check code can be a CRC check code, or other check codes such as a checksum, a parity check code, etc. Those skilled in the art are free to choose the type of check code to use, and this application does not impose any limitation thereto, and the CRC in FIG1B should not be considered as a limitation thereto.

[0054] In order to determine whether a write error occurs in a storage block, the firmware package used in this application may also include a description information document Hexinfo.txt. For example, the description information document used in this application may include the Sector ID, Addr, Size, a second check code (CRC is still used as an example in the figure), and other contents as shown in Figure 1C. Similarly, the CRC here should not be regarded as a limitation of this application.

[0055] Sector ID is the same as in the executable file above and is the identifier of the storage block. Addr can be the starting address of the storage block or the address segment of the storage block. Size is the number of addresses contained in the storage block or the size of the storage block.

[0056] Likewise, the specific contents of the firmware package shown in the figure should not be regarded as limiting the present application.

[0057] In addition, since the content of the above-mentioned description information document only has a descriptive function, when writing the firmware package to the ECU, only the data of the executable file can be written to the storage block, and the OTA master is responsible for reading the relevant content of the description information document from the firmware package; the data of the executable file can also be written to the storage block, and the content of the description information document can be written to other memories such as EEPROM and DFLASH. It can be understood that since there is no need to divide the description information document into multiple data blocks, there is no need to specify the address where the data in the document is stored, and further, there is no need to specify the memory for storing the document. It only needs to be distinguished from the memory for storing the executable file. According to one embodiment of the present application, the executable file can be written to the program Flash and the description information document can be written to the data Flash. The program Flash and the data Flash are different.

[0058] Based on the content of the above description information document, according to an embodiment disclosed in the present application, a method for determining whether a write error occurs in a storage block based on a storage response message may include the following S1031-S1032:

[0059] S1031. Obtain a second check code generated based on the data of the data block;

[0060] In this step, the OTA master control may obtain the second verification code from the firmware package, or may control the ECU to obtain the second verification code from the memory storing the description information document.

[0061] S1032: Compare the first check code and the second check code to see whether they are consistent, and determine whether a write error occurs in the storage block.

[0062] In this step, whether a write error occurs in the storage block is determined by comparing the first and second check codes to see if they are consistent. The first check code is generated based on the written data, and the second check code is generated based on the original data in the firmware package. Moreover, according to the above embodiment of the present application, each storage block corresponds to a first check code and a second check code.

[0063] It is understood that for comparison, the first check code should be generated using the same method and data as the second check code. The data used to generate the first and second check codes corresponding to Sector_m may be all data from Sector_n to Sector_m, or only the data corresponding to Sector_m.

[0064] The above process of determining whether a write error occurs in the storage block can be determined by the OTA master according to the description information document and the storage response message when writing, or it can be determined by the program when running the firmware program whether a write error occurs.

[0065] As is well known to those skilled in the art, a characteristic of storage spaces such as Flash is that only blank storage cells can be written to, so the existing data must be erased before writing. The smallest storage unit is a page, and multiple pages form a sector. Writing is done by page, and erasing is done by block. Therefore, when implementing breakpoint-resume transfer of a firmware package transferred to a storage space, whether the breakpoint location where the exception occurred is accurately located to the block or further to the page, the entire block's existing data must be completely erased when subsequently rewriting.

[0066] If breakpoints are specified at the page level, a write error must be checked every time a page is filled. Erasing is done block by block, so whether data is backed up and retransmitted for the current block, or backed up and retransmitted for the current page, the ECU will be burdened. Therefore, the solution in this application specifies only the breakpoint location at the block level, enabling breakpoint-resume transfers without placing a significant burden on the ECU.

[0067] According to one embodiment of the present application, a firmware package can be used to upgrade the firmware of an ECU node on a vehicle. A vehicle typically includes multiple ECU nodes, each with storage space. Each ECU node controls one or more functional modules. For example, ECU node A controls the vehicle's power system, ECU node B controls the vehicle's air conditioning, and ECU node C controls the vehicle's interior lighting.

[0068] Since the car needs to read data from the memory while driving, and writing and reading data simultaneously will put a heavy burden on the memory, continuing to upgrade the firmware while driving will affect the vehicle performance and even endanger the user's personal safety. Therefore, according to an embodiment disclosed in this application, when it is detected that the vehicle is in a driving state, the upgrade of ECU nodes with a preset importance level can be interrupted. The method may include the following S1033-S1035:

[0069] S1033. Determine the importance of the ECU node;

[0070] In this step, the importance of the ECU node currently being upgraded can be distinguished based on factors such as driving safety and user experience. According to the above embodiment of the present application, ECU node A controls the vehicle power system, and based on driving safety factors, its importance is considered important; ECU node C controls the interior lighting, and based on driving safety, user experience factors, its importance is considered unimportant. It can be understood that the factors used in this application to determine the importance of ECU nodes are not limited to the above-mentioned driving safety and user experience factors. Those skilled in the art can flexibly select the factors for determining the importance based on actual conditions.

[0071] S1034: Determine whether the vehicle is in a driving state.

[0072] In this step, in order to further avoid misjudgment and strike a balance between firmware upgrades and driving safety and user experience, it is possible to comprehensively judge whether the vehicle is currently in driving state based on information such as location, speed, acceleration, and whether there is someone in the main driver's seat.

[0073] S1035: When the vehicle is in driving state, interrupt the ECU node with a preset importance level.

[0074] Specifically, if it is detected that the importance of the current ECU node is important and the vehicle is in driving state, the writing process of the current ECU node can be interrupted to protect the safety of the user;

[0075] If it is detected that the importance of the current ECU node is not important, the current writing process can be continued without interruption regardless of whether the vehicle is in driving state, so that the firmware writing process can be continued while the vehicle is driving, thereby minimizing the time that the user cannot use the vehicle due to the need for firmware upgrade, and facilitating user use.

[0076] S104: If it is determined that a write exception occurs in the storage block, determine the destination data block based on the storage block identifier in the storage response message, and rewrite the destination data block into the storage block pointed to by the storage block identifier.

[0077] In this step, the OTA master control may determine the storage block identifier after determining that a write exception occurs in the storage block, and write a data block corresponding to the storage block where the write exception occurs.

[0078] It is understood that before writing the above-mentioned target data block to the corresponding storage block, the OTA master control can also determine whether the current conditions meet the preset resume conditions. For example, when the writing process is interrupted by the user or when the writing process is interrupted while the vehicle is in motion, the current driving state of the vehicle can be determined. When the vehicle is currently idle, the user is asked whether to resume the transfer from the breakpoint or the OTA master control decides whether to resume the transfer from the breakpoint. The method for determining the current driving state of the vehicle can be as shown in the above step S1034.

[0079] Thus, this application discloses a method for upgrading ECU firmware. The method can achieve breakpoint-resume transmission by determining the storage block to which the breakpoint belongs and then rewriting the data block corresponding to the storage block. When it is detected that the vehicle is in motion, the firmware upgrade of only the more important ECU nodes can be interrupted, and the firmware upgrade of the less important ECU nodes can continue. On the basis of ensuring the safety of the user's driving, the time occupied by the firmware upgrade in the vehicle is reduced to less than 30 minutes, thereby improving the user experience.

[0080] Corresponding to the embodiments of the aforementioned method, the present application also provides embodiments of an ECU firmware upgrade device, an electronic device terminal used therein, and a storage medium for storing software programs.

[0081] Embodiments of the file processing apparatus of the present application can be applied to computer devices, such as servers or terminal devices. The apparatus embodiments can be implemented through software, hardware, or a combination of software and hardware. For example, in a software implementation, as a logically defined apparatus, the apparatus is formed by a processor for file processing in which the apparatus reads corresponding computer program instructions from a non-volatile memory into memory and executes them.

[0082] According to the second aspect of the present application, as shown in Figure 2, a car 200 is provided, which has an OTA master control 201 and at least one ECU node, the ECU node has a storage space, the storage space includes multiple storage blocks, and the OTA master control 201 is used to execute a method corresponding to the above-mentioned method embodiment.

[0083] According to a third aspect of the present application, an ECU firmware upgrade device 300 is provided. The data in the firmware package is divided into multiple data blocks, each data block corresponding to an address segment of a storage block in the storage space of the ECU. As shown in FIG3 , which is a software structure diagram of an electronic device in which the ECU firmware upgrade device according to an embodiment of the present application is located, the device includes:

[0084] A data writing module 301 is configured to write the data block into the corresponding storage block in the storage space;

[0085] A message receiving module 302 is configured to receive a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier;

[0086] The abnormality detection module 303 is used to determine whether a write abnormality occurs in the storage block, wherein the write abnormality includes: a write abnormality determined based on the storage response message;

[0087] The breakpoint resume module 304 is configured to determine a target data block based on the storage block identifier in the storage response message if a write exception occurs to the storage block, and rewrite the target data block into the storage block pointed to by the storage block identifier.

[0088] In another implementation example, the above-mentioned ECU firmware upgrade device includes: a processor, wherein the processor is used to execute the above-mentioned program modules stored in the memory, including: a data writing module, a message receiving module, an anomaly detection module and a breakpoint resume module.

[0089] According to a fourth aspect of an embodiment of the present application, an ECU firmware upgrade system is provided, as shown in FIG4 . The system includes an OTA master control device 400 and at least one ECU node 500 . The ECU node 500 has a storage space including multiple storage blocks.

[0090] The OTA master control device 400 includes a processor 401, a memory 402, a computer program stored in the memory 402 and executable on the processor 401, a communication interface 403, and a bus 404. When the processor 401 executes the program, the method of the first aspect is implemented. The processor 401, the memory 402, and the communication interface 403 are connected to each other within the device via the bus 404.

[0091] The processor 401 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0092] The memory 402 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 402 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 402 and is called and executed by the processor 401.

[0093] The communication interface 403 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WIFI, Bluetooth, etc.).

[0094] The bus 404 comprises a pathway for transmitting information between various components of the device (eg, the processor 401 , the memory 402 , and the communication interface 403 ).

[0095] It should be noted that although the above device only shows the processor 401, the memory 402, the communication interface 403, and the bus 404, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0096] Corresponding to the embodiments of the aforementioned method, the present application also provides a computer-readable storage medium for upgrading ECU firmware, on which a program is stored, and when the program is executed by a processor, the corresponding operations in the embodiments of the aforementioned method are implemented.

[0097] For the embodiments of the apparatus, equipment, and storage medium, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0098] The foregoing description describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0099] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention claimed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not claimed herein. The description and examples are to be considered merely as exemplary, and the true scope and spirit of the present application are indicated by the claims.

[0100] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

[0101] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for upgrading ECU firmware, characterized in that: The data in the firmware package is divided into a plurality of data blocks, each data block corresponding to an address segment of one of the storage blocks in the storage space of the ECU, and the method includes: Writing the data block into the corresponding storage block in the storage space; receiving a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier; Determining whether a write exception occurs in the storage block, wherein the write exception includes: a write exception determined based on the storage response message; If it is determined that a write exception occurs in the storage block, a destination data block is determined based on the storage block identifier in the storage response message, and the destination data block is rewritten into the storage block pointed to by the storage block identifier.

2. The method according to claim 1, characterized in that The write abnormality determined based on the storage response message includes: a response time length of the storage response message exceeds a preset value or a write error occurs in the storage block.

3. The method according to claim 2, characterized in that The storage response message carries a response duration or a first check code, where the first check code is generated based on the data written into the storage block and is used to indicate that a write error occurs in the storage block.

4. The method according to claim 3, characterized in that The write error includes an error in the written data, or incomplete writing of the data in the storage block.

5. The method according to claim 3, characterized in that The determination that a write error occurs in the storage block based on the storage response message includes: Obtaining a second check code generated based on the data of the data block; Comparing the first check code and the second check code to see whether they are consistent, and determining whether a write error occurs in the storage block.

6. The method according to claim 1, wherein The ECU is placed on a vehicle, the vehicle includes a plurality of ECU nodes, each of the ECU nodes has a storage space, and the method further includes: When the vehicle is in a driving state, the writing process of the ECU node with an importance level of a preset level is interrupted.

7. An automobile, characterized in that: The car is provided with an OTA master control and at least one ECU node, the ECU node is provided with a storage space, the storage space includes a plurality of storage blocks, and the OTA master control is used to execute the method according to any one of claims 1-6.

8. An ECU firmware upgrade device, characterized in that: The data in the firmware package is divided into a plurality of data blocks, each data block corresponding to an address segment of one of the storage blocks in the storage space of the ECU, and the device includes: A data writing module, configured to write the data block into a corresponding storage block in the storage space; A message receiving module, configured to receive a storage response message returned by the storage space, wherein the storage response message carries a storage block identifier; an abnormality detection module, configured to determine whether a write abnormality occurs in the storage block, wherein the write abnormality includes: a write abnormality determined based on the storage response message; The breakpoint resume module is used to determine the destination data block based on the storage block identifier in the storage response message if it is determined that a write exception occurs in the storage block, and write the destination data block into the storage block pointed to by the storage block identifier.

9. An ECU firmware upgrade system, characterized in that: The system includes an OTA master control device and at least one ECU node, wherein the ECU node has a storage space, and the storage space includes multiple storage blocks; The OTA master control device includes: processor; A memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method according to any one of claims 1 to 6 is implemented.

10. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the operations in the method according to any one of claims 1 to 6 are implemented.

Images