Upgrading method and device of electronic control unit, electronic equipment, chip and medium

Abstract

The invention provides an electronic control unit upgrading method and device, electronic equipment, a chip and a medium, and relates to the technical field of automotive electronics. The upgrading method of the electronic control unit comprises the following steps: in response to an upgrading instruction, moving a boot-load upgrading file from a cache region to a first running region, and erasing the boot-load upgrading file in the cache region; in the first running area, flashing the boot-load upgrading file and activating a corresponding boot-load program; loading the application program upgrading file into the cache region, and moving the application program upgrading file from the cache region to a second running region based on the starting loading program; in the second running area, the application program upgrading file is flashed and written. Through the technical scheme provided by the invention, the problem that bootloader upgrade is not supported or the ECU is unstable in the upgrade of the ECU is solved, support is provided for the bootloader upgrade in the ECU, and the stability of the ECU is improved.

Description

Technical Field

[0001] This disclosure relates to the field of automotive electronics technology, and in particular to a method, apparatus, electronic device, chip, and medium for upgrading an electronic control unit. Background Technology

[0002] 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

[0003] This disclosure aims to at least partially address one of the technical problems in the related art.

[0004] 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 bootloader upgrade in the ECU and improving the stability of the ECU.

[0005] A first aspect of this disclosure provides a method for upgrading an electronic control unit, the method comprising:

[0006] 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.

[0007] 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.

[0008] 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.

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

[0010] 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:

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

[0012] 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.

[0013] 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:

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

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

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

[0017] 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:

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

[0019] 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.

[0020] 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.

[0021] 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:

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

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

[0024] 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:

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

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

[0027] Erase application update files from the cache.

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

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

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

[0031] Flash the application update file.

[0032] In one embodiment of this disclosure, after flashing the application upgrade file, the method further includes:

[0033] Perform dependency checks on application upgrade files;

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

[0035] A second aspect of this disclosure provides an upgrade apparatus for an electronic control unit, the apparatus comprising:

[0036] The first moving module is used 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 that runs the startup loading upgrade file;

[0037] The first flashing module is used 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.

[0038] The second moving module is used 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.

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

[0040] A third aspect of this disclosure provides 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, the instructions being executed by the at least one processor to enable the at least one processor to perform any of the methods described in the first aspect of this disclosure.

[0041] A fourth aspect of this disclosure provides a chip including at least one processor and a communication interface; the communication interface is used 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 of any one of the first aspects of this disclosure through logic circuits or executing code instructions.

[0042] The seventh aspect of this disclosure provides a vehicle including an upgrade device for an electronic control unit according to the second aspect embodiment, an electronic device according to the third aspect embodiment, or a chip according to the fourth aspect embodiment.

[0043] 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 bootloader upgrades in ECUs. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of ECUs. By avoiding the complexity of ECUs caused by adding new storage space, it improves the stability of ECUs.

[0044] 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

[0045] 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.

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

[0047] Figure 2 This diagram illustrates ECU upgrades in bootloader and APP modes in related technologies.

[0048] Figure 3 This diagram illustrates ECU upgrades in BM, bootloader, and APP modes in related technologies.

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

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

[0051] Figure 6 This is a flowchart illustrating how, in response to an upgrade command, the startup loading upgrade file is moved from the cache to the first runtime area according to an embodiment of this disclosure;

[0052] Figure 7 This is a flowchart illustrating the process of setting up and erasing an upgrade file during startup, according to an embodiment of this disclosure.

[0053] Figure 8 This is a flowchart illustrating how, in one embodiment of the present disclosure, a startup loading upgrade file is written and the corresponding startup loading program is activated in the first running area.

[0054] Figure 9 This is a flowchart illustrating how, according to an upgrade command or a first mobile identifier, the successful loading and flashing of the upgrade file is confirmed in an embodiment of this disclosure.

[0055] Figure 10 This is a flowchart illustrating the process of setting up and erasing an application upgrade file, as described in an embodiment of this disclosure.

[0056] Figure 11 This is a flowchart illustrating the process of writing an application upgrade file in a second running area, according to an embodiment of this disclosure.

[0057] Figure 12 This is a flowchart illustrating a dependency check of an application upgrade file according to an embodiment of the present disclosure;

