ECU (Electronic Control Unit) non-inductive refreshing method and related device

Abstract

The invention discloses an ECU (Electronic Control Unit) non-inductive refreshing method and a related device, and relates to the technical field of controller software updating, and the method comprises the following steps: running a first bootstrap program in a first partition, so that when the first bootstrap program monitors a software refreshing request, based on address allocation information pre-configured for a target program, the target program is updated according to the address allocation information pre-configured for the target program; brushing the target program into a corresponding address of the second partition; and after the target program is refreshed, switching to the second partition to sequentially run the second boot startup program in the second partition and the target program in the second partition, and if the target program in the second partition is not successfully run, running the default program in the second partition. According to the method, the address allocation information can be dynamically configured for the target program, and software refreshing of any address allocation is realized; moreover, when the swiped-in target program has an operation problem, the default program can be skipped to be operated, so that the driving safety problem caused by the fact that the electronic control unit is stuck due to the fact that the target program has the problem is avoided.

Description

Technical Field

[0001] The present application relates to the technical field of controller software update, and in particular to an ECU senseless refresh method and related devices. Background Art

[0002] With the continuous development of automotive electronic technology, the performance and functions of the Electronic Control Unit (ECU), as the core control component of the car, are also constantly improving. In order to ensure the stability and reliability of the ECU and meet the growing driving needs, it is particularly important to regularly update and refresh the software of the ECU. However, traditional ECU refresh methods often require the disassembly of the ECU or interruption of its normal operation, which not only increases the maintenance cost and time cost, but may also cause inconvenience to the normal use of the vehicle. Therefore, it is particularly important to develop a method that can achieve senseless refresh of the ECU without affecting the normal operation of the vehicle. Summary of the invention

[0003] In view of the above problems, the present application provides an ECU senseless refresh method and related devices, which are used to achieve the purpose of ECU senseless refresh. The specific scheme is as follows:

[0004] The first aspect of the present application provides an ECU non-sensing refresh method, comprising:

[0005] Running a first boot program in the first partition, so that when the first boot program detects a software refresh request, based on address allocation information preconfigured for the target program, the target program is refreshed into a corresponding address of the second partition, wherein the software refresh request is used to update the software program of the electronic control unit to the target program, and the first partition and the second partition are obtained by dividing a storage area of ​​the electronic control unit;

[0006] After the target program is refreshed, switching to the second partition to sequentially run the second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition runs, the second boot program can verify the target program in the second partition based on the address allocation information;

[0007] If the target program in the second partition fails to run successfully, a default program in the second partition is run, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

[0008] Optionally, the target program is composed of a plurality of data segments, each of which is pre-configured with address allocation information;

[0009] The step of flashing the target program to a corresponding address of the second partition based on the address allocation information preconfigured for the target program includes:

[0010] Based on the address allocation information preconfigured for the multiple data segments respectively, the multiple data segments are flushed to the corresponding addresses of the second partition respectively.

[0011] Optionally, the address allocation information preconfigured for each of the data segments is stored in a header file preconfigured for the data segment.

[0012] Optionally, also include:

[0013] If the target program in the second partition runs successfully, the target program in the second partition is flashed into the first partition.

[0014] Optionally, the process of determining whether the target program in the second partition is successfully executed includes:

[0015] Determining whether the number of times the second boot program is repeatedly executed reaches a preset number of times within a preset time period;

[0016] If yes, determining that the target program in the second partition runs successfully;

[0017] If not, it is determined that the target program in the second partition has not been successfully executed.

[0018] Optionally, the main control chip of the electronic control unit has an AB Swap function, and the AB Swap function enables the first partition and the second partition to have the same storage space and the same storage address.

[0019] A second aspect of the present application provides an ECU non-sensing refresh device, comprising:

[0020] a first running module, configured to run a first boot program in the first partition, so that when the first boot program detects a software refresh request, the target program is refreshed into a corresponding address of the second partition based on address allocation information preconfigured for the target program, wherein the software refresh request is used to update the software program of the electronic control unit to the target program, and the first partition and the second partition are obtained by dividing a storage area of ​​the electronic control unit;

[0021] a second running module, configured to switch to the second partition after the target program is refreshed, so as to sequentially run a second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition is run, the second boot program can verify the target program in the second partition based on the address allocation information;

[0022] The third running module is used to run the default program in the second partition if the target program in the second partition fails to run successfully, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

