A vehicle-mounted embedded software backup upgrade method and system

Abstract

The application discloses a kind of vehicle embedded software backup upgrade method and system, it is related to embedded software technical field, including: receiving external erasing instruction, for activation partition and backup partition executes check operation, according to the backup corresponding data of determination result;After backup is completed, the activation partition is executed and new program is written into action;Device completes writing and re-powers on after entering start fault-tolerant process, the program effectiveness of activation partition and backup partition is executed multiple rounds of repeated verification;When triggering version rollback process, storage driver is loaded into random access memory and is executed, detect whether rollback state flag reaches the upper limit of set rollback number, under the condition that upper limit is not reached, data recovery action is executed.The system is configured in the chip without hardware SWAP mechanism and using the same surface start scheme.The application avoids invalid backup by pre-checking, combined with running environment isolation and rollback upper limit determination, to prevent the device from falling into infinite restart cycle.

Description

Technical Field

[0001] This application relates to the field of embedded software technology, and in particular to a method and system for backing up and upgrading vehicle-mounted embedded software. Background Technology

[0002] In embedded systems such as automotive electronics, software upgrades are the primary means of fixing system defects and adding new features. For microcontrollers without traditional hardware swap mechanisms, the system typically employs an A / B side backup architecture to support the upgrade process. This backup architecture mainly includes two schemes: off-side boot and same-side boot. The off-side boot scheme keeps the active partition program running during the upgrade, flashes the new program to the backup area, and selects the newly flashed partition to boot from upon restart using an update flag. The same-side boot scheme, on the other hand, ensures that the software always boots from the active partition and continuously performs download and flash operations on the active partition.

[0003] This invention primarily addresses the same-sideboard boot partitioning scheme. Existing same-sideboard boot upgrade schemes have significant limitations in practical engineering applications. Before performing erasure and write operations, the system lacks a differentiated erasure verification mechanism for critical applications, which can easily lead to invalid backups or erroneous erasures when the program status is unclear. Furthermore, the original backup operations fail to ensure the synchronization and consistency between the application and the calibration data.

[0004] Furthermore, during the startup phase of a device upgrade interruption or power-on, the existing system's program validity verification and rollback triggering logic are incomplete, resulting in weak overall fault tolerance. When a power outage, transmission error, or program file corruption occurs during the upgrade process, the system is prone to triggering anomalies. More seriously, the existing rollback logic lacks protection against frequent rollbacks and fails to constrain the number of triggers during rollback operations. If the rollback source data also contains anomalies, the device is highly susceptible to entering an infinite rollback and restart loop, ultimately leading to complete controller failure and an inability to enter a communication state that supports rewriting. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for backing up and upgrading in-vehicle embedded software, which at least solves one of the technical problems in the prior art: the lack of pre-upgrade verification leads to erroneous erasure and invalid backup, and the lack of program validity verification and rollback number constraints during the startup rollback phase, which causes the device to easily fall into an infinite loop of restarts and eventually fail when the upgrade is abnormal.

[0006] This invention provides the following solution:

[0007] The first aspect of this invention provides a method for backing up and upgrading vehicle-mounted embedded software, comprising:

[0008] Receive erase command sent from external command source, perform verification operation on active partition and backup partition, and back up the corresponding data according to the judgment result of the verification operation;

[0009] After the backup process is complete, the active partition is erased and the new program is written.

[0010] After the device completes the writing and is powered on again, it enters the boot fault tolerance process. During this stage, the validity of the program in the activation partition and backup partition is repeatedly verified in multiple rounds.

[0011] When the version rollback process is triggered during the verification phase of the fault tolerance process, the storage driver is loaded into the random access memory for execution. The rollback status flag is checked to see if the set rollback count limit has been reached. If the limit has not been reached, the data recovery action is performed.