[0058] Figure 13 This is a flowchart illustrating an ECU upgrade process according to an embodiment of the present disclosure;

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

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

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

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

[0063] 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.

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

[0065] Bootloader: In this disclosure, a bootloader 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.

[0066] 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.

[0067] 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.

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

[0069] Figure 1 This is a schematic diagram of the ECU upgrade process in related technologies. For example... Figure 1 As shown, in the ECU, 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, it performs a file dependency check 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 the application file and does not demonstrate BT's own upgrade capabilities and requirements.

[0070] Figure 2 This diagram illustrates ECU upgrades in bootloader and APP modes in related technologies. Figure 2 As shown, the flash memory partition of the ECU chip only contains a bootloader file area and an application file area. 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 flashing 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 file area. The bootloader 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 write is successful. A reset command is then used to make the written data effective. Although this solution has low requirements for flash resources, it has the following drawbacks: 1. If the bootloader file has a bug, the ECU cannot be upgraded. 2. There is no backup file for the application file, meaning that if the ECU upgrade fails, the application file's functionality is lost.

[0071] Figure 3 This diagram illustrates ECU upgrades in BM, bootloader, and APP modes in related technologies. Figure 3As shown, the flash partitions of the ECU chip include a boot manager partition, a boot loader file partition, a boot loader 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 loader file area, erases the boot loader file partition or the boot loader file backup partition, and then writes the data to the application file backup partition or the boot loader 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 loader file in the boot loader file backup partition is transferred to the boot loader file partition, and the application file in the application file backup partition is transferred to the application file partition. Finally, the executable program in the boot manager partition jumps to the application 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 boot failure 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.

[0072] In summary, among the related technologies, ECU upgrades have issues such as not supporting bootloader upgrades or ECU instability.

[0073] This disclosure aims to solve the problems of bootloader 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 file in the bootloader partition, and activates the bootloader to upgrade the application programs. This completes the upgrade of the bootloader in the ECU, ensuring that both the ECU's bootloader and application files are upgraded, thus improving ECU stability.

[0074] 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, specifically including:

[0075] 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.

[0076] 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.

[0077] 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.

[0078] OTA Updates: With the development of intelligent vehicle technology, OTA (Over-The-Air) updates have become an important trend in the automotive industry. OTA technology allows for remote upgrades to a vehicle's ECU, providing users with the latest software version and fixing known issues. The startup loader upgrade is one of the key technologies for implementing OTA updates.

[0079] 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.

[0080] 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.

[0081] 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.

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

[0083] Figure 4 This is a flowchart illustrating an electronic control unit upgrade method according to an embodiment of the present disclosure. The method is executed in the overall electronic control unit of the vehicle and its individual sub-electronic control units. Figure 4 The embodiment shown illustrates an upgrade method for the electronic control unit that includes:

[0084] 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.

[0085] 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 and the APP can be further upgraded. After the user triggers the APP upgrade command, the APP upgrade is completed. APP updates can only be completed based on the successful flashing of the bootloader.

[0086] The bootloader upgrade file refers to a new file that upgrades the bootloader file. 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.

[0087] Upon receiving the user's upgrade commands for the ECU's bootloader and the application, 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 by subsequent application upgrade files.

[0088] 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.

[0089] In this embodiment, the bootloader refers to the executable program that loads the upgrade file. The upgrade file is flashed in the first running area. The bootloader corresponding to this upgrade file is then activated, completing the bootloader upgrade in the ECU.

[0090] 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.

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

[0092] After the ECU bootloader upgrade is complete, since the bootloader upgrade file has been cleared from the cache before the APP upgrade file is loaded, the APP upgrade file is loaded into the cache, thus reusing the cache's storage space without needing to add flash storage, reducing the ECU upgrade cost. 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.

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

[0094] 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.

[0095] 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) in the ECU. The application upgrade file is loaded into the cache area. Based on the bootloader 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 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 bootloader upgrades in ECUs. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of ECUs. By avoiding the complexity of ECUs caused by adding new storage space, it improves the stability of ECUs.

