Micro control unit application program upgrading method, device, system, equipment and medium

Abstract

The embodiments of the present disclosure disclose a micro control unit application program upgrading method, device, system, equipment and medium. The method comprises the following steps: determining a first application program currently running when detecting an upgrading command, upgrading other application programs except the first application program, and updating version mark bits corresponding to the other application programs after the upgrading is completed, so as to determine an application program to be run next according to the version marks of the application programs, and make the other application programs run next. The present disclosure realizes the alternate upgrading between the application programs in the vehicle, reduces the version gap between the application programs, and when an abnormal situation such as power failure of the equipment, transmission terminal or upgrading failure occurs during the application program upgrading process, the other program is run to return to the version before the upgrading, thereby solving the problem that the prior art cannot return to the version before the upgrading, and ensuring the normal use of the equipment in the abnormal situation.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle networking technology, and in particular to a method, apparatus, system, device and medium for upgrading microcontroller applications. Background Technology

[0002] In the research and development and application of vehicle microcontroller units (MCUs), it is often necessary to upgrade the vehicle MCU application program due to the need for continuous repair and functional iteration.

[0003] Currently, there are two main methods for upgrading vehicle microcontroller applications: firmware flashing via a programmer or upgrading via ISP (In-System Programming). However, both methods have some problems in practical applications. The programmer method typically requires a physical connection and dedicated flashing equipment, and necessitates disassembling and flashing each vehicle individually, which is difficult to implement for autonomous vehicles already deployed on-site. While the ISP method allows firmware updates via external host computer software without disassembling the device, it lacks a firmware recovery mechanism. If power failure, transmission interruption, or upgrade failure occurs during the microcontroller application upgrade process, the application cannot be restored to the previous version, rendering the device unusable.

[0004] In the process of realizing the present invention, it was found that the prior art has at least the following technical problems: In the process of upgrading the microcontroller application, if there are abnormal situations such as power failure, transmission interruption, or upgrade failure, the microcontroller application cannot be restored to the version before the upgrade, which will cause the device to be unusable. Summary of the Invention

[0005] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a microcontroller application upgrade method, apparatus, system, device, and medium. When abnormal situations such as device power failure, transmission terminal failure, or upgrade failure occur during the application upgrade process, the microcontroller application can be restored to the version before the upgrade, thereby ensuring the normal use of the device.

[0006] In a first aspect, embodiments of this disclosure provide a method for upgrading a microcontroller application, the method comprising:

[0007] An upgrade command was detected, and the first application currently running on the target vehicle was determined.

[0008] Upgrade other applications besides the first application;

[0009] After the upgrade of the other applications is completed, update the version flag bit corresponding to the other applications;

[0010] Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next.

[0011] Secondly, embodiments of this disclosure also provide a microcontroller application upgrade device, the device comprising:

[0012] The execution determination module is used to detect upgrade commands and determine the first application currently running on the target vehicle;

[0013] An upgrade module is used to upgrade applications other than the first application.

[0014] The version update module is used to update the version flag bit of the other applications after the upgrade of the other applications is completed;

[0015] Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next.

[0016] Thirdly, this disclosure also provides a microcontroller application upgrade system, including a host computer and a target vehicle, wherein the host computer includes a version query module, a triggering module, and an upgrade module; wherein,

[0017] The version query module is used to obtain upgrade reference information for the target vehicle, wherein the upgrade reference information includes at least one of the program version of each application, the hardware version of each application, and vehicle information.

[0018] The triggering module is used to determine whether to generate an upgrade command based on the upgrade reference information;

[0019] The upgrade module is used to transmit upgrade data to the target vehicle;

[0020] The target vehicle is configured to execute the microcontroller application upgrade method as described above in response to the detection of an upgrade command.

[0021] Fourthly, this disclosure also provides an electronic device, the electronic device comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the microcontroller application upgrade method as described above.

[0022] Fifthly, embodiments of this disclosure also provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the microcontroller application program upgrade method as described above.

[0023] This disclosure provides a microcontroller application upgrade method, apparatus, system, device, and medium. The method, upon detecting an upgrade command, identifies the currently running first application, upgrades other applications besides the first application, and updates the version flag of each other application after the upgrade is complete. Based on the version flag of each application, the method determines the next application to be run, ensuring that the other applications are run in the next iteration. Furthermore, if another upgrade command is detected, applications besides the first application can be upgraded, enabling alternating upgrades between applications in the vehicle and reducing version differences between applications. In the event of abnormal situations such as device power failure, transmission terminal failure, or upgrade failure during the application upgrade process, other programs can be run to return to the previous version, solving the problem of existing technologies being unable to restore to the previous version, ensuring normal device operation under abnormal conditions, and improving user experience. Attached Figure Description

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

[0025] Figure 1A This is a flowchart of a microcontroller application upgrade method according to an embodiment of the present disclosure;

[0026] Figure 1B This is a memory layout diagram of a source code storage unit in one embodiment of this disclosure;

[0027] Figure 1C This is a flowchart illustrating a hardware compatibility check in one embodiment of this disclosure;

[0028] Figure 2A This is a flowchart of another microcontroller application upgrade method in an embodiment of this disclosure;

[0029] Figure 2B This is a schematic diagram illustrating an application upgrade process according to an embodiment of this disclosure;

[0030] Figure 3A This is a flowchart of another microcontroller application upgrade method in an embodiment of this disclosure;

[0031] Figure 3B This is a memory layout diagram of a data storage unit in one embodiment of this disclosure;

[0032] Figure 3C This is a flowchart illustrating the setting of a mode switching bit in one embodiment of this disclosure;

[0033] Figure 3D This is a flowchart illustrating the determination process for core reset in one embodiment of this disclosure;

[0034] Figure 3E This is a flowchart of a program reset embodiment of the present disclosure;

[0035] Figure 3F This is a schematic diagram of a power-on reset process in one embodiment of the present disclosure;

[0036] Figure 4 This is a schematic diagram of the structure of a microcontroller application upgrade device according to an embodiment of the present disclosure;

[0037] Figure 5A This is a schematic diagram of the structure of a microcontroller application upgrade system according to an embodiment of the present disclosure;

[0038] Figure 5B This is a schematic diagram illustrating the dependencies between modules in a microcontroller application upgrade system according to an embodiment of this disclosure;

[0039] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0040] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0041] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0042] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0043] Existing methods for upgrading vehicle microcontroller applications typically involve using a programmer to update the firmware (for minor updates) or using the ISP (In-Service Module) method. While the ISP method allows firmware updates via external host computer software without disassembling the device, it lacks a firmware recovery mechanism. If an anomaly occurs during the upgrade process, the device cannot revert to its previous state or can only revert to the initial version, not the version before the upgrade.

[0044] To address the aforementioned issues, this disclosure provides a method, apparatus, system, device, and medium for upgrading microcontroller applications. In the event of abnormal situations such as device power failure, transmission terminal issues, or upgrade failure during the application upgrade process, the microcontroller application can be restored to its previous version, thus ensuring normal device operation. It should be noted that the microcontroller application upgrade method provided in this embodiment can be used to upgrade the applications (i.e., firmware) corresponding to each microcontroller in a vehicle, and can also be used to upgrade the applications corresponding to microcontrollers in other electronic devices, such as the microcontrollers of robots and medical devices. This embodiment does not limit the application scenarios of this microcontroller application upgrade method; taking a vehicle MCU as an example, the upgrade process of the MCU application is explained.