[0012] This method avoids the risk of data loss during the upgrade process by introducing pre-verification and startup fault tolerance verification mechanisms within a single-sided startup architecture. When the version rollback process is triggered, the storage driver is loaded into random access memory for execution, achieving isolation between the execution environment and the target operating memory in the physical runtime address space, thus avoiding conflicts caused by concurrent read and write operations within the same Flash memory chip. Simultaneously, the introduction of rollback status flags and upper limit threshold judgments prevents continuous cyclic restarts of the device under abnormal conditions from the control logic level, improving the operational stability of the vehicle controller.

[0013] Preferably, the verification operation is performed on the active partition and the backup partition, including: determining the application of the currently active partition and identifying whether the application belongs to the engine electronic control unit application;

[0014] When it is determined that the application in the active partition is not an engine electronic control unit application, the flash memory of the active partition is erased directly.

[0015] When the active partition application is determined to be an engine electronic control unit application, the validity status of the active partition application is determined.

[0016] If the activation partition program is invalid, directly perform the erase operation on the activation partition Flash; if the activation partition program is valid, continue to determine the validity status of the backup partition program.

[0017] In one specific embodiment, after further determining the validity status of the backup partition program, the process includes:

[0018] When the backup partition program is determined to be invalid, the backup operation is triggered directly.

[0019] When the backup partition program is determined to be valid, it reads and compares the backup partition version with the active partition version. If the comparison result shows that the two versions are the same, it directly performs the erase operation of the active partition Flash. If the comparison result shows that the two versions are different, it triggers the execution of the backup operation.

[0020] Furthermore, triggering a backup operation includes:

[0021] Disable the valid flag for the backup partition;

[0022] Determine the currently set upgrade content mode. The upgrade content mode is divided into simply upgrading the application or calibration data, and upgrading each segment of the application and calibration data sequentially.

[0023] Perform the corresponding backup partition erase action based on the upgrade content mode:

[0024] When the upgrade content mode is to simply upgrade the application or calibration data, only the data corresponding to that mode is erased; when the upgrade content mode is to upgrade each segment of the application and calibration data in sequence, if the current erase module is the application, the application and calibration data are erased simultaneously.

[0025] Based on the upgrade content mode, the applications and calibration data in the active partition will be copied to the backup partition;

[0026] After the copy operation is complete, enable the valid flag for the backup partition.

[0027] Preferably, the validity of the program on the active partition and the backup partition is verified in multiple rounds, including:

[0028] The validity of the partition activation program is determined. If the partition activation program is determined to be valid, the execution path is controlled to jump to the application execution.

[0029] If the activation partition program is determined to be invalid, the repeated verification logic for the activation partition is triggered. If the number of verifications has not reached the set limit, the activation partition program will be repeatedly verified.

[0030] When the number of times the activation partition program performs a loop verification reaches the set verification limit, the verification of that partition will stop, and the backup partition verification process will begin.

[0031] In one specific embodiment, after entering the backup partition verification process, the process includes:

[0032] Determine the validity status of the backup partition program; if the backup partition program is determined to be invalid, trigger a repeated verification process for the backup partition, and perform cyclic verification on the backup partition if the number of verifications has not reached the set verification limit.

[0033] When the number of times the backup partition is verified reaches the set verification limit, the verification process is terminated and the device is controlled to enter the Boot default session state; if the backup partition program is determined to be valid, the rollback status flag verification step is entered to determine whether the currently set rollback status flag has reached the set rollback number limit.

[0034] When the rollback status flag has reached the set limit, the control device directly enters the Boot default session;

[0035] When the rollback status flag has not reached the set rollback limit, the corresponding version rollback process is triggered.

[0036] Furthermore, after the version rollback process is completed, it also includes: re-evaluating the validity of the activated partition program;

[0037] If the activation partition program is determined to be valid at this time, the control device will perform a reset action, and the device will re-enter the Bootloader boot process after the reset.

[0038] If the activation partition program is determined to be invalid, the control device enters the Boot default session and maintains basic communication in the Boot default session state, and supports performing on-site debugging actions or receiving re-flash commands.