[0023] The third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the ECU non-sensing refresh method of the above-mentioned first aspect or any implementation method of the first aspect.

[0024] A fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0025] The memory is used to store computer programs;

[0026] The processor is used to execute the computer program so that the electronic device can implement the ECU senseless refresh method of the above-mentioned first aspect or any implementation method of the first aspect.

[0027] The fifth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement the ECU non-sensing refresh method of the above-mentioned first aspect or any implementation method of the first aspect.

[0028] With the help of the above technical scheme, the ECU senseless refresh method provided by the present application can refresh the target program in the second partition while running the first partition, and then run the target program in the second partition after the refresh is completed. Since the old program in the first partition can be run while refreshing the target program, the present application can complete the refresh during the normal operation of the vehicle, thereby realizing the senseless refresh of the ECU.

[0029] Furthermore, the present application can pre-configure address allocation information for the target program, so that the present application can dynamically set the address allocation information according to the size of the target program and the hardware address space resources, which improves the utilization rate of the hardware address space resources on the one hand, and on the other hand, by not constraining the address allocation of the program to be refreshed, it can implement a software refresh strategy with arbitrary address division, which is more flexible. When the refreshed target program has a running problem, it can jump to run the default program, avoiding the problem of driving safety caused by the electronic control unit being stuck due to the problem of the target program. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0031] Figure 1 A schematic diagram of a system architecture provided for this application;

[0032] Figure 2 A schematic diagram of an optional hardware structure of the terminal 100 provided in this application;

[0033] Figure 3 A schematic diagram of the structure of a server 200 provided in this application;

[0034] Figure 4 A flowchart of an ECU non-sensing refresh method provided in this application;

[0035] Figure 5 A schematic diagram of an optional structure of the first partition and the second partition provided in this application;

[0036] Figure 6 A schematic diagram of a data segment within an APP2 sub-partition provided by this application;

[0037] Figure 7 A schematic diagram of updating the ECU program in the second partition provided by this application;

[0038] Figure 8 A comparison of the space occupied by the new and old ECU programs in the first and second partitions provided for this application;

[0039] Fig. 9 A schematic diagram of the structure of an ECU non-sensing refresh device provided in this application;

[0040] Fig.10 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION

[0041] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0042] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0043] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0044] In order to achieve senseless refresh of ECU, several technical solutions are provided.

[0045] In one technical solution, the storage area of ​​the ECU is artificially divided into a programming area and an execution area. During normal operation, the program in the execution area will be executed. At this time, if the ECU software needs to be upgraded, the target program (i.e., the ECU program that needs to be refreshed) needs to be refreshed into the programming area. After the refresh is completed, the address mapping is switched so that the target program starts running from the starting address of the programming area.

[0046] In this technical solution, the programming area needs to start from a fixed offset address of 0 when refreshing, and the size and location of the refresh software program cannot be dynamically allocated (that is, the size and storage location of the target program are fixed and cannot be changed); in addition, when the refresh is successful, the startup address of the target program is immediately written into the boot program. When the refresh is successful but the actual target program has an abnormality or BUG (defect), it will still start from the target program after resetting. Under extreme working conditions, the ECU cannot be rescued or re-flashed.

[0047] In another technical solution, the storage area of ​​ECU is divided into area A and area B. During normal operation, the program in a certain area (taking area A as an example) will be executed. During the refresh process, the refresh driver is downloaded first, and then the refresh driver is called to perform software refresh in area B. After the refresh is completed and the verification is successful, the refresh driver is erased, the AB area switching function is enabled, and the software in area B is executed.

[0048] In this technical solution, since there is no boot process of the boot program, when the refresh is successful, the startup address of the target program is immediately written into the boot program. When the refresh is successful but the actual target program has an abnormality or bug, it will still start from the target program after reset, which will cause the ECU to be unable to be rescued and re-flashed under extreme conditions. In addition, this technical solution immediately clears the refresh driver after the refresh is completed. When there is a need for version rollback, multiple version backups, etc., manual intervention will be required because the refresh driver needs to be re-downloaded.

[0049] In order to solve the problems existing in the above-mentioned prior art, the present application provides an ECU senseless refresh method and related devices. In order to enable those skilled in the art to better understand the present application, a detailed introduction is given below.