[0045] Figure 1A This is a flowchart illustrating a microcontroller application upgrade method according to an embodiment of this disclosure. The method can be executed by a microcontroller application upgrade device, which can be implemented in software and / or hardware, and can be configured in an electronic device. Figure 1A As shown, the method may specifically include the following steps:

[0046] S110: An upgrade command was detected. The first application currently running on the target vehicle was determined.

[0047] In this embodiment, the target vehicle may include at least two applications. Specifically, each application may be an application corresponding to the same microcontroller unit in the target vehicle. For example, each application may be a program for the microcontroller unit of the autonomous driving system, or a program for the microcontroller unit of the suspension system, etc.

[0048] The advantage of having all applications corresponding to the same microcontroller is that by alternately upgrading the various applications corresponding to the same microcontroller, it is possible to avoid the situation where the microcontroller cannot function due to the inability to revert to the previous application when an abnormality occurs during the upgrade process of a certain application of the microcontroller. This ensures the normal use of the vehicle and thus guarantees the driving safety of the vehicle.

[0049] The upgrade command can be a command transmitted from the host computer to the vehicle's microcontroller unit to trigger the upgrade process. Specifically, when the microcontroller unit receives the upgrade command from the host computer, it can check whether the target vehicle's current speed is zero. If not, it stops responding to the upgrade command; if so, it can continue responding to the upgrade command and determine the currently running first application.

[0050] S120, Upgrade applications other than the first application.

[0051] Specifically, after identifying the currently running first application, other applications that are not running can be upgraded. It should be noted that in this embodiment, the number of other applications not running can be one or more. Specifically, if the same microcontroller unit in the target vehicle corresponds to two applications, the number of other applications is 1; if the same microcontroller unit in the target vehicle corresponds to at least three applications, the number of other applications is at least two.

[0052] In this embodiment, if there are multiple other applications, one of them can be selected for upgrade, or all other applications can be upgraded, or the application with the lowest version can be selected for upgrade.

[0053] In one specific implementation, upgrading other applications includes: obtaining the interrupt vector corresponding to the other application; determining the target location corresponding to the other application in the source code storage unit based on the interrupt vector; obtaining upgrade data; and replacing the data stored in the target location with the upgrade data.

[0054] The source code storage unit can be used to store program data from the microcontroller unit; for example, it can be a code flash. The source code storage unit can store program data corresponding to each application. See, for an example... Figure 1B The diagram illustrates a memory layout of a source code storage unit. Taking the microcontroller unit corresponding to application 1 and application 2 as an example, application 1, application 2, and the bootloader are stored in the source code storage unit. The source code storage unit can provide 64K of space for the bootloader and reserve 128K*4=512K of space for application 1 and application 2 respectively.

[0055] When it is necessary to upgrade other applications, you can first locate the location of the program data of the other application in the source code storage unit, and then update the data in that location.

[0056] Specifically, an interrupt vector table can be maintained in advance, which includes interrupt vectors corresponding to each application. Based on the interrupt vector table, the interrupt vectors corresponding to other applications to be upgraded can be queried, and the address pointed to by the interrupt vector can be determined as the target location. The data stored in the target location is replaced by upgrade data sent by the host computer, thereby realizing the upgrade of other applications.

[0057] In the above implementation, each application can be stored in the source code storage unit, without needing to be stored separately in different storage units. Therefore, when an application is upgraded, the interrupt vector directly locates the corresponding position of the other application in the source code storage unit to flush the data, thus upgrading the microcontroller's program. Compared to storing the program data corresponding to each application in different storage units, the method of this embodiment can reduce memory usage.

[0058] Considering that the firmware hardware type issued by the host computer may not match the firmware hardware type of the target vehicle during application upgrades, which could lead to upgrade failure, the following steps are taken before upgrading applications other than the first application: obtaining the current firmware hardware type corresponding to the target vehicle; determining the firmware hardware type to be input corresponding to the upgrade command; determining whether the upgrade conditions are met based on the current firmware hardware type and the firmware hardware type to be input; if so, then performing the upgrade operation for applications other than the first application.

[0059] The current firmware hardware type can be the firmware type of each application corresponding to the microcontroller unit, while the firmware hardware type to be input can be the firmware type corresponding to the upgrade data to be sent by the host computer. Specifically, if the current firmware hardware type matches the firmware hardware type to be input, the upgrade operation can be performed on applications other than the first application; if the current firmware hardware type does not match the firmware hardware type to be input, a prompt message can be displayed to indicate that the current firmware hardware type does not match the firmware hardware type to be input, i.e., the hardware is incompatible and the upgrade cannot be performed.

[0060] For example, see Figure 1CThis document illustrates a hardware compatibility check flowchart. Upon detecting an upgrade command, an upgrade script is executed, which then retrieves the current firmware hardware type. If the current firmware hardware type is type A, the document further checks if the hardware type of the input firmware is also type A. If yes, the upgrade proceeds; otherwise, it displays a message indicating a mismatch between the current and input firmware hardware types and exits. If the current firmware hardware type is type B, the document further checks if the hardware type of the input firmware is also type B. If yes, the upgrade proceeds; otherwise, it displays a message indicating a mismatch between the current and input firmware hardware types and exits. If the current firmware hardware type is type C, the document further checks if the hardware type of the input firmware is also type C. If yes, the upgrade proceeds; otherwise, it displays a message indicating a mismatch between the current and input firmware hardware types and exits. If the current firmware hardware type is not found, or if another hardware type is found, the document displays a message indicating an error in hardware type retrieval or that no hardware type was retrieved, and then exits.

[0061] In the above implementation, by determining whether the current firmware hardware type matches the firmware hardware type to be input in the upgrade data input by the host computer before upgrading other applications, a hardware compatibility check is performed, avoiding upgrade failures due to hardware incompatibility and improving the success rate of program upgrades.

[0062] S130. After upgrading other applications, update the version flag bits corresponding to the other applications. Each application has its own version flag bit, which is used to determine the application to be run next.

[0063] Specifically, after upgrading other applications, the version flag for those applications can be updated. Each application has a version flag that indicates its current version.

[0064] In this embodiment, the purpose of updating the version flag of other applications after their upgrades are completed is to update the current version of the other applications. This allows the target vehicle to determine the latest version of the other application and enable its operation when it needs to power on again and needs to identify the application to be run.

[0065] Specifically, updating the version flag for other applications can be done by directly setting the version flag for those applications to a preset value, such as 1 or 0, or by calculating a new version flag based on the current version flag.

[0066] In one specific implementation, updating the version flag bit corresponding to other applications includes: updating the version flag bit corresponding to other applications based on the sum of the version flag bit corresponding to the first application and a first value; or, updating the version flag bit corresponding to other applications based on the sum of the version flag bit corresponding to other applications and a second value.

[0067] The second value can be greater than the first value. The first value represents the version difference between applications and can be set to 1; the second value represents the version difference between two consecutive upgrades for each application. Taking a microcontroller unit corresponding to two applications as an example, the second value can be set to 2. That is, the version flag corresponding to the first application can be added to the first value and used as the version flag corresponding to other applications; the version flag corresponding to other applications can be added to the second value and used as the new version flag corresponding to other applications.

[0068] The above method allows for the modification of the version flag bit of other applications after the upgrade is completed. Compared to directly setting the version flag bit to 1 or 0, this method ensures that the version flag bit of the updated other applications is greater than the version flag bit of the unupdated first application. This ensures that the updated other applications will run on the next power-on. Furthermore, by accumulating the version flag bit after each upgrade, the version flag bit can be used to determine the number of upgrades, which can be used for subsequent microcontroller upgrade analysis.

