An upgrading method and system of a vehicle-mounted ECU control unit supporting a hibernation function

Abstract

The application belongs to the technical field of automobile ECU data flashing, and specifically provides an upgrading method and system of a vehicle-mounted ECU control unit supporting a sleep function, wherein the method comprises the following steps: an upgrading request controller sends an upgrading request instruction frame to an ECU; the ECU starts upgrading and downloads an upgrading package; the total programmable page number N is calculated according to the upgrading package size and the programming page size; the ECU requests the upgrading request controller to send the i-th page data, i is an integer starting from 1, and after the upgrading data and the verification are successful, the i-th page data is flashed to the i-th page of the to-be-upgraded firmware area until the upgrading is completed. The automobile ECU upgrading method is reliable and safe, the ECU enters the upgrading state immediately after receiving the upgrading instruction, no confirmation of the user is needed, and no judgment of the vehicle driving state is needed. During the upgrading, the ECU can even normally perform data interaction with the vehicle without affecting the vehicle driving, so that the safe upgrading without stopping is achieved, the user experience is greatly improved, the traffic jam is prevented, and the traffic efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of automotive ECU data flashing technology, and more specifically, to an upgrade method and system for an on-board ECU control unit that supports hibernation function. Background Technology

[0002] As automotive electronics become increasingly electrified and intelligent, more and more functions are integrated. Many functional and safety defects are often unpredictable during the product design phase. Therefore, most OEMs require that the ECU control units of certain in-vehicle devices be upgradeable at the factory. When market feedback indicates device defects, especially when these defects can be remedied by software upgrades, they are handled by remotely updating the ECU via OTA (Over-The-Air) updates from vehicle networking devices or in-vehicle intelligent gateways—a process commonly known as patching. This method is often the most economical and fastest, and the preferred choice for most OEMs.

[0003] Different ECU upgrades have different safety conditions, but most ECU units ensure that the vehicle is in an absolutely safe upgrade environment by judging key signals such as the vehicle's parking status, gear position, and speed, or even by confirming through the human-vehicle interaction system when starting the safety upgrade process.

[0004] When the ECU receives an upgrade command, it resets and jumps to the bootloader area to process the upgrade flashing operation in a single-task manner. Once the ECU enters flashing mode, it will no longer respond to external commands unrelated to the upgrade. The vehicle cannot start if the ECU flashing is not complete.

[0005] Although the ECU samples and judges some key signals before the upgrade, many external factors, such as prolonged vehicle vibration and aging wiring harness contact problems, vehicle fuse failure, and temporary stops at traffic lights, can cause the ECU to abnormally enter the flashing state. When the ECU, which is related to driving safety, enters the flashing state, the original operating code has been erased, making it impossible to temporarily exit the upgrade and start the vehicle. The car must be started only after the flashing is complete. This leads to long traffic jams caused by vehicle upgrades, which greatly affects public transportation order and efficiency. Summary of the Invention

[0006] This invention addresses the technical problem in the prior art where a car cannot start after an ECU related to driving safety enters a flashing / rewriting state, causing traffic congestion.

[0007] This invention provides an upgrade method for an on-board ECU control unit that supports hibernation function, comprising the following steps:

[0008] Step 1: The upgrade request controller sends a wake-up frame to the ECU, waits 1 second, and then sends an upgrade request command frame to the ECU.

[0009] Step 2: The ECU replies to the upgrade request controller with the starting address Program_entry of the application partition to be upgraded and the programmable page size;

[0010] Step 3: The upgrade request controller continues to send commands to the ECU via the communication interface to request the download of the upgrade package;

[0011] Step 4: If the ECU determines that the size of the upgrade package is less than or equal to the size of the application partition to be upgraded, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size; otherwise, it replies that programming has failed and exits the upgrade program.

[0012] Step 5: Set the programmed status flag field on the fourth page of the ECU parameter partition, and set the global variable upgrade flag to true. Record the global variable update_sts = upgrade package data update_data.

[0013] Step 6: The ECU requests the upgrade request controller to send the i-th page of data, where i is an integer starting from 1 and incrementing.

[0014] Step 7: The ECU receives the upgrade data of page i and verifies it successfully, then flashes the data of page i to page i of the firmware area to be upgraded;

[0015] Step 8: The ECU replies to the upgrade request controller that the upgrade is successful. The ECU assigns a value to the global variable upgrade flag to indicate that the upgrade is complete. The global variable update_sts is set to update_para. The ECU then exits the programming thread.

