Controller upgrade method, apparatus, and vehicle

Abstract

This application provides a controller upgrade method, apparatus, and vehicle. The controller includes a storage area, which includes a first startup mode header and a second startup mode header. The first startup mode header is used to indicate at least a first partition, which is a running storage area. The second startup mode header is used to indicate at least a second partition, which is a non-running storage area. The method includes: obtaining a first upgrade file, which includes a bootloader BL program upgrade package; and performing an upgrade operation based on the BL program upgrade package. This controller upgrade method is compatible with different types of ECUs, thereby improving the efficiency of BL firmware upgrades and reducing upgrade risks.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicles, and more specifically, to a controller upgrade method, apparatus, and vehicle. Background Technology

[0002] As smart cars become more widely used in daily life, users expect them and their related devices to provide a more comfortable and intelligent experience. To meet these needs, automakers and suppliers are constantly increasing the types and number of electronic control units (ECUs) in smart cars. These ECUs need to be initialized and loaded via a bootloader (BL) to ensure that the software functions properly and to achieve system security, stability, and remote upgrade capabilities.

[0003] Currently, with the rapid evolution of software systems in terms of top-level functions and features, the level of vehicle intelligence is constantly improving. This rapid development also places higher demands on the underlying firmware for adaptation, requiring continuous optimization and updates to related basic software, drivers, and underlying communication protocols to ensure system stability and compatibility. This high-frequency adaptation and iteration process inevitably introduces new security vulnerabilities, which need to be addressed by upgrading the bootloader firmware.

[0004] However, current BL firmware upgrade solutions have poor applicability, mainly due to insufficient compatibility, complex upgrade processes, and security challenges. Therefore, designing a more flexible, secure, and efficient BL firmware upgrade solution to reduce the upgrade risks of BL firmware is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a controller upgrade method, apparatus, and vehicle. The controller upgrade method is compatible with different types of ECUs, thereby improving the efficiency of BL firmware upgrades and reducing upgrade risks.

[0006] In a first aspect, a controller upgrade method is provided. The controller includes a storage area, which includes a first boot mode header and a second boot mode header. The first boot mode header is used to indicate at least a first partition, which is a running storage area. The second boot mode header is used to indicate at least a second partition, which is a non-running storage area. The method includes: obtaining a first upgrade file, which includes a bootloader (BL) program upgrade package; and performing an upgrade operation based on the BL program upgrade package.

[0007] In one possible implementation, the storage area in the controller can refer to the physical storage space inside or outside the chip used to store program code, configuration data, and runtime information. It can include flash memory, random access memory (RAM), or registers, which together support the startup, execution, and function implementation of the controller.

[0008] In one possible implementation, data fields (e.g., boot partition flags) in the first boot mode header and the second boot mode header can be used to indicate the corresponding partition.

[0009] In one possible implementation, the controller performing the upgrade operation based on the BL program upgrade package may include: the controller performing a flashing operation on the second BL program based on the BL program upgrade package.

[0010] In one possible implementation, the controller can refer to the ECU, which is a specific implementation of the controller and is widely used in various modules of automobiles such as powertrain, body control, and infotainment.

[0011] In this embodiment, different boot mode headers indicate different partitions, facilitating dynamic software-level indication of the partition to be loaded during controller startup after BL program upgrade. This enables flexible switching between the running storage area and the non-running storage area, allowing controllers that do not support hardware dual partitions to exhibit hardware dual partition characteristics. In this way, the controller upgrade method is compatible with different types of ECUs, improving the efficiency of BL firmware upgrades and reducing upgrade risks without changing the hardware architecture.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the BL program upgrade package includes the upgrade package of the first BL program in the first partition. Based on the BL program upgrade package, the upgrade operation is performed, including: flashing without executing the upgrade package of the first BL program.

[0013] In this embodiment of the application, since the first partition is the running storage area, when the BL program upgrade package includes the upgrade package of the first BL program in the first partition, the program package of the first BL program is not flashed. This can avoid the situation where the program fails to start or the system crashes due to the flashing of the startup code that is currently in use, thus ensuring the stability and security of the current code running environment and reducing the risks in the upgrade process.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending a first response message to the installation module, the first response message being used to indicate that the BL program upgrade package has been successfully flashed.

[0015] In this embodiment of the application, when the BL program upgrade package includes the upgrade package of the first BL program in the first partition, without executing the first BL program flashing, the controller can send a "flashing successful" status to the installation module according to the preset logic to mark the completion of this round of upgrade tasks. In this way, the continuity and stability of the entire upgrade process can be ensured, and the risks in the upgrade process can be further reduced.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the first startup mode header includes a first cyclic redundancy check (CRC) check range, the BL program upgrade package includes an upgrade package of the second BL program in the second partition, or the BL program upgrade package includes an upgrade package of the first BL program in the first partition and an upgrade package of the second BL program; according to the BL program upgrade package, an upgrade operation is performed, including: upgrading the second BL program according to the upgrade package of the second BL program, adjusting the first CRC check range to the second CRC check range, and the CRC check performed by the controller in the second CRC check range failing.

[0017] In this embodiment, when the BL program upgrade package includes a second BL program upgrade package, or includes a first BL program package and a second BL program upgrade package, after the controller completes the upgrade of the second BL program using the second BL program upgrade package, it can adjust the first CRC check range corresponding to the first boot mode header to the second CRC check range. This prevents the first BL program from jumping to the running storage area when it starts, thereby realizing flexible switching between the running storage area and the non-running storage area. This allows the controller, which does not support hardware dual partitioning, to exhibit the characteristics of supporting hardware dual partitioning, ensuring that the controller upgrade method is compatible with different types of ECUs.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, the first upgrade file further includes first version information of the BL program upgrade package. Before upgrading the second BL program according to the upgrade package of the second BL program, the method further includes: obtaining second version information of the second BL program; upgrading the second BL program according to the upgrade package of the second BL program, including: upgrading the second BL program according to the upgrade package of the second BL program if the first version information and the second version information do not match.

[0019] In one possible implementation, if the first version information and the second version information match, the controller can discard the BL program upgrade package and skip the upgrade process of the second BL program.

[0020] In this embodiment, before upgrading the second BL program based on the upgrade package of the second BL program, the controller can pre-confirm whether the second version information of the second BL program to be upgraded matches the first version information in the upgrade file. This avoids unnecessary upgrade operations even when the version information matches, thereby reducing the number of times the controller needs to be rewritten and extending the controller's rewrite lifespan.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the first upgrade file further includes a first hash value of the BL program upgrade package. Before upgrading the second BL program according to the upgrade package of the second BL program, the method further includes: obtaining a second hash value of the second BL program; upgrading the second BL program according to the upgrade package of the second BL program, including: upgrading the second BL program according to the upgrade package of the second BL program if the first hash value and the second hash value do not match.

[0022] In one possible implementation, if the first hash value and the second hash value match, the controller can discard the BL program upgrade package and skip the upgrade process of the second BL program.

[0023] In this embodiment, since the hash value serves as an identifier for the integrity and uniqueness of firmware content, it can effectively reflect whether the program version or content has changed. Before the controller upgrades the second BL program based on the upgrade package of the second BL program, it can pre-confirm whether the second hash value of the second BL program to be upgraded matches the first hash value in the upgrade file. If the two hash values ​​do not match, it indicates that the BL program to be upgraded does not match the target BL program in the upgrade package in terms of actual content, and the upgrade process can be executed. This processing method can effectively avoid unnecessary flashing and rebooting of storage areas, improving the efficiency and reliability of BL firmware upgrades.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, before obtaining the first upgrade file, the method further includes: receiving a first request message sent by the installation module, the first request message being used to request reading the version information and / or hash value of the second BL program; and sending a second response message to the installation module according to the first request message, the second response message including second version information and / or a second hash value.

[0025] In this embodiment, the controller can send a second response message to the installation module, enabling the installation module to obtain the second version information and / or the second hash value of the second BL program in the controller's non-running storage area. This facilitates the installation module in determining the specific contents of the BL program upgrade package based on the second version information and / or the second hash value.

[0026] In conjunction with the first aspect, in some implementations of the first aspect, the second startup mode header includes a third CRC check range, and the method further includes: adjusting the third CRC check range to a fourth CRC check range, and the CRC check performed by the controller in the fourth CRC check range passes.

[0027] In this embodiment, after the controller completes the upgrade of the second BL program using the second BL program upgrade package, it can adjust the third CRC check range corresponding to the second startup mode header so that the second BL program jumps to the running storage area when it starts, thereby realizing flexible switching between the non-running storage area and the running storage area. This makes the controller, which does not support hardware dual partitioning, exhibit the characteristics of supporting hardware dual partitioning, ensuring that the controller upgrade method can be compatible with different types of ECUs.

[0028] In conjunction with the first aspect, in some implementations of the first aspect, the first upgrade file further includes an application upgrade package and / or a calibration component upgrade package, and the method further includes: upgrading the application in the second partition according to the application upgrade package, and / or upgrading the calibration component in the second partition according to the calibration component upgrade package.

[0029] In one possible implementation, the calibration component can be used to store adjustable parameters and configuration data, enabling the controller to flexibly fine-tune and dynamically optimize its functions without modifying or rewriting the main program code. Through the configuration of the calibration component, developers or calibration engineers can adjust parameters during system operation or remotely to meet the differences in operating conditions, product models, or user needs, achieving rapid iteration and precise control of the controller.

[0030] In this embodiment of the application, in addition to the BL program upgrade package, the first upgrade file may also include an application upgrade package and a calibration component upgrade package. In this way, the controller can complete the upgrade of the BL program and other functional components in one upgrade process, avoiding the problem of incompatibility between the BL program, application version and calibration component, and improving the upgrade reliability of the controller.

[0031] In conjunction with the first aspect, in some implementations of the first aspect, the content of the upgrade package of the BL program is associated with the type of controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first and second partitions of the second hardware form are different. Before obtaining the first upgrade file, the method further includes: sending first type information, which is used to indicate that the controller type is one of the three hardware forms.

[0032] In this embodiment, the controller can report its type to the server, which facilitates the server in generating a corresponding BL program upgrade package based on the controller type. This effectively avoids upgrade failures caused by incompatible upgrade packages and further improves the upgrade efficiency of the controller.

[0033] In conjunction with the first aspect, in some implementations of the first aspect, the BL program upgrade package also includes an upgrade address. Upgrading the second BL program in the second partition according to the upgrade package of the second BL program includes: determining a first erase address according to the upgrade address, the first erase address being the address for erasing the second BL program; erasing the content at the first erase address; and burning the data of the upgrade package of the second BL program into the storage area where the program code corresponding to the first erase address runs.

