Method and apparatus for upgrading electronic control unit, electronic device, chip and medium

Abstract

The present disclosure relates to the technical field of automobile electronics, and provides a method and apparatus for upgrading an electronic control unit (ECU), an electronic device, a chip and a medium. The method for upgrading the ECU comprises: in response to an upgrade instruction, moving a BootLoader upgrade file from a cache area to a first operation area, and erasing the BootLoader upgrade file in the cache area; in the first operation area, flashing the BootLoader upgrade file and activating a corresponding BootLoader program; loading an application program upgrade file into the cache area, and moving the application program upgrade file from the cache area to a second operation area on the basis of the BootLoader program; and in the second operation area, flashing the application program upgrade file. The technical solution provided in the present disclosure solves the problem of not supporting BootLoader upgrade or an ECU being unstable during ECU upgrade, providing support for BootLoader upgrade in the ECU, and improving the stability of the ECU.

Description

A method, apparatus, electronic device, chip, and medium for upgrading an electronic control unit.

[0001] Cross-references to related applications

[0002] This disclosure claims priority to Chinese Patent Application No. 2024105133253, filed on April 26, 2024, entitled “A method, apparatus, electronic device, chip and medium for upgrading an electronic control unit”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of automotive electronics technology, and includes, but is not limited to, a method, apparatus, electronic device, chip, and medium for upgrading an electronic control unit. Background Technology

[0004] With the continuous advancement of vehicle electrification technology, especially in the field of new energy vehicles, over-the-air (OTA) technology, which supports the upgrading of various functions of the entire vehicle, has become extremely common. In the process of upgrading various functions of the vehicle's electronic control unit (ECU) via OTA, the stability of the bootloader (BT) itself also needs to be continuously improved through self-upgrades. In related technologies, the ECU upgrade process has problems such as not supporting bootloader upgrades and ECU instability. Summary of the Invention

[0005] The present disclosure aims to solve one of the technical problems in the related art at least to a certain extent.

[0006] This disclosure provides an upgrade method, apparatus, electronic device, chip, and medium for an electronic control unit (ECU) to solve the problem that ECU upgrades do not support BootLoader upgrades. By moving and flashing the BootLoader upgrade file from the cache to the BootLoader boot partition, and after activating the BootLoader, the application upgrade file is flashed to the corresponding boot partition, thus completing the upgrade of the BootLoader in the ECU and improving the stability of the ECU.

[0007] This disclosure provides an embodiment of an electronic control unit upgrade method, the method comprising:

[0008] In response to the upgrade command, the startup upgrade file is moved from the cache area to the first running area, and the startup upgrade file in the cache area is erased. The first running area is the area in the electronic control unit where the startup upgrade file is run.

[0009] In the first running area, the startup loading upgrade file is flashed and the corresponding startup loader is activated. The startup loader is the executable program of the startup loading upgrade file.

[0010] The application upgrade file is loaded into the cache area. Based on the startup loader, the application upgrade file is moved from the cache area to the second running area. The second running area is the area in the electronic control unit where the application upgrade file runs. Both the application upgrade file and the startup load upgrade file are files to be upgraded for the electronic control unit.

[0011] In the second running area, the application upgrade file is flashed.

[0012] In one embodiment of this disclosure, in response to an upgrade command, the startup loading upgrade file is moved from the cache to the first runtime area, including:

[0013] In response to the upgrade command, the system initialization of the electronic control unit is performed;

[0014] Verify whether the startup loading upgrade file in the cache is valid. If it is invalid, set the move flag of the startup loading upgrade file to failure. If it is valid, erase the original startup loading file from the first running area and move the startup loading upgrade file in. In the first running area, the original startup loading file existed before the startup loading upgrade file.

[0015] In one embodiment of this disclosure, after moving the startup loading upgrade file from the cache to the first runtime area in response to an upgrade command, the process includes:

[0016] Set the first write flag to valid when loading the upgrade file;

[0017] Set the first move flag to successful when loading the upgrade file;

[0018] Erase the startup load upgrade files in the cache.

[0019] In one embodiment of this disclosure, in the first running area, the startup loading upgrade file is written and the corresponding startup loading program is activated, including:

[0020] In the first running area, flash the startup and load the upgrade file;

[0021] In response to the startup command, if the first write flag is valid, then based on the upgrade command or the first move flag, confirm that the startup loading and flashing of the upgrade file was successful.

[0022] In response to the activation command, check whether the startup loading upgrade file has been successfully flashed. If the flashing is successful, activate the startup loading program.

[0023] In one embodiment of this disclosure, confirming successful loading and flashing of the upgrade file based on the upgrade command or a first mobile identifier includes:

[0024] Verify either the status of the upgrade command or the first movement identifier;

[0025] If the upgrade command status is valid or the first move identifier is successful, the verification passes, confirming that the upgrade file loading and flashing were successful.

[0026] In one embodiment of this disclosure, in response to a second upgrade instruction, the application upgrade file is loaded into a cache, and then, based on a startup loader, the application upgrade file is moved from the cache to a second runtime area, including:

[0027] Set the second write flag for the application upgrade file to be valid;

[0028] Set the second move flag for the application upgrade file to successful;

[0029] Erase application update files from the cache.

[0030] In one embodiment of this disclosure, the application upgrade file is flashed in the second running area, including:

[0031] During startup loader execution, the second move identifier and the second write identifier are verified in the second runtime area;

[0032] If the second mobile identifier and the second write identifier are verified, the application upgrade file is initialized;

[0033] Application upgrade file flashing complete.

[0034] In one embodiment of this disclosure, after the application upgrade file is flashed, the method further includes:

[0035] Perform dependency checks on application upgrade files;

[0036] If the dependency check passes, the upgrade of the electronic control unit is complete.

[0037] This disclosure provides an upgrade system for an electronic control unit, the system comprising: a first operating area, a second operating area, a cache area, and an updater partition, wherein:

[0038] The updater partition is configured as follows:

[0039] In response to the upgrade command, the startup load upgrade file is moved from the cache to the first running area, so that the startup load upgrade file is written in the first running area;

[0040] In response to the upgrade command, the application upgrade file is moved from the cache area to the second running area so that the application upgrade file is successfully written in the second running area.

[0041] This disclosure provides an upgrade device for an electronic control unit, the device comprising:

[0042] The first moving module is configured to move the startup loading upgrade file from the cache area to the first running area in response to the upgrade command, wherein the first running area is the area in the electronic control unit where the startup loading upgrade file is executed;

[0043] The first flashing module is configured to flash the startup loading upgrade file and activate the corresponding startup loading program in the first running area. The startup loading program is the executable program of the startup loading upgrade file.

[0044] The second moving module is configured to load the application upgrade file into the cache area and move the application upgrade file from the cache area to the second running area based on the startup loader. The second running area is the area in the electronic control unit where the application upgrade file runs. Both the application upgrade file and the startup loader upgrade file are files to be upgraded for the electronic control unit.

[0045] The second flashing module is configured to flash the application upgrade file in the second running area.

[0046] This disclosure provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0047] This disclosure provides a chip including at least one processor and a communication interface; the communication interface is configured to receive signals input to the chip or signals output from the chip, and the processor communicates with the communication interface and implements the method described above through logic circuits or executed code instructions.

[0048] This disclosure provides a vehicle including an electronic control unit upgrade system as described above, or an electronic control unit upgrade device as described above, or an electronic device as described above, or a chip as described above.

