Software flashing verification method and device, storage medium, controller and vehicle

Abstract

The invention relates to the technical field of software updating, and discloses a software flashing verification method and device, a storage medium, a controller and a vehicle, the method is used for an MCU, the MCU comprises a first partition and a second partition, the first partition and the second partition are each provided with a variable storage space, and the method comprises the steps that when software flashing of the first partition is completed, the second partition is provided with a variable storage space; writing a state variable in the variable storage space in the first partition as a first variable value; and switching to the first partition and restarting the MCU from the first partition, performing read-write and judgment processing on the state variables in the variable storage space in the first partition, determining whether the flashed software is successfully started and normally runs or not, and switching to the second partition and restarting the MCU from the second partition when determining that the flashed software is failed to start. According to the method, it is ensured that even though the software subjected to double-partition flashing and upgrading cannot run, normal recovery starting can be guaranteed, and the reliability of software safety recovery after double-partition flashing and upgrading is greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software update, and in particular, to a software flashing verification method, device, storage medium, controller, and vehicle. Background Art

[0002] With the popularization of intelligence, the software function update flashing of the MCU on intelligent vehicles has become relatively frequent. Ensuring the reliability of software flashing on the user side has an important impact on the user experience. In some special scenarios, such as the OTA server being attacked or malicious tampering with the flashing software, etc., it may cause the software after flashing and upgrading to fail to run properly.

[0003] Related technologies use a static storage flag verification method to verify the software. Since the existence of the static storage flag of the software is considered legal, when the software fails to enter the running state for some reason, it will cause the flashed software to neither run nor be able to switch back to the normal software partition before flashing. Summary of the Invention

[0004] The present invention aims to solve at least one of the technical problems in the related technologies to some extent. For this reason, one object of the present invention is to provide a software flashing verification method to ensure that even if the software after dual - partition flashing and upgrading fails to enter the running state, it can still ensure normal recovery and startup, greatly improving the reliability of software security recovery after dual - partition flashing and upgrading.

[0005] The second object of the present invention is to provide a software flashing verification device.

[0006] The third object of the present invention is to provide a computer - readable storage medium.

[0007] The fourth object of the present invention is to provide a controller.

[0008] The fifth object of the present invention is to provide a vehicle.

[0009] To achieve the above object, an embodiment of the first aspect of the present invention provides a software flashing verification method for an MCU. The MCU includes a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition. The method includes: when the software flashing of the first partition is completed, writing the status variable in the variable storage space of the first partition as a first variable value; switching to the first partition and restarting the MCU from the first partition, performing read, write, and judgment processing on the status variable in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, switching to the second partition and restarting the MCU from the second partition, wherein when the flashed software starts successfully and runs normally, read, write, and judgment processing are performed on the status variable in the variable storage space of the first partition.

[0010] According to the software flashing verification method of the embodiment of the present invention, by defining variable storage spaces for storing status variables in the first partition and the second partition of the MCU, when flashing the software in the first partition, read, write, and judgment processing are performed on the status variable in the variable storage space of the first partition to capture dynamic information on whether the software enters operation after flashing, and when it is determined that the flashed software fails to start, the MCU is switched and restarted to enable the MCU to resume normal startup.

[0011] In addition, the software flashing verification method proposed according to the above embodiment of the present invention may further have the following additional technical features: According to an embodiment of the present invention, the status variable is a uint8 variable, which is divided into two 4-bit hexadecimal digits.

[0012] According to an embodiment of the present invention, the values of the status variable include a first variable value, a second variable value, and a third variable value. The first variable value is 0x01, the second variable value is 0x02, and the third variable value is 0x12. The read, write, and judgment processing of the status variable in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally includes: Reading the status variable in the variable storage space of the first partition and determining whether the status variable is 0x01; If so, enabling the watchdog, writing the status variable in the variable storage space of the first partition as the second variable value, and then starting the flashed software. When the flashed software starts successfully and runs normally, the flashed software writes the status variable in the variable storage space of the first partition as the third variable value. When the flashed software fails to start and the watchdog times out, the MCU is restarted in the first partition; Reading the status variable in the variable storage space of the first partition; If the value of the state variable is 0x12, it is determined that the flashed software starts successfully and runs normally; If the value of the state variable is 0x02, it is determined that the flashed software in the first partition fails to start.