[0034] In this embodiment, during the upgrade process of the controller BL program upgrade package to the second BL program, the controller can parse the upgrade address in the upgrade file to obtain the first erase address, and burn the data of the second BL program upgrade package into the storage area where the program code corresponding to the first erase address runs, thereby completing the upgrade of the second BL program. This processing method helps to ensure the upgrade effect of the BL program and improves the upgrade success rate of the BL program.

[0035] In conjunction with the first aspect, in some implementations of the first aspect, the first upgrade file further includes a first description information or a second description information of the BL program upgrade package. The first description information is used to instruct the controller to enable the BL program upgrade function, and the second description information is used to instruct the controller not to enable the BL program upgrade function. The first description information corresponds to the first OTA signature of the BL program upgrade package, and the second description information corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different. According to the BL program upgrade package, the upgrade operation is performed, including: if the first upgrade file includes the first description information, performing the upgrade operation according to the BL program upgrade package.

[0036] In this embodiment of the application, the application of the first description information enables the controller to start the BL program upgrade function. In this way, the timing of the controller's BL firmware upgrade function can be precisely controlled to avoid misoperation or unexpected upgrades, thereby further reducing the upgrade risk of the controller.

[0037] Secondly, a controller upgrade method is provided, the method comprising: obtaining a first upgrade file, the first upgrade file including a BL program upgrade package; sending the first upgrade file to the controller; wherein the controller includes a storage area, the storage area including a first boot mode header and a second boot mode header, the first boot mode header being used to indicate a first partition, the first partition being a running storage area, and the second boot mode header being used to indicate a second partition, the second partition being a non-running storage area.

[0038] In this embodiment, the installation module can send a first upgrade file to the controller, which can then use this file to upgrade the bootloader (BL) program. Because the controller uses different boot mode headers to indicate different partitions, it facilitates dynamic software-level indication of the partition to be loaded upon controller startup after the BL program upgrade. This enables flexible switching between the running storage area and the non-running storage area, allowing controllers that do not support hardware dual partitions to exhibit hardware dual partitioning characteristics. In this way, the controller upgrade method is compatible with different types of ECUs, improving the efficiency of BL firmware upgrades and reducing upgrade risks without changing the hardware architecture.

[0039] In conjunction with the second aspect, in some implementations of the second aspect, the BL program upgrade package includes the upgrade package of the first BL program in the first partition, or the BL program upgrade package includes the upgrade package of the second BL program in the second partition, or the BL program upgrade package includes the upgrade package of the first BL program and the upgrade package of the second BL program.

[0040] In this embodiment, the installation module can send a specific BL program upgrade package to the controller based on the controller type. In this way, the transmission of the BL program upgrade package can be more targeted, thereby improving the reliability of controller upgrades.

[0041] In conjunction with the second aspect, in some implementations of the second aspect, the first upgrade file also includes the first version information and / or the first hash value of the BL program upgrade package. Sending the first upgrade file to the controller includes: sending the first upgrade file to the controller if the first version information and the second version information do not match, and / or the first hash value does not match the second hash value.

[0042] In this embodiment, before sending the first upgrade file to the controller, the installation module can determine whether the version information and / or hash value in the BL program package matches the version information and / or hash value of the BL program to be upgraded on the controller. This avoids sending the first upgrade file to the controller even when the version information or hash value matches, preventing the controller from performing unnecessary upgrade operations, thereby reducing the number of times the controller needs to be rewritten and extending its lifespan.

[0043] In conjunction with the second aspect, in some implementations of the second aspect, the first upgrade file also includes an application upgrade package and / or a calibration component upgrade package, wherein the application upgrade package is used for upgrading applications in the second partition, and the calibration component upgrade package is used for upgrading calibration components in the second partition.

[0044] In this embodiment of the application, in addition to the BL program upgrade package, the first upgrade file may also include an application upgrade package and a calibration component upgrade package. In this way, the controller can complete the upgrade of the BL program and other functional components in one upgrade process, avoiding the problem of incompatibility between the BL program, application version and calibration component, and improving the upgrade reliability of the controller.

[0045] In conjunction with the second aspect, in some implementations of the second aspect, obtaining the first upgrade file includes: generating the first upgrade file.

[0046] In one possible implementation, the process of generating the first upgrade file may include merging the BL program upgrade packages, for example, merging the first BL program upgrade package and the second BL program upgrade package into a single BL program upgrade package.

[0047] In conjunction with the second aspect, in some implementations of the second aspect, the content of the upgrade package of the BL program is associated with the type of the controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first and second partitions of the second hardware form are different. Before generating the first upgrade file, the method includes: receiving first type information sent by the controller, the first type information indicating that the controller type is one of the three hardware forms; generating the first upgrade file, including: generating the first upgrade file according to the first type information.

[0048] In this embodiment, the server can generate a corresponding BL program upgrade package based on the controller type reported by the controller, and send a first upgrade file including the BL program upgrade package to the controller. This effectively avoids upgrade failures caused by upgrade package mismatches and further improves the controller's upgrade efficiency.

[0049] In conjunction with the second aspect, in some implementations of the second aspect, sending the first upgrade file to the controller includes: sending the first upgrade file to the controller via a diagnostic tool or an over-the-air (OTA) management platform.

[0050] In this embodiment, the server can send the first upgrade file to the controller via a diagnostic tool or an OTA management platform. In this way, the server can flexibly choose the method of sending the upgrade file based on different upgrade scenarios, thereby achieving efficient, accurate and secure upgrades to the controller program.

[0051] In conjunction with the second aspect, in some implementations of the second aspect, the first upgrade file further includes a first description information or a second description information of the BL program upgrade package. The first description information is used to instruct the controller to enable the BL program upgrade function, and the second description information is used to instruct the controller not to enable the BL program upgrade function. The first description information corresponds to the first OTA signature of the BL program upgrade package, and the second description information corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different.

[0052] Thirdly, a controller upgrade device is provided, comprising: an acquisition unit and a processing unit; the acquisition unit is used to acquire a first upgrade file, the first upgrade file including a bootloader (BL) program upgrade package; the processing unit is used to perform an upgrade operation according to the BL program upgrade package.

[0053] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is also used for flashing the upgrade package without executing the first BL program.

[0054] In conjunction with the third aspect, in some implementations of the third aspect, the device further includes: a transceiver unit, used to send a first response information to the installation module, the first response information being used to indicate that the BL program upgrade package has been successfully flashed.

[0055] In conjunction with the third aspect, in some implementations of the third aspect, the first startup mode header includes a first cyclic redundancy check (CRC) check range, the BL program upgrade package includes an upgrade package of the second BL program in the second partition, or the BL program upgrade package includes an upgrade package of the first BL program in the first partition and an upgrade package of the second BL program; the processing unit is specifically used to upgrade the second BL program according to the upgrade package of the second BL program, and adjust the first CRC check range to the second CRC check range, and the CRC check performed by the controller in the second CRC check range fails.

[0056] In conjunction with the third aspect, in some implementations of the third aspect, the first upgrade file also includes first version information of the BL program upgrade package; the acquisition unit is also used to acquire second version information of the second BL program; the processing unit is specifically used to upgrade the second BL program according to the upgrade package of the second BL program when the first version information and the second version information do not match.

[0057] In conjunction with the third aspect, in some implementations of the third aspect, the first upgrade file also includes a first hash value of the BL program upgrade package; the acquisition unit is also used to acquire a second hash value of the second BL program; and the processing unit is specifically used to upgrade the second BL program according to the upgrade package of the second BL program when the first hash value and the second hash value do not match.

[0058] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is further configured to receive a first request message sent by the installation module, the first request message being used to request the reading of the version information and / or hash value of the second BL program; the processing unit is further configured to send a second response message to the installation module according to the first request message, the second response message including second version information and / or second hash value.

[0059] In conjunction with the third aspect, in some implementations of the third aspect, the second startup mode header includes a third CRC check range, a processing unit, and is also used to adjust the third CRC check range to a fourth CRC check range, and the CRC check performed by the controller in the fourth CRC check range passes.

[0060] In conjunction with the third aspect, in some implementations of the third aspect, the first upgrade file further includes an application upgrade package and / or a calibration component upgrade package, and the processing unit is further configured to upgrade the application in the second partition according to the application upgrade package, and / or upgrade the calibration component in the second partition according to the calibration component upgrade package.

[0061] In conjunction with the third aspect, in some implementations of the third aspect, the content of the upgrade package of the BL program is associated with the type of controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components of the first and second partitions in the second hardware form are different. The transceiver unit is also used to send first type information, which is used to indicate that the controller type is one of the three hardware forms.

[0062] In conjunction with the third aspect, in some implementations of the third aspect, the BL program upgrade package also includes an upgrade address and a processing unit, which are further used to: determine a first erase address based on the upgrade address, wherein the first erase address is the address for erasing the second BL program; erase the content at the first erase address, and burn the data of the upgrade package of the second BL program into the storage area where the program code corresponding to the first erase address runs.

[0063] In conjunction with the third aspect, in some implementations of the third aspect, the first upgrade file also includes a first description information or a second description information of the BL program upgrade package. The first description information is used to instruct the controller to enable the BL program upgrade function, and the second description information is used to instruct the controller not to enable the BL program upgrade function. The first description information corresponds to the first OTA signature of the BL program upgrade package, and the second description information corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different. The processing unit is specifically used to perform an upgrade operation according to the BL program upgrade package when the first upgrade file includes the first description information.

[0064] Fourthly, a controller upgrade device is provided, comprising: an acquisition unit and a transceiver unit, wherein the transceiver unit is used to send a first upgrade file to the controller; wherein the controller includes a storage area, the storage area including a first startup mode header and a second startup mode header, the first startup mode header being used to indicate a first partition, the first partition being a running storage area, and the second startup mode header being used to indicate a second partition, the second partition being a non-running storage area.

[0065] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the BL program upgrade package includes the upgrade package of the first BL program in the first partition, or the BL program upgrade package includes the upgrade package of the second BL program in the second partition, or the BL program upgrade package includes the upgrade package of the first BL program and the upgrade package of the second BL program.

[0066] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is further configured to: send a first request message to the controller, the first request message being used to request the reading of the version information and / or hash value of the second BL program in the second partition; and receive a first response message sent by the controller, the first response message including the second version information and / or the second hash value of the second BL program.