[0016] Preferably, step one specifically includes:

[0017] If the current ECU is in a sleep low-power state, the upgrade controller's wake-up frame is used to wake up the ECU;

[0018] If the ECU is currently running, it does not respond to wake-up frame operations.

[0019] Preferably, step 0 is included before step one:

[0020] First, the Flash memory storing the ECU's operating code is divided into a linearly contiguous Bootloader area, parameter area, first application area, and second application area, with each area being an integer multiple of the smallest erase unit.

[0021] The Bootloader area is used to store the system startup code, and the bootloader reads the contents of the second partition parameter area to determine the application entry address.

[0022] The parameter partitions include a first page, a second page, a third page, and a fourth page. The first page stores the current entry address of the application and its checksum. The bootloader code first reads this content and performs verification to determine whether to execute the program in the first application partition or the program in the second application partition. The second page is used to back up and store data content. Before programming the data content of the first page, the data content of the first page is copied to the address space of the second page. The third page stores the minimum erase unit page size, the starting address and size of the first application partition, and the starting address and size of the second application partition. The fourth page stores the erase status flag of the application to be upgraded and the programming status of the application partition to be upgraded.

[0023] The first application partition is used to store application code, and it is empty during the initial production state; the second application partition stores application code, and it is empty during the initial production state.

[0024] Secondly, when the ECU receives the upgrade request command frame from the upgrade request controller, the ECU jumps to the Bootloader area to start running.

[0025] Preferably, the ECU switching to the Bootloader area to begin operation specifically includes:

[0026] S01, the ECU reads the first page of the parameter area and parses out the application entry address A1 and the check code V1;

[0027] S02, Calculate the checksum V11 of the application entry address A1;

[0028] If the value of V1 is equal to the value of V11, jump to address A1 to start executing the application;

[0029] If the value of V1 is not equal to the value of V11, then read the contents of the second page of the parameter area, parse out the application entry address A2 and the checksum V2; jump to address A2 to start execution.

[0030] Preferably, step two specifically includes:

[0031] If the current program entry address is the address of the first application partition, then the application partition to be upgraded is the second application partition; otherwise, the application partition to be upgraded is the first application partition.

[0032] Preferably, step S100 is included after step three and before step four:

[0033] A hibernation detection thread with higher priority than the communication thread is created to detect whether the ECU can enter hibernation mode. When the hibernation thread detects that the ignition signal changes from an invalid signal to a valid signal, it creates all driving-related tasks to ensure normal information interaction with the vehicle.

[0034] Preferably, S100 specifically includes the following situations:

[0035] (1) When the hibernation thread detects that the ignition signal has changed from a valid signal to an invalid signal, it shuts down all threads related to vehicle operation and queries the value of the global variable update_sts.

[0036] (2) If the current value of update_sts is the upgrade package data update_data, then continue to wait for the value of update_sts to be updated to the update parameter update_para;

[0037] (3) If the current global variable update_sts has the value of update_none, then query the erase status flag of the application partition to be upgraded on the fourth page of the parameter area.

[0038] Preferably, S100 specifically includes the following situations:

[0039] If the current value of the global variable update_sts is the update parameter update_para, perform the following steps:

[0040] S101, Erase the data content of the second page of the parameter partition;

[0041] S102, copy the data content of the first page of the parameter partition to the second page of the parameter partition for backup;

[0042] S103, erase the data content of the first page of the parameter partition;

[0043] S104, Write the application entry address as the upgraded application partition to the first page of the parameter area, and update its checksum;

[0044] S105, erase the data content of the second page of the parameter partition;

[0045] S106, Copy the data content of the first page of the parameter partition to the second page of the parameter partition for synchronization;

[0046] S107, assign a value to the global variable upgrade flag to complete the upgrade, and record update_sts = update_end;

[0047] S108, the ECU determines that the ignition signal is invalid and enters sleep mode after updating_sts is updated_end for 5 seconds.

[0048] Preferably, steps S101 to S108 are executed when the ignition signal is invalid or the device is in sleep mode, and the current operating area cannot be erased before the programming is completed.

[0049] This invention also provides an upgrade for an on-board ECU control unit that supports hibernation functionality. The system is used to implement a method for upgrading an on-board ECU control unit that supports hibernation functionality, comprising:

[0050] The upgrade request controller is used to send a wake-up frame to the ECU, wait 1 second, and then send an upgrade request command frame and a command to request the download of the upgrade package to the ECU.

[0051] The ECU determines whether the upgrade package size is less than or equal to the partition size of the application to be upgraded. If so, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size; otherwise, it replies that programming has failed and exits the upgrade program.

[0052] It requests the upgrade request controller to send the i-th page of data, where i is an integer starting from 1; it receives the i-th page of upgrade data and verifies its success, then flashes the i-th page of data to the i-th page of the firmware area to be upgraded.

[0053] The ECU replies to the upgrade request controller that the upgrade is successful, assigns a value to the global variable upgrade flag to complete the upgrade, records the global variable update_sts = update parameter update_para, and then exits the programming thread.

[0054] Beneficial Effects: This invention provides an upgrade method and system for an on-board ECU control unit that supports hibernation function. The method includes: Step 1, an upgrade request controller sends a wake-up frame to the ECU and waits for 1 second before sending an upgrade request command frame to the ECU; Step 2, the ECU replies to the upgrade request controller with the starting address Program_entry of the application partition to be upgraded and the programmable page size; Step 3, the upgrade request controller continues to send a command to the ECU to request downloading the upgrade package through the communication interface; Step 4, if the ECU determines that the upgrade package size is less than or equal to the size of the application partition to be upgraded, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programmable page size; otherwise, it replies with a programming failure message. Step 5: Set the programmed status flag field on the fourth page of the ECU parameter partition, and set the global variable upgrade flag to true. Record the global variable update_sts = upgrade package data update_data. Step 6: The ECU requests the upgrade request controller to send the i-th page of data, where i is an integer incrementing from 1. Step 7: The ECU receives the i-th page of upgrade data and verifies its success, then writes the i-th page of data to the i-th page of the firmware area to be upgraded. Step 8: The ECU replies to the upgrade request controller that the upgrade is successful, sets the global variable upgrade flag to complete the upgrade, records the global variable update_sts = update parameter update_para, and the ECU exits the programming thread. This automotive ECU upgrade method is reliable and safe. The ECU enters the upgrade state immediately upon receiving the upgrade command, without user confirmation or needing to assess the vehicle's driving status. During the upgrade, the ECU can even interact with the vehicle normally without affecting its operation, thus achieving a safe, non-stop upgrade, greatly improving user experience, preventing traffic congestion, and improving traffic efficiency. Attached Figure Description

[0055] Figure 1 A flowchart illustrating an upgrade method for an on-board ECU control unit that supports hibernation functionality, provided by this invention.

[0056] Figure 2 This is a schematic diagram of the Flash partition provided by the present invention;

[0057] Figure 3 This is a schematic diagram of a hibernation task provided by the present invention. Detailed Implementation

[0058] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0059] Figure 1The present invention provides an upgrade method for an on-board ECU control unit supporting hibernation function, comprising: Step 1, an upgrade request controller sends a wake-up frame to the ECU, waits 1 second, and then sends an upgrade request command frame to the ECU; Step 2, the ECU replies to the upgrade request controller with the starting address Program_entry of the application partition to be upgraded and the programmable page size; Step 3, the upgrade request controller continues to send a command to the ECU to request downloading the upgrade package through the communication interface; Step 4, if the ECU determines that the upgrade package size is less than or equal to the size of the application partition to be upgraded, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programmable page size; otherwise, it replies that programming has failed and exits the upgrade process. The procedure is as follows: Step 5, set the programmed status flag field on the fourth page of the ECU parameter partition, and assign the global variable upgrade flag to true, recording the global variable update_sts = upgrade package data update_data; Step 6, the ECU requests the upgrade request controller to send the i-th page of data, where i is an integer incrementing from 1; Step 7, the ECU receives the i-th page of upgrade data and verifies its success, then writes the i-th page of data to the i-th page of the firmware area to be upgraded; Step 8, the ECU replies to the upgrade request controller that the upgrade is successful, the ECU assigns the upgrade flag to the global variable upgrade flag to complete the upgrade, records the global variable update_sts = update parameter update_para, and the ECU exits the programming thread. This automotive ECU upgrade method is reliable and safe. The ECU enters the upgrade state immediately upon receiving the upgrade command, without requiring user confirmation or judgment of the vehicle's driving status. During the upgrade, the ECU can even interact with the vehicle normally without affecting vehicle operation, thus achieving a safe, non-stop upgrade, greatly improving the user experience, preventing traffic congestion, and improving traffic efficiency.