[0039] Preferably, loading the storage driver into random access memory for execution includes:

[0040] The storage driver is copied from the Flash memory to the random access memory and executed in the random access memory. By changing the physical address region where the driver code runs, conflicts are avoided when performing Flash read and write operations.

[0041] The initialization status of the driver is checked. If the driver initialization status is detected as successful, the subsequent judgment steps are executed.

[0042] In one specific embodiment, performing a data recovery operation includes:

[0043] Obtain the consistency verification result, and based on the consistency verification result, perform the corresponding erase operation on the application and calibration data stored in the active partition as needed;

[0044] After the active partition data is erased, copy the application and calibration data recorded in the backup partition back to the active partition as needed;

[0045] During the erase and copy operations, the value of the rollback status flag is incremented synchronously.

[0046] After the application and calibration data are completely copied to the active partition, the program validity flag of the active partition is enabled, and the accumulated rollback status flag value is reset to zero.

[0047] The second aspect of the present invention provides an in-vehicle embedded software backup and upgrade system, including a chip system without a hardware SWAP mechanism configured in a target controller. The internal hardware carrier of the chip system includes a Flash memory and a random access memory. The Flash memory is divided into an active partition and a backup partition, and a same-side boot scheme is adopted in the program running mechanism. The external instruction source of the chip system is a T-BOX device.

[0048] The above solution achieves the following beneficial technical effects:

[0049] This invention performs differentiated verification for critical applications based on specific application types. Before performing the erase operation, it identifies whether the application in the active partition belongs to the engine electronic control unit (ECU) application, and determines the subsequent execution branch by comparing the program validity status and version consistency between the active partition and the backup partition. This mechanism avoids the loss of critical controller data due to direct erasure without a clear program status, and prevents the backup of invalid data or the execution of incorrect erase operations.

[0050] This invention provides an automatic backup mechanism before upgrades. Before erasing and writing new programs to the active partition, the system triggers a backup operation based on the pre-verification comparison results. According to the currently set upgrade content mode, the existing valid applications and calibration data in the active partition are pre-copied to the backup partition and enabled. This step ensures that if subsequent attempts to write new programs to the active partition fail or an error occurs, the device has a complete and usable data rollback source stored internally.

[0051] This invention introduces a mechanism to prevent frequent rollbacks. When a version rollback is triggered during the fault-tolerant process, the rollback status flag is checked and it is determined whether the set rollback limit has been reached, thus constraining the number of rollback executions. When the rollback status flag reaches the set limit, the control device directly enters the default Boot session, avoiding the device from getting stuck in an infinite rollback and restart loop due to program file corruption. This ensures that the target device can ultimately remain in a secure session that supports basic communication and rewriting. Attached Figure Description

[0052] Figure 1 This is an upgrade and backup flowchart of an in-vehicle embedded software backup and upgrade method provided by an embodiment of the present invention.

[0053] Figure 2 This is a schematic diagram of the fault-tolerant process of an in-vehicle embedded software backup and upgrade method provided in one embodiment of the present invention.

[0054] Figure 3 This is a schematic diagram of the version rollback process of an in-vehicle embedded software backup and upgrade method provided in one embodiment of the present invention. Detailed Implementation

[0055] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] See attached document Figure 1 -Appendix Figure 3 This invention provides a method for backing up and upgrading in-vehicle embedded software, which may include:

[0057] This method operates within a chip system lacking a hardware swap mechanism. This system is configured within target controllers such as the Engine Control Unit (EMS). The internal hardware includes Flash memory and random access memory. The Flash memory is divided into an active partition and a backup partition, and a same-side boot scheme is used for program execution. External commands to the system originate from the T-BOX device. Control actions during the target controller's power-on phase are executed by the bootloader.

[0058] Based on the above system architecture, the working lifecycle of this method consists of three main processes.