[0013] According to an embodiment of the present invention, the value of the state variable includes a fourth variable value, and the fourth variable value is 0x00. The method further includes: When it is determined that the value of the state variable is 0x12, write the state variable in the variable storage space in the first partition as the fourth variable value, and start the flashed software.

[0014] According to an embodiment of the present invention, when the flashed software starts successfully and runs normally, the flashed software reads the state variable in the variable storage space in the first partition, and when the lower 16 - bit of the state variable is not 0, write the state variable in the variable storage space in the first partition as the third variable value.

[0015] According to an embodiment of the present invention, the method further includes: when it is determined that the flashed software fails to start, write the state variable in the variable storage space in the first partition as the first variable value, switch to the second partition, and restart the MCU from the second partition.

[0016] To achieve the above object, an embodiment of the second aspect of the present invention provides a software flashing verification device for an MCU. The MCU includes a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition. The device includes: a flashing module, configured to write the state variable in the variable storage space in the first partition as the first variable value when the software flashing of the first partition is completed; a verification module, configured to switch to the first partition, restart the MCU from the first partition, perform read - write and judgment processing on the state variable in the variable storage space in the first partition, determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, switch to the second partition and restart the MCU from the second partition, wherein when the flashed software starts successfully and runs normally, read - write and judgment processing are performed on the state variable in the variable storage space in the first partition.

[0017] To achieve the above object, an embodiment of the third aspect of the present invention provides a computer - readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the software flashing verification method as proposed in the first - aspect embodiment of the present invention.

[0018] To achieve the above object, an embodiment of the fourth aspect of the present invention provides a controller, including a memory and a processor. A computer program is stored on the memory. When the computer program is executed by the processor, a software flashing verification method as provided in the embodiment of the first aspect of the present invention is implemented.

[0019] To achieve the above object, an embodiment of the fifth aspect of the present invention provides a vehicle, including the controller as provided in the embodiment of the fourth aspect of the present invention.

[0020] Additional aspects and advantages of the present invention will be given in part in the following description, become apparent in part from the following description, or be learned through the practice of the present invention. Description of the Drawings

[0021] Figure 1 is the flowchart of the MCU dual-partition software flashing and upgrading; Figure 2(a) is the process of verifying the software and starting recovery using a static storage flag Figure 1 ; Figure 2(b) is the second flowchart of verifying the software and starting recovery using a static storage flag; Figure 3 is the flowchart of the software flashing verification method according to an embodiment of the present invention; Figure 4 is the flowchart of determining whether the flashed software starts successfully and runs normally according to an embodiment of the present invention; Figure 5 is the flowchart of the software flashing verification method according to a specific embodiment of the present invention; Figure 6 is the schematic diagram of the software flashing verification device according to an embodiment of the present invention; Figure 7 is the structural block diagram of the controller according to an embodiment of the present invention; Figure 8 is the schematic diagram of a vehicle according to an embodiment of the present invention. Detailed Embodiments

[0022] Embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the drawings, where the same or similar reference numerals denote the same or similar elements or elements with the same or similar functions from start to end. The embodiments described below with reference to the drawings are exemplary and are intended to explain the present invention, and should not be construed as a limitation to the present invention.

[0023] It should be noted that the MCU dual-partition software flashing and upgrading process is as Figure 1As shown below, the following steps are carried out in sequence: enter the extended session, check the programming preconditions, turn off the DTC (Diagnostic Trouble Code) function, turn off the normal CAN (Controller Area Network) bus communication, enter the programming session, perform security access authentication, write fingerprints, download the Flash driver, erase the application program in the unactivated partition, download the application program, perform software data verification, check the application program dependencies, switch partitions, restart the MCU, etc.

[0024] In the above upgrade process, related technologies use a static storage flag verification method to verify the software and start recovery in the "software data verification" step.

[0025] As a specific example, as shown in Figure 2(a), when performing software data verification, check the static storage flag. This step is a key action performed during software data verification. If the check of the static storage flag fails, switching partitions is prohibited. The final start recovery method after the check of the static storage flag fails is to start from the old partition. If the check of the static storage flag is successful, switch partitions. The final start method after the check of the static storage flag is successful is to start from the newly flashed software partition.