[0069] In this embodiment, when an upgrade command is detected, the first application and other applications can be identified, the other applications can be upgraded, and the version flag of the other applications can be updated after the upgrade is completed so that the other applications can run on the next power-on. Furthermore, if a new upgrade command is received after the next power-on, the other applications can be identified as the new first application, and the other applications except the new first application can be upgraded, thereby realizing the alternating upgrade between programs.

[0070] Taking a microcontroller unit with application 1 and application 2 as an example, when an upgrade command is detected for the first time, if application 1 is running, application 2 will be upgraded and its version flag will be updated. When the target vehicle is powered on again, application 2 can be determined to be the latest version based on the version flags of application 1 and application 2. If an upgrade command is detected again during the running of application 2, application 1 will be upgraded and its version flag will be updated. This process can be repeated to achieve alternating upgrades of application 1 and application 2.

[0071] It should be noted that, compared with the method of copying the application data of the application stored in the main area to the backup area before the application is upgraded, the method provided in this embodiment does not require copying the application data before each upgrade, which greatly improves the upgrade efficiency. Furthermore, the method provided in this embodiment allows another application to be run directly after the upgrade fails, without having to copy the application data from the backup area to the main area again, further improving the upgrade efficiency, reducing user waiting time, and improving the user experience.

[0072] The microcontroller application upgrade method provided in this embodiment determines the currently running first application when an upgrade command is detected, upgrades other applications besides the first application, and updates the version flag bit corresponding to the other applications after the upgrade is completed. Based on the version flag bit of each application, the method determines the next application to be run, ensuring that the other applications are run in the next iteration. Furthermore, if an upgrade command is detected again, applications besides the first application can be upgraded, enabling alternating upgrades between applications in the vehicle and reducing version differences between applications. In the event of abnormal situations such as device power failure, transmission terminal failure, or upgrade failure during the application upgrade process, other programs can be run to return to the previous version, solving the problem of existing technologies being unable to restore to the previous version, ensuring normal device operation under abnormal conditions, and improving user experience.

[0073] Figure 2A This is a flowchart illustrating another microcontroller application upgrade method according to an embodiment of this disclosure. Based on the above embodiments, the upgrade process for other applications is described exemplarily. See also... Figure 2A The method may include the following steps:

[0074] S210: An upgrade command was detected. The first application currently running on the target vehicle was determined.

[0075] S220. Update the upgrade flag bits corresponding to other applications besides the first application and generate a program reset command. Each application also has an upgrade flag bit, which is used to determine the application to be upgraded when the program is reset.

[0076] In this embodiment, the purpose of updating the upgrade flag bits corresponding to other applications is to ensure that after the program is reset according to the program reset command, it can be determined by the upgrade flag bits corresponding to other applications that other applications are being upgraded.

[0077] For example, updating the upgrade flags for other applications can be done by directly setting the upgrade flags for other applications to a preset value, or by calculating new upgrade flags for other applications based on the upgrade flags for each application.

[0078] In one specific implementation, updating the upgrade flag bits corresponding to applications other than the first application can be done by: updating the upgrade flag bits corresponding to other applications based on the sum of a first value and the upgrade flag bits corresponding to the first application; or, updating the upgrade flag bits corresponding to other applications based on the sum of a second value and the upgrade flag bits corresponding to other applications.

[0079] That is, the updated upgrade flag for other applications can be equal to the sum of the first value and the upgrade flag for the first application, or it can be equal to the sum of the second value and the upgrade flag for other applications before the update.

[0080] The above method allows for the modification of upgrade flag bits for other applications before program reset. Compared to directly setting the upgrade flag bit to 1 or 0, this method ensures that the upgrade flag bits for other applications are greater than those for the first application, thus guaranteeing that other applications are upgraded after program reset. Furthermore, by accumulating the upgrade flag bit before each upgrade reset, the upgrade flag bit can be used to determine the number of upgrades, which can be used for subsequent microcontroller upgrade analysis.

[0081] After updating the version flags of other applications, a program reset command can be generated to trigger a restart of the microcontroller unit, i.e., reset to the starting address in the source code storage unit, so as to jump from the currently running first application to rerun the bootloader.

[0082] S230: Upgrade other applications based on program reset commands.

[0083] In this embodiment, after generating the program reset command, the pointer to the first application in the source code storage unit can be redirected to the bootloader, allowing other applications to be upgraded via the bootloader. The bootloader can have both the function of upgrading applications and the function of bootstrapping applications.

[0084] Specifically, the bootloader can obtain the interrupt vectors corresponding to other applications, determine the target location corresponding to the other applications in the source code storage unit based on the interrupt vectors, and write the upgrade data to the target location.

[0085] S240. After upgrading other applications, update the version flags corresponding to those applications.

[0086] In this embodiment, if other applications complete their upgrades, they can be run directly through the bootloader; if other applications fail to upgrade, applications other than those other can be run directly through the bootloader.

[0087] Optionally, the method provided in this embodiment may further include: when other applications are detected to have failed to upgrade, upgrading the other applications again based on a preset number of upgrades and / or a preset waiting time.

[0088] The preset upgrade count can be a pre-set number of times that other applications can be upgraded during the response to an upgrade command; the preset wait time can be a pre-set duration for waiting for other applications to be upgraded again during the response to an upgrade command.

[0089] The preset number of upgrade attempts and the preset waiting time can be set according to actual business needs. A larger preset number of upgrade attempts and a larger preset waiting time result in a higher probability of successful upgrades for other applications, but a longer waiting time for the user. Conversely, a smaller preset number of upgrade attempts and a smaller preset waiting time result in a lower probability of successful upgrades for other applications, but a shorter waiting time for the user. Therefore, these parameters can be set based on the user's waiting time and upgrade success rate requirements.

[0090] Specifically, when an application upgrade fails, the current number of attempts can be updated, and a decision can be made based on the current number of attempts and the preset number of upgrades to re-upgrade the application; alternatively, when an application upgrade fails, the application can continue to upgrade within a preset waiting time; or, within a preset waiting time, a decision can be made based on the current number of attempts and the preset number of upgrades to re-upgrade the application.

[0091] In the above process, by setting a preset number of upgrade attempts and / or a preset waiting time, the system avoids repeatedly initiating upgrade attempts, preventing users from waiting too long. This also improves the success rate of upgrades for other applications. Of course, if other applications are re-upgraded based on the preset number of upgrade attempts and / or the preset waiting time, and the upgrades for those applications still fail, other applications can be run directly.

[0092] For example, see Figure 2B , Figure 2BThis diagram illustrates an application upgrade process, using a microcontroller unit corresponding to two applications as an example to demonstrate the process. After a program reset is performed according to the program reset command, a CRC (Cyclic Redundancy Check) is first performed on the program text files (i.e., cookies) of each application. The program text files store various flag bits for each application; the specific CRC verification process is explained later. If both application text files pass the verification, the upgrade flag bits of the two applications are further compared. If upgrade flag bit_1 of application 1 equals upgrade flag bit_2 of application 2, an abnormal situation is identified, and a coding error message is fed back. If upgrade flag bit_1 of application 1 is greater than upgrade flag bit_2 of application 2, application 1 can be upgraded. If upgrade flag bit_1 of application 1 is less than upgrade flag bit_2 of application 2, application 2 can be upgraded.