[0059] First, the upgrade backup process is executed. The system receives an erase command from an external source. Upon receiving this command, the system performs a verification operation on the active partition and the backup partition. The verification action determines the validity and version consistency of the programs within the partitions. Based on the verification result, the system backs up the corresponding data. After the backup step is completed, the system performs an erase operation on the active partition and writes the new programs.

[0060] After the device completes the write process and powers on again, it enters the boot fault-tolerant process. The bootloader takes over control. During this stage, the system performs multiple rounds of repeated verification on the program validity of the active and backup partitions. Based on the results of these multiple verifications for each partition, the system determines the boot level and performs the corresponding downgrade operation.

[0061] The version rollback process is triggered during the verification phase of the fault tolerance process. The system loads the storage driver into random access memory for execution, avoiding read / write operation conflicts through runtime environment isolation. The system checks whether the rollback status flag has reached the set rollback count limit. If the limit has not been reached, data recovery is performed. The system limits the number of rollback executions through the above status flags to avoid cyclic execution operations under abnormal conditions.

[0062] Regarding the aforementioned upgrade and backup process, the system first enters the erasure command reception and application identification stage. The system receives the erasure command for the active partition Flash. Before executing the erasure action, the system determines whether the currently active partition application belongs to the engine electronic control unit (ECU) application. If the active partition application is determined not to be an ECU application, the system skips subsequent verification steps and directly performs the erasure operation on the active partition Flash. If the active partition application is determined to be an ECU application, the system triggers the subsequent verification process.

[0063] The system enters the validity and version consistency verification phase. The system first determines the validity status of the activation partition program. If the activation partition program is invalid, the system directly performs an erase operation on the activation partition's Flash memory. If the activation partition program is valid, the system continues to determine the validity status of the backup partition program.

[0064] When the backup partition program status is determined to be invalid, the system directly triggers a backup operation. When the backup partition program status is determined to be valid, the system further reads and compares the backup partition version with the active partition version. If the comparison result shows that the two versions are the same, the system directly performs an erase operation on the active partition's Flash memory. If the comparison result shows that the two versions are different, the system triggers a backup operation.

[0065] When performing a backup operation, the system first disables the validity flag of the backup partition. The system then determines the currently configured upgrade mode. Upgrade modes can be either a simple upgrade of the application or calibration data, or a sequential upgrade of the application and calibration data segments.

[0066] The system performs the corresponding backup partition erasure action based on the upgrade content mode. When the upgrade content mode is simply upgrading the application or calibration data, the system only erases the data corresponding to that mode. When the upgrade content mode involves sequentially upgrading each segment of the application and calibration data, if the currently erased module is the application, the system simultaneously erases both the application and calibration data.

[0067] After the erase operation is complete, the system copies the application and calibration data from the active partition to the backup partition according to the upgrade content mode described above. After the copying operation is completed, the system enables the validity flag of the backup partition, completing the synchronization backup operation. After completing all the above verification and backup processes, the system performs an erase operation on the active partition Flash and writes the new program into the active partition Flash.

[0068] After the new program is written and the system is powered on again, it enters the boot fault tolerance process. The bootloader performs the boot process.

[0069] The system first determines the validity of the activation partition program. If the activation partition program is deemed valid, the system controls the execution path to jump to the application. If the activation partition program is deemed invalid, the system triggers repeated verification logic for the activation partition. The system checks the current number of verifications for the activation partition. If the number of verifications has not reached the set limit, the system performs a loop verification of the activation partition program.

[0070] When the number of loop verifications for the active partition program reaches the set verification limit, the system stops verifying the partition and enters the backup partition verification process. The system determines the validity status of the backup partition program. If the backup partition program is deemed invalid, the system triggers a re-verification process for the backup partition. The system performs loop verification on the backup partition if the number of verifications has not reached the set verification limit. When the number of loop verifications for the backup partition reaches the set verification limit, the system terminates the verification process and controls the device to enter the Boot default session state.