[0096] Figure 5 This is a schematic diagram of an ECU upgrade in BM, bootloader, and APP modes according to an embodiment of this disclosure. Figure 5 As shown, the ECU's flash partitions include a boot manager partition, a bootloader file partition, an application file partition, a backup partition, and an updater partition. The backup partition stores backup files of the application files or bootloader files, while the updater partition stores the updaters for the application files or bootloader files. After the boot manager starts, it jumps to the updater partition. This updater monitors whether the bootloader or application needs an upgrade. If an upgrade is required, it moves the corresponding update package. In response to the upgrade command, it moves the bootloader upgrade file from the backup partition to the bootloader file partition, flashes the bootloader upgrade file to the bootloader file partition, and activates it, completing the ECU's bootloader upgrade. After the bootloader function runs, the data received from the diagnostic tool is stored in the backup partition. At this point, the received data is the application file. After receiving the data, it jumps back to the updater partition, where the updater moves the application to the application file partition, thus ensuring the ECU update is complete.

[0097] Figure 6This is a flowchart illustrating how, in response to an upgrade command, the startup loading upgrade file is moved from the cache to the first runtime area, according to an embodiment of this disclosure. Figure 6 Yes Figure 4 Further explanation of step 401, based on Figure 6 The illustrated embodiment includes the following steps:

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

[0099] 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.

[0100] 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.

[0101] In this embodiment, the move identifier of the startup load upgrade file refers to an identifier indicating whether the startup load upgrade file can be used for the move operation. If it can be used to move the startup load upgrade file, 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, that is, 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, then the move identifier of the startup load upgrade file is set to failure. If the startup load upgrade file in the buffer is valid, then 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 area to the first running area according to the upgrade command, accurately preparing for the startup load upgrade file to be written to the first running area.

[0102] Figure 7 This is a flowchart illustrating the process of setting up and erasing an upgrade file during startup, as described in an embodiment of this disclosure. Figure 7 Yes Figure 6 Further explanation following step 602, based on Figure 7 The illustrated embodiment includes the following steps:

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

[0104] In this embodiment, the first write flag refers to the status flag indicating that the bootloader upgrade file can be written to the target partition. After erasing the original bootloader file in the first running area and moving in the bootloader upgrade file, the first write flag of the bootloader upgrade file is set to valid. This indicates that the bootloader upgrade file can be written to the first running area.

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

[0106] In this embodiment, the first move identifier refers to the result identifier of the boot load upgrade file being moved to the first running partition. Since the boot load upgrade file has been successfully moved into the first running partition, the first move identifier is set to success.

[0107] Step 703: Erase the startup load upgrade files in the cache area.

[0108] In this embodiment, after the startup loading upgrade file is moved from the cache area to the first running partition, 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.

[0109] Figure 8 This is a flowchart illustrating how, in one embodiment of the present disclosure, a startup loading upgrade file is written and the corresponding startup loading program is activated in the first running area. Figure 8 Yes Figure 7 and Figure 4 The specific explanation of step 402 is based on Figure 8 The illustrated embodiment includes the following steps:

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

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

[0112] 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.

[0113] 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 partition. 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 move flag, it confirms that the startup loading upgrade file has been successfully written to the first running partition. Specifically, the upgrade command is valid, and the first move flag is successful.

[0114] 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.

[0115] 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 to the first running partition. If the flashing is successful, the bootloader is activated, that is, the bootloader is executed. Thus, the bootloader upgrade in the ECU is successfully achieved.

[0116] Figure 9 This is a flowchart illustrating how, according to an upgrade command or a first mobile identifier, the successful loading and flashing of the upgrade file is confirmed. Figure 9 Yes Figure 8 The specific explanation of step 802 is based on Figure 9 The illustrated embodiment includes the following steps:

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

[0118] In this embodiment, during the process of confirming that the upgrade file has been successfully written to the first running partition, 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.

[0119] 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.

[0120] In this embodiment, if the upgrade command is valid, the verification passes; if the first movement identifier is successful, the verification passes; if both the upgrade command and the first movement identifier are successful, the verification passes, confirming successful loading and flashing of the upgrade file. The upgrade of the bootloader in the ECU is verified.

[0121] Figure 10 This is a flowchart illustrating the setting and erasing of an application upgrade file, as described in an embodiment of this disclosure.

[0122] Figure 10 Yes Figure 4 The specific explanation following step 403 is based on Figure 10 The illustrated embodiment includes the following steps:

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