[0050] See also Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100 and a server 200. The server 200 may include one or more servers ( Figure 1 In the example, a server is included, and the server 200 can provide the method provided in the embodiment of the present application for one or more terminals.

[0051] Among them, an application can be installed on the terminal 100, and the above application and web page can provide an interface. The terminal 100 can receive relevant parameters entered by the user on the interface and send the above parameters to the server 200. The server 200 can obtain processing results based on the received parameters and return the processing results to the terminal 100.

[0052] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters by itself without the cooperation of the server, and the embodiments of the present application are not limited to this.

[0053] Next describe Figure 1 The product form of the mid-terminal 100;

[0054] The terminal 100 in the embodiment of the present application can be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc., and the embodiment of the present application does not impose any restrictions on this.

[0055] Figure 2 An optional hardware structure diagram of the terminal 100 is shown.

[0056] refer to Figure 2As shown, the terminal 100 may include a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), an earphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190 and other components. Those skilled in the art will appreciate that Figure 2 These are merely examples of terminals or multi-function devices and do not constitute limitations on the terminals or multi-function devices, which may include more or fewer components than those shown in the figures, or combinations of certain components, or different components.

[0057] The input unit 130 can be used to receive input digital or character information, and generate key signal input related to the user settings and function control of the portable multifunctional device. Specifically, the input unit 130 may include a touch screen 131 (optional) and / or other input devices 132. The touch screen 131 can collect the user's touch operations on or near it (such as the user's operation on or near the touch screen using any suitable object such as fingers, joints, stylus, etc.), and drive the corresponding connection device according to a pre-set program. The touch screen can detect the user's touch action on the touch screen, convert the touch action into a touch signal and send it to the processor 170, and can receive and execute the command sent by the processor 170; the touch signal at least includes the touch point coordinate information. The touch screen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, the touch screen can be implemented using multiple types such as resistive, capacitive, infrared and surface acoustic wave. In addition to the touch screen 131, the input unit 130 can also include other input devices. Specifically, other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control key, a switch key, etc.), a trackball, a mouse, a joystick, and the like.

[0058] Among them, the input device 132 can receive input data and the like.

[0059] The display unit 140 may be used to display information input by a user or provided to a user, various menus of the terminal 100, an interactive interface, file display, and / or playback of any multimedia file.

[0060] The memory 120 can be used to store instructions and data. The memory 120 can mainly include an instruction storage area and a data storage area. The data storage area can store various data, such as multimedia files, texts, etc.; the instruction storage area can store software units such as operating systems, applications, instructions required for at least one function, or their subsets and extensions. It can also include a non-volatile random access memory; provide the processor 170 with hardware, software and data resources including management of computing and processing equipment, and support control software and applications. It is also used for the storage of multimedia files, and the storage of running programs and applications.

[0061] The processor 170 is the control center of the terminal 100. It uses various interfaces and lines to connect various parts of the entire terminal 100. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it executes various functions of the terminal 100 and processes data, thereby controlling the terminal device as a whole. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface and application program, and the modem processor mainly processes wireless communication. It is understandable that the above-mentioned modem processor may not be integrated into the processor 170. In some embodiments, the processor and the memory may be implemented on a single chip, and in some embodiments, they may also be implemented separately on separate chips. The processor 170 may also be used to generate corresponding operation control signals, send them to corresponding components of the computing and processing device, read and process data in the software, especially read and process data and programs in the memory 120, so that each functional module therein performs corresponding functions, thereby controlling the corresponding components to act according to the requirements of the instructions.

[0062] Among them, the memory 120 can be used to store software codes related to the ECU senseless refresh method, the processor 170 can execute the steps of the ECU senseless refresh method, and can also schedule other units (such as the above-mentioned input unit 130 and the display unit 140) to achieve corresponding functions.

[0063] The radio frequency unit 110 (optional) can be used for receiving and sending information or receiving and sending signals during a call, for example, after receiving the downlink information of the base station, it is sent to the processor 170 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, etc. In addition, the radio frequency unit 110 can also communicate with network devices and other devices through wireless communication. The wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile Communication (Global System of Mobile Communication, GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, CDMA), Wideband Code Division Multiple Access (Wideband Code Division Multiple Access, WCDMA), Long Term Evolution (Long Term Evolution, LTE), email, Short Messaging Service (SMS), etc.

[0064] In this embodiment of the present application, the RF unit 110 can send data to the server 200 and receive processing results sent by the server 200.

[0065] It should be understood that the radio frequency unit 110 is optional and can be replaced by other communication interfaces, such as a network port.