[0067] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first upgrade file also includes the first version information and / or the first hash value of the BL program upgrade package. The transceiver unit is specifically used to send the first upgrade file to the controller when the first version information and the second version information do not match, and / or the first hash value does not match the second hash value.

[0068] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first upgrade file also includes an application upgrade package and / or a calibration component upgrade package, wherein the application upgrade package is used for upgrading applications in the second partition, and the calibration component upgrade package is used for upgrading calibration components in the second partition.

[0069] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the apparatus further includes a processing unit for generating a first upgrade file.

[0070] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the content of the upgrade package of the BL program is associated with the type of the controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first and second partitions of the second hardware form are different. The transceiver unit is also used to receive first type information sent by the controller, which indicates that the controller type is one of the three hardware forms. The processing unit is also used to generate a first upgrade file based on the first type information.

[0071] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is specifically used to send the first upgrade file to the controller via a diagnostic instrument or an OTA (Over-The-Air) management platform.

[0072] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first upgrade file also includes a first description information or a second description information of the BL program upgrade package. The first description information is used to instruct the controller to enable the BL program upgrade function, and the second description information is used to instruct the controller not to enable the BL program upgrade function. The first description information corresponds to the first OTA signature of the BL program upgrade package, and the second description information corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different.

[0073] Fifthly, a controller upgrade device is provided, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory for reading and executing instructions in the memory, such that the device implements the method in any one of the implementations of the first or second aspect described above.

[0074] Sixthly, a computer-readable storage medium is provided, the computer-readable storage medium storing program code that, when the computer program code is run on a computer, causes the computer to perform the method in any one of the implementations of the first or second aspect described above.

[0075] In a seventh aspect, a chip is provided, the chip including circuitry for performing the method in any one of the implementations of the first or second aspect described above.

[0076] Eighthly, a computer program product is provided, the computer product including a computer program that, when the computer program is run by a processor, causes the method in any of the implementations of the first or second aspect to be executed.

[0077] Ninthly, a vehicle is provided, including: a controller upgrade device as described in any of the third or fourth aspects above.

[0078] In a tenth aspect, a server is provided, comprising: a controller upgrade device as described in any implementation of the fourth aspect above. Attached Figure Description

[0079] Figure 1 This is a functional schematic diagram of a vehicle provided in an embodiment of this application;

[0080] Figure 2 This is an architecture diagram applicable to a controller upgrade method provided in an embodiment of this application;

[0081] Figure 3 This is a schematic flowchart of a controller upgrade method provided in an embodiment of this application;

[0082] Figure 4 This is a schematic diagram of the internal storage partitioning of an ECU provided in an embodiment of this application;

[0083] Figure 5 This is a schematic diagram of an ECU internal software configuration provided in an embodiment of this application;

[0084] Figure 6 This is a schematic diagram of the storage partitioning of the start-up mode header in an ECU chip according to an embodiment of this application;

[0085] Figure 7 This is a schematic diagram of a flashing process provided in an embodiment of this application;

[0086] Figure 8 This is a flowchart illustrating another upgrade method provided in an embodiment of this application;

[0087] Figure 9 This is a flowchart illustrating another upgrade method provided in an embodiment of this application;

[0088] Figure 10 This is a flowchart illustrating another upgrade method provided in an embodiment of this application;

[0089] Figure 11 This is a schematic diagram of a controller upgrade device provided in an embodiment of this application;

[0090] Figure 12 This is a schematic diagram of a controller upgrade device provided in an embodiment of this application. Detailed Implementation

[0091] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0092] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In this application, "at least one" means one or more, and "more" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0093] The use of prefixes such as "first" and "second" in this application embodiment is solely for distinguishing different descriptive objects and does not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is found in the claims or the context of the embodiments, and the use of such prefixes should not constitute unnecessary restrictions.

[0094] As described in the background section, with the rapid evolution of software systems in terms of top-level functions and features, the level of vehicle intelligence is constantly improving, encompassing multiple fields such as autonomous driving, smart cockpits, and vehicle networking. This rapid development also places higher demands on the underlying firmware for adaptation, requiring continuous optimization and updates to related basic software, drivers, and underlying communication protocols to ensure system stability and compatibility. However, this high-frequency adaptation and iteration process inevitably introduces new security vulnerabilities, such as software compatibility failures, performance bottlenecks, security risks, and performance issues caused by the configuration of the bootloader firmware itself. If these security vulnerabilities are not discovered and fixed in a timely manner, they may affect vehicle reliability and even pose potential security risks.

[0095] Under normal circumstances, the aforementioned security vulnerabilities can be resolved by upgrading the BL firmware. However, current solutions for upgrading BL firmware have poor applicability, mainly due to insufficient compatibility, complex upgrade processes, and security challenges.

[0096] For example, within the same vehicle model project, there might be ECUs that support dual-partitioning and those that don't. ECUs supporting dual-partitioning (such as gateways) have features like security upgrades and fault rollback to ensure system stability; while ECUs that don't support dual-partitioning (such as windows and seats) use single-partitioning to reduce hardware costs, development complexity, and optimize the overall vehicle electronic architecture. In such projects, firmware upgrade functionality is typically planned and designed for ECUs supporting dual-partitioning, but not for ECUs that don't. This results in firmware upgrade schemes being incompatible with different types of hardware, increasing the risk of ECUs becoming unusable.

[0097] Therefore, designing a more flexible, secure, and efficient BL firmware upgrade solution and reducing the upgrade risks of BL firmware is an urgent problem to be solved.

[0098] This application provides a controller upgrade method, apparatus, and vehicle. The controller upgrade method is compatible with different types of ECUs, thereby improving the efficiency of BL firmware upgrades and reducing upgrade risks.

[0099] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0100] Figure 1 This is a functional schematic diagram of a vehicle provided in an embodiment of this application.

[0101] like Figure 1 As shown, the vehicle 100 involved in this application may include multiple subsystems, such as a perception system 120, a computing platform 130, and an over-the-air (OTA) upgrade module 140. Optionally, the vehicle 100 may include more or fewer subsystems, and each subsystem may include one or more components. In addition, each subsystem and component of the vehicle 100 can be interconnected via wired or wireless means.

[0102] The perception system 120 may include several sensors for sensing information about the environment surrounding the vehicle 100. For example, the perception system 120 may include a positioning system, which may be a global positioning system (GPS), a BeiDou system, or another positioning system. The perception system 120 may include one or more of the following: an inertial measurement unit (IMU), a rain sensor, a humidity and temperature sensor, a lidar, a millimeter-wave radar, an ultrasonic radar, and a camera device.

[0103] Some or all of the functions of vehicle 100 can be controlled by computing platform 130. Computing platform 130 may include processors 131 to 13n (n being a positive integer). A processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In reconfigurable hardware circuits, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement some or all of the functions of the aforementioned units. Furthermore, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. In addition, the computing platform 130 may also include a memory for storing instructions. Some or all of the processors 131 to 13n can call the instructions in the memory to implement the corresponding functions.

[0104] The computing platform 130 can control the functions of the vehicle 100 based on inputs received from various subsystems (e.g., the sensing system 120). In some embodiments, the computing platform 130 can be used to provide control over many aspects of the vehicle 100 and its subsystems.

[0105] The OTA upgrade module 140 is used for the management and control of firmware and software upgrades. It interacts with the cloud server via wireless communication (such as 4G / 5G, Wi-Fi) to download and verify update software packages, while coordinating the upgrade process of each ECU to ensure software version synchronization and compatibility. In addition, this module also has functions such as upgrade strategy management, fault rollback, download recovery, and network security protection to ensure the security, stability, and reliability of OTA upgrades, thereby improving vehicle software maintenance efficiency and user experience.

[0106] Optionally, the above components are just an example. In actual applications, the components in each of the above modules may be added or deleted as needed.

[0107] The vehicle 100 in this application may include: road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, vehicle 100 may be a means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle.

[0108] Figure 2 This is an architecture diagram applicable to a controller upgrade method provided in an embodiment of this application.

[0109] like Figure 2 As shown, the system architecture includes: a supplier version release system, an OTA management platform / original equipment manufacturer (OEM) operation and maintenance system, a vehicle-to-cloud channel and communication forwarding nodes, after-sales system tools, and vehicles.

[0110] The supplier version release system is used to submit the bootloader firmware to the vehicle manufacturer's OTA management platform / OEM maintenance system.

[0111] OTA management platform / OEM operation and maintenance system is used to manage BL program upgrade packages provided by various suppliers, and supports OTA policy management, OTA task management and vehicle management associated with projects.

[0112] The vehicle-to-cloud channel and communication forwarding node are used to establish a remote interaction channel (including data plane channel and command plane channel) between the OTA management platform / OEM operation and maintenance system and the vehicle, so as to realize data transmission.

[0113] The after-sales system tool supports the development of host computer functions for flashing according to the flashing specifications of vehicle manufacturers and enterprises. Specifically, the after-sales system tool can obtain upgrade packages for component ECUs from the OEM's maintenance system and communicate with the vehicle through the vehicle's onboard diagnostics (OBD) interface to initiate and complete the ECU flashing process based on diagnostic methods. Optionally, this after-sales system tool may include, but is not limited to, a diagnostic tool.

[0114] The vehicle may include: an OBD diagnostic interface, a diagnostic gateway, an OTA management module and / or installation module, and component ECUs (ECU1 to ECUn). The vehicle's OBD and diagnostic gateway can act as communication forwarding nodes between the component ECUs and aftermarket system tools, performing diagnostic and interactive functions. The OTA management module and / or installation module are used for issuing and executing OTA upgrade tasks, respectively. The component ECUs can be modules that undertake functions in various areas within the vehicle's electronic and electrical system architecture, including embedded microcontroller units (MCUs). Optionally, the vehicle may be... Figure 1 In vehicle 100, the OBD diagnostic interface, diagnostic gateway, OTA management module and / or installation module, and component ECU can be located in Figure 1 In the OTA upgrade module 140.

[0115] It should be noted that, Figure 2 The system architecture shown can be applied to both OTA upgrade scenarios and local upgrade scenarios. For the objects to be upgraded (ECU1 to ECUn), it is not aware of whether the current scenario is an OTA upgrade or a local upgrade.