[0093] Furthermore, after application 1 or application 2 is upgraded, it is determined whether the upgrade was successful. If the upgrade is successful, the upgraded application 1 or application 2 is run directly, and the version flag of the upgraded application 1 or application 2 is incremented by one. If the upgrade is unsuccessful, application 2 or application 1 is run.

[0094] If Cookies_1 of Application 1 passes verification but Cookies_2 of Application 2 fails verification, then Application 1 will run directly; if Cookies_1 of Application 1 fails verification but Cookies_2 of Application 2 passes verification, then Application 2 will run directly; if both Cookies_1 of Application 1 and Cookies_2 of Application 2 fail verification, then it is determined to be an abnormal situation, and an encoding error message (such as a fail code) will be returned.

[0095] The microcontroller application upgrade method provided in this embodiment can update the upgrade flag bits corresponding to other applications and generate a program reset command. Then, the program reset is executed based on the program reset command. The method also determines whether other applications need to be upgraded based on the upgrade flag bits of each application and upgrades those other applications. This realizes application upgrade based on program reset, ensuring that after program reset, the upgrade flag bits can be used to determine whether other applications need to be upgraded, thereby ensuring the correctness of program upgrade.

[0096] Figure 3AThis is a flowchart of another microcontroller application upgrade method according to an embodiment of this disclosure. Based on the above embodiments, it adds a step of determining whether the program is in upgrade mode after a program reset; if so, other applications are upgraded. See also... Figure 3A The method may include the following steps:

[0097] S310: An upgrade command was detected. The first application currently running on the target vehicle was determined.

[0098] S320. Update the upgrade flag bits for applications other than the first application.

[0099] S330: Access the preset storage area in the data storage unit, set the mode switching bit in the preset storage area to the identifier corresponding to the upgrade mode, and generate a program reset command.

[0100] The data storage unit can be used to store relevant data for each application, such as storage mode switching bits, application text files, and application configuration information. Optionally, the data storage unit and the source code storage unit can be located on the same chip.

[0101] For example, see Figure 3B The diagram illustrates a memory layout of a data storage unit. Taking a microcontroller unit corresponding to two applications as an example, the data storage unit includes a preset storage area (HOTRESET), a program text file area (Cookies_1) for application 1, a program text file area (Cookies_2) for application 2, and a program configuration information (Config) area.

[0102] Specifically, the preset storage area can be a hot-boot function area, including at least a mode switching bit used to indicate the program reset mode, such as upgrade mode or hot-boot mode. The preset storage area may also include pointer information, i.e., the location of the currently running first application; or it may include version information of the bootloader, etc. The space of the preset storage area can be 32 bytes.

[0103] Each application's program text file may include application flags, such as version flags, upgrade flags, and existence flags, and may also include checksums corresponding to the flags (such as checksums calculated using CRC). During the process of updating the version or upgrade flags of other applications, the program text files corresponding to those applications in the data storage unit can be accessed, and the new version or upgrade flags can replace the original ones. Program configuration information may include relevant configuration parameters for the application, and the space for the program configuration information area can be 128KB.

[0104] In this embodiment, considering that both warm starts and upgrades can cause program resets, to distinguish between program resets caused by warm starts and those caused by upgrades, the mode switching bit in the preset storage area can be set to the identifier corresponding to the upgrade mode after an upgrade command is detected. Correspondingly, upon receiving a warm start command, the mode switching bit in the preset storage area can be set to the identifier corresponding to the warm start mode, and the target address corresponding to the currently running application can be determined, where the target address points to the currently running application in the source code storage unit.

[0105] For example, see Figure 3C The diagram illustrates a flowchart for setting a mode switching bit. When the currently running application receives an upgrade command, it sets the mode switching bit to the identifier corresponding to the upgrade mode and generates a program reset command. When it receives a warm boot command, it sets the mode switching bit to the identifier corresponding to the warm boot mode, determines the target address, and generates a program reset command.

[0106] S340. Based on the program reset command, run the bootloader. The bootloader determines whether the mode switching bit is the identifier corresponding to the upgrade mode. If so, upgrade other applications.

[0107] Specifically, after generating the program reset command, the program is reset according to the command. After the program is reset to the starting address in the source code storage unit, the bootloader will run. Further, the bootloader determines whether the mode switching bit corresponds to the upgrade mode flag. If it does, it determines the applications to be upgraded (i.e., other applications) based on the upgrade flag bits of each application, and then upgrades those other applications. If it corresponds to the warm boot mode flag, the warm boot process is executed.

[0108] In one specific implementation, the method provided in this embodiment further includes: if the mode switching bit is determined by the bootloader to be the identifier corresponding to the hot start mode, then jump to the application that was last run in the target vehicle.

[0109] Specifically, the target address can be obtained, and the current pointer pointing to the source code storage unit can be controlled to jump to the target address to run the application pointed to by the target address, i.e., the previously run application. In this way, a warm restart of the program after a reset is achieved, which can directly jump to the previously run application without having to re-run the program data in the source code storage unit from the starting address, thus reducing the user's waiting time.

[0110] Considering that in addition to program resets caused by hot starts and upgrades, program resets can also be caused by vehicle power-on, and that program resets caused by hot starts and upgrades can be core resets, in order to distinguish between power-on resets and core resets, it is also possible to determine whether it is a core reset before judging the mode switching bit.

[0111] In one specific implementation, before determining whether the mode switching bit corresponds to the upgrade mode via the bootloader, the method further includes: determining whether the current program reset is a power-on reset or a core reset via the bootloader; if it is a core reset, then the operation of determining whether the mode switching bit corresponds to the upgrade mode is performed. That is, after running the bootloader, if the bootloader determines that it is a core reset, it further determines whether it is the upgrade mode or the hot start mode based on the mode switching bit; if the bootloader determines that it is a power-on reset, then there is no need to determine the mode switching bit, and the application to be run can be determined directly based on the version flag bit corresponding to each application.

[0112] See Figure 3D This document illustrates a flowchart for determining a core reset. Taking the microcontroller unit corresponding to application program 1 and application program 2 as an example, after determining that the current program reset is a core reset, the bootloader can start booting and determine whether the mode switching bit is the identifier corresponding to the upgrade mode. If so, the upgrade process is executed; otherwise, the warm boot process is executed. Specifically, the target address can be used to determine whether it points to application program 1 or application program 2. If it is application program 1, the process jumps to application program 1; if it is application program 2, the process jumps to application program 2.

[0113] For example, see Figure 3E The diagram illustrates a program reset flowchart. First, after a program reset, the bootloader runs. The bootloader then determines whether it was a power-on reset or a core reset. If it was a power-on reset, it identifies the application to be run based on the version flags of each application and executes the program. If it was a core reset, it further determines whether it was a warm boot or an upgrade. If it was a warm boot, it jumps to the previously run application; if it was an upgrade, it identifies other applications that need to be upgraded based on the upgrade flags, performs the upgrade, and runs the upgraded application after the upgrade is complete.

[0114] If a warm-start command is received during application operation, the mode switching bit is set to the identifier corresponding to the warm-start mode, and a program reset command is generated to reset the program; if an upgrade command is received, the mode switching bit is set to the identifier corresponding to the upgrade mode, and a program reset command is generated to reset the program; if a version check command is received, the version information is confirmed.

[0115] By determining whether the current program reset is a power-on reset or a core reset, the system distinguishes between the two. During a core reset, it checks whether the mode switching bit corresponds to the upgrade mode to differentiate between the upgrade mode and the hot start mode. This enables accurate judgment of various reset scenarios during program reset, avoids performing operations inconsistent with the reset scenario, and ensures error-free operation after program reset.