[0066] The terminal 100 also includes a power supply 190 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 170 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0067] The terminal 100 further includes an external interface 180 , which may be a standard Micro USB interface or a multi-pin connector, and may be used to connect the terminal 100 to communicate with other devices, or to connect a charger to charge the terminal 100 .

[0068] Although not shown, the terminal 100 may also include a flashlight, a wireless fidelity (WiFi) module, a Bluetooth module, sensors with different functions, etc., which are not described in detail here. Some or all of the methods described below may be applied in the following embodiments. Figure 2 In the terminal 100 shown.

[0069] Next describe Figure 1 The product form of the server 200;

[0070] Figure 3 A structural diagram of a server 200 is provided, such as Figure 3 As shown, the server 200 includes a bus 201, a processor 202, a communication interface 203, and a memory 204. The processor 202, the memory 204, and the communication interface 203 communicate with each other via the bus 201.

[0071] The bus 201 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0072] The processor 202 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0073] The memory 204 may include a volatile memory, such as a random access memory (RAM). The memory 204 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0074] Among them, the memory 204 can be used to store software codes related to the ECU senseless refresh method, the processor 202 can execute the steps of the ECU senseless refresh method of the chip, and can also schedule other units to achieve corresponding functions.

[0075] It should be understood that the above-mentioned terminal 100 and server 200 can be centralized or distributed devices, and the processors in the above-mentioned terminal 100 and server 200 (such as processor 170 and processor 202) can be hardware circuits (such as application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), general-purpose processors, DSPs, microprocessors or microcontrollers, etc.), or a combination of these hardware circuits. For example, the processor can be a hardware system with an instruction execution function, such as a CPU, DSP, etc., or a hardware system without an instruction execution function, such as an ASIC, FPGA, etc., or a combination of the above-mentioned hardware systems without an instruction execution function and hardware systems with an instruction execution function.

[0076] The present application provides a method for refreshing an ECU without any sense. The following is a detailed description of the method for refreshing an ECU without any sense in accordance with an embodiment of the present application in conjunction with the accompanying drawings.

[0077] Reference Figure 4 , Figure 4 A flow chart of a method for refreshing an ECU without any sense provided in an embodiment of the present application is provided, and the method may include:

[0078] Step S401: Run the first boot program in the first partition, so that when the first boot program detects a software refresh request, it refreshes the target program into the corresponding address of the second partition based on the address allocation information preconfigured for the target program.

[0079] The software refresh request is used to update the software program of the electronic control unit to the target program.

[0080] In an embodiment of the present application, the storage area of ​​the electronic control unit (hereinafter referred to as ECU) can be pre-divided into a first partition and a second partition, one of the two partitions is used to run the ECU program so that the vehicle can drive normally (running partition), and the other partition is used as a backup partition for ECU software refresh.

[0081] Optionally, the first partition and the second partition are divided in a 1:1 manner. Figure 5 , is a schematic diagram of an optional structure of the first partition and the second partition. Figure 5The first partition contains three sub-partitions, namely BOOT1 sub-partition, APP1 sub-partition and BackUp1 sub-partition, and the second partition also contains three sub-partitions, namely BOOT2 sub-partition, APP2 sub-partition and BackUp2 sub-partition. Among them, BOOT1 and BOOT2 sub-partitions are used to store bootloader, APP1 and APP2 sub-partitions are used to store ECU programs, and BackUp1 and BackUp2 sub-partitions are used to store default programs.

[0082] In the embodiment of the present application, the functions of the boot program include: (1) starting the ECU and completing the basic operating environment configuration; (2) monitoring whether there is a software refresh request, and if so, performing a software update on the backup partition; optionally, "monitoring whether there is a software refresh request" includes: monitoring whether there is a software refresh request on the CANFD (CAN with Flexible Data-Rate) network or the EtherNet (Ethernet) network; (3) after the software update is completed or the power-on is completed normally, a software jump of the actual executed APP (application program, specifically referring to the ECU program in this application) is performed.

[0083] For ease of distinction, the embodiment of the present application describes the boot program stored in the BOOT1 sub-partition as the first boot program, and describes the boot program stored in the BOOT2 sub-partition as the second boot program.