[0060] In a specific implementation scenario:

[0061] Step 1: The upgrade request controller sends a wake-up frame to the ECU. After sending the wake-up frame, the upgrade request controller waits one second before sending an upgrade request command frame to the ECU. The ECU receives the upgrade request command frame through the communication interface.

[0062] It should be noted that: if the current ECU is in a sleep low-power state, the wake-up frame of the upgrade controller is used to wake up the ECU; if the current ECU is in a running state, it does not respond to the wake-up frame operation.

[0063] Step two, the ECU replies to the upgrade request controller device with the starting address of the application partition to be upgraded, Program_entry, and the programmable page size.

[0064] It's important to note that the current program entry address and the entry address of the application partition to be upgraded are relative. If the current program entry address is the address of the first application partition, then the application partition to be upgraded is the address of the second application partition; conversely, if the current program entry address is not the address of the first application partition, then the application partition to be upgraded is the address of the first application partition. The current application partition can be determined by whether the current PC pointer value of the application is less than the starting address of the second application partition. If the current PC pointer value is less than the starting address of the second application partition, then the current program entry address is the starting address of the first application partition; if the current PC pointer value is greater than the starting address of the second application partition, then the current program entry address is the starting address of the second application partition. The current program entry address can also be determined by reading the contents of the first or second page of the parameter area.

[0065] Step 3: After receiving the Program_entry starting address of the application partition to be upgraded and the programmable page size parameter, the upgrade request controller continues to send a command requesting the download of the upgrade package to the ECU through the communication interface. The command includes the upgrade package size.

[0066] Step four: If the ECU determines that the upgrade package size is less than or equal to the partition size of the application to be upgraded, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size. Otherwise, programming fails, and the upgrade process exits.

[0067] Step 5: Set the programmed status flag field on the fourth page of the ECU parameter partition, and set the global variable upgrade flag to true. Record the global variable update_sts = upgrade package data update_data.

[0068] Step six: The ECU requests the transmission of the i-th page of data (i is an integer starting from 1), allowing only the last page's data length to be less than the minimum erase page size. Data can be received in page-size order or data length order without specifying page size.

[0069] The format of the programming data in the controller's response to the upgrade request is shown in the table below:

[0070]

[0071] Step 7: The ECU receives and successfully verifies the upgrade data on page i, then flashes the data from page i to page i of the firmware area to be upgraded. This includes the following steps:

[0072] a. The ECU determines whether the current page i value is equal to the total number of programmable pages N. If not, the i value is incremented by 1, and the process jumps to step five. If yes, the process continues to the next step.

[0073] b. Verify the firmware area code. If the verification passes, the entire application programming to be upgraded is complete.

[0074] Step 8: The ECU replies to the upgrade request controller that the upgrade is successful. The ECU assigns a value to the global variable upgrade flag to indicate that the upgrade is complete. The global variable update_sts is set to update_para. The ECU then exits the programming thread.

[0075] Among them, such as Figure 2 As shown, the Flash memory storing the ECU's operating code is divided into linear, contiguous partitions. The size of each partition is an integer multiple of the smallest erase unit. Each partition contains at least the following four areas:

[0076] Bootloader area: The system power-on / reset entry address, used to store the system startup boot code. The bootloader reads the contents of the second partition parameter area to determine the application entry address.

[0077] Parameter area: The parameter partition size is at least 4 pages in size, namely the first page, the second page, the third page, and the fourth page.

[0078] The first page stores the current entry address of the application and its checksum. The Bootloader code first reads this content and performs a checksum to determine whether to execute the program from the first application partition or the program from the second application partition.

[0079] The second page is used to back up and store data, which is a backup of the data on the first page. Before programming the data on the first page, the data on the first page is copied to the address space of the second page. This prevents incomplete updates to the first page under extreme conditions and also prevents the application entry address from being lost due to data verification failures, which could lead to program malfunction. In the production stage, both the first and second pages store the starting address of the first application partition.

[0080] The third page stores the minimum erase unit page size, the starting address and size of the first application partition, and the starting address and size of the second application partition. The content of this page must not be modified, and write protection should be enabled at the factory to prevent changes to the data on this page.