[0116] For example, the interaction process of various components in an OTA upgrade scenario can be found in [reference needed]. Figure 2 In section ① to ④, the supplier version release system provides the OTA management platform / OEM operation and maintenance system with a software upgrade version (including the upgrade file of the BL firmware) that meets the delivery conditions; after the OTA management platform / OEM operation and maintenance system creates the task and configures the OTA policy, it sends the OTA task to the vehicle; after the vehicle receives the OTA task, the OTA management module in the vehicle can parse the OTA task sent from the cloud and coordinate the installation module to execute the OTA task.

[0117] As another example, the interaction process in a near-end upgrade scenario can be found in [reference needed]. Figure 2 In section ⑤ to ⑧, the after-sales system tools download the software package (including the upgrade file of the BL firmware) through the OEM maintenance system; after the diagnostic tool establishes a diagnostic link with the vehicle, the diagnostic tool can initiate a local flashing process, forward the flashing request to the vehicle and receive the flashing response through the diagnostic gateway, and complete the point-to-point ECU upgrade process.

[0118] It should be noted that, Figure 2 The system architecture shown is merely illustrative and intended to provide an intuitive understanding of the implementation principles of the controller upgrade method. It does not constitute any limitation on the applicable system architecture for the controller upgrade method involved in this application. Those skilled in the art can modify the system architecture according to specific practical needs. Figure 2 The system architecture shown can be flexibly adjusted. For example, new modules can be added to support more complex functional requirements, some modules can be removed to simplify system design, or existing modules can be replaced with newer modules or hardware. Furthermore, the system architecture may vary across different application scenarios due to differences in requirements, resources, or constraints.

[0119] Figure 3 This is a flowchart illustrating a controller upgrade method provided in an embodiment of this application. Method 300 may include steps S301 and S302.

[0120] S301, the installation module sends the first upgrade file to the controller.

[0121] The controller includes a storage area, which includes a first boot mode header and a second boot mode header. The first boot mode header is used to indicate at least a first partition, which is a running storage area. The second boot mode header is used to indicate at least a second partition, which is a non-running storage area. The first upgrade file may include a BL program upgrade package.

[0122] Optionally, the storage area in the controller can refer to the physical storage space inside or outside the chip used to store program code, configuration data and runtime information, and may include Flash, RAM or registers, which together support the startup, execution and function implementation of the controller.

[0123] Alternatively, data fields (e.g., boot partition flags) in the first boot mode header and the second boot mode header can be used to indicate the corresponding partition.

[0124] Optionally, the installation module can be Figure 2 The installed module in the vehicle, the controller can refer to the ECU (e.g., corresponding to...). Figure 2 ECU1 to ECUn, that is, ECU is a specific implementation of the controller, which is widely used in various modules of automobiles such as power system, body control, and infotainment.

[0125] Optionally, the BL program upgrade package includes an upgrade package for the first BL program in the first partition, or the BL program upgrade package includes an upgrade package for the second BL program in the second partition, or the BL program upgrade package includes an upgrade package for the first BL program and an upgrade package for the second BL program.

[0126] In one possible implementation, prior to step S301, method 300 further includes the server generating a first upgrade file and the server sending the first upgrade file to the installation module.

[0127] For example, the server can correspond Figure 2 In the supplier version release system, OTA management platform, or OEM operation and maintenance system, the process of generating the first upgrade file may include merging the BL program upgrade package, for example, merging the first BL program upgrade package and the second BL program upgrade package into a BL program upgrade package.

[0128] Optionally, the server can send the first upgrade file to the installation module via a diagnostic tool or OTA management platform, thereby sending the first upgrade file to the controller.

[0129] S302, the controller performs an upgrade operation based on the BL program upgrade package.

[0130] Based on the aforementioned controller upgrade method, different boot mode headers indicate different partitions. This allows for dynamic software-level indication of the partition to be loaded during controller startup after the bootloader (BL) program upgrade. This enables flexible switching between the running and non-running storage areas, allowing controllers that do not support hardware dual-partitioning to exhibit hardware dual-partitioning characteristics. In this way, the controller upgrade method is compatible with different types of ECUs, improving the efficiency of bootloader firmware upgrades and reducing upgrade risks without changing the hardware architecture.

[0131] When the contents of the BL program upgrade package are different, the upgrade operation performed by the controller will also be different.

[0132] According to some embodiments, when the BL program upgrade package includes the upgrade package of the first BL program in the first partition, step S302 includes: the controller does not perform the flashing of the upgrade package of the first BL program.

[0133] Based on the controller upgrade method described above, since the first partition is the runtime storage area, when the BL program upgrade package includes the upgrade package of the first BL program in the first partition, the program package of the first BL program is not flashed. This avoids the situation where the program fails to start or the system crashes due to the flashing of the currently used startup code, thus ensuring the stability and security of the current code running environment and reducing the risks during the upgrade process.

[0134] In one possible implementation, after the controller does not perform the upgrade flashing of the first BL program, method 300 further includes: the controller sending a first response message to the installation module, the first response message being used to indicate that the BL program upgrade package was successfully flashed.

[0135] Based on the controller upgrade method described above, without executing the first BL program flashing, the controller can send a "flashing successful" status to the installation module according to preset logic to mark the completion of this round of upgrade tasks. In this way, the continuity and stability of the entire upgrade process can be ensured, and the risks in the upgrade process can be further reduced.

[0136] According to some embodiments, when the BL program upgrade package includes the upgrade package of the second BL program in the second partition, or the BL program upgrade package includes the upgrade package of the first BL program in the first partition and the upgrade package of the second BL program, and the first boot mode header includes the first CRC check range, step S302 includes: the controller upgrades the second BL program according to the upgrade package of the second BL program, and adjusts the first CRC check range to the second CRC check range, and the CRC check performed by the controller in the second CRC check range fails.

[0137] Based on the above controller upgrade method, after the controller completes the upgrade of the second BL program using the second BL program upgrade package, it can adjust the first CRC check range corresponding to the first startup mode header to the second CRC check range, so that the first BL program avoids jumping to the running storage area when it starts, thereby realizing flexible switching between the running storage area and the non-running storage area. This makes the controller, which does not support hardware dual partitioning, exhibit the characteristics of supporting hardware dual partitioning, and ensures that the controller upgrade method can be compatible with different types of ECUs.

[0138] In one possible implementation, the second startup mode header includes a third CRC check range, and step S302 further includes: adjusting the third CRC check range to a fourth CRC check range, and the CRC check performed by the controller in the fourth CRC check range passes.

[0139] It should be understood that the boot mode header, by setting the starting address and length of the CRC check, actually controls which storage areas need to participate in integrity verification. Only when the specified partition passes the CRC check will the execution jump to execute the code of that partition. Therefore, by configuring the CRC check range, the boot mode header indirectly realizes the control and management of the target partition for boot jump, which helps to improve the security and stability of the system.

[0140] According to some embodiments, the controller and / or installation module may verify the BL program upgrade package before the controller performs the upgrade operation based on the BL program upgrade package.

[0141] In one possible implementation, the first upgrade file also includes first version information of the BL program upgrade package. Before step S302, the controller obtains the second version information of the second BL program. Then, in step S302, if the first version information and the second version information do not match, the controller upgrades the second BL program according to the upgrade package of the second BL program. Conversely, if the first version information and the second version information match, the controller can discard the BL program upgrade package and skip the upgrade process of the second BL program.

[0142] Based on the controller upgrade method described above, unnecessary upgrade operations can be avoided when the version information matches, thereby reducing the number of times the controller needs to be rewritten and extending the controller's rewrite lifespan.

[0143] In one possible implementation, the first upgrade file also includes a first hash value of the BL program upgrade package. Before step S302, the controller obtains a second hash value of the second BL program. Then, in step S302, if the first hash value and the second hash value do not match, the controller upgrades the second BL program according to its upgrade package. Conversely, if the first hash value and the second hash value match, the controller can discard the BL program upgrade package and skip the upgrade process for the second BL program.

[0144] Based on the controller upgrade method described above, since the hash value serves as an identifier for the integrity and uniqueness of firmware content, it can effectively reflect whether the program version or content has changed. Before upgrading the second BL program based on the upgrade package of the second BL program, the controller can pre-confirm whether the second hash value of the second BL program to be upgraded matches the first hash value in the upgrade file. If the two hash values ​​do not match, it indicates that the BL program to be upgraded is inconsistent with the target BL program in the upgrade package in terms of actual content, and the upgrade process can be executed. This approach can effectively avoid unnecessary flashing and rebooting of storage areas, improving the efficiency and reliability of BL firmware upgrades.

[0145] In one possible implementation, before step S301, the installation module may send a first request to the controller, requesting to read the version information and / or hash value of the second BL program. The controller can then send a second response to the installation module based on the first request, the first response including the second version information and / or the second hash value. In step S301, the installation module may send a first upgrade file to the controller if the first and second version information do not match, and / or if the first hash value does not match the second hash value.

[0146] Based on the controller upgrade method described above, the installation module can avoid sending the first upgrade file to the controller when the version information or hash value matches, thus preventing the controller from performing unnecessary upgrade operations. This reduces the number of times the controller needs to be rewritten and extends the controller's rewrite lifespan.

[0147] According to some embodiments, in addition to including the BL program upgrade package, the first upgrade file may also include upgrade packages for other components and / or upgrade-related information.

[0148] In one possible implementation, the first upgrade file further includes an application upgrade package and / or a calibration component upgrade package. Then, after step S302, method 300 further includes: the controller can upgrade the application in the second partition according to the application upgrade package, and / or upgrade the calibration component in the second partition according to the calibration component upgrade package.

[0149] Based on the controller upgrade method described above, the controller can complete the upgrade of the BL program and other functional components in one upgrade process, avoiding the problem of incompatibility between the BL program, application version and calibration components, and improving the reliability of the controller upgrade.

[0150] It should be understood that calibration components can be used to store adjustable parameters and configuration data, enabling the controller to flexibly fine-tune and dynamically optimize its functions without modifying or rewriting the main program code. With the calibration components set, developers or calibration engineers can adjust the parameters during system operation or remotely to meet the differences in operating conditions, product models, or user needs, achieving rapid iteration and precise control of the controller.

[0151] In one possible implementation, the first upgrade file further includes a first description or a second description of the BL program upgrade package. The first description is used to instruct the controller to enable the BL program upgrade function, and the second description is used to disable the BL program upgrade function. The first description corresponds to the first OTA signature of the BL program upgrade package, and the second description corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different. Step S302 includes: if the first upgrade file includes the first description, the controller performs an upgrade operation according to the BL program upgrade package.