[0084] First, the first partition is used as the running partition, and the second partition is used as the backup partition. The embodiment of the present application first runs the first boot startup program in the first partition. As described above, in addition to starting the ECU and completing the basic running environment configuration, the first boot startup program also monitors whether there is a software refresh request. If there is no software refresh request, the first boot startup program will verify the ECU program in its own partition according to the statically configured program address (pre-configured initial address) stored in its own partition (including software validity check). If the verification passes, after the ECU program in its own partition is normally powered on, it jumps to run the ECU program in its own partition.

[0085] Optionally, the software refresh request is a request sent by the host computer to update the ECU program in the backup partition to the target program. Optionally, the host computer can be a computer, an OTA (Over The Air Technology) master control device. Of course, the host computer can also be other devices, which is not limited in this application.

[0086] If the first boot program detects a software refresh request, the ECU program in the second partition is updated, specifically, the ECU program in the second partition is updated to the target program. In this embodiment, address allocation information can be dynamically configured for the target program, and the address allocation information will point to a certain position of the APP2 sub-partition in the second partition, and then the first boot program can flash the target program into the corresponding address of the second partition based on the address allocation information dynamically pre-configured for the target program, that is, flash the target program into the address pointed to by the address allocation information in the second partition.

[0087] The above-mentioned “dynamic” means that for different target programs, the configured address allocation information can be the same or different, which can be specifically determined according to the size of the target program and the hardware address space resources.

[0088] Since the address allocation information can be dynamically configured for the target program, software refresh of any address allocation of the ECU is achieved, which is more flexible.

[0089] Step S402: after the target program is refreshed, switch to the second partition to sequentially run the second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition runs, the second boot program can verify the target program in the second partition based on the address allocation information.

[0090] In an embodiment of the present application, after the target program is refreshed in the second partition, that is, after the target program is completely written into the second partition, the first partition can be switched to the second partition to start running from the second boot startup program in the second partition. When the second boot startup program runs successfully, it jumps to run the target program in the second partition, thereby realizing the ECU's senseless refresh.

[0091] During the refresh process, if the address allocation information is changed compared to the initial address, the first boot program can record the changed address allocation information, so that the second boot program can verify the target program in the second partition based on the address allocation information of the target program.

[0092] Optionally, the first boot program may record the address allocation information of the target program in the APP2 sub-partition of the second partition, so that the second boot program may obtain the address allocation information of the target program.

[0093] Step S403: If the target program in the second partition fails to run successfully, then run the default program in the second partition, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

[0094] As mentioned above, the second partition includes the BackUp2 sub-partition, which stores the default program of the ECU. The default program includes the basic functions of the ECU, and the default program will not go wrong during operation, thereby ensuring that when the target program in the second partition cannot run successfully, the ECU can still be prevented from getting stuck by running the default program in the second partition.

[0095] Optionally, when the default program is running, relevant staff can be notified so that they can repair the target program and manually flash it into the second partition or the first partition during the running of the default program, thereby enhancing the robustness of the ECU software.

[0096] Optionally, the default program may be the first version of the ECU software program, or may be the version that occupies the smallest storage space among various versions of the ECU software program. Of course, the default program may also be other, which is not specifically limited in this application.

[0097] The ECU senseless refresh method provided in the present application can refresh the target program in the second partition while running the first partition. After the refresh is completed, the target program in the second partition can be run. Since the old program in the first partition can be run while refreshing the target program, the present application can complete the refresh during the normal operation of the vehicle, thereby realizing the senseless refresh of the ECU.

[0098] Furthermore, the present application can dynamically pre-configure address allocation information for the target program according to the size of the target program and the hardware address space resources, which improves the utilization rate of the hardware address space resources on the one hand, and can implement a software refresh strategy with arbitrary address division by not constraining the address allocation of the program to be refreshed (i.e., the target program) on the other hand, with higher flexibility. When the refreshed target program has a running problem, it can jump to run the default program, avoiding the problem of driving safety caused by the electronic control unit being stuck due to a problem with the target program.

[0099] In addition, this application does not require refreshing the driver. Even if there is a need for version rollback, multiple version backups, etc., no manual intervention is required, saving labor costs.

[0100] In some embodiments of the present application, in order to facilitate the refresh process, the target program can be divided into multiple data segments, optionally, the multiple data segments include program segments and calibration data segments, for example, see Figure 6 A schematic diagram of a data segment within an APP2 sub-partition is shown, where the ECU program within the APP2 subprogram includes a program segment and a calibration data segment.