[0081] Page four stores the erase status flag and programming status of the application to be upgraded. The programming status indicates whether the application has been programmed; both partially and fully programmed fields are considered programmed. By default, this page contains the erase status flag of the application to be upgraded as erased, and the programming flag field is empty (no data has been written).

[0082] The first application partition, app1, is used to store the application code, and it is used to store the application code in the initial production state.

[0083] The second application partition, app2, stores the application code and is empty in the initial production state.

[0084] In the preferred embodiment, after the ECU program is powered on / reset or awakened by a wake-up source, that is, after the ECU receives the upgrade request command frame sent by the upgrade request controller, the ECU jumps to the Bootloader area to start running; the Bootloader code execution begins, and the specific steps are as follows:

[0085] S01, the ECU reads the first page of the parameter area and parses out the application entry address A1 and the check code V1;

[0086] S02, Calculate the checksum V11 of the application entry address A1;

[0087] If the value of V1 is equal to the value of V11, jump to address A1 to start executing the application;

[0088] If the value of V1 is not equal to the value of V11, then read the contents of the second page of the parameter area, parse out the application entry address A2 and the checksum V2; jump to address A2 to start execution.

[0089] Preferred solution, for reference Figure 3 After the Bootloader code is executed, the specific steps include:

[0090] S1, jump to the application code area (app1 and app2).

[0091] S2, Initialize the communication interface used for programming operations. The communication interface must have sleep / wake-up function (the communication interface can be one or more of the following with external communication capabilities: CAN, SPI, IIC, USART, USB, etc.).

[0092] S3, obtain the entry address of the application to be upgraded, Program_entry.

[0093] S4, create a global variable upgrade flag and initialize it with the value update_none. Record the global variable update_sts as the global variable upgrade flag initial value update_none.

[0094] S5: Create a hibernation detection thread with priority P+1 to detect whether the ECU can enter hibernation mode.

[0095] S6 creates a communication thread with priority P. The larger the number P, the lower the thread priority; that is, P+1 priority is greater than P priority.

[0096] S7: When the hibernation thread detects that the ignition signal has changed from invalid to valid, it creates all driving-related tasks to ensure normal information interaction with the vehicle. Specifically, this includes the following scenarios:

[0097] When the hibernation thread detects that the ignition signal has changed from a valid signal to an invalid signal, it shuts down all vehicle-related threads and queries the value of the global variable update_sts.

[0098] If the current value of the global variable update_sts is the upgrade package data update_data, then continue to wait for the value of update_sts to be updated to the update parameter update_para.

[0099] If the current value of the global variable update_sts is the update parameter update_para, execute the following steps. These steps should be performed when the ignition signal is invalid and the device is in sleep mode. The current operating area cannot be erased before this programming is completed:

[0100] S71, erase the data content of the second page of the parameter partition;

[0101] S72, copy the data content of the first page of the parameter partition to the second page of the parameter partition for backup;

[0102] S73, erase the data content of the first page of the parameter partition;

[0103] S74, write the application entry address to the upgraded application partition to the first page of the parameter area, and update its checksum;

[0104] S75, erase the data content of the second page of the parameter partition;

[0105] S76, copy the data content of the first page of the parameter partition to the second page of the parameter partition for synchronization;

[0106] S77, the global variable upgrade flag is assigned a value indicating that the upgrade is complete, and update_sts = update_end is recorded as complete;

[0107] S78, the ECU determines that the ignition signal is invalid and update_sts is update_end for 5 seconds before entering sleep mode.

[0108] If the current global variable `update_sts` has the value of `update_none`, the ECU queries the erase status flag of the application partition to be upgraded on the fourth page of the parameter area. If the erase status flag is in an erased state and the programmed flag is not set, the ECU automatically enters sleep mode after 5 seconds. If the application partition to be upgraded is not erased, or the erase status flag is erased and the programmed flag is set, the ECU performs the erase operation on the application partition to be upgraded. After the erase operation is completed, the fourth page address space is erased, the erase status flag of the application partition to be upgraded is updated to erased, and the address and erase status flag of the application partition to be upgraded are updated in the fourth page address space of the parameter area. The programmed status flag field of the application partition to be upgraded remains empty. Finally, the ECU enters sleep mode.

[0109] This invention also provides an upgrade method for an on-board ECU control unit that supports hibernation functionality. The system is used to implement an upgrade method for an on-board ECU control unit that supports hibernation functionality, comprising:

[0110] The upgrade request controller is used to send a wake-up frame to the ECU, wait 1 second, and then send an upgrade request command frame and a command to request the download of the upgrade package to the ECU.

[0111] The ECU determines whether the upgrade package size is less than or equal to the partition size of the application to be upgraded. If so, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size; otherwise, it replies that programming has failed and exits the upgrade program.

[0112] It requests the upgrade request controller to send the i-th page of data, where i is an integer starting from 1; it receives the i-th page of upgrade data and verifies its success, then flashes the i-th page of data to the i-th page of the firmware area to be upgraded.

[0113] The ECU replies to the upgrade request controller that the upgrade is successful, assigns a value to the global variable upgrade flag to complete the upgrade, records the global variable update_sts = update parameter update_para, and then exits the programming thread.

[0114] The ECU performs the following functions:

[0115] (1) ECU ignition signal detection module. The ignition signal can be used to wake up the ECU and to create driving-related threads.

[0116] (2) Communication module. Used as a wake-up source when the ECU is in sleep mode; receives upgrade commands; receives upgrade data;

[0117] (3) Programming module. Used to program the application to be upgraded using the programming data received by the communication module.

[0118] (4) Sleep Management Module. Used to detect the conditions for ECU sleep and cause the ECU to enter sleep mode.

[0119] The upgrade request controller device must meet the following functions:

[0120] The upgrade request controller can be a portable diagnostic tool, a vehicle gateway, a vehicle networking terminal that supports remote download of upgrade files, or an equivalent upgrade device. The upgrade request controller must store firmware compatible with both the first and second application partitions. The ECU to be upgraded can be a normally functioning ECU or a dormant ECU.

[0121] Beneficial effects:

[0122] (1) Safety upgrades can be performed directly without judging the vehicle's driving status.

[0123] (2) Working in a thread mode can ensure that the ECU can also interact with the vehicle during the upgrade.

[0124] (3) No customer waits during the upgrade, and the vehicle can be used and driven away immediately. The upgrade can be seamless for the vehicle driver and passengers, and can avoid various traffic accidents caused by the upgrade.

[0125] (4) Power outages during upgrades will not affect the next upgrade of the equipment. Just make sure the equipment goes into hibernation once before the next upgrade.

[0126] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0127] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0129] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0130] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0131] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0132] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. An upgrade method for an on-board ECU control unit supporting hibernation function, characterized in that, Includes the following steps: Step 1: The upgrade request controller sends a wake-up frame to the ECU, waits 1 second, and then sends an upgrade request command frame to the ECU. Step 2: The ECU replies to the upgrade request controller with the starting address Program_entry of the application partition to be upgraded and the programmable page size; Step 3: The upgrade request controller continues to send commands to the ECU via the communication interface to request the download of the upgrade package; Step 4: If the ECU determines that the size of the upgrade package is less than or equal to the size of the application partition to be upgraded, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size. Otherwise, reply with "programming failed" and exit the upgrade program; Step 5: Set the programmed status flag field on the fourth page of the ECU parameter partition, and set the global variable upgrade flag to true. Record the global variable update_sts = upgrade package data update_data. Step 6: The ECU requests the upgrade request controller to send the i-th page of data, where i is an integer starting from 1 and incrementing. Step 7: The ECU receives the upgrade data of page i and verifies it successfully, then flashes the data of page i to page i of the firmware area to be upgraded; Step 8: The ECU replies to the upgrade request controller that the upgrade is successful. The ECU assigns a value to the global variable upgrade flag to indicate that the upgrade is complete. It records the global variable update_sts = update parameter update_para and then exits the programming thread. S100 includes the steps after step three and before step four: Create a hibernation detection thread with a higher priority than the communication thread to detect whether the ECU can enter hibernation mode. When the hibernation thread detects that the ignition signal changes from an invalid signal to a valid signal, it creates all driving-related tasks to ensure normal information interaction with the vehicle. Specifically, S100 includes the following situations: (1) When the hibernation thread detects that the ignition signal has changed from a valid signal to an invalid signal, it shuts down all threads related to vehicle operation and queries the value of the global variable update_sts; (2) If the current value of update_sts is the upgrade package data update_data, then continue to wait for the value of update_sts to be updated to the update parameter update_para; (3) If the current global variable update_sts has the value of update_none, then query the erase status flag of the application partition to be upgraded on the fourth page of the parameter area; Specifically, S100 includes the following situations: If the current value of the global variable update_sts is the update parameter update_para, perform the following steps: S101, Erase the data content of the second page of the parameter partition; S102, copy the data content of the first page of the parameter partition to the second page of the parameter partition for backup; S103, erase the data content of the first page of the parameter partition; S104, Write the application entry address as the upgraded application partition to the first page of the parameter area, and update its checksum; S105, erase the data content of the second page of the parameter partition; S106, Copy the data content of the first page of the parameter partition to the second page of the parameter partition for synchronization; S107, assign a value to the global variable upgrade flag to complete the upgrade, and record update_sts = update_end; S108, the ECU determines that the ignition signal is invalid and enters sleep mode after updating_sts is updated_end for 5 seconds.