[0026] As another specific example, as shown in Figure 2(b), when performing software data verification, the Bootloader (boot loader) starts. After the Bootloader starts, it checks the static storage flag of the flashed software. If the check fails, perform a partition switch and start from the switched partition. If the check is successful, directly start the software of the current partition.

[0027] It can be seen that when using the static storage flag verification method to verify the software and start recovery, the static storage flag is stored in the specified storage location when the flashing is completed. When the software flashing checksum and system startup check this content as correct, it is considered that the software is okay, and the dual - partition system will switch to the newly flashed partition. The recovery method is to restore to the normal old partition before flashing when the static storage flag (such as the signature storage flag, etc.) check fails.

[0028] The static storage flag verification method has the problem that a software flashing that is considered legal is successful but cannot run properly, and this method also cannot capture the dynamic information of whether the software enters operation after flashing.

[0029] To solve the problems existing in this static verification method of software flashing, the embodiments of the present invention provide a software flashing verification method, device, storage medium, controller, and vehicle. The software flashing verification method, device, storage medium, controller, and vehicle of the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0030] The software flashing verification method in the embodiments of the present invention is used for an MCU (Micro Controller Unit), and the MCU may include a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition.

[0031] To ensure that although the software (APP) after dual - partition flashing and upgrading cannot enter the running state, normal restart can still be guaranteed. In the embodiments of the present invention, a status variable A is set, and a variable storage space for storing the status variable A is defined in the NvM (Non - Volatile Memory) storage of both the first partition and the second partition.

[0032] By reading the status variable A in the variable storage space of the area where the flashed software is located, dynamic information on whether the software enters the running state after flashing is captured. When it is determined that the flashed software fails to start according to the status variable A, the MCU is switched to restart, so that the MCU can restart normally.

[0033] It should be noted that if the software in the first partition is flashed, read - write and judgment processing are performed on the status variable in the variable storage space of the first partition. If the software in the second partition is flashed, read - write and judgment processing are performed on the status variable in the variable storage space of the second partition.

[0034] Figure 3 is a flowchart of the software flashing verification method according to an embodiment of the present invention. As Figure 3 shown, the software flashing verification method may include: S101, when the software flashing of the first partition is completed, write the status variable in the variable storage space of the first partition as a first variable value; S102, switch to the first partition and restart the MCU from the first partition, perform read - write and judgment processing on the status variable in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, switch to the second partition and restart the MCU from the second partition. Among them, when the flashed software starts successfully and runs normally, read - write and judgment processing are performed on the status variable in the variable storage space of the first partition.

[0035] Specifically, during the process of the Bootloader performing software update flashing on the first partition, when the software flashing of the first partition is completed and the "software data verification" step is carried out, the status variable in the variable storage space of the first partition is written as the first variable value. It should be noted that the first variable value represents the flashing completion status. When the status variable is the first variable value, it indicates that the current process is in the flashing completion state.

[0036] The Bootloader completes the partition switch and restart, that is, it switches from the second partition to the first partition and restarts the MCU from the first partition to load and run the flashed software. Based on the first startup into the Bootloader after flashing, the Bootloader reads, writes, and judges the status variables in the variable storage space in the first partition to determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, it switches to the second partition and restarts the MCU from the second partition.

[0037] In the software flashing verification method according to the embodiment of the present invention, by defining variable storage spaces for storing status variables in the first partition and the second partition of the MCU, when flashing the software in the first partition, the status variables in the variable storage space in the first partition are read, written, and judged to capture the dynamic information of whether the software enters operation after flashing, and when it is determined that the flashed software fails to start, the MCU is switched and restarted to enable the MCU to resume normal startup.

[0038] In an embodiment of the present invention, the status variable is a uint8 variable, which is divided into two 4-bit hexadecimal digits.

[0039] In the embodiment of the present invention, the status variable A is a uint (unsigned integer) 8 variable, which is divided into two 4-bit HEX (Hexadecimal) digits. Among them, the value of the high hex digit (APP running Hex digit) represents "App runs normally", and the value of the low hex digit (flashing Hex digit) represents "flashing completion status".

[0040] The embodiment of the present invention defines the value range of the status variable, as shown in Table 1 specifically.

[0041] Table 1 Value range of the status variable

[0042] That is, when the status variable A is 0x01, it represents "flashing completed"; when the status variable A is 0x02, it represents "startup failed after flashing"; when the status variable A is 0x12, it represents "startup successful after flashing"; when the status variable A is 0x00, it represents "not flashed".