[0152] Based on the above controller upgrade method, by applying the first description information, the controller can be enabled to start the BL program upgrade function. In this way, the timing of starting the controller BL firmware upgrade function can be precisely controlled, avoiding misoperation or unexpected upgrades, thereby further reducing the upgrade risk of the controller.

[0153] For example, the first description information and the second description information can be understood as the supporting information of the BL program upgrade package, which provides a basis for whether the controller should use the BL program upgrade package for upgrade, and is auxiliary data to ensure the smooth progress and safe execution of the upgrade process.

[0154] Optionally, when the first upgrade file includes the BL program upgrade package but does not include the first description information, the controller cannot perform an upgrade operation based on the BL program upgrade package after receiving it.

[0155] Optionally, when the first upgrade file includes a BL program upgrade package and second description information, the controller cannot perform an upgrade operation based on the BL program upgrade package.

[0156] It should be noted that, due to the differences in the content indicated by the BL program upgrade package including the first description information and the BL program upgrade package including the second description information, the generated OTA signatures are different, and the hash values ​​corresponding to the two upgrade packages are also different.

[0157] According to some embodiments, the BL program upgrade package also includes an upgrade address. Then step S302 includes: the controller determines a first erase address based on the upgrade address, the first erase address being the address for erasing the second BL program; the controller erases the content at the first erase address and burns the data of the upgrade package of the second BL program into the storage area where the program code corresponding to the first erase address runs.

[0158] Based on the aforementioned controller upgrade method, during the upgrade process of the controller BL program upgrade package for the second BL program, the controller can parse the upgrade address in the upgrade file to obtain the first erase address, and then burn the data of the second BL program upgrade package into the memory area where the program code corresponding to the first erase address runs, thereby completing the upgrade of the second BL program. This processing method helps to ensure the upgrade effect of the BL program and improves the upgrade success rate of the BL program.

[0159] According to some embodiments, the content of the upgrade package of the BL program is associated with the type of controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second hardware form and the third hardware form are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first partition and the second partition in the second hardware form are different. Before step S301, method 300 further includes: the controller sending first type information to the server, the first type information indicating that the controller type is one of the three hardware forms, and the server generating a first upgrade file based on the first type information.

[0160] Based on the controller upgrade method described above, the controller can report its type to the server, which facilitates the server in generating the corresponding BL program upgrade package based on the controller type. This effectively avoids upgrade failures caused by incompatible upgrade packages and further improves the efficiency of controller upgrades.

[0161] Optionally, in the third hardware configuration, the startup jump instructions for the applications and calibration components in the first and second partitions are the same.

[0162] Optionally, the addresses of the flashing files for the first BL program in the first hardware configuration and the second BL program in the second partition can be the same. The addresses of the flashing files for the first BL program and the second BL program in the second and third hardware configurations are different. In the second hardware configuration, the flashing file addresses for the application program and the calibration component are different, while in the third hardware configuration, the flashing addresses for the application program and the calibration component are the same.

[0163] For example, when the first type information indicates that the controller type is a first hardware form factor, the first upgrade file generated by the server may include a first BL program upgrade package or a second BL program upgrade package. When the first type information indicates that the controller type is a second hardware form factor or a third hardware form factor, the first upgrade file generated by the server may include a first BL program upgrade package and a second BL program upgrade package.

[0164] The following example uses an ECU as the controller, combined with... Figure 4 and Figure 5 This section provides a detailed description of the controller types and upgrade package formats in Method 300.

[0165] Figure 4 This is a schematic diagram of the internal storage partitioning of an ECU provided in an embodiment of this application. The hardware form of the ECU involved in this application may include: a component ECU that supports dual hardware partitioning and a component ECU that supports single hardware partitioning. The component ECU that supports dual hardware partitioning may correspond to the first hardware form in method 300, and the component ECU that supports single hardware partitioning may correspond to the second and third hardware forms in method 300.

[0166] For example, the first hardware form can be seen in Figure 4 Type 1 ECU, which supports firmware updates via BL (corresponding firmware) Figure 4There are two upgrade methods: BOOT and application program (APP). Both upgrade methods can perform a ping-pong upgrade by flashing the corresponding partition. For example, if the current running partition is A (corresponding to the first partition in method 300), the hardware security module (HSM), BOOT, APP, calibration (CAL) and other software components in partition B (corresponding to the second partition in method 300) can be flashed through the BOOT or APP upgrade method; if the current running partition is B, the HSM, BOOT, APP, CAL and other software components in partition A can be flashed through the BOOT or APP upgrade method.

[0167] It should be noted that, due to their abundant hardware resources, Class 1 ECUs support the Ethernet protocol within the APP. Therefore, Class 1 ECUs support the diagnostic over internet protocol (DoIP) flashing method. When upgrading, Class 1 ECUs can prioritize the flashing method executed by the APP.

[0168] As another example, the second hardware form factor can be seen in Figure 4 The two types of ECUs perform dual backups for all functional components. Software components such as HSM / BOOT / APP / CAL can be divided into two parts, A and B. These two types of ECUs can also support both BOOT and APP flashing methods, and can determine whether to deploy an Ethernet protocol stack based on the actual resource distribution of the product, thereby developing the Ethernet flashing function in the APP flashing method.

[0169] As another example, the third hardware form factor can be seen in Figure 4 Among the three types of ECUs, the BL firmware can be considered as a minimum system. The BL firmware is divided into two parts, A and B. The HSM, APP, and CAL components are not divided. Furthermore, the three types of ECUs cannot be flashed via the APP and only support the BOOT upgrade method.

[0170] It should be noted that, Figure 4 Although Type 2 and Type 3 ECUs are component ECUs supporting single-partition hardware, for different types of components within an ECU, they can be divided into two parts, Area A and Area B, through a simulated dual-partition approach. This allows Type 2 and Type 3 ECUs to exhibit dual-partition characteristics. The implementation method of simulated dual-partitioning will combine... Figure 6 Detailed explanations are omitted here.

[0171] It should also be noted that in this application, BOOT can refer to the boot area where the BL program is stored. The BL program, as the boot code, is stored on BOOT, while the BL program upgrade package is used to update the contents of the BL program in BOOT, thereby repairing or enhancing the boot logic.

[0172] Figure 5 This is a schematic diagram of an ECU internal software configuration provided in an embodiment of this application. This ECU internal software configuration can be configured according to... Figure 4 The hardware is categorized based on its physical form.

[0173] For example, for the first hardware form of the ECU, since the reset vector mapping table based on the chip dual-partition design masks the physical address information of each partition, the boot jump instructions and flash file addresses for partitions A and B are the same, thus allowing the same software package to be flashed onto different partitions. Therefore, for this type of ECU, a corresponding system is built. Figure 5 The software package for Class 1 ECUs contains consistent BL programs, applications, and calibration components, each including an upgrade package. When building the upgrade file, there is no need to differentiate between Area A and Area B. Furthermore, the configuration information about the dual partitions in the description information (pkg-cfg.xml) regarding the BL programs, applications, and calibration components can be kept consistent. That is, the configuration information about Area A in the description information can be copied to the configuration information about Area B in this file.

[0174] As another example, for ECUs with second and third hardware configurations, since they do not support hardware dual partitioning, the boot addresses and jump instructions of the simulated BOOT and APP dual partitions are different. Therefore, BL program upgrades include two forms: partitioned construction and merged construction.

[0175] (1) Partition construction

[0176] like Figure 5 As shown in the first sub-form of the ECU software package for the two types of ECUs, the software components (including application and calibration) are simulated as dual partitions. Since the data volume of the software components accounts for a large proportion of the entire upgrade package, to save data packet transmission time, the component configurations of partitions A and B can be distinguished in the description information. When flashing software data, the installation module can first determine which partition the ECU is located in. If it is partition A, the installation module can obtain the upgrade package for partition B based on the component configuration of partition B in the description information and transmit it to the corresponding ECU, thereby enabling the ECU to perform the upgrade operation.

[0177] (2) Merge and build

[0178] like Figure 5As shown in the software packages for the three types of ECUs, although the BL firmware of the three types of ECUs achieves dual-partition redundancy backup capability through simulation, the three types of ECUs are still single-partition attributes. That is, the description information of the software package for the three types of ECUs does not support dual-partition configuration information regarding software components. Therefore, the BL program upgrade package for area A and the BL program upgrade package for area B can be merged and built. That is, an upgrade file is built, which can include flashing data for areas A and B. It still appears as a "single-partition attribute" to external components, while the two partitions A and B can be processed differently by the ECU being flashed. In addition, since the data package transmission under the merged construction method may transmit some partition data that does not need to be processed, the impact of the extra transmitted data on the actual flashing performance is very limited because the BL firmware occupies a small space.

[0179] Similarly, such as Figure 5 As shown in the second sub-form of the software package for the two types of ECUs, since the BL firmware is flashed less frequently and the upgrade package is smaller, the BL program upgrade packages for areas A and B can be built together, and the application upgrade package and the calibration component upgrade package can be built into two separate A and B packages.

[0180] It should be noted that for the second and third hardware configurations, upgrading components in zones A and B requires two different software packages. Therefore, once the BL firmware or application is successfully running, its location in a specific zone is determined. During the upgrade process, components in non-running zones can be upgraded. For example, if the BL firmware or application in zone A is currently running, the upgrade process can only process the BL program upgrade data in zone B, ignoring the BL program upgrade data in zone A. Similarly, if the BL firmware or application in zone B is currently running, the upgrade process can only process the BL program upgrade data in zone A, ignoring the BL program upgrade data in zone B.

[0181] It should also be noted that the package can refer to the upgrade package of the upgrade file. The two can be used interchangeably. It can be understood as a combination of packaged files used to guide the upgrade of the BL program, calibration components and applications.

[0182] The following is combined with Figures 6 to 10 The upgrade process of the controller in Method 300 is described in detail, including: the simulated dual-partition method, the simulated dual-partition upgrade version construction method, and the simulated dual-partition information management and upgrade process.

[0183] (1) Mode dual partitioning method

[0184] The ECU chip can implement partition simulation through the design mechanism of the boot mode header (BHMD), that is, specify different boot configurations through the BMHD to support multi-partition management and dynamic boot switching. For example, Figure 6 This is a schematic diagram of the storage partitioning of an ECU chip startup mode header provided in an embodiment of this application, as shown below. Figure 6 As shown in Table 1, the processor supports four BMHDs, meaning it can store four different sets of boot information, theoretically supporting dynamic booting of four independent partitions. Each BMHD can record the partition's boot parameters, such as the header, start address, and end address. In practical applications, the allocated BL region can be divided into virtual A and B region addresses, and these addresses can be configured into two of the BMHDs respectively. For example, the A region address can be configured into BMHD0, and the B region address into BMHD1.