[0049] This disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0050] In summary, according to the electronic control unit (ECU) upgrade method proposed in this disclosure, in response to an upgrade command, the startup load upgrade file is moved from the cache area to the first operating area, and the startup load upgrade file in the cache area is erased. The first operating area is the region within the ECU where the startup load upgrade file runs, completing the movement of the startup load upgrade file to the target storage area and providing storage space for the application upgrade file. In the first operating area, the startup load upgrade file is flashed and the corresponding startup load program is activated. The startup load program is the executable program of the startup load upgrade file, realizing the upgrade of the startup load upgrade file in the ECU. The application upgrade file is loaded into the cache area, and based on the startup load program, the application upgrade file is moved from the cache area to the second operating area. The second operating area is the region within the ECU where the application upgrade file runs. Both the application upgrade file and the startup load upgrade file are files to be upgraded for the ECU, reusing the storage space of the cache area and completing the movement of the application upgrade file to the target storage area. In the second operating area, the application upgrade file is flashed, realizing the upgrade of the application in the ECU. It provides support for upgrading the BootLoader in the ECU. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of the ECU. By avoiding the complexity of the ECU caused by adding new storage space, it improves the stability of the ECU.

[0051] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0052] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0053] Figure 1 is a schematic diagram of the ECU upgrade process in related technologies;

[0054] Figure 2 is a schematic diagram of ECU upgrades in BootLoader and APP modes in related technologies;

[0055] Figure 3 is a schematic diagram of ECU upgrades in BM, BootLoader, and APP modes in related technologies;

[0056] Figure 4 is a flowchart of an electronic control unit upgrade method according to an embodiment of the present disclosure;

[0057] Figure 5 is a schematic diagram of an ECU upgrade in BM, BootLoader and APP modes according to an embodiment of this disclosure;

[0058] Figure 6 is a flowchart of an embodiment of the present disclosure in which the startup loading upgrade file is moved from the cache to the first running area in response to an upgrade command.

[0059] Figure 7 is a flowchart of setting the identifier of the startup loading upgrade file and erasing the file according to an embodiment of this disclosure;

[0060] Figure 8 is a flowchart of a first running area in which a startup loading upgrade file is written and the corresponding startup loading program is activated.

[0061] Figure 9 is a flowchart of a process in which the loading of the upgrade file is successfully initiated and flashed according to an upgrade command or a first movement identifier according to an embodiment of the present disclosure.

[0062] Figure 10 is a flowchart of setting the identifier of an application upgrade file and erasing the file according to an embodiment of this disclosure;

[0063] Figure 11 is a flowchart of the process of writing the application upgrade file in the second running area according to an embodiment of the present disclosure;

[0064] Figure 12 is a flowchart of a dependency check for application upgrade files according to an embodiment of this disclosure;

[0065] Figure 13 is a flowchart of an ECU upgrade according to an embodiment of the present disclosure;

[0066] Figure 14 is a schematic diagram of an ECU upgrade process according to an embodiment of the present disclosure;

[0067] Figure 15A is a schematic diagram of the structure of an electronic control unit upgrade system according to an embodiment of the present disclosure;

[0068] Figure 15B is a schematic diagram of the structure of an electronic control unit upgrade device according to an embodiment of the present disclosure;

[0069] Figure 16 is a block diagram of an electronic device for implementing an upgrade method for the electronic control unit of the present disclosure, according to an exemplary embodiment;

[0070] Figure 17 is a schematic diagram of the chip structure according to an embodiment of this disclosure. Detailed Implementation

[0071] Embodiments of this disclosure are described in detail below, with examples of embodiments shown in the accompanying drawings, wherein the same or similar reference numerals identify the same or similar originals or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0072] First, let's briefly introduce the relevant terms used in this disclosure:

[0073] Bootloader: In this disclosure, it refers to a piece of initialization code that executes before the operating system or other main application runs. It is responsible for preparing the hardware environment required by the system, loading the operating system kernel or application into memory, and then transferring control to them. In embedded systems, the bootloader may also contain functionality for upgrading firmware.

[0074] BootManager (BM): In this disclosure, it refers to a software component in a computer system that is responsible for selecting and loading the appropriate operating system during the startup process.

[0075] Over-the-air (OTA) updates: In this disclosure, OTA refers to the technology by which a device receives and installs software updates via a wireless network. This technology is widely used for remote upgrades of devices such as smartphones, embedded systems, and automotive ECUs. OTA upgrades can fix known issues, add new features, or improve system performance while avoiding the need for a physical connection, thus providing convenience for users.

[0076] In related technologies, especially in the field of new energy vehicles, over-the-air (OTA) updates for the whole vehicle are extremely common. The stability of BT itself also needs to be continuously improved through self-upgrades, while the ECU upgrade process cannot well adapt to the upgrade needs of BT itself.

[0077] Figure 1 illustrates the ECU upgrade process in related technologies. As shown in Figure 1, after the upgrade command is triggered, the ECU enters the pre-programming stage. Responding to the pre-programming stage command, the ECU begins flashing the application (APP) file. During the flashing process, it checks whether all application files have been transferred successfully. If the transfer is incomplete, the flashing of the application files continues; otherwise, a file dependency check is performed on the already flashed application files. If the check passes, the application file flashing is successful; if the check fails, the application file flashing fails. As described above, this ECU upgrade process only flashes and upgrades the application files, and does not demonstrate BT's own upgrade capabilities and requirements.

[0078] Figure 2 illustrates the ECU upgrade process using BootLoader and APP modes in related technologies. As shown in Figure 2, the flash memory partition of the ECU chip only contains a bootloader partition and an application file partition. Since the BootLoader is the first user program executed after the chip powers on, it is mainly used to boot the application file and also to receive the flash file sent by the host computer and overwrite the application file partition. The ECU upgrade process is as follows: When the upgrade begins, the host computer sends a command to the ECU to enter the bootloader partition. The bootloader program corresponding to the bootloader file erases the application file partition and jumps to the application file partition to write new application file data. The integrity of the written data is checked. If the written data is complete, its dependency is checked. If the written data passes the file dependency check, it means that the written data files are not missing, not redundant, and the interdependencies are normal, i.e., the writing is successful. The written data is then made effective by a reset command. Although this solution has low requirements for flash resources, it has the following disadvantages: 1. If the bootloader file has a program error (bug), the ECU will be unable to upgrade. 2. The application file has no backup file, which means that if the ECU upgrade fails, the application file will not be available.

[0079] Figure 3 illustrates ECU upgrades in BM, BootLoader, and APP modes in related technologies. As shown in Figure 3, the flash partitions of the ECU chip include a boot manager partition, a boot load file partition, a boot load file backup partition, an application file partition, and an application file backup partition. BM is the first user program executed after the chip powers on, and its main functions include booting BT or APP and transferring BT or APP. The ECU upgrade process is as follows: Upon receiving the upgrade command from the host computer, the system enters the boot load file partition, erases the boot load file partition or the boot load file backup partition, and then writes the data to the application file backup partition or the boot load file backup partition. Furthermore, the integrity and validity of the written data are verified. If the verification passes, a reset is performed, and the boot load file in the boot load file backup partition is transferred to the boot load file partition, and the application file in the application file backup partition is transferred to the application file partition. Finally, the execution program in the boot manager partition jumps to the application file partition, thus activating the application and completing the ECU upgrade in this mode. This solution uses a backup partition approach; after correct writing, the data is transferred. If an error occurs during the flashing process, it does not affect the execution of the functions of each flash partition. However, BM's transfer function requires integrated flash drivers, which poses risks of uncontrolled startup and accidental erasure. Furthermore, its complex functionality increases the probability of bugs, and updating BM carries significant risks should problems occur. Moreover, the separate storage of the APP and BT in their respective backup partitions places high demands on flash storage resources. In other words, while the BootLoader itself can be upgraded, the cost and risks of upgrades cannot be reasonably controlled, leading to ECU instability.