[0043] In the embodiment of the present invention when performing software data verification, the Bootloader reads, writes, and judges the status variable A, and after the APP starts successfully and runs normally, the APP also reads, writes, and judges the status variable A, so that the dynamic information of whether the software enters operation after flashing can be captured according to the value of the status variable A.

[0044] In an embodiment of the present invention, such as Figure 4As shown, the values of the status variables may include a first variable value, a second variable value, and a third variable value. The first variable value is 0x01, the second variable value is 0x02, and the third variable value is 0x12. Reading, writing, and judging the status variables in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally may include: S201, read the status variables in the variable storage space of the first partition, and judge whether the status variables are 0x01; S202, if so, enable the watchdog, write the status variables in the variable storage space of the first partition as the second variable value, and then start the flashed software. When the flashed software starts successfully and runs normally, the flashed software writes the status variables in the variable storage space of the first partition as the third variable value. When the flashed software fails to start and the watchdog times out, restart the MCU in the first partition; S303, read the status variables in the variable storage space of the first partition; S204, if the value of the status variables is 0x12, determine that the flashed software starts successfully and runs normally; S205, if the value of the status variables is 0x02, determine that the flashed software in the first partition fails to start.

[0045] Since during the software flashing of the first partition, the Bootloader writes the status variables in the variable storage space of the first partition as the first variable value (0x01). Therefore, after the Bootloader completes the partition restart, the Bootloader reads the status variable A in the variable storage space of the first partition and judges whether the status variable A is 0x01, that is, judges whether the upgrade process of the first partition is in the "successfully started after flashing" state at this time.

[0046] If the value of the status variable A is 0x01, it means that the upgrade process of the first partition is in the "flashing completed" state at this time, which may trigger enabling or unconditionally enabling the watchdog, and write the status variables in the variable storage space of the first partition as the second variable value (0x02), that is, change the status variable A from the "flashing completed" state to the "failed to start after flashing" state, and start the flashed software (the first start after flashing).

[0047] It should be noted that if the software after flashing starts successfully and runs normally, variable A will be modified in the software after flashing. If the software after flashing fails to start, or starts successfully but fails to run, the APP will not modify the status variable A, and at the same time the watchdog will time out and the system will restart again (i.e., the second start after flashing). Specifically, when the software after flashing starts successfully and runs normally, the software after flashing will write the status variable in the variable storage space of the first partition as the third variable value (0x12), that is, change the status variable A from the "failed to start after flashing" state to the "started successfully after flashing" state. When the software after flashing fails to start and the watchdog times out, the Bootloader restarts the MCU in the first partition.

[0048] The Bootloader can determine whether the software after flashing starts successfully and runs normally by reading the status variable in the variable storage space of the first partition. Specifically, if the value of the read status variable is 0x12, it means that the software after flashing starts successfully and runs normally. If the value of the read status variable is 0x02, it means that the software after flashing in the first partition fails to start.

[0049] In an embodiment of the present invention, the value of the status variable may include a fourth variable value, and the fourth variable value is 0x00. The software flashing verification method may further include: When it is determined that the value of the status variable is 0x12, write the status variable in the variable storage space of the first partition as the fourth variable value and start the software after flashing.

[0050] Specifically, when the software after flashing starts successfully and runs normally for the first time, the status variable A will be modified in the APP. That is, after writing the value of the status variable as 0x12, the Bootloader will write the status variable in the variable storage space of the first partition as the fourth variable value (0x00) and start the software after flashing (the second start of the software after flashing), that is, change the "started successfully after flashing" state to the "not flashed" state, so that when the software is started again later (without flashing the software again), the software can be started directly normally.

[0051] In an embodiment of the present invention, when the software after flashing starts successfully and runs normally, the software after flashing reads the status variable in the variable storage space of the first partition, and when the lower 16-bit of the status variable is not 0, writes the status variable in the variable storage space of the first partition as the third variable value.

[0052] In the embodiment of the present invention, when the software after flashing starts successfully and runs normally, the software after flashing will perform read, write and judgment processing on the status variable in the variable storage space of the first partition.