[0185] Table 1

[0186] header Starting address End address BMHD0 <![CDATA[A000 0000 H ]]> <![CDATA[A000 001F H ]]> BMHD1 <![CDATA[A002 0000 H ]]> <![CDATA[A002 001F H ]]> BMHD2 <![CDATA[A000 FFE0 H ]]> <![CDATA[A000 FFFF H ]]> BMHD3 <![CDATA[A001 FFE0 H ]]> <![CDATA[A001 FFFF H ]]>

[0187] After the addresses in Area A and Area B are allocated, the verification process can be initiated. The BMHD configuration is traversed and verified sequentially. If a match is found, the process jumps to the corresponding user code instruction to start the boot process. For example, in... Figure 6 In the scenario corresponding to Table 1, the running partition can be obtained by performing a validity check (CRC32) on the BMHD. That is, traversing BMHD0 to BMHD3, if a match is successful, the currently running partition can be obtained according to the BHMD index, and the user can jump to the corresponding virtual partition. Therefore, in the process of booting, updating, and partition switching, which involves partition operations, the CRC value calculated by the BL firmware can be controlled by modifying the CRC check range of the BMHD, so that it points to different partitions to affect the check result, thereby achieving dynamic booting and presenting a "dual partition feature" to the outside world.

[0188] For example, the address of area A is configured in BMHD0, and the address of area B is configured in BMHD1, with BMHD0 corresponding to the first CRC check range and BMHD1 corresponding to the second CRC check range. Since area A is the runtime storage area and area B is the non-runtime storage area, after upgrading the BL program in area B, the first CRC check range can be modified to the second CRC check range, and the third CRC check range can be modified to the fourth CRC check range, causing the CRC check of BMHD0 to fail and the check of BMHD1 to pass. In this way, when traversing the boot mode header, jumping to partition A can be avoided, and jumping to partition B can be performed instead.

[0189] (2) Simulation of dual-partition upgrade version construction method

[0190] Since the simulated dual-partition boot addresses and jump instructions are different, software packages need to be compiled separately for partitions A and B. To reduce maintenance and software version management costs, the program upgrade packages for partitions A and B can be combined into a single upgrade file (see reference). Figure 5 The second sub-form of the two types of ECU software packages and the third type of ECU software package form the partition data to be flashed by the ECU according to the partition status. This processing method also puts higher requirements on partition management. If the ECU mistakenly flashes the program upgrade package of the A area to the B area, or mistakenly writes the program upgrade package of the B area to the A area, it may cause the corresponding partition to fail to start.

[0191] In one possible implementation, to address the issue of accidental overwrites, the program upgrade packages from area A and area B can be combined into a single upgrade file. For example, the steps for combining an upgrade file include: obtaining two pre-set scripts, Lcf_XXX_A.lsl and Lcf_XXX_B.lsl, from the code repository; renaming Lcf_XXX_A.lsl to Lcf_XXX_.lsl and executing the compilation of the area A build artifact; renaming Lcf_XXX_B.lsl to Lcf_XXX_.lsl and executing the compilation of the area B build artifact; and copying the area A and area B build artifacts together into a single file. Optionally, the above build process can be automated using a build script.

[0192] (3) Simulated dual-partition information management

[0193] Since virtual A and B correspond to two different software packages, the BL program or application is in a running state during the flashing process, and its partition has been determined. Therefore, during the upgrade operation performed by the BL program or application, it can be managed or provided to the outside world based on the partition information.

[0194] For example, the ECU can determine the partition where the current bootloader program upgrade or application upgrade is running based on partition information.

[0195] For example, when flashing a partition, the ECU determines whether the upgrade package is in an abnormal state based on the partition information and the address information to prevent flashing failure.

[0196] For example, the controller can provide partition information to services such as OTA upgrades in the form of data identification numbers (DID).

[0197] (4) Upgrade process

[0198] Figure 7This is a schematic diagram of a flashing process provided in an embodiment of this application. The flashing process can be applied to the upgrade process of the BL program. Method 700 may include S701 to S703.

[0199] S701, flash pre-programmed.

[0200] For example, flashing preprogramming can be understood as preparation and checking steps before flashing. Flashing preprogramming may include operations such as: switching extended sessions, performing preprogramming condition checks, disabling diagnostics, and disabling application communication.

[0201] Specifically, the extended session switching allows the ECU to enter a special mode that supports firmware flashing to perform upgrade-related operations; the pre-programming condition check can include confirming whether the ECU meets the flashing safety conditions; disabling diagnostics is used to prevent external diagnostic tools or other ECUs from sending interference commands during the flashing process; and disabling application communication is used to prevent other applications from occupying ECU resources and ensure that the flashing process is not interfered with.

[0202] Optionally, the pre-programmed condition check may include: performing operations such as secure access authentication and writing fingerprints. The secure access authentication is used to verify permissions and ensure that only authorized devices can perform the flashing and writing, preventing unauthorized tampering. The fingerprint is used to record flashing device information, timestamps, software versions, etc., for easy traceability later.

[0203] S702, flashing and programming.

[0204] For example, the ECU can invoke the flash memory driver to perform flashing and data write to disk, and perform a complete check and dependency check. The completeness check and dependency check are used to ensure that the written data is stored correctly, avoiding system malfunctions caused by software version incompatibility.

[0205] S703, flashed and then programmed.

[0206] For example, post-flash programming includes making the flashed content effective after the flash is completed and the system is reset, as well as performing related post-verification actions, such as verifying the software version.

[0207] In one possible implementation, the BL program can be skipped if its version is inconsistent with that of other functional components (e.g., applications and calibration components). That is, when the BL program version for the non-running partition matches the version to be flashed, the BL firmware update can be skipped; when the BL program version for the partition does not match the version to be flashed, the BL firmware for the partition is flashed.

[0208] Figure 8This is a flowchart illustrating another upgrade method provided in this application embodiment. Method 800 can be a detailed description of steps S301 to S302 in method 300, and method 800 can be applied to... Figure 5 In the first sub-form of the two types of ECU software packages, method 800 may include steps S801 to S805.

[0209] S801, the server packages the BL program upgrade package from area A and area B into a single BL program upgrade package.

[0210] For example, the server can configure the description information of the BL program upgrade package during the file packaging process to indicate whether the ECU should enable the BL program upgrade function. This server can be... Figure 2 Chinese server version release system.

[0211] Among them, the BL program upgrade package in area A can correspond to the first BL program upgrade package in method 300, and the BL program upgrade package in area B can correspond to the second BL program upgrade package in method 300.

[0212] S802, the server sends the BL program upgrade package to the installation module.

[0213] S803, install the module parser BL program upgrade package.

[0214] For example, when the installation module parses the BL program upgrade package, it can read the version information and hash value of the BL program in the corresponding area (non-operating area) of the ECU. When the version information and hash value of the BL program in the corresponding area read are inconsistent with the version information or hash value of the BL program upgrade package, step S804 can be executed; otherwise, the BL program upgrade process can be skipped.

[0215] Optionally, the ECU can send the version information and hash value of the BL program for the region to the installation module for the installation module to read.

[0216] Optionally, when parsing the BL program upgrade package, the installation module can also read the BL program version of the corresponding region of the ECU to determine which ECU to send the BL program upgrade package to subsequently.

[0217] S804, the installation module sends the BL program upgrade package to the ECU.

[0218] The BL program upgrade package in this step can include either a BL program upgrade package for area A or area B. For example, when the ECU is currently running in area A, the BL program upgrade package includes the BL program upgrade package for area B; conversely, when the ECU is currently running in area B, the BL program upgrade package includes the BL program upgrade package for area A.

[0219] S805, the ECU performs a BL program upgrade for the corresponding region based on the BL program upgrade package.

[0220] For example, if the ECU is running in area A, the target partition in the BL program upgrade package is area B, and the data to be erased is in area B, then the ECU can erase the data in area B and burn the data from the BL program upgrade package into the runtime area of ​​the program code corresponding to the address.

[0221] Optionally, after the data burning is completed, an integrity check (such as CRC check) can be performed on area B to ensure that the upgraded BL firmware is not damaged.

[0222] In one possible implementation, if the ECU does not receive the BL program upgrade package, the ECU can flash other functional components (e.g., application components and calibration components).

[0223] S806, ECU partitioning after upgrade.

[0224] For example, after the bootloader (BL) program for a partition is upgraded, the ECU can switch the boot order to the upgraded BL firmware partition by modifying the boot mode header and CRC checksum range, and ensure that the ECU loads the upgraded BL firmware upon the next reboot. Furthermore, if the upgraded firmware malfunctions, the ECU can revert to the previous version by rolling back the boot mode header, thus ensuring system stability.

[0225] Optionally, after the partitioning is completed, the installation module can perform a post-verification of the BL program's version information and hash value to verify whether the upgraded BL program's version information and hash value are consistent with the version information and hash value in the BL program upgrade package.

[0226] Figure 9 This is a flowchart illustrating another upgrade method provided in this application embodiment. Method 900 can be a detailed description of steps S301 to S302 in method 300, and method 900 can be applied to... Figure 5 The second sub-form of the 2-type ECU software package and the 3-type ECU software package in the method 900 may include steps S901 to S905.

[0227] S901, the server packages the BL program upgrade package from area A and area B into a single BL program upgrade package.

[0228] For example, the server can configure the description information of the BL program upgrade package during the file packaging process to indicate whether the ECU should enable the BL program upgrade function. This server can be... Figure 2 Chinese server version release system.

[0229] Among them, the BL program upgrade package in area A can correspond to the first BL program upgrade package in method 300, and the BL program upgrade package in area B can correspond to the second BL program upgrade package in method 300.

[0230] S902, the server sends the BL program upgrade package to the installation module.

[0231] S903, install the module parser BL program upgrade package.

[0232] S904, the installation module sends the BL program upgrade package to the ECU.

[0233] The BL program upgrade package can include BL program upgrade packages for areas A and B, meaning that in method 900, the security module plays the role of forwarding the BL program upgrade package.

[0234] Optionally, prior to step S904, the installation module may interact with the ECU to perform pre-programming steps.

[0235] S905, the ECU reads the version information and hash value of the BL program for the region, and determines whether to upgrade the BL program for the region based on the version information and hash value of the BL program in the BL program upgrade package.