[0116] S350: After upgrading other applications, update the version flags corresponding to those applications.

[0117] In the above embodiments, the version flag can be used to determine the application to be run next. Besides using the version flag to determine the application to be run next, a corresponding presence flag can also be set for each application. Upon the next power-on reset, the application to be run can be determined using at least one of the presence flag and the version flag corresponding to each application.

[0118] In one specific implementation, each application also has a corresponding presence flag, which is used to determine whether the application is in a runnable or non-runnable state.

[0119] After upgrading other applications, the process also includes updating the presence flag of other applications to mark them as runnable.

[0120] After determining whether the current program reset is a power-on reset or a core reset through the bootloader, the process further includes: if the current program reset is a power-on reset, then determining the application to be run based on the existence flag bit and / or version flag bit corresponding to each application.

[0121] The presence flag can be an identifier corresponding to a runnable state or a non-runnable state. Before upgrading other applications, while updating the upgrade flag for those applications, their presence flag can also be updated to indicate that the other applications are in a non-runnable state. This ensures that after a program reset, the upgrade for other applications will proceed without directly running them. Conversely, after upgrading other applications, their presence flag can be updated to indicate that they are now runnable.

[0122] Furthermore, after a power-on reset, the application to be run can be determined based on the presence flag and / or version flag of each application. For example, the application in a runnable state can be determined based on the presence flag, and then one of the runnable applications can be selected as the application to be run; or, the latest version of the application can be selected as the application to be run based on the version flag, etc.

[0123] After the bootloader identifies the application to be run, it can be run directly. This implementation method allows for accurate identification of the application to be run upon power-on reset, enabling the priority launch of newer versions of applications or applications that do not require upgrades and are already runnable, thus improving the user experience.

[0124] In one specific implementation, determining the application to be run based on the existence flag and / or version flag corresponding to each application can be as follows: For each application, obtain the preset verification code corresponding to the application, and determine the current verification code based on the upgrade flag, existence flag, and version flag corresponding to the application; determine the flag verification result based on the current verification code and the preset verification code, and determine the application whose flag verification result is verified as a candidate launcher; determine the application to be run based on the existence flag and / or version flag corresponding to each candidate launcher.

[0125] The preset checksum can be a checksum stored in the application's corresponding program text file. The current checksum can be a checksum calculated in real time using the upgrade flag, existence flag, and version flag. For example, the current checksum can be obtained through CRC calculation.

[0126] Specifically, it can be determined whether the current check code is consistent with the preset check code. If so, the check code verification result is considered successful; otherwise, the check code verification result is considered unsuccessful.

[0127] Furthermore, applications that pass the flag verification can be identified as candidate launchers. After identifying each candidate launcher, the applications to be run can be selected based on their corresponding presence flag and / or version flag.

[0128] In this embodiment, the flag bits of each application are verified by using a preset verification code and the current verification code, thereby verifying the application's program text file (i.e., cookies). Then, for applications that pass the verification, applications to be run are selected based on the presence of flag bits and / or version flag bits, thus avoiding running applications with abnormal program text files and ensuring the correctness of program operation.

[0129] In one specific implementation, the application to be run is determined based on the existence flag and / or version flag corresponding to each candidate launcher. This can be done by: determining the candidate launcher that is in a runnable state as the application to be run based on the existence flag corresponding to each candidate launcher; if there are multiple applications to be run, the final application to be run is determined based on the version flag corresponding to each application to be run.

[0130] That is, after determining each candidate startup program based on the flag bit verification result, the existence flag bit of each candidate startup program is further determined. If the existence flag bit is an identifier corresponding to the runnable state, it can be determined as the application to be run. Furthermore, if there are multiple applications to be run determined by the existence flag bit, the latest version of the program among the multiple applications to be run can be used as the final application to be run based on the version flag bit.

[0131] It should be noted that the purpose of prioritizing the existence flag to determine the application to be run is as follows: when an upgrade command is received, the upgrade flag and existence flag of other applications need to be updated so that the other applications can be upgraded after the program is reset. If the other applications fail to upgrade, their existence flag will still be the identifier corresponding to the inoperable state. Therefore, after power-on reset, the other applications can be left running. If an upgrade command is received again, the other applications that have not been run can still be regarded as the applications that need to be upgraded and upgraded again.

[0132] The above method allows for the execution of applications whose program text files are normal and in a runnable state, or applications whose program text files are normal, in a runnable state, and are the latest version. This achieves accurate identification of programs running under power-on reset conditions, avoiding the execution of applications with incorrect flag bits and applications that require upgrades.

[0133] For example, see Figure 3FThe diagram illustrates a power-on reset process. Taking the microcontroller unit corresponding to application 1 (APP1) and application 2 (APP2) as examples, after determining that it is a power-on reset, the bootloader can determine the application to be booted, i.e., the application to be run.

[0134] Specifically, in Figure 3F If APP1's Cookies_1 is normal and APP2's Cookies_2 is abnormal, then APP1 is selected as a candidate launcher. The existence flag (C1.ex) of APP1 is then checked to see if it is 1. If it is, APP1 is run; otherwise, an encoding error message is returned. If APP2's Cookies_2 is normal and APP1's Cookies_1 is abnormal, then APP2 is selected as a candidate launcher. The existence flag (C2.ex) of APP2 is then checked to see if it is 1. If it is, APP2 is run; otherwise, an encoding error message is returned.

[0135] If both Cookies_1 and Cookies_2 are valid, then APP1 will run when C1.ex is 1, and APP2 will run when C2.ex is 1. If both C1.ex and C2.ex are 1, then if the version flag (C1.new) of APP1 is greater than (C2.new), then APP1 will run; if C2.new is greater than C1.new, then APP2 will run; if C2.new is equal to C1.new, then APP1 will run. If neither C1.ex nor C2.ex is 1, an encoding error message will be returned.

[0136] If both Cookies_1 and Cookies_2 are abnormal, an encoding error message will be returned.

[0137] Furthermore, during the operation of APP1 / APP2, if an upgrade command is received, the upgrade flag of APP2 / APP1 can be set to the upgrade flag of APP1 / APP2 + 1, the existence flag of APP2 / APP1 can be set to 1, and a program reset command can be generated to perform core reset and jump to the bootloader to wait for upgrade.

[0138] It should be noted that, considering the possibility of a power outage during the update and upgrade flag and presence flag processes, which could lead to write operations failing in the data storage unit (i.e., the upgrade flag and / or presence flag writes failing), a power-on reset will still allow the application to be run to be determined based on the preset checksum, presence flag, and version flag of each application. See Table 1, which uses application 1 (APP1) and application 2 (APP2) corresponding to the microcontroller unit as examples, to illustrate the post-power-on execution results under various write scenarios involving a power outage during the writing of the upgrade and presence flags of APP2.

[0139] Table 1 shows the running results for different write scenarios before the upgrade.

[0140]

[0141] Specifically, after a power-on reset, if the CRC check of APP2 passes, APP2 can be identified as a candidate startup program. Further checks are made on the presence flag of APP2. If the presence flag of APP2 is successfully written (set to 0), APP1 can be run. If the presence flag of APP2 fails to be written (set to 1), one of APP1 or APP2 can be run. Since APP1 is pre-set to run only if both APP1 and APP2 are available, APP1 will be run first. Therefore, APP1 will run at this point. If the CRC check of APP2 fails, APP1 can be run directly.