[0053] Specifically, when the software after flashing is successfully started and runs normally, it is determined that the lower hexadecimal bit of the state variable is not 0. If the lower hexadecimal bit of the state variable is not 0, the software after flashing will write the state variable in the variable storage space in the first partition to the third variable value (0x12), that is, change the state variable A from the "failed to start after flashing" state to the "successful start after flashing" state. If the lower hexadecimal bit of the state variable is 0, it means that it is not the first time to start the software after flashing, and the software can be directly started and run normally.

[0054] In one embodiment of the present invention, the software flash verification method further includes: When it is determined that the software startup after flashing fails, the state variable in the variable storage space in the first partition is written as the first variable value, and the second partition is switched to restart the MCU from the second partition.

[0055] Specifically, when it is determined that the software startup after flashing fails, the Bootloader writes the state variable in the variable storage space in the first partition as the first variable value, that is, changes the state variable A from the "failed to start after flashing" state to the "flashing completed" state, and switches to the second partition to restart the MCU from the second partition.

[0056] After the software is started for the first time after being flashed in the embodiment of the present invention, based on whether the Bootloader successfully enters the APP, the value of the state variable A will change differently to indicate whether the APP has been entered. If the APP runs successfully, the variable A will be modified in the APP when it is started for the first time after the flashing, and the Bootloader will determine that the last APP startup was successful when it is started for the second time after the flashing, and reset the variable A back to the state before the flashing. If the APP fails to run, the APP will not modify the state variable A, and the watchdog will time out and the system will restart again (that is, the second startup after the flashing occurs). The Bootloader will determine that the APP has failed to run based on the state variable A, and automatically trigger the partition switching process to switch the running partition back to the normal partition before the flashing and restart, and restart back to the old partition software for the third time. At this point, the entire verification and recovery process ends, and the system starts normally.

[0057] The software flash verification method of the embodiment of the present invention is described with a specific embodiment: like Figure 5 As shown in the figure, when checking the software data, the Bootloader writes the storage variable A to 0x01. The Bootloader switches the partition and starts from the new partition (the first partition) at startup. The Bootloader checks the status variable A during the startup process. If it is equal to 0x01, it can trigger the watchdog to be turned on or unconditionally turned on, and rewrite the variable A to 0x02, and start the flashed software.

[0058] The software after flashing starts successfully and enters the running state. After the software after flashing runs successfully, the status variable A is obtained. The software after flashing determines whether the lower 16 bits of the status variable A are 0. If the lower 16 bits of the status variable A are not 0, the higher 16 bits are set to 1. Restart the Bootloader to check whether the value of the status variable A is 0x12. After the Bootloader detects that the value of the status variable A is 0x12, the status variable A is written as 0x00, and the software after flashing is continued to be started. The software after flashing starts successfully. If the lower 16 bits of the status variable A are 0, the software after flashing does not perform any operation on the status variable A and runs normally after startup.

[0059] After the software after flashing fails to start and cannot enter, it causes the watchdog to time out and the system to restart. Restart the Bootloader to check that the value of the status variable A is 0x02 and rewrite it as 0x01. The Bootloader switches partitions, and after the partition switch, the restart is normal.

[0060] The embodiment of the present invention is based on three entities: Bootloader, APP application program, and storage status variable A.

[0061] The embodiment of the present invention provides a highly reliable software flashing verification and recovery solution based on the Bootloader, ensuring that even if the software after dual-partition flashing and upgrading cannot enter the running state, it can still ensure normal recovery startup, greatly improving the reliability of software security recovery after dual-partition flashing and upgrading.

[0062] In the embodiment of the present invention, during the software data verification and system restart process at the end of the flashing process, the Bootloader performs shared reading and judgment of the status variable A with the APP to obtain the real running state fingerprint record of the APP to ensure the high reliability of the software flashing and subsequent recovery processes. By using the software flashing verification method of the embodiment of the present invention, it is possible to prevent the system from getting stuck after system update caused by the fact that although the static verification flag of the flashing software passes the verification, but in fact the APP cannot enter the running state normally. The software flashing verification method of the embodiment of the present invention makes up for the possibility of such risks, further improves the security of the software flashing verification and recovery processes, basically eliminates the failure scenarios of dual-partition MCU software flashing and error recovery, and realizes high reliability and security.

[0063] The present invention provides a software flashing verification device.

[0064] The software flashing verification device in the embodiment of the present invention is used for an MCU, and the MCU includes a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition.