[0071] If the backup partition program is deemed valid, the system enters the rollback status flag verification phase. The system determines whether the currently set rollback status flag has reached the set rollback count limit. When the rollback status flag has reached the set limit, the system control device directly enters the Boot default session. When the rollback status flag has not reached the set rollback count limit, the system triggers the corresponding version rollback process.

[0072] After the version rollback process is completed, the system re-evaluates the validity of the activation partition program. If the activation partition program is deemed valid, the system controls the device to perform a reset. After resetting, the device re-enters the Bootloader boot process. If the activation partition program is deemed invalid, the system controls the device to enter the default Boot session. In the default Boot session, the system maintains basic communication and supports performing on-site debugging actions or receiving re-flash commands.

[0073] When the system triggers a version rollback process during the fault tolerance startup procedure, it first performs a runtime environment isolation operation. The system copies the storage driver from Flash memory to random access memory (RAM) and executes it there. The system avoids conflicts during Flash read / write operations by changing the physical address region where the driver code runs. After the storage driver copying is complete, the system checks the driver's initialization status. If the driver initialization status is successful, the system continues with subsequent judgment steps.

[0074] The system reads and determines the current rollback status flag value. It compares this flag with the set maximum number of rollback attempts. If the system determines that the rollback status flag has reached the set maximum number of attempts, it terminates the current rollback process. If the system determines that the rollback status flag is less than the set maximum number of attempts, it triggers the corresponding data rollback operation.

[0075] The system obtains the consistency verification result. Based on this result, the system performs corresponding erase operations on the applications and calibration data stored in the active partition as needed. After the active partition data is erased, the system copies the applications and calibration data recorded in the backup partition back to the active partition as needed. During the above erase and copy operations, the system synchronously increments the value of the rollback status flag.

[0076] After the application and calibration data are completely copied to the active partition, the system enables the program validity flag on the active partition. The system then resets the accumulated rollback status flag value to zero. At this point, the system completes the current version rollback process and hands the bootloader over to perform a second verification of the active partition's validity after the rollback is complete.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for backing up and upgrading vehicle-mounted embedded software, characterized in that, include: Receive an erase command sent from an external command source, perform a verification operation on the active partition and the backup partition, and back up the corresponding data according to the judgment result of the verification operation; After the backup step is completed, the active partition is erased and the new program is written. After the device completes the writing and is powered on again, it enters the boot fault tolerance process. During this stage, the validity of the program in the active partition and the backup partition is repeatedly verified in multiple rounds. When the version rollback process is triggered during the verification phase of the fault tolerance process, the storage driver is loaded into the random access memory for execution. The rollback status flag is checked to see if the set rollback count limit has been reached. If the limit has not been reached, the data recovery action is performed.

2. The vehicle-mounted embedded software backup and upgrade method according to claim 1, characterized in that, The verification operation performed on the active partition and the backup partition includes: The application in the currently active partition is determined, and it is identified whether the application belongs to the engine electronic control unit application. When it is determined that the application in the active partition is not an engine electronic control unit application, the flash memory of the active partition is erased directly. When the active partition application is determined to be an engine electronic control unit application, the validity status of the active partition application is determined. If the activation partition program is invalid, directly perform the erase operation on the activation partition Flash; if the activation partition program is valid, continue to determine the validity status of the backup partition program.

3. The vehicle-mounted embedded software backup and upgrade method according to claim 2, characterized in that, After continuing to determine the validity status of the backup partition program, the following steps are included: When the backup partition program is determined to be invalid, the backup operation is triggered directly. When the backup partition program is determined to be valid, it reads and compares the backup partition version with the active partition version. If the comparison result shows that the two versions are the same, it directly performs the erase operation of the active partition Flash. If the comparison result shows that the two versions are different, it triggers the execution of the backup operation.