[0142] Of course, considering that power outages can occur not only during the updating and upgrading of the flag bit and the existence flag bit, but also during the updating of the version flag bit and the existence flag bit, the operation of writing the version flag bit and the existence flag bit of other applications into the program text file of the data storage unit may fail when other applications have completed their updates.

[0143] If a power cycle is performed at this point, the application to be run can still be determined based on the preset checksum, presence flag, and version flag of each application. See Table 2, which uses application 1 (APP1) and application 2 (APP2) corresponding to the microcontroller as examples, to illustrate the running results after power-on under various writing conditions when a power outage occurs during the writing of the version flag and presence flag of APP2.

[0144] Table 2 shows the running results corresponding to different write scenarios after the upgrade.

[0145]

[0146] Specifically, after power-on reset, if the CRC check of APP2 passes and the presence flag of APP2 is 1, it can be further determined whether the version flag of APP2 is greater than the version flag of APP1. If the version flag of APP2 is successfully written, then the version flag of APP2 is greater than that of APP1, and APP2 can be run. If the version flag of APP2 fails to be written, then the version flag of APP2 is less than that of APP1, and APP1 can be run.

[0147] If the CRC check of APP2 passes and the presence flag of APP2 is 0, then APP1 can be run directly; if the CRC check of APP2 fails, then APP1 can be run directly.

[0148] The microcontroller application upgrade method provided in this embodiment updates the upgrade flag bits corresponding to other applications when an upgrade command is received, accesses a preset storage area in the data storage unit, sets the mode switching bit to the identifier corresponding to the upgrade mode, generates a program reset command, resets the program using the program reset command, runs the bootloader, and determines whether the mode switching bit is the identifier corresponding to the upgrade mode. If it is, the other applications are upgraded. This method realizes the determination of the upgrade mode after program reset, avoids upgrading other applications in hot start mode, and improves the user experience.

[0149] Figure 4 This is a schematic diagram of the structure of a microcontroller application upgrade device according to an embodiment of this disclosure. Figure 4 As shown: The device includes: a run determination module 410, an upgrade module 420, and a version update module 430.

[0150] The execution determination module 410 is used to detect the upgrade command and determine the first application currently running on the target vehicle;

[0151] Upgrade module 420 is used to upgrade applications other than the first application.

[0152] Version update module 430 is used to update the version flag bit corresponding to the other applications after the upgrade of the other applications is completed;

[0153] Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next.

[0154] The microcontroller application upgrade device provided in this embodiment can determine the currently running first application when an upgrade command is detected, upgrade other applications besides the first application, and update the version flag bit corresponding to the other applications after the upgrade is completed. Based on the version flag bit of each application, the device determines the next application to be run, ensuring that the other applications are run in the next iteration. Furthermore, if an upgrade command is detected again, it can upgrade all applications except the first one, achieving alternating upgrades between applications in the vehicle and reducing version differences between applications. In the event of abnormal situations such as device power failure, transmission terminal failure, or upgrade failure during the application upgrade process, other programs can be run to return to the previous version, solving the problem of existing technologies being unable to restore to the previous version, ensuring normal device operation under abnormal conditions, and improving user experience.

[0155] Based on the above embodiments, optionally, the upgrade module 420 includes a flag bit update unit and a reset upgrade unit, wherein;

[0156] The flag update unit is used to update the upgrade flags corresponding to applications other than the first application and generate a program reset command.

[0157] The reset and upgrade unit is used to upgrade the other applications based on the program reset command.

[0158] Each of the aforementioned applications also has an upgrade flag bit, which is used to determine the application to be upgraded when the program is reset.

[0159] Based on the above embodiments, optionally, the flag update unit is further configured to update the upgrade flag corresponding to the other application according to the sum of the first value and the upgrade flag corresponding to the first application; or, to update the upgrade flag corresponding to the other application according to the sum of the second value and the upgrade flag corresponding to the other application.

[0160] Based on the above implementation, optionally, the flag update unit is further configured to access a preset storage area in the data storage unit and set the mode switching bit in the preset storage area to the identifier corresponding to the upgrade mode; correspondingly, the reset upgrade unit is further configured to run the bootloader based on the program reset command; through the bootloader, determine whether the mode switching bit is the identifier corresponding to the upgrade mode, and if so, upgrade the other applications.

[0161] Based on the above implementation, optionally, the reset and upgrade unit is further configured to determine, through the bootloader, whether the current program reset is a power-on reset or a core reset; if it is a core reset, then perform the operation of determining whether the mode switching bit is the identifier corresponding to the upgrade mode.

[0162] Based on the above implementation, optionally, the reset and upgrade unit is further configured to, if the bootloader determines that the mode switching bit is the identifier corresponding to the hot start mode, jump to run the application that was last run in the target vehicle.

[0163] Based on the above embodiments, optionally, each application application also has a corresponding existence flag bit, which is used to determine whether the application is in a runnable or non-runnable state; the version update module 430 is also used to update the existence flag bits of the other applications to mark the other applications as runnable; the device also includes a power-on reset module, which is used to determine the application to be run based on the existence flag bit and / or version flag bit corresponding to each application application after the bootloader determines whether the current program reset is a power-on reset or a core reset, if the current program reset is a power-on reset.

[0164] Based on the above implementation, optionally, the power-on reset module is further configured to: obtain a preset verification code corresponding to each application; determine the current verification code based on the upgrade flag, existence flag, and version flag corresponding to the application; determine the flag verification result based on the current verification code and the preset verification code; determine the application whose flag verification result is verified as a candidate startup program; and determine the application to be run based on the existence flag and / or version flag corresponding to each candidate startup program.

[0165] Based on the above implementation, optionally, the power-on reset module is further configured to determine the candidate startup program in the runnable state as the application to be run based on the existence flag bit corresponding to each of the candidate startup programs; if there are multiple applications to be run, the final application to be run is determined based on the version flag bit corresponding to each application to be run.

[0166] Based on the above implementation, optionally, the upgrade module 420 is also used to re-upgrade the other applications based on a preset number of upgrades and / or a preset waiting time when the upgrade of the other applications is detected to have failed.

[0167] Based on the above implementation, optionally, the upgrade module 420 is further configured to obtain the interrupt vector corresponding to the other application, determine the target location corresponding to the other application in the source code storage unit based on the interrupt vector, obtain upgrade data, and use the upgrade data to replace the data stored in the target location.

[0168] Based on the above implementation, optionally, the upgrade module 420 is further configured to obtain the current firmware hardware type corresponding to the target vehicle; determine the firmware hardware type to be input corresponding to the upgrade command; determine whether the upgrade conditions are met based on the current firmware hardware type and the firmware hardware type to be input; if so, perform the operation of upgrading other applications besides the first application.

[0169] Based on the above implementation, optionally, the version update module 430 is further configured to update the version flag bit corresponding to the other application based on the sum of the version flag bit corresponding to the first application and the first value; or, update the version flag bit corresponding to the other application based on the sum of the version flag bit corresponding to the other application and the second value.

[0170] Based on the above embodiments, optionally, each application is an application corresponding to the same microcontroller unit in the target vehicle.

[0171] The microcontroller application upgrade device provided in this disclosure can execute the steps in the microcontroller application upgrade method provided in this disclosure, and has the execution steps and beneficial effects, which will not be repeated here.

[0172] Figure 5A This is a schematic diagram of the structure of a microcontroller application upgrade system according to an embodiment of this disclosure. Figure 5A As shown: The system includes a host computer 51 and a target vehicle 52. The host computer includes a version query module 510, a trigger module 511, and an upgrade module 512. Among them;