[0065] Figure 6It is a schematic diagram of a software flashing verification device according to an embodiment of the present invention. As Figure 6 shown, the software flashing verification device 100 may include: A flashing module 10, configured to write the status variable in the variable storage space of the first partition as a first variable value when the software flashing of the first partition is completed; A verification module 20, configured to switch to the first partition and restart the MCU from the first partition, perform read, write, and judgment processing on the status variable in the variable storage space of the first partition, determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, switch to the second partition and restart the MCU from the second partition, wherein when the flashed software starts successfully and runs normally, read, write, and judgment processing are performed on the status variable in the variable storage space of the first partition.

[0066] It should be noted that for other specific implementation manners of the software flashing verification device provided in the embodiments of the present invention, reference may be made to other specific implementation manners of the software flashing verification method in the above embodiments of the present invention.

[0067] The software flashing verification device in the embodiments of the present invention ensures that even if the software after dual-partition flashing and upgrading cannot enter the running state, it can still ensure normal restart, greatly improving the reliability of the safe recovery of the software after dual-partition flashing and upgrading.

[0068] The present invention provides a computer-readable storage medium.

[0069] In this embodiment, a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the software flashing verification method as described above is implemented.

[0070] The present invention provides a controller.

[0071] In this embodiment, the controller may include a memory and a processor. A computer program is stored on the memory. When the computer program is executed by the processor, the software flashing verification method as described above is implemented.

[0072] Figure 7 It is a structural block diagram of the controller according to an embodiment of the present invention.

[0073] As Figure 7 shown, the controller 500 includes: a processor 501 and a memory 503. Among them, the processor 501 and the memory 503 are connected, such as connected through a bus 502. Optionally, the controller 500 may further include a transceiver 504. It should be noted that in practical applications, the transceiver 504 is not limited to one, and the structure of the controller 500 does not constitute a limitation to the embodiments of the present invention.

[0074] The processor 501 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in connection with the disclosure of the present invention. The processor 501 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0075] The bus 502 may include a path for transmitting information between the above components. The bus 502 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 502 may be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 7 only a thick line is shown herein, but it does not mean that there is only one bus or one type of bus.

[0076] The memory 503 is used to store a computer program corresponding to the software flashing verification method of the foregoing embodiments of the present invention, and the computer program is controlled and executed by the processor 501. The processor 501 is used to execute the computer program stored in the memory 503 to implement the content shown in the foregoing method embodiments.

[0077] Among them, the controller 500 includes but is not limited to: mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The illustrated controller 500 is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present invention.

[0078] In the embodiments of the present invention, the computer-readable storage medium and the controller, based on the above software flashing verification method, ensure that although the software after dual-partition flashing and upgrading cannot enter the running state, the normal recovery startup can still be guaranteed, greatly improving the reliability of the safe recovery of the software after dual-partition flashing and upgrading.

[0079] The present invention provides a vehicle.

[0080] Figure 8 It is a schematic diagram of a vehicle according to an embodiment of the present invention. As Figure 8 shown, the vehicle 1000 may include a controller 500 as described above.

[0081] For the vehicle in the embodiment of the present invention, based on the above controller, when upgrading and flashing software, it is ensured that although the software after dual - partition flashing cannot enter the running state, normal recovery startup can still be guaranteed, greatly improving the reliability of the safe recovery of the software after dual - partition flashing and upgrading.

[0082] It should be noted that the logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer - readable medium for use by an instruction execution system, apparatus, or device (such as a computer - based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or used in conjunction with these instruction execution systems, apparatus, or devices. For the purposes of this specification, a "computer - readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non - exhaustive list) of the computer - readable medium include the following: an electrical connection part (electronic device) having one or more wirings, a portable computer diskette (magnetic device), a random access memory (RAM), a read - only memory (ROM), an erasable programmable read - only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read - only memory (CDROM). Additionally, the computer - readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media, then editing, interpreting, or processing it in other suitable ways as necessary, and then storing it in a computer memory.

[0083] It should be understood that each part of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above - mentioned embodiment, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following techniques well - known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application - specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGA), field - programmable gate arrays (FPGA), etc.

[0084] In the description of this specification, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0085] In the description of the present invention, it should be understood that the orientation or positional relationships indicated by the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc. are based on the orientation or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as a limitation of the present invention.