4. The vehicle-mounted embedded software backup and upgrade method according to claim 3, characterized in that, The triggering of the backup operation includes: Disable the valid flag of the backup partition; Determine the currently set upgrade content mode, which is divided into simply upgrading the application or calibration data, and upgrading each segment of the application and calibration data sequentially. Perform the corresponding backup partition erasure action according to the upgrade content mode: When the upgrade content mode is a simple application upgrade or calibration data upgrade, only the data corresponding to that mode is erased; When the upgrade content mode is to upgrade each segment of the application and calibration data in sequence, if the current erase module is the application, the application and calibration data are erased simultaneously. Based on the upgrade content mode, the applications and calibration data in the activated partition are copied to the backup partition; After the copy operation is complete, enable the valid flags of the backup partition.

5. The vehicle-mounted embedded software backup and upgrade method according to claim 4, characterized in that, Perform multiple rounds of repeated verification on the program validity of the activated partition and the backup partition, including: The validity of the partition activation program is determined. If the partition activation program is determined to be valid, the execution path is controlled to jump to the application execution. If the activation partition program is determined to be invalid, the repeated verification logic for the activation partition is triggered. If the number of verifications has not reached the set limit, the activation partition program will be repeatedly verified. When the number of times the activation partition program performs a loop verification reaches the set verification limit, the verification of that partition will stop, and the backup partition verification process will begin.

6. The vehicle-mounted embedded software backup and upgrade method according to claim 5, characterized in that, After entering the backup partition verification process, the following is included: Determine the validity status of the backup partition program; If the backup partition program is determined to be invalid, a repeated verification process is triggered for the backup partition. If the number of verifications does not reach the set limit, the backup partition is subjected to cyclic verification. When the number of times the backup partition performs a loop verification reaches the set verification limit, the verification process is terminated, and the device is controlled to enter the Boot default session state. If the backup partition program is deemed valid, the rollback status flag verification step is entered to determine whether the currently set rollback status flag has reached the set rollback count limit. When the rollback status flag has reached the set limit, the control device directly enters the Boot default session; When the rollback status flag has not reached the set rollback limit, the corresponding version rollback process is triggered.

7. The in-vehicle embedded software backup and upgrade method according to claim 6, characterized in that, After the version rollback process is completed, the following steps are also included: The validity of the partition activation program is assessed again; If the activation partition program is determined to be valid at this time, the control device will perform a reset action, and the device will re-enter the Bootloader boot process after the reset. If the activation partition program is determined to be invalid, the control device enters the Boot default session and maintains basic communication in the Boot default session state, and supports performing on-site debugging actions or receiving re-flash commands.

8. The in-vehicle embedded software backup and upgrade method according to claim 1, characterized in that, The step of loading the storage driver into the random access memory for execution includes: The storage driver is copied from the Flash memory to the random access memory and executed in the random access memory. By changing the physical address region where the driver code runs, conflicts are avoided when performing Flash read and write operations. The initialization status of the driver is checked. If the driver initialization status is detected as successful, the subsequent judgment steps are executed.

9. The vehicle-mounted embedded software backup and upgrade method according to claim 1, characterized in that, The data recovery action includes: Obtain the consistency verification result, and based on the consistency verification result, perform the corresponding erase operation on the application and calibration data stored in the active partition as needed; After the active partition data is erased, copy the application and calibration data recorded in the backup partition back to the active partition as needed; During the process of performing the above erase and copy operations, the value of the rollback status flag is simultaneously incremented; After the application and calibration data are completely copied to the active partition, the program validity flag of the active partition is enabled, and the accumulated rollback status flag value is reset to zero.

10. A vehicle-mounted embedded software backup and upgrade system, comprising executing the vehicle-mounted embedded software backup and upgrade method according to any one of claims 1-9, characterized in that, The chip system includes a chip system without a hardware SWAP mechanism configured in the target controller. The internal hardware carrier of the chip system includes Flash memory and random access memory. The Flash memory is divided into an active partition and a backup partition, and a same-side boot scheme is adopted in the program running mechanism. The external instruction source for the chip system is the T-BOX device.

Images