[0173] The version query module 510 is used to obtain upgrade reference information of the target vehicle 52, wherein the upgrade reference information includes at least one of the program version of each application, the hardware version of each application, and vehicle information.

[0174] The triggering module 511 is used to determine whether to generate an upgrade command based on the upgrade reference information;

[0175] The upgrade module 512 is used to transmit upgrade data to the target vehicle;

[0176] The target vehicle 52 is configured to execute the microcontroller application upgrade method provided in any embodiment of this disclosure in response to the detection of an upgrade command.

[0177] The version query module 510 relies on the version query function provided by each application and can be used to query the software version of each application, the software version of the bootloader, the current hardware version, and the current vehicle model information. The trigger module 511 relies on the version query module 510 and can be used to determine whether to generate an upgrade command. The upgrade module 512 relies on the trigger module 511 and can transmit upgrade data to the bootloader. The version query module 510 can also perform hardware firmware compatibility checks.

[0178] In this embodiment, the target vehicle 52 may include various applications and a bootloader. For example... Figure 5B The diagram illustrates the dependencies between modules in a microcontroller application upgrade system. Specifically, the version query module sends a version query command to the application to obtain upgrade reference information from the application. Further, the triggering module determines whether to trigger the application to jump to the bootloader based on the upgrade reference information obtained from the version query module. If the application jumps to the bootloader, the upgrade module can then transmit upgrade data to the bootloader. After running, the bootloader can determine whether it is a core reset, and thus whether it is in upgrade mode. If it is in upgrade mode, it determines the application to be upgraded based on the upgrade flag bits of each application and writes the upgrade data to the corresponding storage space of that application.

[0179] The microcontroller application upgrade system provided in this disclosure enables alternating upgrades between various applications in the vehicle, reducing version differences between applications. In the event of abnormal situations such as device power failure, transmission terminal failure, or upgrade failure during the application upgrade process, other programs can be run to return to the previous version, solving the problem that the prior art cannot restore to the previous version, ensuring normal use of the device under abnormal conditions, and improving the user experience.

[0180] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. See below for details. Figure 6 It shows a schematic diagram of a structure suitable for implementing the electronic device 600 in the embodiments of this disclosure. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0181] like Figure 6As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes to implement the methods of embodiments as described in this disclosure, based on a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of electronic device 600. The processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0182] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the positioning method as described above. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0183] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0184] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to:

[0185] An upgrade command was detected, and the first application currently running on the target vehicle was determined.

[0186] Upgrade other applications besides the first application;

[0187] After the upgrade of the other applications is completed, update the version flag bit corresponding to the other applications;

[0188] Each of the aforementioned applications has a corresponding version flag, which is used to determine the application to be run next.

[0189] Optionally, when one or more of the above-described procedures are executed by the electronic device, the electronic device may also execute other steps described in the above embodiments.

[0190] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0191] Solution 1: A method for upgrading a microcontroller application, the method comprising:

[0192] An upgrade command was detected, and the first application currently running on the target vehicle was determined.

[0193] Upgrade other applications besides the first application;

[0194] After the upgrade of the other applications is completed, update the version flag bit corresponding to the other applications;

[0195] Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next.

[0196] Option 2: According to the method described in Option 1, upgrading applications other than the first application includes:

[0197] Update the upgrade flag bits for applications other than the first application, and generate a program reset command;

[0198] Based on the program reset command, upgrade the other applications;

[0199] Each of the aforementioned applications also has an upgrade flag bit, which is used to determine the application to be upgraded when the program is reset.

[0200] Option 3: According to the method described in Option 2, after updating the upgrade flag bits corresponding to applications other than the first application, the method further includes:

[0201] Access a preset storage area in the data storage unit and set the mode switching bit in the preset storage area to the identifier corresponding to the upgrade mode;

[0202] Accordingly, upgrading the other applications based on the program reset command includes:

[0203] Based on the program reset command, run the bootloader;

[0204] The bootloader determines whether the mode switching bit is the identifier corresponding to the upgrade mode. If so, it upgrades the other applications.

[0205] Solution 4: According to the method described in Solution 3, before determining whether the mode switching bit is the identifier corresponding to the upgrade mode through the bootloader, the method further includes:

[0206] The bootloader determines whether the current program reset is a power-on reset or a core reset.

[0207] If it is a core reset, then the operation of determining whether the mode switching bit is the identifier corresponding to the upgrade mode is performed.

[0208] Option 5: The method described in Option 4 further includes:

[0209] If the bootloader determines that the mode switching bit is the identifier corresponding to the hot start mode, it will jump to run the application that was last run in the target vehicle.

[0210] Option 6: According to the method described in Option 4, each application also has a corresponding presence flag bit, which is used to determine whether the application is in a runnable state or an inoperable state.

[0211] After the upgrades to the other applications are completed, the following are also included:

[0212] Update the presence flag of the other applications to indicate that the other applications are in a runnable state;

[0213] After determining whether the current program reset is a power-on reset or a core reset through the bootloader, the method further includes:

[0214] If the current program reset is a power-on reset, then the application to be run is determined based on the existence flag bit and / or version flag bit corresponding to each application.

[0215] Solution 7: The method described in any one of Solutions 6, wherein determining the application to be run based on the existence flag and / or version flag corresponding to each application includes:

[0216] For each application, obtain the preset verification code corresponding to the application, and determine the current verification code based on the upgrade flag, existence flag, and version flag corresponding to the application.

[0217] Based on the current check code and the preset check code, the flag verification result is determined, and the application whose flag verification result is verified as passed is determined as a candidate launch program.

[0218] The application to be run is determined based on the existence flag and / or version flag corresponding to each of the candidate launchers.

[0219] Solution 8: According to the method described in Solution 7, determining the application to be run based on the existence flag and / or version flag corresponding to each of the candidate launchers includes:

[0220] Based on the existence flag bit corresponding to each of the candidate launchers, the candidate launchers that are in a runnable state are determined as applications to be run.

[0221] If there are multiple applications to be run, the final application to be run is determined based on the version flag bit corresponding to each application.

[0222] Option 9: The method described in Option 2, further comprising:

[0223] If the upgrade of other applications fails, the other applications will be upgraded again based on a preset number of upgrade attempts and / or a preset waiting time.

[0224] Option 10: According to the method described in Option 2, updating the upgrade flag bits corresponding to applications other than the first application includes:

[0225] Update the upgrade flags corresponding to the other applications based on the sum of the first value and the upgrade flag corresponding to the first application; or,

[0226] The upgrade flags corresponding to the other applications are updated based on the sum of the second value and the upgrade flags corresponding to the other applications.

[0227] Option 11: According to the method described in Option 1, upgrading the other applications includes:

[0228] Obtain the interrupt vectors corresponding to the other applications, and determine the target location corresponding to the other applications in the source code storage unit based on the interrupt vectors;

[0229] Obtain upgrade data and use the upgrade data to replace the data stored in the target location.

[0230] Option 12: According to the method of Option 1, before upgrading other applications besides the first application, the method further includes:

[0231] Obtain the current firmware hardware type corresponding to the target vehicle;

[0232] Determine the firmware hardware type to be input corresponding to the upgrade command, and determine whether the upgrade conditions are met based on the current firmware hardware type and the firmware hardware type to be input. If so, perform the upgrade operation on applications other than the first application.

[0233] Solution 13: According to the method described in Solution 1, updating the version flag corresponding to the other applications includes:

[0234] Based on the sum of the version flag bit corresponding to the first application and the first value, update the version flag bits corresponding to the other applications; or,