[0101] In this embodiment, address allocation information can be pre-configured for multiple data segments respectively, and then the multiple data segments are downloaded in sequence to the addresses indicated by the corresponding address allocation information in the second partition. That is, the process of "based on the address allocation information pre-configured for the target program, flashing the target program into the corresponding addresses of the second partition" in the previous text specifically refers to: based on the address allocation information pre-configured for the multiple data segments respectively, the multiple data segments are flashed into the corresponding addresses of the second partition respectively.

[0102] Optionally, the address allocation information pre-configured for each data segment can be stored in a header file pre-configured for the data segment, that is, the present embodiment can pre-configure a header file for each data segment. When each data segment needs to be flashed into the second partition, that is, when each data segment needs to be downloaded, the header file of each data segment is downloaded first, and according to the address allocation information stored in the header file, the corresponding data segment is downloaded to the corresponding address of the second partition.

[0103] In the embodiment of the present application, when configuring the address allocation information for each data segment, the configuration can be performed with reference to the hardware address space resources and the length of each data segment. After configuring the address allocation information of each data segment, if the address allocation information is updated compared to the old program, the first boot program can record the address allocation information, and then the subsequent second boot program can perform program verification based on the address allocation information. This method enables the present application to dynamically adjust the length and storage address of each data segment (for example, in the old ECU program, the program segment can be made 2M in size and the calibration segment can be made 1M in size, while in the new ECU program (i.e., the target program), the program segment can be made 2.5M in size and the calibration segment can be made 0.5M in size), and it can still run normally without errors after dynamic adjustment, which improves the flexibility of the ECU program version update size, and by dynamically adjusting the address allocation information, the present application can make full use of Flash resources, thereby adding more system functions. In addition, the flexible address allocation method makes it compatible with the target program even if the boot program segment is not updated, saving development time and hardware replacement costs.

[0104] In some other embodiments of the present application, after the target program in the second partition is successfully run, the target program in the second partition can be flashed into the first partition to ensure that the ECU programs in the two partitions remain consistent.

[0105] In one possible implementation, the process of determining whether the target program in the second partition is successfully running in this embodiment may include: determining whether the number of times the second boot startup program is repeatedly run within a preset time length reaches a preset number of times; if so, determining that the target program in the second partition is successfully running; if not, determining that the target program in the second partition is not successfully running.

[0106] In this embodiment, if the target program in the second partition has an abnormality or defect, it will fail to run. At this time, the second boot startup program will be reset and rerun. Therefore, if the number of repeated runs of the second boot startup program reaches the preset number of times within the preset time length, it means that the target program in the second partition cannot be successfully run. Conversely, if the number of repeated runs of the second boot startup program within the preset time length does not reach the preset number of times, it is determined that the target program in the second partition is successfully run.

[0107] The method provided in the embodiment of the present application flashes the target program into the first partition only after the target program in the second partition has been successfully run, thereby avoiding the invalidation of the flashing process of the first partition due to anomalies or defects in the target program in the second partition, and improving the efficiency of refreshing (i.e. updating) the target program.

[0108] In another possible implementation, the main control chip of the ECU provided in the present application may have an AB Swap function, and the ABSwap function enables the first partition and the second partition to have the same storage space and the same storage address.

[0109] Then, the embodiment of the present application can divide the storage area of ​​the ECU into a first partition and a second partition in a 1:1 ratio by enabling the AB Swap function of the main control chip, and make the first partition and the second partition have the same storage address, thereby saving the time of manual partitioning and improving efficiency.

[0110] Optionally, the main control chip can be a Renesas RH850 / U2A16 series automotive-grade MCU (Microcontroller Unit) chip.

[0111] As mentioned above, the first partition and the second partition each contain three sub-partitions. For example, for the first partition, the 0x0-0x5FFFF segment can be defined as the BOOT1 sub-partition, the 0x60000-0x11FFFF segment can be defined as the APP1 sub-partition, and the 0x120000-0x7FFFFF segment can be defined as the BackUp1 sub-partition. Similarly, for the second partition, the 0x0-0x5FFFF segment can be defined as the BOOT2 sub-partition, the 0x60000-0x11FFFF segment can be defined as the APP2 sub-partition, and the 0x120000-0x7FFFFF segment can be defined as the BackUp2 sub-partition.

[0112] In order to enable those skilled in the art to better understand the present application, an optional implementation process of the present application scheme is introduced below in conjunction with the accompanying drawings.

[0113] First, use the first partition as the running partition and the second partition as the backup partition, and perform the following process.