[0080] In summary, among the related technologies, ECU upgrades have issues such as not supporting upgrades to the BootLoader itself or ECU instability.

[0081] This disclosure aims to solve the problems of BootLoader's inability to complete its own upgrade or ECU instability in the aforementioned ECU upgrades. It utilizes a cache area to store BootLoader upgrade files, upgrades the bootloader files in the BootLoader partition, and activates the bootloader program to upgrade the application programs. This completes the upgrade of the BootLoader in the ECU, ensuring that both the ECU's bootloader files and application files are upgraded, thus improving ECU stability.

[0082] The method proposed in this disclosure is applied to the upgrade task of electronic control units. The technology of upgrading the vehicle's ECU by loading the startup program can be applied to multiple scenarios or fields, for example, it can include:

[0083] Software Development and Debugging: During the development of automotive software, developers need to debug and test the software. Upgrading the ECU's bootloader makes it easier to download and refresh the software for iterative development and problem fixing.

[0084] Manufacturing: During automobile production, the ECU of each vehicle may need to be programmed according to specific configurations or customer requirements. Upgrading the bootloader ensures that the software can be written to the ECU quickly and accurately, improving production efficiency.

[0085] After-sales service and maintenance: After a vehicle is sold, ECU upgrades may be necessary to fix software defects, provide new features, or comply with new regulatory requirements. Startup loader upgrades can simplify this process, making aftermarket software upgrades more efficient and reliable.

[0086] OTA Updates: With the development of intelligent vehicle technology, OTA updates have become an important trend in the automotive industry. OTA technology allows for remote upgrades of a vehicle's ECU, providing users with the latest software version and fixing known issues. Upgrading the bootloader is one of the key technologies for implementing OTA updates.

[0087] Enhanced Safety: As automobiles increasingly rely on software to control critical functions, software security becomes paramount. Upgrading the ECU's bootloader can improve system security and prevent problems caused by potential software errors, such as firmware corruption due to misoperation.

[0088] Adaptive cruise control: For advanced driver assistance systems (such as adaptive cruise control) that require real-time processing of large amounts of sensor data, launching an upgrade program can ensure smooth cooperation between the underlying software and the application software, thereby improving the system's performance and reliability.

[0089] In summary, ECU bootloader upgrade technology has wide applications in automotive software development, manufacturing, after-sales service, OTA updates, safety performance enhancement, and advanced driver assistance systems. This disclosure does not limit the application scenarios.

[0090] The upgrade method for the electronic control unit provided in this disclosure will be described in detail below with reference to the accompanying drawings.

[0091] Figure 4 is a flowchart of an electronic control unit upgrade method according to an embodiment of this disclosure. This method is executed in the overall electronic control unit of the vehicle and its individual sub-electronic control units. As shown in the embodiment of Figure 4, the electronic control unit upgrade method includes:

[0092] Step 401: In response to the upgrade command, the startup loading upgrade file is moved from the cache area to the first running area, and the startup loading upgrade file in the cache area is erased. The first running area is the area in the electronic control unit where the startup loading upgrade file is run.

[0093] In this embodiment, the upgrade command refers to the upgrade command for the ECU's BootLoader and APP. It can be an upgrade command initiated by the host computer to the ECU for the BootLoader and APP, or it can be an upgrade command received by the OTA update program in the ECU for the BootLoader and APP. Optionally, the upgrade command includes instructions to automatically execute BootLoader and APP upgrades. After the BootLoader upgrade is completed first, the APP upgrade continues based on the successfully upgraded BootLoader. Optionally, the upgrade command is a user-triggered upgrade command. After the user triggers the BootLoader upgrade command, the BootLoader upgrade is completed, and the user is notified that the BootLoader upgrade is complete, allowing further APP upgrades. After the user triggers the APP upgrade command, the APP upgrade is completed. APP updates can only be completed based on a successful BootLoader flash.

[0094] The bootloader upgrade file refers to a new file that upgrades the bootloader. The cache area refers to the partition in the ECU's flash memory where the bootloader upgrade file or application upgrade file is stored. The primary running area refers to the region within the ECU where the bootloader upgrade file is executed.

[0095] Upon receiving the user's upgrade command for the ECU's BootLoader and APP, the BootLoader upgrade file is moved from the ECU's flash cache to the partition where the upgrade file is loaded during startup, completing the move of the BootLoader upgrade file to the target storage area. The BootLoader upgrade file stored in the cache is then erased to facilitate the reuse of storage space for subsequent APP upgrade files.

[0096] Step 402: In the first running area, the startup loading upgrade file is flashed and the corresponding startup loader is activated. The startup loader is the executable program of the startup loading upgrade file.

[0097] In this embodiment, the bootloader refers to the executable program that loads the bootloader upgrade file. The bootloader upgrade file is flashed in the first running area. The bootloader program corresponding to this bootloader upgrade file is activated, completing the upgrade of the BootLoader in the ECU. Here, flashing the bootloader upgrade file means writing the entire bootloader upgrade file into the first running area to replace the original bootloader file, thereby upgrading the BootLoader in the ECU.

[0098] Step 403: Load the application upgrade file into the cache area. Based on the startup loader, move the application upgrade file from the cache area to the second running area. The second running area is the area in the electronic control unit where the application upgrade file runs. Both the application upgrade file and the startup load upgrade file are files to be upgraded for the electronic control unit.

[0099] In this embodiment, the second operating area refers to the area in the ECU where the application upgrade file is run.

[0100] After the ECU's BootLoader upgrade is complete, the BootLoader upgrade file is cleared before the APP upgrade file is loaded into the cache. This allows for storage space reuse within the cache, eliminating the need for additional flash storage and reducing ECU upgrade costs. Based on the already activated and running BootLoader program, the APP upgrade file is moved from the cache to the second running area. This completes the movement of the application upgrade file to the target storage area.

[0101] Step 404: In the second running area, the application upgrade file is flashed.

[0102] In this embodiment, the existing application upgrade files are flashed in the second operating area to complete the upgrade of the applications corresponding to each function in the ECU. Here, flashing the application upgrade files means writing all the application upgrade files into the second operating area to replace the original application files and realize the upgrade of the applications in the ECU.