2. The upgrade method for the vehicle ECU control unit supporting hibernation function according to claim 1, characterized in that, Step one specifically includes: If the current ECU is in a sleep low-power state, the upgrade controller's wake-up frame is used to wake up the ECU; If the ECU is currently running, it does not respond to wake-up frame operations.

3. The upgrade method for the vehicle ECU control unit supporting hibernation function according to claim 1, characterized in that, Step 0 is included before step one: First, the Flash memory storing the ECU's operating code is divided into a linearly contiguous Bootloader area, parameter area, first application area, and second application area, with each area being an integer multiple of the smallest erase unit. The Bootloader area is used to store the system startup code, and the bootloader reads the contents of the second partition parameter area to determine the application entry address. The parameter partitions include a first page, a second page, a third page, and a fourth page. The first page stores the current entry address of the application and its checksum. The bootloader code first reads this content and performs verification to determine whether to execute the program in the first application partition or the program in the second application partition. The second page is used to back up and store data content. Before programming the data content of the first page, the data content of the first page is copied to the address space of the second page. The third page stores the minimum erase unit page size, the starting address and size of the first application partition, and the starting address and size of the second application partition. The fourth page stores the erase status flag of the application to be upgraded and the programming status of the application partition to be upgraded. The first application partition is used to store application code, and it is empty during the initial production state; the second application partition stores application code, and it is empty during the initial production state. Secondly, when the ECU receives the upgrade request command frame from the upgrade request controller, the ECU jumps to the Bootloader area to start running.

4. The upgrade method for the vehicle ECU control unit supporting hibernation function according to claim 3, characterized in that, The specific steps involved in the ECU jumping to the Bootloader area to begin operation are as follows: S01, the ECU reads the first page of the parameter area and parses out the application entry address A1 and the check code V1; S02, Calculate the checksum V11 of the application entry address A1; If the value of V1 is equal to the value of V11, jump to address A1 to start executing the application; If the value of V1 is not equal to the value of V11, then read the contents of the second page of the parameter area, parse out the application entry address A2 and the checksum V2; jump to address A2 to start execution.

5. The upgrade method for the vehicle ECU control unit supporting hibernation function according to claim 3, characterized in that, Step two specifically includes: If the current program entry address is the address of the first application partition, then the application partition to be upgraded is the second application partition; otherwise, the application partition to be upgraded is the first application partition.

6. The upgrade method for the vehicle ECU control unit supporting hibernation function according to claim 1, characterized in that, Execute steps S101 to S108 under the condition that the ignition signal is invalid and the device is in sleep mode, and the current running area cannot be erased before the programming is completed.

7. An upgrade system for an on-board ECU control unit supporting hibernation function, characterized in that, The system is used to implement the upgrade method for an on-board ECU control unit supporting hibernation function as described in any one of claims 1-6, comprising: The upgrade request controller is used to send a wake-up frame to the ECU, wait 1 second, and then send an upgrade request command frame and a command to request the download of the upgrade package to the ECU. The ECU determines whether the upgrade package size is less than or equal to the partition size of the application to be upgraded. If so, the ECU calculates the total number of programmable pages N based on the upgrade package size and the programming page size; otherwise, it replies that programming has failed and exits the upgrade program. It requests the upgrade request controller to send the i-th page of data, where i is an integer starting from 1; it receives the i-th page of upgrade data and verifies its success, then flashes the i-th page of data to the i-th page of the firmware area to be upgraded. The ECU replies to the upgrade request controller that the upgrade is successful, assigns a value to the global variable upgrade flag to indicate that the upgrade is complete, records the global variable update_sts = update_para, and then exits the programming thread.

Images