[0114] When allocating address allocation information to each data segment contained in the target program, the AB Swap function of the main control chip is started, and the Flash segment where the first partition is located is mapped to the startup segment, so that the ECU software can enter the first partition when it starts, and the ECU software startup address is written as 0x0 address.

[0115] Run the first boot program in the first partition, start the ECU through the first boot program, and complete the basic operating environment configuration. During the normal ECU startup process, the first boot program will verify the ECU program in the APP1 sub-partition according to the initial address (that is, 0x0 address) and check the software validity. After it is correct, it will jump to run the ECU program in APP1; if the first boot program detects a software refresh request during the operation of the ECU program in APP1, refer to Figure 7 As shown, the ECU program in the second partition is updated, that is, the ECU program in the APP2 sub-partition is updated to the target program. Specifically, the header file of the first data segment contained in the target program is downloaded, and according to the address allocation information in the header file (defined as the first address allocation information here), the first data segment is downloaded to the address indicated by the first address allocation information in APP2 in the second partition; then the header file of the second data segment contained in the target program is downloaded, and according to the address allocation information in the header file (defined as the second address allocation information here), the second data segment is downloaded to the address indicated by the second address allocation information in APP2 in the second partition; and so on, until all the data segments are downloaded.

[0116] See also Figure 8 As shown, it is a comparison diagram of the space occupied by the new and old ECU programs in the first partition and the second partition. Since the present application can pre-configure address allocation information for each data segment contained in the target program (i.e., the new ECU program), the size of the target program can be dynamically adjusted. Therefore, if the old ECU program occupies a large space, the new ECU program (i.e., the target program) can occupy a smaller space when the ECU program is updated.

[0117] In this embodiment, during the above downloading process, the first boot program may also record the address allocation information of each data segment.

[0118] After the refresh is completed, the second boot startup program will verify the target program in the second partition. If the verification is incorrect, the target program in the second partition can be adjusted. When the verification is correct, the software flip flag is set.

[0119] Next, the ECU program in the first partition is reset, and the main control chip switches to the second running partition to start running the second boot startup program and the target program. When the target program is powered on and runs for a preset period of time without any abnormality or defect (that is, the target program runs successfully), the target program in the second partition is flashed into APP1 of the first partition to update the ECU program in APP1 to the target program.

[0120] When an exception occurs in the target program in the second partition, a reset is triggered and the second boot program is restarted. When the second boot program is repeated for a preset number of times within a preset time, the default program in the second partition is jumped to wait for ECU rescue.

[0121] When the ECU program needs to be updated next time, the second partition can be used as the running partition and the first partition as the backup partition, so that the ECU program in the first partition can be updated when the target program in the second partition is running. The specific process corresponds to the above. Please refer to the above process for details and will not be repeated here.

[0122] It can be seen that the present application can realize the senseless refresh of ECU without restricting the address allocation of the updated software (i.e., the target program), and can realize software refresh and software multi-backup strategy with arbitrary address allocation, which is more flexible and can make better use of hardware address space resources; and the present application can actively switch to the default program with no operating problems when the target program has an abnormal operating problem, avoiding scenarios with great safety hazards such as the vehicle being unable to start under extreme working conditions, stalling and losing control at high speed, and ensuring the safety of passengers.

[0123] The above introduces a method for refreshing an ECU without any sense provided by an embodiment of the present application. The following will introduce a device for executing the above method for refreshing an ECU without any sense.

[0124] See also Fig. 9 , Fig. 9 This is a schematic diagram of the structure of an ECU non-sensing refresh device provided in an embodiment of the present application. Fig. 9 As shown, the device may include:

[0125] The first running module 501 is used to run the first boot program in the first partition, so that when the first boot program detects a software refresh request, based on the address allocation information preconfigured for the target program, the target program is refreshed into the corresponding address of the second partition, wherein the software refresh request is used to update the software program of the electronic control unit to the target program, and the first partition and the second partition are obtained by dividing the storage area of ​​the electronic control unit;

[0126] A second running module 502, configured to switch to the second partition after the target program is refreshed, so as to sequentially run the second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition is run, the second boot program can verify the target program in the second partition based on the address allocation information;

[0127] The third running module 503 is used to run the default program in the second partition if the target program in the second partition fails to run successfully, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

[0128] In a possible implementation, the target program is composed of multiple data segments, and each data segment is pre-configured with address allocation information.