[0103] In summary, according to the electronic control unit (ECU) upgrade method proposed in this disclosure, in response to an upgrade command, the bootloader upgrade file is moved from the cache area to the first operating area, and the bootloader upgrade file in the cache area is erased. The first operating area is the region within the ECU where the bootloader upgrade file runs, completing the movement of the bootloader upgrade file to the target storage area and providing storage space for the application upgrade file. In the first operating area, the bootloader upgrade file is flashed and the corresponding bootloader program is activated. The bootloader program is the executable program of the bootloader upgrade file, realizing the upgrade of the bootloader upgrade file (BootLoader upgrade file) in the ECU. The application upgrade file is loaded into the cache area. Based on the bootloader program, the application upgrade file (APP upgrade file) is moved from the cache area to the second operating area. The second operating area is the region within the ECU where the application upgrade file runs. Both the application upgrade file and the bootloader upgrade file are files to be upgraded for the ECU, reusing the storage space of the cache area and completing the movement of the application upgrade file to the target storage area. In the second operating area, the application upgrade file is flashed, realizing the upgrade of the application in the ECU. It provides support for upgrading the BootLoader in the ECU. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of the ECU. By avoiding the complexity of the ECU caused by adding new storage space, it improves the stability of the ECU.

[0104] Figure 5 is a schematic diagram of an ECU upgrade in BM, BootLoader, and APP modes according to an embodiment of this disclosure. As shown in Figure 5, the ECU's flash partition includes a boot manager partition, a boot load file partition, an application file partition, a backup partition, and an updater partition. The backup partition is used to store backup files of application files or boot load files, and the updater partition is used to store the updater for application files or boot load files. After the boot manager starts, it jumps to the updater partition, where the updater monitors whether the BootLoader or APP needs to be upgraded. If an upgrade is needed, it moves the corresponding update package. In response to the upgrade command, the boot load upgrade file is moved from the backup partition to the boot load file partition, the boot load upgrade file is flashed to the boot load file partition, and activated, completing the ECU upgrade of the BootLoader. After the boot load function runs, the data received from the diagnostic tool is stored in the backup partition. At this time, the received data is the APP upgrade file. After receiving the data, it jumps back to the updater partition, where the updater moves the APP upgrade file to the application file partition, thereby ensuring the ECU update is complete.

[0105] Figure 6 is a flowchart illustrating how, in response to an upgrade command, the upgrade file is moved from the cache to the first runtime area according to an embodiment of this disclosure. Figure 6 further illustrates step 401 of Figure 4, and based on the embodiment shown in Figure 6, includes the following steps:

[0106] Step 601: In response to the upgrade command, perform system initialization of the electronic control unit.

[0107] In this embodiment, upon receiving an upgrade command from the host computer or an OTA (Over-The-Air) automatic upgrade command, the ECU performs system initialization. Optionally, components such as the clock, timer, and flash driver are initialized.

[0108] Step 602: Verify whether the startup loading upgrade file in the cache is valid. If it is invalid, set the move flag of the startup loading upgrade file to failure. If it is valid, erase the original startup loading file from the first running area and move the startup loading upgrade file in. In the first running area, the original startup loading file existed before the startup loading upgrade file.

[0109] In this embodiment, the move identifier of the startup load upgrade file indicates whether the startup load upgrade file can be used for the move operation. If it can be used for the move, the move identifier is successful; otherwise, the move identifier is unsuccessful. After the ECU completes system initialization, it verifies whether the startup load upgrade file stored in the buffer is valid. For example, it confirms whether the startup load upgrade file is a valid file through a signature verification algorithm. Optionally, the signature verification algorithm includes algorithms such as MD5, SHA1, and CRC32. If the startup load upgrade file in the buffer is invalid, the move identifier of the startup load upgrade file is set to failure. If the startup load upgrade file in the buffer is valid, the original startup load file is erased from the first running area, and the startup load upgrade file is moved in, completing the update of the startup load file. In the first running area, the original startup load file exists before the startup load upgrade file. Through the method proposed in this embodiment, the ECU moves the startup load upgrade file from the buffer to the first running area according to the upgrade command, preparing for the startup load upgrade file to be written to the first running area.

[0110] Figure 7 is a flowchart illustrating the process of setting the identifier of an upgrade file and erasing the file according to an embodiment of this disclosure. Figure 7 further illustrates the steps following step 602 in Figure 6. Based on the embodiment shown in Figure 7, the steps include:

[0111] Step 701: Set the first write flag for loading the upgrade file to valid.

[0112] In this embodiment, the first write flag refers to the status flag indicating that the startup loading upgrade file can be written to the first running area. After erasing the original startup loading file in the first running area and moving in the startup loading upgrade file, the first write flag of the startup loading upgrade file is set to valid, indicating that the startup loading upgrade file can be written to the first running area.

[0113] Step 702: Set the first move flag for starting the loading of the upgrade file to success.

[0114] In this embodiment, the first movement identifier refers to the result identifier of the startup loading upgrade file being moved to the first running area. Since the startup loading upgrade file has been successfully moved into the first running area, the first movement identifier is set to success.

[0115] Step 703: Erase the startup loading upgrade files in the cache area.

[0116] In this embodiment, after the startup loading upgrade file is moved from the cache area to the first running area, the startup loading upgrade file in the cache area is erased, which facilitates the storage of the application upgrade file and achieves the purpose of time-sharing reuse of this area, thereby saving flash storage resources, reducing the cost of ECU upgrade, avoiding the complexity of the ECU caused by the addition of storage space, and thus improving the stability of the ECU.

[0117] Figure 8 is a flowchart illustrating the process of writing the startup loading upgrade file and activating the corresponding startup loading program in the first running area according to an embodiment of this disclosure. Figure 8 provides a detailed explanation of step 402 in Figures 7 and 4. Based on the embodiment shown in Figure 8, the steps include:

[0118] Step 801: In the first running area, flash the startup loading upgrade file.

[0119] In this embodiment, after moving the startup loading upgrade file to the first running area, the startup loading upgrade file is then written to the first running area.

[0120] Step 802: In response to the startup command, if the first write flag is valid, then based on the upgrade command or the first move flag, confirm that the startup loading and flashing of the upgrade file was successful.

[0121] In this embodiment, the startup command refers to the diagnostic command currently being executed by the host computer or OTA received by the ECU, used to diagnose whether the startup loading upgrade file has been successfully written to the first running area. After receiving the startup command, the ECU verifies whether the first write flag is valid. If valid, then based on the upgrade command or the first movement flag, it confirms that the startup loading upgrade file has been successfully written to the first running area. Specifically, the upgrade command is valid, and the first movement flag is successful.

[0122] Step 803: In response to the activation command, check whether the startup loading upgrade file has been successfully flashed. If the flashing is successful, activate the startup loading program.

[0123] In this embodiment, the activation command refers to the instruction received by the ECU from the host computer or OTA to confirm whether the bootloader can be executed. When the ECU receives the activation command, it checks whether the bootloader upgrade file has been successfully flashed into the first running area. If the flashing is successful, the bootloader is activated, that is, the bootloader is executed. Thus, the upgrade of the BootLoader in the ECU is successfully achieved.

[0124] Figure 9 is a flowchart illustrating a successful startup and loading of an upgrade file based on an upgrade command or a first mobile identifier, according to an embodiment of this disclosure. Figure 9 provides a detailed explanation of step 802 in Figure 8. Based on the embodiment shown in Figure 9, the following steps are included:

[0125] Step 901: Verify either the status of the upgrade instruction or the first movement identifier.

[0126] In this embodiment, during the process of confirming that the upgrade file has been successfully written to the first running area, optionally, the status of the upgrade command is verified; optionally, the first movement identifier is verified; optionally, the status of the upgrade command and the first movement identifier are verified.

[0127] Step 902: If the upgrade command is valid or the first move identifier is successful, the verification is successful, confirming that the upgrade file loading and flashing were successfully initiated.