[0235] The version flags of the other applications are updated based on the sum of the version flags of the other applications and the second value.

[0236] Option 14: According to any one of Options 1-13, each application is an application corresponding to the same microcontroller unit in the target vehicle.

[0237] Option 15: A microcontroller application upgrade device, comprising:

[0238] The execution determination module is used to detect upgrade commands and determine the first application currently running on the target vehicle;

[0239] An upgrade module is used to upgrade applications other than the first application.

[0240] The version update module is used to update the version flag bit of the other applications after the upgrade of the other applications is completed;

[0241] Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next.

[0242] Solution 16: A microcontroller application upgrade system, comprising a host computer and a target vehicle, wherein the host computer includes a version query module, a trigger module, and an upgrade module; wherein,

[0243] The version query module is used to obtain upgrade reference information for the target vehicle, wherein the upgrade reference information includes at least one of the program version of each application, the hardware version of each application, and vehicle information.

[0244] The triggering module is used to determine whether to generate an upgrade command based on the upgrade reference information;

[0245] The upgrade module is used to transmit upgrade data to the target vehicle;

[0246] The target vehicle is configured to execute the method described in any one of schemes 1-14 in response to the detection of an upgrade command.

[0247] Option 17: An electronic device, the electronic device comprising:

[0248] One or more processors;

[0249] Storage device for storing one or more programs;

[0250] When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of schemes 1-14.

[0251] Scheme 18: A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of Schemes 1-14.

[0252] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A method for upgrading a microcontroller application, characterized in that, The method includes: An upgrade command was detected, and the first application currently running on the target vehicle was determined. Update the upgrade flag bits corresponding to other applications besides the first application, access the preset storage area in the data storage unit, set the mode switching bit in the preset storage area to the identifier corresponding to the upgrade mode, and generate a program reset command. The mode switching bit is used to indicate the program reset mode, including at least the upgrade mode and the hot start mode. Based on the program reset command, run the bootloader; The bootloader determines whether the current program reset is a power-on reset or a core reset. If it is a core reset, the bootloader determines whether the mode switching bit is the identifier corresponding to the upgrade mode. If so, the other applications are upgraded. After the upgrade of the other applications is completed, update the version flag bit corresponding to the other applications; If it is a power-on reset, the application to be run is determined based on the version flag bit corresponding to each application. Each application has a version flag bit, which is used to determine the application to be run next; each application also has an upgrade flag bit, which is used to determine the application to be upgraded when the program is reset.

2. The method according to claim 1, characterized in that, The method further includes: If the bootloader determines that the mode switching bit is the identifier corresponding to the hot start mode, it will jump to run the application that was last run in the target vehicle.

3. The method according to claim 1, characterized in that, Each of the aforementioned applications also has a corresponding presence flag, which is used to determine whether the application is in a runnable or non-runnable state; After the upgrades to the other applications are completed, the following are also included: Update the presence flag of the other applications to indicate that the other applications are in a runnable state; After determining whether the current program reset is a power-on reset or a core reset through the bootloader, the method further includes: If the current program reset is a power-on reset, then the application to be run is determined based on the existence flag bit and version flag bit corresponding to each application.

4. The method according to claim 3, characterized in that, The step of determining the application to be run based on the existence flag and version flag corresponding to each application includes: For each application, obtain the preset verification code corresponding to the application, and determine the current verification code based on the upgrade flag, existence flag, and version flag corresponding to the application. Based on the current check code and the preset check code, the flag verification result is determined, and the application whose flag verification result is verified as passed is determined as a candidate launch program. The application to be run is determined based on the existence flag and version flag corresponding to each of the candidate launchers.

5. The method according to claim 4, characterized in that, The step of determining the application to be run based on the existence flag and version flag corresponding to each of the candidate launchers includes: Based on the existence flag bit corresponding to each of the candidate launchers, the candidate launchers that are in a runnable state are determined as applications to be run. If there are multiple applications to be run, the final application to be run is determined based on the version flag bit corresponding to each application.

6. The method according to claim 1, characterized in that, The method further includes: If the upgrade of other applications fails, the other applications will be upgraded again based on a preset number of upgrade attempts and / or a preset waiting time.

7. The method according to claim 1, characterized in that, The step of updating the upgrade flag bits for applications other than the first application includes: Update the upgrade flags corresponding to the other applications based on the sum of the first value and the upgrade flag corresponding to the first application; or, The upgrade flags corresponding to the other applications are updated based on the sum of the second value and the upgrade flags corresponding to the other applications.

8. The method according to claim 1, characterized in that, Upgrading the other applications includes: Obtain the interrupt vectors corresponding to the other applications, and determine the target location corresponding to the other applications in the source code storage unit based on the interrupt vectors; Obtain upgrade data and use the upgrade data to replace the data stored in the target location.

9. The method according to claim 1, characterized in that, Before upgrading other applications besides the first application, the method further includes: Obtain the current firmware hardware type corresponding to the target vehicle; Determine the firmware hardware type to be input corresponding to the upgrade command, and determine whether the upgrade conditions are met based on the current firmware hardware type and the firmware hardware type to be input. If so, perform the upgrade operation on applications other than the first application.

10. The method according to claim 1, characterized in that, Updating the version flags corresponding to the other applications includes: Based on the sum of the version flag bit corresponding to the first application and the first value, update the version flag bits corresponding to the other applications; or, The version flags of the other applications are updated based on the sum of the version flags of the other applications and the second value.

11. The method according to any one of claims 1-10, characterized in that, Each of the aforementioned applications corresponds to the same microcontroller unit in the target vehicle.

12. A microcontroller application upgrade device, characterized in that, include: The execution determination module is used to detect upgrade commands and determine the first application currently running on the target vehicle; An upgrade module is used to upgrade applications other than the first application. The version update module is used to update the version flag bit of the other applications after the upgrade of the other applications is completed; Each of the aforementioned applications has a corresponding version flag bit, which is used to determine the application to be run next. The upgrade module includes a flag update unit and a reset upgrade unit. The flag update unit is used to update the upgrade flags corresponding to applications other than the first application and generate a program reset command. The reset upgrade unit is used to upgrade the other applications based on the program reset command. Each application also has an upgrade flag, which is used to determine the application to be upgraded when the program is reset. The flag update unit is further configured to access a preset storage area in the data storage unit and set the mode switching bit in the preset storage area to the identifier corresponding to the upgrade mode; the reset upgrade unit is further configured to run a bootloader based on the program reset command; the bootloader determines whether the mode switching bit is the identifier corresponding to the upgrade mode, and if so, upgrades the other applications; the mode switching bit is used to indicate the program reset mode, including at least the upgrade mode and the hot start mode; The reset and upgrade unit is also used to determine whether the current program reset is a power-on reset or a core reset through the bootloader; if it is a core reset, it performs the operation of determining whether the mode switching bit is the identifier corresponding to the upgrade mode; if it is a power-on reset, it determines the application to be run according to the version flag bit corresponding to each application.

13. A microcontroller application upgrade system, characterized in that, This includes a host computer and a target vehicle. The host computer includes a version query module, a triggering module, and an upgrade module. The version query module is used to obtain upgrade reference information for the target vehicle, wherein the upgrade reference information includes at least one of the program version of each application, the hardware version of each application, and vehicle information. The triggering module is used to determine whether to generate an upgrade command based on the upgrade reference information; The upgrade module is used to transmit upgrade data to the target vehicle; The target vehicle is configured to execute the method of any one of claims 1-11 in response to the detection of an upgrade command.

14. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-11.

Images