[0129] Then, the process of flashing the target program into the corresponding address of the second partition based on the address allocation information preconfigured for the target program in the first running module may include: flashing multiple data segments into the corresponding addresses of the second partition based on the address allocation information preconfigured for multiple data segments respectively.

[0130] In a possible implementation, the address allocation information preconfigured for each data segment is stored in a header file preconfigured for the data segment.

[0131] In a possible implementation, the ECU senseless refresh device provided in the present application may also include: a data backup module, which is used to refresh the target program in the second partition into the first partition if the target program in the second partition runs successfully.

[0132] In a possible implementation, the ECU non-sensing refresh device provided in the present application may also include: a judgment module, which is used to determine whether the target program in the second partition is successfully run, specifically, to determine whether the number of repeated runs of the second boot startup program within a preset time length reaches a preset number of times. If so, it is determined that the target program in the second partition is successfully run; if not, it is determined that the target program in the second partition is not successfully run.

[0133] In a possible implementation, the main control chip of the electronic control unit has an AB Swap function, and the AB Swap function enables the first partition and the second partition to have the same storage space and the same storage address.

[0134] The present application also provides an electronic device in an embodiment. Fig.10As shown, it shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Fig.10 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0135] like Fig.10 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0136] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a memory card, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Fig.10 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0137] Also provided in an embodiment of the present application is a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any one of the ECU senseless refresh methods provided in the embodiments of the present application.

[0138] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any ECU non-sensing refresh method provided in the embodiment of the present application.

[0139] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0140] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0141] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0142] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. A method for refreshing an ECU without any sense, characterized in that: include: Running a first boot program in the first partition, so that when the first boot program detects a software refresh request, based on address allocation information preconfigured for the target program, the target program is refreshed into a corresponding address of the second partition, wherein the software refresh request is used to update the software program of the electronic control unit to the target program, and the first partition and the second partition are obtained by dividing a storage area of ​​the electronic control unit; After the target program is refreshed, switching to the second partition to sequentially run the second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition runs, the second boot program can verify the target program in the second partition based on the address allocation information; If the target program in the second partition fails to run successfully, a default program in the second partition is run, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

2. The ECU non-sensing refresh method according to claim 1, characterized in that: The target program is composed of a plurality of data segments, each of which is pre-configured with address allocation information; The step of flashing the target program to a corresponding address of the second partition based on the address allocation information preconfigured for the target program includes: Based on the address allocation information preconfigured for the multiple data segments respectively, the multiple data segments are flushed to the corresponding addresses of the second partition respectively.

3. The ECU non-sensing refresh method according to claim 2 is characterized in that: The address allocation information preconfigured for each of the data segments is stored in a header file preconfigured for the data segment.

4. The ECU non-sensing refresh method according to claim 1, characterized in that: Also includes: If the target program in the second partition runs successfully, the target program in the second partition is flashed into the first partition.

5. The ECU non-sensing refresh method according to claim 4 is characterized in that: The process of determining whether the target program in the second partition is successfully executed includes: Determining whether the number of times the second boot program is repeatedly executed reaches a preset number of times within a preset time period; If yes, determining that the target program in the second partition runs successfully; If not, it is determined that the target program in the second partition has not been successfully executed.

6. The ECU non-sensing refresh method according to claim 1, characterized in that: The main control chip of the electronic control unit has an AB Swap function, and the AB Swap function enables the first partition and the second partition to have the same storage space and the same storage address.

7. An ECU non-sensing refresh device, characterized in that: include: a first running module, configured to run a first boot program in the first partition, so that when the first boot program detects a software refresh request, the target program is refreshed into a corresponding address of the second partition based on address allocation information preconfigured for the target program, wherein the software refresh request is used to update the software program of the electronic control unit to the target program, and the first partition and the second partition are obtained by dividing a storage area of ​​the electronic control unit; a second running module, configured to switch to the second partition after the target program is refreshed, so as to sequentially run a second boot program in the second partition and the target program in the second partition, wherein before the target program in the second partition is run, the second boot program can verify the target program in the second partition based on the address allocation information; The third running module is used to run the default program in the second partition if the target program in the second partition fails to run successfully, wherein the default program is a program that includes basic functions of the electronic control unit and can run normally.

8. A computer program product, characterized in that It includes computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the ECU senseless refresh method as described in any one of claims 1 to 6.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the ECU senseless refresh method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the ECU senseless refresh method as described in any one of claims 1 to 6.

Images