[0236] For example, when the version information and hash value of the BL program in the non-operating region read by the ECU are inconsistent with the version information and hash value of the BL program in the BL program upgrade package, the ECU can perform the BL program upgrade operation for the region according to the BL program upgrade package and ignore the upgrade data about the currently operating partition in the BL program upgrade package. Otherwise, the flashing process can be skipped, and the ECU can send instruction information to the installation module to prepare for the upgrade operation of other functional components.

[0237] Optionally, after the bootloader (BL) program upgrade is complete, the ECU can switch the boot order of the upgraded BL firmware partition by modifying the boot mode header and CRC check range, and ensure that the ECU loads the upgraded BL firmware on the next reboot. Furthermore, if the upgraded firmware malfunctions, the ECU can revert to the previous version by rolling back the boot mode header, thus ensuring system stability.

[0238] Optionally, after the partitioning is completed, the installation module can perform a post-verification of the BL program's version information and hash value to verify whether the upgraded BL program's version information and hash value are consistent with the version information and hash value in the BL program upgrade package.

[0239] Figure 10This is a flowchart illustrating another upgrade method provided in this application embodiment. Method 1000 can be a detailed description of steps S301 to S302 in method 300, and method 1000 can be applied to... Figure 5 For a Class 1 ECU software package, method 1000 may include steps S1001 to S1005.

[0240] S1001, Server builds BL program upgrade package.

[0241] For example, when the server builds the BL program upgrade package, it can configure a description file for the BL program upgrade package to indicate whether the ECU enables the BL program upgrade function. Since the Class 1 ECU software package can be used to upgrade the BL firmware of both Region A and Region B, the BL program upgrade package in method 1000 does not distinguish between Region A BL program upgrade packages and Region B BL program upgrade packages.

[0242] S1002, the server sends the BL program upgrade package to the installation module.

[0243] S1003, Install module parsing BL program upgrade package.

[0244] For example, when the installation module parses the BL program upgrade package, it can read the version information and hash value of the BL program in the corresponding area (non-operating area) of the ECU. When the version information and hash value of the BL program in the corresponding area read are inconsistent with the version information or hash value of the BL program upgrade package, step S1004 can be executed; otherwise, the BL program upgrade process can be skipped.

[0245] Optionally, the ECU can send the version information and hash value of the BL program for the region to the installation module for the installation module to read.

[0246] S1004, the installation module sends the BL program upgrade package to the ECU.

[0247] S1005, the ECU reads the version information and hash value of the BL program in the region, and determines whether to upgrade the BL program in the region based on the version information and hash value of the BL program in the BL program upgrade package.

[0248] For example, when the version information and hash value of the BL program in the non-operating region read by the ECU are inconsistent with the version information and hash value of the BL program in the BL program upgrade package, the ECU can perform the BL program upgrade operation for the region according to the BL program upgrade package and ignore the upgrade data about the currently operating partition in the BL program upgrade package. Otherwise, the flashing process can be skipped, and the ECU can send instruction information to the installation module to prepare for the upgrade operation of other functional components.

[0249] Optionally, after the bootloader (BL) program upgrade is complete, the ECU can switch the boot order of the upgraded BL firmware partition by modifying the boot mode header and CRC check range, and ensure that the ECU loads the upgraded BL firmware on the next reboot. Furthermore, if the upgraded firmware malfunctions, the ECU can revert to the previous version by rolling back the boot mode header, thus ensuring system stability.

[0250] Optionally, after the partitioning is completed, the installation module can perform a post-verification of the BL program's version information and hash value to verify whether the upgraded BL program's version information and hash value are consistent with the version information and hash value in the BL program upgrade package.

[0251] It should be understood that, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0252] Figure 11 This is a schematic diagram of a controller upgrade device provided in an embodiment of this application. The device 1100 may include an acquisition unit 1110, a transceiver unit 1120, and a processing unit 1130. The acquisition unit 1110 is used to acquire instructions and / or data; the transceiver unit 1120 is used to receive or send instructions and / or data; and the processing unit 1130 is used to perform data processing so that the device 1100 implements the aforementioned control method.

[0253] Optionally, the device 1100 further includes a storage unit for implementing corresponding storage functions and storing corresponding instructions and / or data.

[0254] As a design feature, device 1100 can be used to indicate the actions performed by the controller in the above method embodiments.

[0255] In one embodiment, the apparatus 1100 includes an acquisition unit 1110 and a processing unit 1130. The acquisition unit 1110 is used to acquire a first upgrade file, the first upgrade file including a bootloader BL program upgrade package. The processing unit 1130 is used to perform an upgrade operation according to the BL program upgrade package.

[0256] In one possible implementation, the processing unit 1130 is also used to flash an upgrade package without executing the first BL program.

[0257] In one possible implementation, the device 1100 further includes a transceiver unit 1120, used to send a first response message to the installation module, the first response message being used to indicate that the BL program upgrade package has been successfully flashed.

[0258] In one possible implementation, the first startup mode header includes a first cyclic redundancy check (CRC) check range, the BL program upgrade package includes an upgrade package of the second BL program in the second partition, or the BL program upgrade package includes an upgrade package of the first BL program in the first partition and an upgrade package of the second BL program; the processing unit 1130 is specifically used to upgrade the second BL program according to the upgrade package of the second BL program, and adjust the first CRC check range to the second CRC check range, and the CRC check performed by the controller in the second CRC check range fails.

[0259] In one possible implementation, the first upgrade file also includes first version information of the BL program upgrade package; the acquisition unit 1110 is also used to acquire second version information of the second BL program; the processing unit 1130 is specifically used to upgrade the second BL program according to the upgrade package of the second BL program when the first version information and the second version information do not match.

[0260] In one possible implementation, the first upgrade file also includes a first hash value of the BL program upgrade package; the acquisition unit 1110 is also used to acquire a second hash value of the second BL program; the processing unit 1130 is specifically used to upgrade the second BL program according to the upgrade package of the second BL program when the first hash value and the second hash value do not match.

[0261] In one possible implementation, the transceiver unit 1120 is further configured to receive a first request message sent by the installation module, the first request message being used to request the reading of the version information and / or hash value of the second BL program; the processing unit 1130 is further configured to send a second response message to the installation module according to the first request message, the second response message including second version information and / or second hash value.

[0262] In one possible implementation, the second startup mode header includes a third CRC check range, and the processing unit 1130 is further configured to adjust the third CRC check range to a fourth CRC check range, wherein the CRC check performed by the controller in the fourth CRC check range passes.

[0263] In one possible implementation, the first upgrade file further includes an application upgrade package and / or a calibration component upgrade package. The processing unit 1130 is also configured to upgrade the application in the second partition according to the application upgrade package, and / or upgrade the calibration component in the second partition according to the calibration component upgrade package.

[0264] In one possible implementation, the content of the BL program upgrade package is associated with the controller type, which includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first and second partitions of the second hardware form are different. The transceiver unit 1120 is also used to send first type information, which is used to indicate that the controller type is one of the three hardware forms.

[0265] In one possible implementation, the BL program upgrade package also includes an upgrade address. The processing unit 1130 is further configured to: determine a first erase address based on the upgrade address, wherein the first erase address is the address for erasing the second BL program; erase the content at the first erase address; and burn the data of the upgrade package of the second BL program into the storage area where the program code corresponding to the first erase address is executed.

[0266] In one possible implementation, the first upgrade file also includes a first description or a second description of the BL program upgrade package. The second description is used to instruct the controller not to enable the BL program upgrade function. The first description corresponds to the first OTA signature of the BL program upgrade package, and the second description corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different. The processing unit 1130 is specifically used to perform an upgrade operation according to the BL program upgrade package when the first upgrade file includes the first description.

[0267] As a design feature, device 1100 can be used to indicate the actions performed by the installation module or server in the above method embodiments.

[0268] According to some embodiments, the device 1100 includes: an acquisition unit 1110 and a transceiver unit 1120, the transceiver unit 1120 being used to send a first upgrade file to a controller; wherein the controller includes a storage area, the storage area including a first startup mode header and a second startup mode header, the first startup mode header being used to indicate a first partition, the first partition being a running storage area, and the second startup mode header being used to indicate a second partition, the second partition being a non-running storage area.

[0269] In one possible implementation, the BL program upgrade package includes an upgrade package for the first BL program in the first partition, or the BL program upgrade package includes an upgrade package for the second BL program in the second partition, or the BL program upgrade package includes an upgrade package for the first BL program and an upgrade package for the second BL program.

[0270] In one possible implementation, the transceiver unit 1120 is further configured to: send a first request message to the controller, the first request message being used to request reading the version information and / or hash value of the second BL program in the second partition; and receive a first response message sent by the controller, the first response message including the second version information and / or the second hash value of the second BL program.

[0271] In one possible implementation, the first upgrade file also includes first version information and / or a first hash value of the BL program upgrade package. The transceiver unit 1120 is specifically used to send the first upgrade file to the controller when the first version information and the second version information do not match, and / or the first hash value does not match the second hash value.

[0272] In one possible implementation, the first upgrade file also includes an application upgrade package and / or a calibration component upgrade package, wherein the application upgrade package is used to upgrade the application in the second partition, and the calibration component upgrade package is used to upgrade the calibration component in the second partition.

[0273] In one possible implementation, the device 1100 further includes a processing unit 1130 for generating a first upgrade file.

[0274] In one possible implementation, the content of the upgrade package of the BL program is associated with the type of the controller. The controller type includes three hardware forms: a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second and third hardware forms are different. Furthermore, the startup jump instructions of the application programs and calibration components in the first and second partitions of the second hardware form are different. The transceiver unit 1120 is also used to receive first type information sent by the controller. The first type information is used to indicate that the controller type is one of the three hardware forms. The processing unit 1130 is also used to generate a first upgrade file based on the first type information.

[0275] In one possible implementation, the transceiver unit 1120 is specifically used to send a first upgrade file to the controller via a diagnostic instrument or an OTA (Over-The-Air) management platform.

[0276] In one possible implementation, the first upgrade file further includes a first description or a second description of the BL program upgrade package. The first description is used to instruct the controller to enable the BL program upgrade function. The second description is used to instruct the controller not to enable the BL program upgrade function. The first description corresponds to the first OTA signature of the BL program upgrade package, and the second description corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different.

[0277] Figure 12 This is a schematic diagram of another controller upgrade device provided in an embodiment of this application.