[0124] In this embodiment, the second write flag refers to a status flag indicating that the application upgrade file can be written to the target partition. After erasing the original application file in the second running area and moving in the application upgrade file, the second write flag of the application upgrade file is set to valid. This indicates that the application upgrade file can be written to the second running area.

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

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

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

[0128] In this embodiment, after the application upgrade file is moved from the cache area to the second running partition, 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.

[0129] Figure 11 This is a flowchart illustrating the process of writing an application upgrade file in the second running area, as described in one embodiment of this disclosure. Figure 11 Yes Figure 10 and Figure 4 The specific explanation of step 404 is based on Figure 11 The illustrated embodiment includes the following steps:

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

[0131] 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.

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

[0133] 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.

[0134] Step 1103: Flash the application upgrade file.

[0135] 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.

[0136] Figure 12 This is a flowchart illustrating a dependency check of an application upgrade file according to an embodiment of the present disclosure. Figure 12 Yes Figure 11 The specific explanation following step 1103 is based on Figure 12 The illustrated embodiment includes the following steps:

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

[0138] 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.

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

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

[0141] Figure 13 This is a flowchart illustrating an ECU upgrade process according to an embodiment of this disclosure. Figure 13 As shown, the ECU's flash partitions are divided into the First Operating Area (BT), the Second Operating Area (APP), the Updater Partition, and the Startup Manager Partition (BM). The diagram records and explains each step in the ECU upgrade process. Steps occurring in the BM are identified by labels such as A1, A2, A3, and A4; steps occurring in the First Operating Area (BT) are identified by labels such as B1, B2, B3, ..., B11; steps occurring in the Second Operating Area are identified by labels such as C1 and C2; and steps occurring in the Updater Partition are identified by labels such as D1, D2, B3, ..., D9.

[0142] in,

[0143] The steps within BM are as follows:

[0144] 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.

[0145] 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.

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

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

[0148] The steps within BT are as follows:

[0149] 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.

[0150] 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., B4.

[0151] 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.

[0152] Step B4: Determine the BT transfer flag. If the "BT transfer flag" is in a "successful" state, it means the BT has been successfully activated and proceed to B5; if the flag is in a "failure" state, it means the new BT activation failed and proceed to B6; if it is in an "other state" (neither successful nor failed), it means that the BT was not upgraded in this upgrade and directly determine the "APP transfer flag," i.e., step B8.

[0153] 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.

[0154] 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.

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

[0156] 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.

[0157] 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.

[0158] 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.

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

[0160] 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 D2; if it contains APP files, it jumps to D3.

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

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

[0163] 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, jump to D10. If the transfer is complete, jump to D6.

[0164] Step D6: After the 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 the reset, it will boot into BT, where subsequent processing will be performed.

[0165] 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.

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

[0167] 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 D7.

[0168] 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, reset, and after the reset, it will boot into BT, where subsequent processing will be performed.

[0169] Step D9: If writing to the APP transfer flag fails, then initiate self-destruction (erase the updater partition), delete cache data, and reset. After resetting, it will boot into BT, where subsequent processing will be performed.

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

[0171] 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.

[0172] 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.

[0173] Figure 14 This is a schematic diagram of an ECU upgrade process according to an embodiment of this disclosure. Figure 14 As shown, in the ECU, 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, while simultaneously monitoring the completion of the transmission of all BT-related files. If the transmission of all files is incomplete, the remaining BT-related files continue to be transmitted. If all files are transmitted successfully, the transmitted BT is activated. If BT activation fails, the bootloader upgrade fails. If BT activation succeeds, the APP upgrade file continues to be transmitted, and the transmission of the APP upgrade file is checked for completion. If the APP upgrade file is not transmitted successfully, the transmission of the APP upgrade file continues until it is completely transmitted. If the APP upgrade file has been transmitted successfully, 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.

[0174] 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 bootloader upgrades 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 added 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 device. Since the device provided in this disclosure corresponds to the methods provided in the above embodiments, the implementation methods are also applicable to the device provided in this embodiment, and will not be described in detail in this embodiment.

[0175] Figure 15 This is a schematic diagram of the structure of an electronic control unit upgrade device 1500 according to an embodiment of this disclosure. Figure 15 As shown, the upgrade device for the electronic control unit includes:

[0176] The first moving module 1510 is used to respond to an upgrade command by moving the startup loading upgrade file from the cache area to the first running area and erasing the startup loading upgrade file in the cache area. The first running area is the area in the electronic control unit where the startup loading upgrade file is run.

[0177] The first flashing module 1520 is used 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.

[0178] The second moving module 1530 is used 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.

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

[0180] In some embodiments, the first moving module 1510 is used for:

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

[0182] 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.

[0183] 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:

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

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

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

[0187] In some embodiments, the first write module 1520 is used for:

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

[0189] 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.

[0190] 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.

[0191] In some embodiments, the first flashing module 1520 confirms successful flashing of the upgrade file based on the upgrade command or the first movement identifier in the following manner:

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

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

[0194] 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:

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

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

[0197] Erase application update files from the cache.

[0198] In some embodiments, the second writing module 1540 is used for:

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

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

[0201] Flash the application update file.

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

[0203] Perform dependency checks on application upgrade files;

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

[0205] 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 bootloader upgrades in ECUs. By reusing the cache area, it avoids allocating additional storage space for application upgrade files, reducing the upgrade cost of ECUs. By avoiding the complexity of ECUs caused by adding new storage space, it improves the stability of ECUs.

[0206] 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.

[0207] Figure 16 This is a block diagram of an electronic device 1600 for implementing the above-described electronic control unit upgrade method, according to an exemplary embodiment.

[0208] For example, electronic device 1600 can be a mobile phone, computer, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0209] Reference Figure 16 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.

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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 for outputting audio signals.

[0215] 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.

[0216] Sensor assembly 1614 includes one or more sensors for providing 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, the 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, for use in imaging applications. In some embodiments, sensor assembly 1614 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0217] 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 (NewRadio), 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.

[0218] 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.

[0219] 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.

[0220] 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.

[0221] Embodiments of this disclosure also provide a computer program product, including a computer program that is executed by a processor to perform an upgrade method for an electronic control unit as described in the above embodiments of this disclosure.

[0222] Figure 17 This is a schematic diagram of the structure of a chip 1700 for implementing the above-described electronic control unit upgrade method, according to an exemplary embodiment.

[0223] Reference Figure 17 The chip 1700 includes at least one communication interface 1701 and a processor 1702; the communication interface 1701 is used 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 executing code instructions.

[0224] Embodiments of this disclosure also propose a vehicle that includes an upgrade device for the aforementioned electronic control unit.

[0225] 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.

[0226] 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.

[0227] 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.

[0228] 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, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0229] 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.

[0230] 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.

[0231] 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.

[0232] 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, characterized in that, The method includes: 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, characterized in that, 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 system verifies whether the startup loading upgrade file in the cache is valid. 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 original startup loading file existed before the startup loading upgrade file.

3. The method according to claim 1, characterized in that, 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, characterized in that, 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, characterized in that, 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 instruction or the first movement identifier; If the status of the upgrade instruction is valid or the first mobile identifier is successful, the verification passes, confirming that the startup loading of the upgrade file was successfully completed.

6. The method according to claim 1, characterized in that, 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 area.

7. The method according to claim 6, characterized in that, 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 second mobile identifier and the second write identifier pass verification, then the application upgrade file is initialized; Flash the application upgrade file.

8. The method according to claim 7, characterized in that, After flashing the application upgrade file, the process also includes: Perform dependency checks on the application upgrade files; If the dependency check passes, the upgrade of the electronic control unit is complete.

9. An upgrade device for an electronic control unit, characterized in that, The device includes: A 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 region in the electronic control unit where the startup loading upgrade file is run; The first flashing module is used to flash the startup loading upgrade file in the first running area and activate the corresponding startup loading program, wherein the startup loading program is the executable program of the startup loading upgrade file; The second moving module is used 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 used to flash the application upgrade file in the second running area.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. A chip, characterized in that, It includes at least one processor and a communication interface; the communication interface is used 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 according to any one of claims 1-8 through logic circuits or executing code instructions.

12. A vehicle, characterized in that, The device may include an upgrade device for the electronic control unit as described in claim 9, or an electronic device as described in claim 10, or a chip as described in claim 11.

Images