[0128] In this embodiment, if the upgrade command is valid, the verification passes; if the first movement flag is successful, the verification passes; if both the upgrade command and the first movement flag are successful, the verification passes, confirming successful boot loading and flashing of the upgrade file. The upgrade of the BootLoader in the ECU was verified.

[0129] Figure 10 is a flowchart illustrating the identification setting and file erasure of an application upgrade file according to an embodiment of this disclosure. Figure 10 provides a detailed description of the steps following step 403 in Figure 4. Based on the embodiment shown in Figure 10, the steps include:

[0130] Step 1001: Set the second write flag of the application upgrade file to valid.

[0131] In this embodiment, the second write flag refers to the status flag indicating that the application upgrade file can be written to the second runtime area. After erasing the original application file in the second runtime area and moving in the application upgrade file, the second write flag of the application upgrade file is set to valid, indicating that the application upgrade file can be written to the second runtime area.

[0132] Step 1002: Set the second move identifier of the application upgrade file to successful.

[0133] In this embodiment, the second movement identifier refers to the result identifier of the application upgrade file being moved to the second running area. Since the application upgrade file has been successfully moved into the second running area, the second movement identifier is set to success.

[0134] Step 1003: Erase the application update files in the cache.

[0135] In this embodiment, after the application upgrade file is moved from the cache area to the second running area, the application upgrade file in the cache area is erased, and the area is time-division multiplexed to facilitate storage for other applications, thereby saving flash storage resources and reducing the cost of ECU upgrade.

[0136] Figure 11 is a flowchart illustrating the process of flashing an application upgrade file in a second running area according to an embodiment of this disclosure. Figure 11 provides a detailed description of step 404 in Figures 10 and 4. Based on the embodiment shown in Figure 11, the steps include:

[0137] Step 1101: When the startup loader is running, verify the second move identifier and the second write identifier in the second running area.

[0138] In this embodiment, when the startup loader is running, the second move representation and the second write identifier of the application upgrade file are verified in the second running area.

[0139] Step 1102: If the second mobile identifier and the second write identifier are verified, initialize the application upgrade file.

[0140] In this embodiment, if the second move identifier and second write identifier of the application upgrade file pass the verification, it means that the application upgrade file has been moved into the second running area, which meets the requirements for application upgrade. Then, the application upgrade file is initialized, and the second running area is set to write mode.

[0141] Step 1103: Complete flashing the application upgrade file.

[0142] In this embodiment, the upgrade command is automatically executed to send an instruction to the host computer or via OTA to flash the application, and the application upgrade file is flashed into the second running area. This achieves the upgrade of the application in the ECU.

[0143] Figure 12 is a flowchart illustrating a dependency check of an application upgrade file according to an embodiment of this disclosure. Figure 12 provides a detailed description following step 1103 of Figure 11. Based on the embodiment shown in Figure 12, the steps include:

[0144] Step 1201: Perform a dependency check on the application upgrade files.

[0145] In this embodiment, a file dependency check is performed on the application upgrade files that have already been flashed. Optionally, based on the directory tree structure, it is checked whether the files are related to each other to ensure that no files are missing after the upgrade.

[0146] Step 1202: If the dependency check passes, the upgrade of the electronic control unit is complete.

[0147] In this embodiment, if the dependency check of the application upgrade file passes, the ECU upgrade is considered complete. This upgrade of the BootLoader and APP in the ECU improves the stability of the ECU.

[0148] Figure 13 is a flowchart of an ECU upgrade according to an embodiment of this disclosure. As shown in Figure 13, the flash partition of the ECU is divided into a first operating area (BT), a second operating area (APP), an updater partition, and a boot manager partition (BM). In Figure 13, each step in the ECU upgrade is recorded and described. Hereinafter, the steps occurring in the BM are indicated by identifiers such as A1, A2, A3, and A4; the steps occurring in the first operating area (BT) are indicated by identifiers such as B1, B2, B3, ..., B11; the steps occurring in the second operating area are indicated by identifiers such as C1 and C2; and the steps occurring in the updater partition are indicated by identifiers such as D1, D2, B3, ..., D9.

[0149] in,

[0150] The steps within BM are as follows:

[0151] Step A1: After the MCU is powered on, it first enters BM and performs the minimum system initialization of the ECU, such as clock, timer, flash driver, etc.

[0152] Step A2: After the minimum system initialization, attempt to boot the updater by reading the updater's valid flag. If it is invalid, attempt to boot the BT, i.e., execute step A3.

[0153] Step A3: Attempt to boot BT by reading the valid flags of the updater. If invalid, stop at BM, i.e., step A4.

[0154] Step A4: Reaching this step indicates that the ECU cannot start normally and will lose its upgrade capability.

[0155] The steps within BT are as follows:

[0156] Step B1: Once BM successfully boots BT, it will jump to BT. This is the first step in BT execution, performing the initialization of peripheral resources required by BT, such as the Controller Area Network (CAN) interface, internal electrically erasable programmable read-only memory (EEPROM), external memory, protocol stack, middleware, etc. After initialization, it will proceed to B2.

[0157] Step B2: Determine if the programming flag is valid. If valid, proceed to B3. If invalid, continue to determine the "BT transfer flag", i.e., step B4.

[0158] Step B3: This step indicates that a diagnostic tool has requested a reprogramming request. The necessary actions are: clear the programming flag, enter the programming session, reply with a positive response to the diagnostic tool, and proceed to step B9 to prepare for receiving the next diagnostic command from the diagnostic tool. Here, the diagnostic tool refers to the diagnostic signal received by the ECU from the host computer.

[0159] Step B4: Determine the BT transfer flag. If the "BT transfer flag" is in a "successful" state, it means that BT has been successfully activated and proceed to step B5. If the flag is in a "failure" state, it means that the new BT has failed to activate and proceed to step B6. If it is in an "other state", that is, neither successful nor failed, it means that no BT has been upgraded in this upgrade. Directly determine the "APP transfer flag", that is, step B8.

[0160] Step B5: Performing this step indicates that the BT upgrade has been successful. This step requires clearing the BT transfer flag, entering the programming session, unlocking secure access, replying with a positive response to the diagnostic tool, and proceeding to step B9 to prepare to receive the next diagnostic command from the diagnostic tool.

[0161] Step B6: This step indicates that the BT upgrade has failed. This step requires clearing the BT transfer flag, entering the programming session, unlocking secure access, replying with a negative response to the diagnostic tool, and proceeding to step B9 to prepare to receive the next diagnostic command from the diagnostic tool.

[0162] Step B8: Determine the "APP transfer flag". If the "APP transfer flag" is in a "success" state, proceed to step B7; if the flag is in a "failure" state, proceed to step B10; if it is in an "other state", that is, neither success nor failure, it means that the APP was not upgraded in this upgrade, and directly determine the "APP validity flag", that is, step B11.

[0163] Step B7: Performing this step indicates that the APP transfer was successful. This step requires clearing the APP transfer flag, entering the programming session, unlocking secure access, replying with a positive response to the diagnostic instrument, and proceeding to step B9 to prepare to receive the next diagnostic command from the diagnostic instrument.

[0164] Step B10: This step indicates that the APP transfer failed. This step requires clearing the APP transfer flag, entering the programming session, unlocking secure access, replying with a negative response to the diagnostic instrument, and proceeding to step B9 to prepare to receive the next diagnostic command from the diagnostic instrument.