[0278] The device 1200 includes a memory 1210, a processor 1220, and a communication interface 1230. The memory 1210, processor 1220, and communication interface 1230 are connected via an internal connection path. The memory 1210 stores instructions, and the processor 1220 executes the instructions stored in the memory 1210 to control the communication interface 1230 to acquire information, enabling the device 1200 to implement the aforementioned controller upgrade method. Optionally, the memory 1210 can be coupled to the processor 1220 via an interface, or it can be integrated with the processor 1220.

[0279] It should be noted that the communication interface 1230 described above uses a transceiver device, such as, but not limited to, a transceiver. The communication interface 1230 may also include an input / output interface.

[0280] The processor 1220 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 1220, the controller upgrade device 1200 performs the controller upgrade method in the above embodiments.

[0281] In implementation, each step of the above method can be completed by the integrated logic circuitry of the hardware in the processor 1220 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 1210, and the processor 1220 reads the information in memory 1210 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0282] Optionally, Figure 12 The communication interface 1230 in the middle can achieve Figure 11The acquisition unit 1110 or the transceiver unit 1120 in the middle, Figure 12 The processor 1220 in the middle can achieve Figure 11 The processing unit 1130 in the middle.

[0283] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to memory, which stores instructions. The processor calls the instructions stored in memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functions of some or all units can be implemented through the design of the hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all units are implemented through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby implementing the functions of some or all units. All units of the above devices can be implemented entirely through processor calling software, or entirely through hardware circuits, or partially through processor calling software with the remaining parts implemented through hardware circuits.

[0284] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0285] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0286] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a System-on-a-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.

[0287] This application also provides a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the above-described... Figure 3 , Figures 7 to 10 The controller upgrade method shown in any one of the above.

[0288] This application also provides a computer program product, which includes a computer program that, when run, causes the computer to perform the above-described actions. Figure 3 , Figures 7 to 10 The controller upgrade method shown in any one of the above.

[0289] This application embodiment also provides a chip, including: a circuit, the circuit being used to perform the above... Figure 3 , Figures 7 to 10 The controller upgrade method shown.

[0290] This application embodiment also provides a vehicle, the vehicle comprising: as follows Figure 11 or Figure 12 The controller upgrade device shown.

[0291] This application embodiment also provides a server, the server comprising: as shown in the example Figure 11 or Figure 12 The controller upgrade device shown.

[0292] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

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

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

[0298] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A controller upgrade method characterized by, The controller includes a storage area, the storage area including a first boot mode header and a second boot mode header, the first boot mode header being used to indicate at least a first partition, the first partition being a running storage area, and the second boot mode header being used at least to indicate at least a second partition, the second partition being a non-running storage area, the method including: Obtain the first upgrade file, which includes a bootloader (BL) program upgrade package; Perform the upgrade operation according to the BL program upgrade package.

2. The method as described in claim 1, characterized in that, The BL program upgrade package includes an upgrade package for the first BL program in the first partition. The step of performing an upgrade operation based on the BL program upgrade package includes: The upgrade package for the first bootloader is not flashed.

3. The method as described in claim 2, characterized in that, The method further includes: A first response message is sent to the installation module, which indicates that the BL program upgrade package has been successfully flashed.

4. The method as described in claim 1, characterized in that, The first boot mode header includes a first cyclic redundancy check (CRC) check range, and the BL program upgrade package includes the upgrade package of the second BL program in the second partition, or the BL program upgrade package includes the upgrade package of the first BL program in the first partition and the upgrade package of the second BL program. The step of performing the upgrade operation according to the BL program upgrade package includes: The second BL program is upgraded according to the upgrade package of the second BL program, and the first CRC check range is adjusted to the second CRC check range. The CRC check performed by the controller in the second CRC check range fails.

5. The method as described in claim 4, characterized in that, The first upgrade file also includes first version information of the BL program upgrade package. Before upgrading the second BL program according to the second BL program upgrade package, the method further includes: Obtain the second version information of the second BL program; Upgrading the second BL program according to the upgrade package of the second BL program includes: If the first version information and the second version information do not match, the second BL program is upgraded according to the upgrade package of the second BL program.

6. The method as described in claim 4 or 5, characterized in that, The first upgrade file also includes a first hash value of the BL program upgrade package. Before upgrading the second BL program according to the second BL program upgrade package, the method further includes: Obtain the second hash value of the second BL program; Upgrading the second BL program according to the upgrade package of the second BL program includes: If the first hash value and the second hash value do not match, the second BL program is upgraded according to the upgrade package of the second BL program.

7. The method according to any one of claims 4 to 6, characterized in that, Before obtaining the first upgrade file, the method further includes: Receive a first request message sent by the installation module, the first request message being used to request to read the version information and / or hash value of the second BL program; The installation module is sent a second response message based on the first request message. The second response message includes a second version message and / or a second hash value.

8. The method according to any one of claims 4 to 7, characterized in that, The second boot mode header includes a third CRC check range, and the method further includes: The third CRC check range is adjusted to the fourth CRC check range, and the CRC check performed by the controller within the fourth CRC check range passes.

9. The method according to any one of claims 4 to 8, characterized in that, The first upgrade file also includes an application upgrade package and / or a calibration component upgrade package, and the method further includes: Upgrade the applications in the second partition according to the application upgrade package, and / or, The calibration components in the second partition are upgraded according to the calibration component upgrade package.

10. The method according to any one of claims 4 to 9, characterized in that, The content of the upgrade package of the BL program is associated with the type of the controller. The controller type includes three hardware forms, namely a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second hardware form and the third hardware form are different. Furthermore, the startup jump instructions of the application programs and calibration components of the first partition and the second partition in the second hardware form are different. Before obtaining the first upgrade file, the method further includes: Send a first type of information, which indicates that the controller is one of the three hardware forms.

11. The method according to any one of claims 4 to 10, characterized in that, The BL program upgrade package also includes an upgrade address, and the step of upgrading the second BL program in the second partition according to the second BL program upgrade package includes: The first erase address is determined based on the upgrade address, and the first erase address is the address at which the second BL program is erased; The contents at the first erase address are erased, and the data of the upgrade package of the second BL program is burned into the storage area where the program code corresponding to the first erase address is executed.

12. The method according to any one of claims 4 to 11, characterized in that, The first upgrade file also includes a first description or a second description of the BL program upgrade package. The first description is used to instruct the controller to enable the BL program upgrade function, and the second description is used to instruct the controller not to enable the BL program upgrade function. The first description corresponds to the first OTA signature of the BL program upgrade package, and the second description corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different. The step of performing the upgrade operation according to the BL program upgrade package includes: If the first upgrade file includes the first description information, the upgrade operation is performed according to the BL program upgrade package.

13. A controller upgrade method, characterized in that, The method includes: Obtain the first upgrade file, which includes the BL program upgrade package; Send the first upgrade file to the controller; The controller includes a storage area, which includes a first boot mode header and a second boot mode header. The first boot mode header indicates a first partition, which is a running storage area, and the second boot mode header indicates a second partition, which is a non-running storage area.

14. The method as described in claim 13, characterized in that, The BL program upgrade package includes an upgrade package for the first BL program in the first partition, or the BL program upgrade package includes an upgrade package for the second BL program in the second partition, or the BL program upgrade package includes upgrade packages for both the first BL program and the second BL program.

15. The method as described in claim 13 or 14, characterized in that, Before sending the first upgrade file to the controller, the method further includes: Send a first request message to the controller, the first request message being used to request the version information and / or hash value of the second BL program in the second partition; The controller sends a first response message, which includes the second version information and / or the second hash value of the second BL program.

16. The method as described in claim 15, characterized in that, The first upgrade file also includes the first version information and / or the first hash value of the BL program upgrade package, and sending the first upgrade file to the controller includes: If the first version information and the second version information do not match, and / or the first hash value does not match the second hash value, the first upgrade file is sent to the controller.

17. The method according to any one of claims 13 to 16, characterized in that, The first upgrade file also includes an application upgrade package and / or a calibration component upgrade package, wherein the application upgrade package is used to upgrade the application in the second partition, and the calibration component upgrade package is used to upgrade the calibration component in the second partition.

18. The method according to any one of claims 13 to 17, characterized in that, The process of obtaining the first upgrade file includes: Generate the first upgrade file.

19. The method as described in claim 18, characterized in that, The content of the upgrade package of the BL program is associated with the type of the controller. The controller type includes three hardware forms, namely a first hardware form, a second hardware form, and a third hardware form. The startup jump instructions of the first BL program in the first hardware form and the second BL program in the second partition are the same. The startup jump instructions of the first BL program and the second BL program in the second hardware form and the third hardware form are different. Furthermore, the startup jump instructions of the application programs and calibration components of the first partition and the second partition in the second hardware form are different. Prior to generating the first upgrade file, the method includes: Receive first type information sent by the controller, the first type information being used to indicate that the controller is one of the three hardware forms; The generation of the first upgrade file includes: The first upgrade file is generated based on the first type of information.

20. The method according to any one of claims 13 to 19, characterized in that, Sending the first upgrade file to the controller includes: The first upgrade file is sent to the controller via a diagnostic tool or an OTA (Over-The-Air) management platform.

21. The method according to any one of claims 13 to 20, characterized in that, The first upgrade file also includes a first description or a second description of the BL program upgrade package. The first description is used to instruct the controller to enable the BL program upgrade function, and the second description is used to instruct the controller not to enable the BL program upgrade function. The first description corresponds to the first OTA signature of the BL program upgrade package, and the second description corresponds to the second OTA signature of the BL program upgrade package. The first OTA signature and the second OTA signature are different.

22. A controller upgrade device, characterized in that, The apparatus includes units or modules for performing the method as described in any one of claims 1 to 12, or 13 to 21.

23. A controller upgrade device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory, the memory being used to store computer programs or instructions, and the processor being used to execute the computer programs or instructions in the memory, such that the method of any one of claims 1 to 12 is performed.

24. A controller upgrade device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory, the memory being used to store computer programs or instructions, and the processor being used to execute the computer programs or instructions in the memory, such that the method of any one of claims 13 to 21 is performed.

25. A chip, characterized in that, The chip includes circuitry for performing the method as described in any one of claims 1 to 21.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 21.

27. A computer program product, characterized in that, The computer product includes a computer program that, when run, causes the computer to perform the method as described in any one of claims 1 to 21.

28. A vehicle, characterized in that, Includes the apparatus as described in claim 22 or 23.

Images