[0086] In addition, the terms "first" and "second" are only used for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present invention, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically and clearly defined.

[0087] In the present invention, unless otherwise clearly specified and defined, the terms "mounted", "connected", "connected to", "fixed", etc. should be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or integrated; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the communication inside two elements or the interaction relationship between two elements, unless otherwise clearly defined. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0088] In the present invention, unless otherwise clearly specified or limited, the first feature being "on" or "under" the second feature may mean that the first and second features are in direct contact, or the first and second features are indirectly in contact through an intermediate medium. Further, the first feature being "above", "over" and "on top of" the second feature may mean that the first feature is directly above or obliquely above the second feature, or merely indicates that the horizontal height of the first feature is higher than that of the second feature. The first feature being "under", "beneath" and "underneath" the second feature may mean that the first feature is directly below or obliquely below the second feature, or merely indicates that the horizontal height of the first feature is less than that of the second feature.

[0089] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A software flashing verification method, characterized in that, For an MCU, the MCU includes a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition. The method includes: When the software flashing of the first partition is completed, write the status variable in the variable storage space of the first partition as a first variable value; Switch to the first partition and restart the MCU from the first partition, perform read, write, and judgment processing on the status variable in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally, and when it is determined that the flashed software fails to start, switch to the second partition and restart the MCU from the second partition. Wherein, when the flashed software starts successfully and runs normally, perform read, write, and judgment processing on the status variable in the variable storage space of the first partition.

2. The software flashing verification method according to claim 1, wherein The status variable is a uint8 variable, which is divided into two 4-bit hexadecimal bits.

3. The software flashing verification method according to claim 2, characterized in that The values of the status variable include a first variable value, a second variable value, and a third variable value. The first variable value is 0x01, the second variable value is 0x02, and the third variable value is 0x12. The performing read, write, and judgment processing on the status variable in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally includes: Read the status variable in the variable storage space of the first partition and determine whether the status variable is 0x01; If so, enable the watchdog, write the status variable in the variable storage space of the first partition as the second variable value, and then start the flashed software. Wherein, when the flashed software starts successfully and runs normally, the flashed software writes the status variable in the variable storage space of the first partition as the third variable value. When the flashed software fails to start and the watchdog times out, restart the MCU in the first partition; Read the status variable in the variable storage space of the first partition; If the value of the status variable is 0x12, determine that the flashed software starts successfully and runs normally; If the value of the status variable is 0x02, determine that the flashed software in the first partition fails to start.

4. The software flashing verification method according to claim 3, characterized in that, The values of the status variable include a fourth variable value, and the fourth variable value is 0x00. The method further includes: When it is determined that the value of the status variable is 0x12, write the status variable in the variable storage space of the first partition as the fourth variable value, and start the flashed software.

5. The software flashing verification method according to claim 4, wherein, When the flashed software starts successfully and runs normally, the flashed software reads the status variable in the variable storage space of the first partition, and when the lower 16-bit of the status variable is not 0, write the status variable in the variable storage space of the first partition as the third variable value.

6. The software flashing verification method according to claim 5, characterized in that The method further includes: When it is determined that the flashed software fails to start, write the status variable in the variable storage space of the first partition as the first variable value, switch to the second partition, and restart the MCU from the second partition.

7. A software flashing verification device, characterized in that, For an MCU, the MCU includes a first partition and a second partition, and variable storage spaces are provided in both the first partition and the second partition. The device includes: A flashing module, configured to write the status variables in the variable storage space of the first partition as a first variable value when the software flashing of the first partition is completed; A verification module, configured to switch to the first partition and restart the MCU from the first partition, perform read, write, and judgment processing on the status variables in the variable storage space of the first partition to determine whether the flashed software starts successfully and runs normally, and switch to the second partition and restart the MCU from the second partition when it is determined that the flashed software fails to start, wherein when the flashed software starts successfully and runs normally, read, write, and judgment processing are performed on the status variables in the variable storage space of the first partition.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the software flashing verification method according to any one of claims 1-6.

9. A controller, comprising a memory and a processor, wherein a computer program is stored on the memory, characterized in that, When the computer program is executed by the processor, it implements the software flashing verification method according to any one of claims 1-6.

10. A vehicle, characterized in that, Includes the controller according to claim 9.

Images