[0165] Step B11: Determine if the APP is valid. If valid, proceed to the APP (step C1). If invalid, proceed to step B9 to prepare to receive the next diagnostic command from the diagnostic instrument.

[0166] The steps performed within the updater partition are as follows:

[0167] Step D1: After the updater is booted up, it starts copying data from the backup partition. The updater has a built-in flash driver. If the current updater recognizes that the backup partition contains BT files, it jumps to step D2. If it contains APP files, it jumps to step D3.

[0168] Step D2: Verify the legality of the BT file, mainly by verifying the legality through the signature information. If the verification passes, proceed to step D4; otherwise, proceed to step D8.

[0169] Step D8: Write the BT transfer flag = failed, then restart. After restarting, it will be guided to BT, where subsequent processing will be performed.

[0170] Step D4: This step begins the BT transfer process. First, the BT valid flag and the old BT are erased. Then, the new BT is copied from the backup partition. The entire transfer process cycles through NRC78 to maintain the diagnostic session. If the transfer process encounters an error, proceed to step D10. If the transfer is complete, proceed to step D6.

[0171] Step D6: After BT transfer is completed, write the BT valid flag and write the BT transfer flag to indicate success. Then, start self-destruction (erase the updater partition), delete cache data, and reset. After reset, it will be booted into BT, where subsequent processing will be performed.

[0172] Step D10: This step handles the aftermath of a failed BT transfer. The updater needs to respond with a negative response. Once the diagnostic tool receives the negative response, it will end the flashing process. Since the BT has been deleted, it has lost the ability to be upgraded again. When the power is turned on again, it will be guided to the updater to perform the BT copy. Therefore, the ECU is not completely bricked at this time and still has the ability to recover itself.

[0173] Step D3: Verify the legality of the APP file, mainly by verifying the legality of the signature information. If the verification passes, proceed to step D5; otherwise, proceed to step D9.

[0174] Step D5: This step begins the APP migration process. First, the APP validity flag and the old APP are erased. Then, the new APP is copied from the backup partition. The entire migration process will cycle through NRC78 to maintain the diagnostic session. If the migration process fails, jump to D9. If the migration is successful, jump to step D7.

[0175] Step D7: After the APP is successfully transferred, write the APP valid flag, write the APP transfer flag = success, self-destruct (erase updater partition), delete cache data, and reset. After resetting, it will be guided to BT for subsequent processing.

[0176] Step D9: If the write to the APP transfer flag fails, then self-destruct (erase the updater partition), delete cache data, and reset. After resetting, it will be guided to BT for subsequent processing.

[0177] The steps performed within the second operating area are as follows:

[0178] Step C1: After entering the APP, perform the necessary initialization required by the APP, schedule the APP functions normally, and be ready to receive new flashing commands initiated by the diagnostic instrument at any time.

[0179] Step C2: When a programming request is received from the diagnostic tool, the "programming flag" must be written to be valid. Then, a reset is performed, and the ECU restarts and enters BT.

[0180] Figure 14 is a schematic diagram of an ECU upgrade process according to an embodiment of this disclosure. As shown in Figure 14, after the upgrade command is triggered, the ECU enters the pre-programming stage. Responding to the pre-programming stage command, the ECU begins transmitting the BT upgrade file and simultaneously monitors whether the transmission of all BT-related files is complete. If all file transmissions are incomplete, the remaining BT-related files continue to be transmitted. If all files are transmitted, the already transmitted BT is activated. If BT activation fails, the BootLoader upgrade fails. If BT activation is successful, the APP upgrade file continues to be transmitted, and the transmission of the APP upgrade file is checked. If the APP upgrade file is not transmitted, the transmission of the APP upgrade file continues until all transmissions are complete. If the APP upgrade file has been transmitted, a file dependency check is performed. If the check passes, the ECU upgrade flashing is successful; if the check fails, the ECU upgrade flashing fails.

[0181] This disclosure provides an upgrade method for an electronic control unit (ECU). In response to an upgrade command, a startup upgrade file is moved from a cache area to a first operating area, and the startup upgrade file in the cache area is erased. The first operating area is the region within the ECU where the startup upgrade file runs, completing the movement of the startup upgrade file to the target storage area and providing storage space for the application upgrade file. In the first operating area, the startup upgrade file is flashed and the corresponding startup loading program is activated. The startup loading program is the executable program of the startup upgrade file, realizing the upgrade of the startup upgrade file in the ECU. The application upgrade file is loaded into the cache area. Based on the startup loading program, the application upgrade file is moved from the cache area to a second operating area. The second operating area is the region within the ECU where the application upgrade file runs. Both the application upgrade file and the startup upgrade file are files to be upgraded for the ECU, reusing the storage space of the cache area and completing the movement of the application upgrade file to the target storage area. In the second operating area, the application upgrade file is flashed, realizing the upgrade of the application in the ECU. This provides support for upgrading the BootLoader in the ECU. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of the ECU. By avoiding the complexity of the ECU due to the increased storage space, it improves the stability of the ECU. Corresponding to the methods provided in the above embodiments, this disclosure also provides an electronic control unit upgrade system and apparatus. Since the system and apparatus provided in this disclosure correspond to the methods provided in the above embodiments, the implementation methods are also applicable to the system and apparatus provided in this embodiment, and will not be described in detail here.

[0182] Figure 15A is a schematic diagram of the structure of an electronic control unit upgrade system 2 according to an embodiment of the present disclosure. As shown in Figure 15A, the electronic control unit upgrade system 2 includes: a first operating area 21, a second operating area 22, a cache area 23, and an updater partition 24, wherein:

[0183] The updater partition 24 is configured to: in response to an upgrade command, move the startup loading upgrade file from the cache 23 to the first running area 21, so that the startup loading upgrade file is flushed in the first running area 21;

[0184] In response to the upgrade command, the application upgrade file is moved from the cache area 23 to the second running area 22 so that the application upgrade file can be flashed in the second running area 22.

[0185] For example, cache 23 is configured to store startup load upgrade files or application upgrade files; updater partition 24 is configured to store a first updater or a second updater.

[0186] In some embodiments, the first updater is configured to move the startup loading upgrade file from the cache 23 to the first running area 21 in response to an upgrade command, so that the startup loading upgrade file is flushed in the first running area 21 and the corresponding startup loader is activated, wherein the startup loader is the executable program of the startup loading upgrade file;

[0187] The second updater is configured to move the application upgrade file from the cache 23 to the second runtime 22 in response to an upgrade command, so that the application upgrade file is successfully written in the second runtime 22.

[0188] In some embodiments, referring to FIG15A, the system further includes: a boot manager partition 20; wherein the boot manager partition 20 is configured to store a boot manager, and the boot manager is configured to boot the first run area 21 or the updater partition 24 after being started.

[0189] In some embodiments, the first operating area 21 is the area in the electronic control unit where the startup loading upgrade file is executed, and the second operating area 22 is the area in the electronic control unit where the application upgrade file is executed.

[0190] In some embodiments, both the application upgrade file and the startup loading upgrade file are upgrade files for the electronic control unit.

[0191] Here, cache area 23 corresponds to the aforementioned backup partition, first running area 21 corresponds to the aforementioned startup loading file partition, and second running area 22 corresponds to the aforementioned application file partition. In this embodiment of the present disclosure, after the startup manager is started, it will guide the first running area 21 or the updater partition 24 to start. The purpose of guiding the first running area is to store the startup loading upgrade file or application upgrade file in cache area 23. The purpose of guiding the updater partition 24 is to move the startup loading upgrade file to the first running area 21 or move the application upgrade file to the second running area 22.

[0192] It should be noted that the interaction process between the various partitions in the system has been described in the above embodiments, and will not be repeated here to avoid repetition.

[0193] Figure 15B is a schematic diagram of an electronic control unit upgrade device 1500 according to an embodiment of the present disclosure. As shown in Figure 15B, the electronic control unit upgrade device includes:

[0194] The first moving module 1510 is configured to, in response to an upgrade command, move the startup loading upgrade file from the cache area to the first running area and erase the startup loading upgrade file in the cache area, wherein the first running area is the area in the electronic control unit where the startup loading upgrade file runs;

[0195] The first flashing module 1520 is configured to flash the startup loading upgrade file and activate the corresponding startup loading program in the first running area. The startup loading program is the executable program of the startup loading upgrade file.

[0196] The second moving module 1530 is configured to load the application upgrade file into the cache area and move the application upgrade file from the cache area to the second running area based on the startup loader. The second running area is the area in the electronic control unit where the application upgrade file runs. Both the application upgrade file and the startup loader upgrade file are files to be upgraded for the electronic control unit.

[0197] The second flashing module 1540 is configured to flash the application upgrade file in the second running area.

[0198] In some embodiments, the first moving module 1510 is further configured to:

[0199] In response to the upgrade command, the system initialization of the electronic control unit is performed;

[0200] Verify whether the startup loading upgrade file in the cache is valid. If it is invalid, set the move flag of the startup loading upgrade file to failure. If it is valid, erase the original startup loading file from the first running area and move the startup loading upgrade file in. In the first running area, the original startup loading file existed before the startup loading upgrade file.

[0201] In some embodiments, after the first moving module 1510 moves the startup loading upgrade file from the cache to the first running area in response to an upgrade command, it is further configured to:

[0202] Set the first write flag of the startup load upgrade file to valid; set the first move flag of the startup load upgrade file to successful; erase the startup load upgrade file in the cache.

[0203] In some embodiments, the first flashing module 1520 is further configured as follows:

[0204] In the first running area, flash the startup and load the upgrade file;

[0205] In response to the startup command, if the first write flag is valid, then based on the upgrade command or the first move flag, confirm that the startup loading and flashing of the upgrade file was successful.

[0206] In response to the activation command, check whether the startup loading upgrade file has been successfully flashed. If the flashing is successful, activate the startup loading program.

[0207] In some embodiments, the first flashing module 1520 is further configured as follows:

[0208] Verify either the status of the upgrade command or the first movement identifier;

[0209] If the upgrade command status is valid or the first move identifier is successful, the verification passes, confirming that the upgrade file loading and flashing were successful.

[0210] In some embodiments, after loading the application upgrade file into the cache and moving the application upgrade file from the cache to the second runtime area based on the startup loader, the second moving module 1530 is further configured to:

[0211] Set the second write flag of the application upgrade file to valid; set the second move flag of the application upgrade file to successful; erase the application upgrade file in the cache.

[0212] In some embodiments, the second flashing module 1540 is further configured as follows:

[0213] During startup loader execution, the second move identifier and the second write identifier are verified in the second runtime area;

[0214] If the second mobile identifier and the second write identifier are verified, the application upgrade file is initialized;

[0215] Application upgrade file flashing complete.

[0216] In some embodiments, after the second flashing module 1540 has finished flashing the application upgrade file, it is further configured to:

[0217] Perform dependency checks on application upgrade files;

[0218] If the dependency check passes, the upgrade of the electronic control unit is complete.

[0219] In summary, the upgrade device of the electronic control unit (ECU) responds to the upgrade command by moving the startup upgrade file from the cache area to the first operating area and erasing the startup upgrade file from the cache area. The first operating area is the region within the ECU where the startup upgrade file runs, completing the movement of the startup upgrade file to the target storage area and providing storage space for the application upgrade file. In the first operating area, the startup upgrade file is flashed and the corresponding startup loading program is activated. The startup loading program is the executable program of the startup upgrade file, realizing the upgrade of the startup upgrade file in the ECU. The application upgrade file is loaded into the cache area, and based on the startup loading program, the application upgrade file is moved from the cache area to the second operating area. The second operating area is the region within the ECU where the application upgrade file runs. Both the application upgrade file and the startup upgrade file are files to be upgraded for the ECU, reusing the storage space of the cache area and completing the movement of the application upgrade file to the target storage area. In the second operating area, the application upgrade file is flashed, realizing the upgrade of the application in the ECU. It provides support for upgrading the BootLoader in the ECU. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of the ECU. By avoiding the complexity of the ECU caused by adding new storage space, it improves the stability of the ECU.

[0220] The methods and apparatus provided in the embodiments of this disclosure have been described above. To implement the functions of the methods provided in the embodiments of this disclosure, the electronic device may include a hardware structure and software modules, and may implement the above functions in the form of a hardware structure, software modules, or a hardware structure plus software modules. One of the above functions may be executed in the form of a hardware structure, software modules, or a hardware structure plus software modules.

[0221] Figure 16 is a block diagram illustrating an electronic device 1600 for implementing the above-described electronic control unit upgrade method according to an exemplary embodiment. For example, the electronic device 1600 may be a mobile phone, computer, messaging device, game console, tablet device, medical device, fitness device, personal digital assistant, etc.

[0222] Referring to FIG16, the electronic device 1600 may include one or more of the following components: a processing component 1602, a memory 1604, a power supply component 1606, a multimedia component 1608, an audio component 1610, an input / output (I / O) interface 1612, a sensor component 1614, and a communication component 1616.

[0223] Processing component 1602 typically controls the overall operation of electronic device 1600, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1602 may include one or more processors 1620 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1602 may include one or more modules to facilitate interaction between processing component 1602 and other components. For example, processing component 1602 may include a multimedia module to facilitate interaction between multimedia component 1608 and processing component 1602.

[0224] Memory 1604 is configured to store various types of data to support the operation of electronic device 1600. Examples of this data include instructions for any application or method operating on electronic device 1600, contact data, phonebook data, messages, pictures, videos, etc. Memory 1604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0225] Power supply component 1606 provides power to various components of electronic device 1600. Power supply component 1606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1600.

[0226] Multimedia component 1608 includes a screen that provides an output interface between electronic device 1600 and a user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1608 includes a front-facing camera and / or a rear-facing camera. When electronic device 1600 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0227] Audio component 1610 is configured to output and / or input audio signals. For example, audio component 1610 includes a microphone (MIC) configured to receive external audio signals when electronic device 1600 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1604 or transmitted via communication component 1616. In some embodiments, audio component 1610 also includes a speaker configured to output audio signals.

[0228] I / O interface 1612 provides an interface between processing component 1602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0229] Sensor assembly 1614 includes one or more sensors configured to provide state assessments of various aspects of electronic device 1600. For example, sensor assembly 1614 may detect the on / off state of electronic device 1600, the relative positioning of components such as the display and keypad of electronic device 1600, changes in position of electronic device 1600 or a component of electronic device 1600, the presence or absence of user contact with electronic device 1600, orientation or acceleration / deceleration of electronic device 1600, and temperature changes of electronic device 1600. Sensor assembly 1614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1614 may also include a light sensor, such as a CMOS or CCD image sensor, configured for use in imaging applications. In some embodiments, sensor assembly 1614 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0230] Communication component 1616 is configured to facilitate wired or wireless communication between electronic device 1600 and other devices. Electronic device 1600 can access wireless networks based on communication standards, such as WiFi, 2G or 3G, 4G LTE, 5G NR (New Radio), or combinations thereof. In one exemplary embodiment, communication component 1616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0231] In an exemplary embodiment, the electronic device 1600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0232] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1604 including instructions, which can be executed by a processor 1620 of an electronic device 1600 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0233] Embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the electronic control unit upgrade method described in the above embodiments of this disclosure.

[0234] Embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements the electronic control unit upgrade method described in the above embodiments of this disclosure.

[0235] Figure 17 is a schematic diagram illustrating the structure of a chip 1700 for implementing the above-described electronic control unit upgrade method according to an exemplary embodiment. Referring to Figure 17, the chip 1700 includes at least one communication interface 1701 and a processor 1702; the communication interface 1701 is configured to receive signals input to the chip 1700 or signals output from the chip 1700, and the processor 1702 communicates with the communication interface 1701 and implements the electronic control unit upgrade method described in the above embodiments through logic circuits or executed code instructions.

[0236] Embodiments of this disclosure also propose a vehicle that includes an upgrade system for the aforementioned electronic control unit, or an upgrade device for the aforementioned electronic control unit, or the aforementioned electronic device, or the aforementioned chip.

[0237] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0238] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0239] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain.

[0240] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or otherwise processing it in a suitable manner if necessary, and then storing it in a computer memory.

[0241] It should be understood that various parts of the embodiments of this disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0242] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0243] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a hard disk, or an optical disk, etc.

[0244] Although embodiments of the present disclosure have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A method for upgrading an electronic control unit, the method comprising: In response to an upgrade command, the startup upgrade file is moved from the cache area to the first running area, and the startup upgrade file in the cache area is erased. The first running area is the region in the electronic control unit where the startup upgrade file is run. In the first running area, the startup loading upgrade file is written and the corresponding startup loading program is activated. The startup loading program is the executable program of the startup loading upgrade file. The application upgrade file is loaded into the cache area, and based on the startup loader, the application upgrade file is moved from the cache area to the second running area, wherein the second running area is the area in the electronic control unit where the application upgrade file runs, and both the application upgrade file and the startup loader upgrade file are files to be upgraded for the electronic control unit; In the second running area, the application upgrade file is flashed and completed.

2. The method according to claim 1, wherein, The step of responding to the upgrade command by moving the upgrade file from the cache to the first runtime area includes: In response to the upgrade command, the system initialization of the electronic control unit is performed; the validity of the startup loading upgrade file in the cache area is verified. If it is invalid, the movement flag of the startup loading upgrade file is set to failure. If it is valid, the original startup loading file is erased from the first running area and the startup loading upgrade file is moved in. In the first running area, the existence of the original startup loading file is earlier than that of the startup loading upgrade file.

3. The method according to claim 1 or 2, wherein, The step of responding to the upgrade command by moving the upgrade file from the cache to the first runtime area includes: Set the first write flag of the startup loading upgrade file to valid; Set the first movement flag of the startup loading upgrade file to successful; Erase the startup load upgrade file in the cache area.

4. The method according to claim 3, wherein, The step of writing the startup loading upgrade file and activating the corresponding startup loading program in the first running area includes: In the first running area, the startup loading upgrade file is written; In response to the startup command, if the first write identifier is valid, then according to the upgrade command or the first move identifier, it is confirmed that the startup loading upgrade file has been successfully written. In response to the activation command, check whether the startup loading upgrade file has been successfully flashed. If the flashing is successful, activate the startup loading program.

5. The method according to claim 4, wherein, The step of confirming that the startup loading upgrade file was successfully flashed based on the upgrade instruction or the first mobile identifier includes: Verify either the status of the upgrade command or the first mobility identifier; if the status of the upgrade command is valid or the first mobility identifier is successful, the verification passes, confirming that the startup loading of the upgrade file was successfully completed.

6. The method according to any one of claims 1 to 5, wherein, The step of loading the application upgrade file into the cache area, and then moving the application upgrade file from the cache area to the second runtime area based on the startup loader, includes: Set the second write flag of the application upgrade file to valid; set the second move flag of the application upgrade file to successful; erase the application upgrade file in the cache.

7. The method according to claim 6, wherein, The process of flashing the application upgrade file in the second running area includes: When the startup loader runs, the second movement identifier and the second write identifier are verified in the second running area; if the verification of the second movement identifier and the second write identifier passes, the application upgrade file is initialized; the application upgrade file is then flashed.

8. The method according to any one of claims 1 to 7, wherein, After the application upgrade file has been flashed, the process also includes: A dependency check is performed on the application upgrade file; if the dependency check passes, the upgrade of the electronic control unit is completed.

9. An upgrade system for an electronic control unit, the system comprising: The system consists of a first running area, a second running area, a cache area, and an updater partition, among which: The updater partition is configured as follows: In response to the upgrade command, the startup load upgrade file is moved from the cache to the first running area, so that the startup load upgrade file is written in the first running area; In response to the upgrade command, the application upgrade file is moved from the cache area to the second running area so that the application upgrade file is successfully flashed in the second running area.

10. The system according to claim 9, wherein, The system further includes a boot manager partition, wherein the boot manager partition is configured to store a boot manager, and the boot manager is configured to boot the first running area or the updater partition after being started.

11. The system according to claim 9 or 10, wherein, The first operating area is the region in the electronic control unit where the startup loading upgrade file is executed; the second operating area is the region in the electronic control unit where the application upgrade file is executed.

12. The system according to any one of claims 9 to 11, wherein, Both the application upgrade file and the startup loading upgrade file are upgrade files for the electronic control unit.

13. An upgrade device for an electronic control unit, the device comprising: The first moving module is configured to, in response to an upgrade command, move the startup loading upgrade file from the cache area to the first running area and erase the startup loading upgrade file in the cache area, wherein the first running area is the area in the electronic control unit where the startup loading upgrade file runs; The first flashing module is configured to flash the startup loading upgrade file and activate the corresponding startup loading program in the first running area. The startup loading program is the executable program of the startup loading upgrade file. The second moving module is configured to load the application upgrade file into the cache area and, based on the startup loading program, move the application upgrade file from the cache area to the second running area, wherein the second running area is the area in the electronic control unit where the application upgrade file runs, and both the application upgrade file and the startup loading upgrade file are files to be upgraded for the electronic control unit; The second flashing module is configured to flash the application upgrade file in the second running area.

14. An electronic device, comprising: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

15. A chip comprising at least one processor and a communication interface; the communication interface being configured to receive signals input to the chip or signals output from the chip, the processor communicating with the communication interface and implementing the method according to any one of claims 1-8 via logic circuitry or executable code instructions.

16. A vehicle comprising an upgrade system for an electronic control unit according to any one of claims 9-12, or an upgrade device for an electronic control unit according to claim 13, or comprising an electronic device according to claim 14, or comprising a chip according to claim 15.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-8.

Images