MCU startup methods, devices, readable storage media, and computer program products

Abstract

This application discloses a startup method, device, readable storage medium, and computer program product for an MCU, relating to the field of MCU embedded technology. The MCU is configured with a code execution area and at least two backup areas, one containing the current latest firmware data and the other containing historically successfully booted firmware data. The method includes: upon detecting that the MCU has entered startup mode, running the firmware data in the code execution area to start the MCU; if the MCU startup is abnormal, writing the firmware data from the target backup area into the code execution area, and returning to the step of running the firmware data in the code execution area until the MCU starts normally or a preset retry termination condition is met; wherein, the target backup area is any backup area in which data has not been retried and written into the code execution area. This application improves the robustness of MCU startup.

Description

Technical Field

[0001] This application relates to the field of MCU embedded technology, and in particular to a method, device, readable storage medium and computer program product for starting up an MCU. Background Technology

[0002] An MCU (Microcontroller Unit) is a highly integrated embedded chip that integrates a processor core, memory, clock module, and various peripheral interfaces. It is widely used in low-power applications such as wearable devices and industrial controllers. Compared to high-performance processors, MCUs, with their advantages of low power consumption, real-time response, and miniaturization, have become the preferred control core for resource-constrained devices. In devices such as wearable devices, the MCU is responsible for critical functions such as sensor data acquisition, power management, and user interaction logic; its normal startup and stable operation directly determine the availability of the device.

[0003] The MCU's boot process is a critical link from hardware reset to software readiness, involving multiple stages such as power management, clock initialization, storage media access, and program loading. Typically, after power-on, the internal bootloader completes a hardware self-test and then jumps to the application entry address according to preset logic (such as partition flags and checksum verification). For low-power devices like wearables, the MCU's boot reliability directly determines the device's availability. However, in existing technologies, the MCU boot process is highly dependent on the integrity of the storage media and the stability of the operating environment. Any anomaly at any stage of the boot process (such as data corruption, hardware transients, or incorrect configuration parameters) can lead to boot failure, resulting in low robustness of the MCU boot process. For example, if the MCU encounters an abnormal interruption (such as power failure or communication failure) during an OTA (Over-The-Air Technology) upgrade, its boot process may fail due to corrupted program code or incorrect flags, preventing the device from entering a normal working state.

[0004] Therefore, how to improve the robustness of MCU startup is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The main objective of this application is to provide a method, device, readable storage medium, and computer program product for starting up an MCU, aiming to solve the technical problem of how to improve the robustness of MCU startup.

[0006] To achieve the above objectives, this application provides a method for booting an MCU, wherein the MCU is provided with a code execution area and at least two backup areas, which respectively back up the current latest version firmware data and historical successfully booted version firmware data. The MCU boot method includes the following steps:

[0007] If the MCU is detected to have entered boot mode, the firmware data in the code execution area is executed to start the MCU;

[0008] If the MCU fails to start, the firmware data in the target backup area is written into the code execution area, and the process returns to the step of running the firmware data in the code execution area until the MCU starts normally or the preset retry termination condition is met.

[0009] The target backup area is any backup area in which data has not been retried to be written to the code execution area.

[0010] In one possible implementation, prior to the step of writing firmware data from the target backup area into the code execution area, the method further includes:

[0011] If the data in each of the backup areas is not retried and written to the code execution area, then the backup area that keeps data synchronized with the code execution area is determined as the target backup area.

[0012] In one possible implementation, after the step of running the firmware data in the code execution area, the method further includes:

[0013] If the MCU starts normally, the flag value of the preset upgrade flag bit is obtained;

[0014] If the flag value is a first preset value, then the firmware data in the new version backup area is written into the code execution area, wherein the first preset value is a value indicating that the MCU needs to be upgraded with firmware, and the new version backup area is a backup area in each of the backup areas that backs up the current latest version firmware data;

[0015] Set the flag value of the preset upgrade flag bit to a second preset value, and determine that the MCU enters the startup mode, wherein the second preset value is a value indicating that the MCU does not need to perform a firmware upgrade.

[0016] In one possible implementation, after the step of obtaining the flag value of the preset upgrade flag bit, the method further includes:

[0017] If the flag value is the second preset value, then the MCU is controlled to enter the application mode.

[0018] In one possible implementation, after the step of controlling the MCU to enter application mode, the method further includes:

[0019] If a firmware upgrade instruction is received, the firmware data for the upgrade version is obtained according to the firmware upgrade instruction;

[0020] Write the upgraded firmware data into the old version backup area and set the preset upgrade flag to the first preset value. The old version backup is a backup area in each of the backup areas that has backed up the firmware data of the historically successfully started version.

[0021] After detecting that the MCU is in an idle state, it is determined that the MCU enters the startup mode.

[0022] In one possible implementation, before the step of writing the upgraded firmware data to the first backup area or the second backup area, the method further includes:

[0023] The integrity of the upgraded firmware data is verified to obtain the verification result, wherein the integrity verification includes CRC verification and / or signature verification.

[0024] If the verification result indicates that the verification passed, then the step of writing the upgraded firmware data to the old version backup area is executed.

[0025] In one possible implementation, each of the backup areas may be located in the Flash memory of the MCU or in an external memory associated with the MCU.

[0026] In addition, to achieve the above objectives, this application also provides a wearable device, the wearable device MCU, the MCU including: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the MCU startup method as described above.

[0027] In addition, to achieve the above objectives, this application also provides a readable storage medium, which is a computer-readable storage medium, on which a computer program is stored, and the computer program is executed by a processor to implement the steps of the MCU startup method as described above.

[0028] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the MCU startup method described above.

[0029] One or more technical solutions proposed in this application have at least the following technical effects:

[0030] In this application, the MCU is configured with a code execution area and at least two backup areas, one containing the latest firmware version and the other containing historically successfully booted firmware versions. When the MCU is detected to be entering boot mode, the firmware data in the code execution area is run to start the MCU. If the MCU boots abnormally, the firmware data in the target backup area is written into the code execution area, and the process returns to the step of running the firmware data in the code execution area until the MCU boots normally or a preset retry termination condition is met. The target backup area is any backup area in which data has not been retried and written into the code execution area. Thus, in this embodiment, by configuring at least two backup areas for the MCU, one containing the latest firmware version and the other containing historically successfully booted firmware versions, when the firmware data in the code execution area malfunctions, causing the MCU to boot abnormally, the firmware data in the backup areas is sequentially written into the code execution area, and the firmware data in the code execution area is re-run to restart the MCU. This ensures that even if an abnormality occurs at any stage of the MCU boot process, the MCU can still be restarted using the firmware data in the backup areas, thereby improving the robustness of the MCU boot process. Furthermore, at least one backup of the firmware data of a historically successfully booted version is configured. This ensures that even if the latest firmware version malfunctions, the firmware data of the historically successfully booted version can be used to maximize the chances of the MCU booting normally, so as to avoid affecting the user's normal use of the device, thereby further improving the robustness of the MCU boot process. Attached Figure Description

[0031] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart illustrating the first embodiment of the MCU startup method of this application;

[0034] Figure 2 This is a schematic diagram illustrating the firmware partitioning method stored in the Flash memory of the MCU according to an embodiment of the MCU startup method of this application;

[0035] Figure 3 This is a schematic diagram of the MCU upgrade process involved in one embodiment of the MCU startup method of this application;

[0036] Figure 4 This is a schematic diagram of the MCU startup process according to an embodiment of the MCU startup method of this application;

[0037] Figure 5 This is a schematic diagram of the hardware operating environment involved in the MCU startup method apparatus in this application embodiment.

[0038] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0039] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] It should be noted that the execution subject of the various embodiments of the MCU startup method of this application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or a wearable device that can realize the above functions, such as smart glasses. The various embodiments of the MCU startup method of this application do not impose specific limitations on this. For example, the various embodiments of this application are described and explained with smart glasses as the execution subject.

[0041] Based on this, this application proposes a first embodiment of an MCU startup method, wherein the MCU is provided with a code execution area and at least two backup areas, which respectively back up the current latest version firmware data and historical successfully booted version firmware data. Please refer to... Figure 1 As shown, the MCU startup method includes the following steps S10 to S20:

[0042] Step S10: If the MCU is detected to have entered the boot mode, the firmware data in the code execution area is executed to start the MCU;

[0043] MCU refers to an integrated circuit chip, specifically a complete microcomputer system that integrates a computer's CPU (Central Processing Unit), memory (including program memory and data memory), input / output interfaces, and other functional modules onto a single chip.

[0044] In this embodiment, the MCU has a Flash memory, which includes multiple firmware areas. Specifically, the multiple firmware areas include a code execution area and a bootloader area. The code execution area is used to store the firmware data currently used by the smart glasses, and the bootloader area is used to store the boot program. The boot program can jump to the code execution area and then start running the firmware data in the code execution area to start the MCU.

[0045] The MCU is configured with two backup areas, one containing the latest firmware version and the other containing firmware version data from historical successful boots. That is, the MCU is configured with at least two backup areas. For example, the MCU is configured with two backup areas (which can be referred to as the first backup area and the second backup area respectively). One backup area contains the latest firmware version and the other backup area contains firmware version data from historical successful boots. The firmware versions backed up by the two backup areas are not the same. The various embodiments of this application are described and explained accordingly.

[0046] Furthermore, to improve the space utilization of the Flash memory, the space size of each firmware partition can be adjusted based on the usage data of each firmware partition. Specifically, historical usage data of each firmware partition in the Flash memory is obtained, including historical space utilization and / or historical data update frequency. For any historical usage data, if the historical usage data meets preset adjustment conditions, the space size of the corresponding firmware partition is adjusted. These preset adjustment conditions can be conditions pre-set by relevant personnel, such as meeting any one of the following conditions: historical space utilization greater than a first preset threshold, historical space utilization less than a first preset threshold, or historical data update frequency greater than a first preset frequency. Specifically, if the space is greater than the first preset threshold or the data update frequency is greater than the first preset frequency, the space size of the firmware partition is increased; if the space is less than the first preset threshold, the space size of the firmware partition is decreased. Here, the data update frequency refers to the update frequency of data in the firmware partition.

[0047] Furthermore, a data prediction mode can be pre-trained. This mode is used to predict future usage data based on historical usage data. When the predicted future usage data meets the preset adjustment conditions, the space size of the firmware partition corresponding to the predicted usage data can be adjusted in advance to adjust the storage space size of each firmware partition in the Flash memory. This reduces the phenomenon of data writing failure due to insufficient firmware partition capacity and further improves the space utilization of the Flash memory.

[0048] It should be noted that both the first backup area and the second backup area can be located in the Flash memory, or they can be located in the external memory associated with the MCU, in order to reduce the resource consumption of the Flash memory. For example, in one specific embodiment, refer to... Figure 2 As shown, the MCU has Flash memory, which is divided into multiple firmware areas. Specifically, the Flash memory is divided into a Bootloader area, a code execution area, a first backup area, a second backup area, a LOG area, and a Factory data area. The Bootloader area stores the bootloader program, which is the first code to run when the system starts. The Bootloader is responsible for initializing the hardware, checking the system status, and determining which partition to load the application code from. The code execution area stores the currently running application code. After the Bootloader completes hardware initialization, it loads the application code from this partition and begins execution. One of the first and second backup areas contains the latest version of firmware data, while the other contains firmware data from previously successfully booted versions. The LOG area stores system operation logs, which may include error messages, system events, user operation records, etc., for system debugging and maintenance. The Factory data area stores factory settings data, such as the device's initial configuration, calibration data, serial number, etc.

[0049] Based on the above partitioning settings, when the MCU is detected to have entered boot mode, the firmware data in the code execution area is run to start the MCU.

[0050] It should be noted that the conditions for the MCU to enter the boot mode can be preset, so that the MCU enters the boot mode when the condition is detected. For example, in a specific embodiment, the MCU is determined to enter the boot mode when it is detected that it meets any of the following conditions: power-on reset, software reset, hardware reset, watchdog timeout, firmware upgrade flag indicating firmware upgrade, abnormal event detection, or user restart. Among them, power-on reset refers to the MCU being powered on for the first time or re-powered, at which time the power management module generates a reset signal; software reset refers to the MCU's application actively calling a software reset instruction, or receiving an external reset command through a preset communication interface; hardware reset refers to the MCU's reset pin detecting a low-level pulse signal or a continuous low level for more than a threshold duration; watchdog timeout refers to the MCU's hardware watchdog counter overflowing and not being refreshed by the application within a preset time; firmware upgrade flag indicating firmware upgrade refers to the firmware upgrade completion flag in the MCU's storage medium being set, and the upgraded firmware passing integrity verification; abnormal event detection refers to the MCU detecting at least one of the following abnormal events during operation: critical peripheral initialization failure, stack overflow, or firmware checksum error; user restart refers to the user requesting a restart of the device.

[0051] Step S20: If the MCU startup is abnormal, the firmware data in the target backup area is written into the code execution area, and the process returns to the step of running the firmware data in the code execution area until the MCU starts normally or the preset retry termination condition is met. The target backup area is any backup area in the code execution area where the data in each backup area has not been retried and written into the code execution area.

[0052] If the MCU startup fails, the firmware data in the target backup area is written to the code execution area. The target backup area is any backup area from which data has not been retried for writing to the code execution area. It should be noted that retrying write refers to writing firmware data from the backup area to the code execution area when the MCU startup fails, in order to write data when restarting the MCU. It should also be noted that the retry write order between the first and second backup areas can be preset to ensure orderly retry of data writing. For example, firmware data from the backup area containing the latest firmware version can be written to the code execution area first. If a startup failure occurs again, firmware data from the backup area containing historically successfully booted firmware versions can then be written to the code execution area, ensuring that the latest firmware version is tested first to determine if it can function correctly.

[0053] After writing the firmware data backed up in the target backup area into the code execution area, the firmware data in the code execution area is run again. Specifically, the MCU can be restarted after the firmware data is written into the code execution area, that is, the MCU is controlled to enter the boot mode again so as to run the firmware data written into the code execution area in the current boot process.

[0054] The specific termination condition for the preset retry can be a termination condition set in advance by relevant personnel, such as the number of retries being greater than or equal to the total number of backup areas, the code runtime being greater than or equal to the preset duration, etc. This embodiment does not impose specific restrictions on this.

[0055] In this embodiment, the MCU is configured with a code execution area and at least two backup areas, one containing the latest firmware version and the other containing historically successfully booted firmware versions. When the MCU is detected to have entered boot mode, the firmware data in the code execution area is run to start the MCU. If the MCU boots abnormally, the firmware data in the target backup area is written into the code execution area, and the process returns to the step of running the firmware data in the code execution area until the MCU boots normally or a preset retry termination condition is met. The target backup area is any backup area in which data has not been retried and written into the code execution area. Thus, in this embodiment, by configuring at least two backup areas for the MCU, one containing the latest firmware version and the other containing historically successfully booted firmware versions, when the firmware data in the code execution area malfunctions, causing an MCU boot failure, the firmware data in the backup areas is sequentially written into the code execution area, and the firmware data in the code execution area is re-run to restart the MCU. This ensures that even if an abnormality occurs at any stage of the MCU boot process, the MCU can still be restarted using the firmware data in the backup areas, thereby improving the robustness of the MCU boot process. Furthermore, at least one backup of the firmware data of a historically successfully booted version is configured. This ensures that even if the latest firmware version malfunctions, the firmware data of the historically successfully booted version can be used to maximize the chances of the MCU booting normally, so as to avoid affecting the user's normal use of the device, thereby further improving the robustness of the MCU boot process.

[0056] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, before the step of writing the firmware data in the target backup area into the code execution area, the method further includes:

[0057] Step A10: If the data in each of the backup areas has not been retried to be written to the code execution area, then the backup area that keeps data synchronized with the code execution area is determined as the target backup area.

[0058] It should be noted that the firmware data in the code execution area can be recorded from which backup area it originates from, that is, which backup area is kept in sync with the code execution area. In the event of an initial MCU startup failure, the firmware data in the backup area that is kept in sync with the code execution area will be written to the code execution area first. In other words, the firmware data in the code execution area will be restored from the backup area first, so as to reduce the occurrence of MCU startup abnormalities due to data corruption in the code execution area.

[0059] It is understandable that after each successful MCU upgrade, the backup area containing the latest firmware data (i.e., the firmware data of this upgrade version) can be recorded as a backup area that keeps data synchronized with the code execution area.

[0060] In one possible implementation, after the step of running the firmware data in the code execution area, the method further includes:

[0061] Step B10: If the MCU starts normally, obtain the flag value of the preset upgrade flag bit;

[0062] This preset upgrade flag indicates whether the MCU needs a firmware upgrade. Typically, upon receiving an upgrade command, the application sets the upgrade flag. When the MCU restarts, the bootloader checks that the upgrade flag is set and then executes the upgrade process. After the upgrade is complete, the upgrade flag usually needs to be cleared or modified to indicate that the upgrade process is finished, allowing the MCU to boot and run the application normally.

[0063] Step B20: If the flag value is a first preset value, then write the firmware data in the new version backup area into the code execution area, wherein the first preset value is a value indicating that the MCU needs to be upgraded with firmware, and the new version backup area is a backup area in each of the backup areas that backs up the current latest version firmware data.

[0064] If the flag value at the preset upgrade flag bit is the first preset value, then the firmware data in the new version backup area is written to the code execution area to restart the MCU based on the latest version firmware data and upgrade the MCU. The first preset value is a value (such as 1) that indicates that the MCU needs to be upgraded.

[0065] Step B30: Set the flag value of the preset upgrade flag bit to a second preset value, and determine that the MCU enters the startup mode, wherein the second preset value is a value indicating that the MCU does not need to be upgraded.

[0066] After writing the firmware data from the new version backup area into the code execution area, the flag value of the preset upgrade flag bit is set to the second preset value. The second preset value is a value (such as 0) that indicates that the MCU does not need to be upgraded. Specifically, the flag value of the preset upgrade flag bit can be set to the second preset value by modifying or clearing the preset upgrade flag bit.

[0067] Furthermore, after writing the firmware data from the new version backup area into the code execution area, the MCU is determined to enter the boot mode to restart the MCU based on the latest version firmware data and upgrade the MCU.

[0068] In one possible implementation, after the step of obtaining the flag value of the preset upgrade flag bit, the method further includes:

[0069] Step C10: If the flag value is a second preset value, then control the MCU to enter the application mode.

[0070] If the flag value indicates that the MCU does not need to be upgraded, it means that the firmware data has not been updated. At this time, the MCU is controlled to enter the application (APP) mode. In APP mode, the MCU will run the application code written by the user, and implement the specific functions of the device through these codes, such as data processing, user interface interaction, sensor reading, network communication, etc.

[0071] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, after the step of controlling the MCU to enter the application mode, the method further includes:

[0072] Step D10: If a firmware upgrade instruction is received, obtain the firmware data for the upgrade version according to the firmware upgrade instruction;

[0073] After the MCU enters application mode, if it receives a firmware upgrade command, it retrieves the firmware data for the upgraded version based on the command. This can be understood as retrieving the firmware data from a server (such as an OTA server).

[0074] Step D20: Write the firmware data of the upgraded version into the old version backup area and set the preset upgrade flag to the first preset value. The old version backup is the backup area in each of the backup areas that has backed up the firmware data of the historical successfully started version.

[0075] After obtaining the upgraded firmware data, the upgraded firmware data is written to the old version backup area. Specifically, if the firmware data backed up in the new version backup area has successfully booted the MCU, then the upgraded firmware data is written to the old version backup area. The old version backup area is the backup area that has backed up the firmware data of the previously successfully booted version. It can be understood that after the upgraded firmware data is written to the old version backup area, the old version backup area will now contain the latest version firmware data, thus switching to the new version backup area. The original new version backup area will then contain the backup area that has backed up the previously successfully booted version, thus switching to the old version backup area. For example, assuming that before receiving the firmware upgrade command, the first backup area is the new version backup area, which contains the firmware data of the latest version (such as version V2.2), and the second backup area is the old version backup area, which contains the firmware data of the previously successfully booted version (such as version V2.0). After receiving the firmware upgrade command, assuming that the obtained firmware data for the upgrade version is version V2.3, if the firmware data of version V2.2 has successfully booted the MCU, the firmware data of version V2.3 can be written to the second backup area. At this time, the second backup area is switched to the new version backup area, and the first backup area is switched to the old version backup area.

[0076] Furthermore, if the firmware data backed up in the new version backup area has failed to successfully boot the MCU, it indicates that the firmware data for that version is invalid. In this case, the firmware data for the upgraded version can be written to the new version backup area. For example, assuming that in the above example, if the firmware data for version V2.2 has failed to successfully boot the MCU, the firmware data for version V2.3 can be written to the first backup area. At this time, the first backup area is still the new version backup area, and the second backup area is still the old version backup area.

[0077] Step D30: After detecting that the MCU is in an idle state, determine that the MCU enters the startup mode.

[0078] After successfully writing the upgraded firmware data to the backup area and setting the preset upgrade flag to the first preset value indicating that the MCU needs to be upgraded, if the MCU is detected to be in an idle state, it is determined that the MCU enters the startup mode so that when the MCU is in an idle state, the MCU is started based on the upgraded firmware data to upgrade the MCU firmware.

[0079] In one possible implementation, before the step of writing the upgraded firmware data to the first backup area or the second backup area, the method further includes:

[0080] Step E10: Perform integrity verification on the upgraded firmware data to obtain the verification result, wherein the integrity verification includes CRC verification and / or signature verification.

[0081] Integrity verification refers to verifying whether the received firmware data is consistent with the firmware data sent by the server. Specifically, integrity verification includes, but is not limited to, CRC (Cyclic Redundancy Check) verification and / or signature verification. It may also include parity check, BCC (Block Check Character), MD5 (Message Digest Algorithm version 5), etc. Relevant personnel can set specific integrity verification methods based on actual needs. This embodiment does not impose specific limitations on this.

[0082] Step E20: If the verification result indicates that the verification passed, then the step of writing the firmware data of the upgraded version to the old version backup area is executed.

[0083] If the verification passes, the received firmware data for the upgrade version will be written to the backup area; otherwise, if the verification fails, the upgrade failure will be reported to the server.

[0084] For example, to aid in understanding the technical concept or principle of the MCU startup method combined with the first and second embodiments described above, a specific embodiment is listed below. In this specific embodiment, the MCU startup method is applied to smart glasses. The MCU in the smart glasses is connected to a mobile phone via Wi-Fi and / or Bluetooth (BT) signals. The user can interact with the smart glasses through a specific interactive APP on the mobile phone, which is essentially interacting with the MCU in the smart glasses. The user can interact with the MCU through this interactive APP to trigger the upgrade process. The APP communicates with the MCU via Wi-Fi or Bluetooth, sends upgrade commands, and receives upgrade status. The mobile phone is connected to an OTA server, which is responsible for storing firmware upgrade packages, managing the upgrade process, sending upgrade commands, and receiving status reports. The MCU contains multiple modules responsible for handling different stages of the upgrade process, specifically including a strategy parsing module, a download module, an upgrade module, and an exception handling module. The strategy parsing module is used to analyze the upgrade strategy and decide whether to perform an upgrade. The download module is used to download new firmware upgrade packages from the OTA server. The upgrade module is used to write the downloaded firmware into the MCU's memory (such as NOR flash memory). The exception handling module is used to handle errors or abnormal situations that may occur during the upgrade process. The MCU can report its current version number and device identification information to the OTA server, allowing the OTA server to check for upgrade information. If an upgrade is available, the OTA server returns the upgrade information, which may include whether a new version is available. If a new version is available, the MCU downloads the upgrade package from the OTA server, initiates the upgrade process based on the downloaded package, and reports the upgrade result to the OTA server, including whether the upgrade was successful. The firmware partitioning of the NOR flash memory in the MCU is as follows: Figure 2 As shown, based on this, refer to Figure 4 As shown, the MCU startup process includes:

[0085] After the MCU enters boot mode, it first enters the Bootloader area in the flash memory. The bootloader then jumps to the code execution area and begins running the firmware data in the code execution area to start the MCU. If the MCU fails to boot, the firmware data in the backup area is written to the code execution area. Specifically, after the MCU is upgraded, it needs to record which backup area (referred to as backup area 1) the current boot code comes from. If the MCU fails to boot, the firmware data in the currently recorded boot backup area is written to the code execution area, and then the MCU is restarted. If the boot still fails, the firmware data from another code backup area (referred to as backup area 2) is written to the code execution area, and the current boot area record is updated to backup area 2, and then the MCU is rebooted. If the MCU boots successfully, it checks whether the upgrade flag is set.

[0086] If the upgrade flag is not set, the system enters APP mode. If the upgrade flag is set, the upgrade flag is cleared, and the firmware data in the backup area is written to the code execution area. Specifically, the firmware data in the backup area containing the latest version of firmware is written to the code execution area, and then the MCU is restarted.

[0087] After entering APP mode, if an upgrade command is received, the upgrade package (i.e., firmware data of the upgrade version) sent by the OTA server is received and stored in the corresponding backup area. The received upgrade package is subjected to CRC check and upgrade package signature verification. If the verification fails, the upgrade failure is reported to the OTA server. If the verification is successful, the upgrade flag is set and the MCU is restarted.

[0088] It should be noted that the above examples are only used to help understand this embodiment and do not constitute a limitation on the startup process of the MCU in this embodiment. Any simple modifications based on this technical concept are within the protection scope of this application.

[0089] Furthermore, this application also proposes a boot device, which is deployed in an MCU. The MCU has a code execution area and at least two backup areas, which respectively back up the current latest version firmware data and historical successfully booted version firmware data. The boot device includes:

[0090] The running module is used to run the firmware data in the code execution area to start the MCU when the MCU is detected to have entered the boot mode;

[0091] The retry module is used to write the firmware data in the target backup area into the code execution area if the MCU startup is abnormal, and return to the step of executing the firmware data in the code execution area until the MCU starts normally or the preset retry end condition is met.

[0092] The target backup area is any backup area in which data has not been retried to be written to the code execution area.

[0093] In one embodiment, the retry module is further configured to:

[0094] If the data in each of the backup areas is not retried and written to the code execution area, then the backup area that keeps data synchronized with the code execution area is determined as the target backup area.

[0095] In one embodiment, the startup device further includes an upgrade module for:

[0096] If the MCU starts normally, the flag value of the preset upgrade flag bit is obtained;

[0097] If the flag value is a first preset value, then the firmware data in the new version backup area is written into the code execution area, wherein the first preset value is a value indicating that the MCU needs to be upgraded with firmware, and the new version backup area is a backup area in each of the backup areas that backs up the current latest version firmware data;

[0098] Set the flag value of the preset upgrade flag bit to a second preset value, and determine that the MCU enters the startup mode, wherein the second preset value is a value indicating that the MCU does not need to perform a firmware upgrade.

[0099] In one embodiment, the upgrade module is further configured to:

[0100] If the flag value is the second preset value, then the MCU is controlled to enter the application mode.

[0101] In one embodiment, the upgrade module is further configured to:

[0102] If a firmware upgrade instruction is received, the firmware data for the upgrade version is obtained according to the firmware upgrade instruction;

[0103] Write the upgraded firmware data into the old version backup area and set the preset upgrade flag to the first preset value. The old version backup is a backup area in each of the backup areas that has backed up the firmware data of the historically successfully started version.

[0104] After detecting that the MCU is in an idle state, it is determined that the MCU enters the startup mode.

[0105] In one embodiment, the upgrade module is further configured to:

[0106] The integrity of the upgraded firmware data is verified to obtain the verification result, wherein the integrity verification includes CRC verification and / or signature verification.

[0107] If the verification result indicates that the verification passed, then the step of writing the upgraded firmware data to the old version backup area is executed.

[0108] In one embodiment, each of the backup areas may be located in the Flash memory of the MCU or in an external memory associated with the MCU.

[0109] Furthermore, this application also proposes a wearable device, which includes an MCU. The MCU includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the MCU startup method described above.

[0110] refer to Figure 5 The diagram illustrates a structural schematic suitable for implementing wearable devices according to embodiments of this application. Wearable devices in embodiments of this application may also include, but are not limited to, smart glasses, virtual reality glasses, virtual reality helmets, extended reality glasses, extended reality helmets, headphones, etc. Figure 5 The wearable device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0111] like Figure 5As shown, the wearable device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the wearable device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the wearable device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show wearable devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0112] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0113] The wearable device provided in this application adopts the MCU startup method in the above embodiments, which can solve the technical problem of how to improve the robustness of MCU startup. Compared with the prior art, the beneficial effects of the wearable device provided in this application are the same as the beneficial effects of the MCU startup method provided in the above embodiments, and other technical features in the wearable device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0114] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] In addition, to achieve the above objectives, this application embodiment also provides a readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the MCU startup method in the above embodiments.

[0117] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0118] The aforementioned computer-readable storage medium may be included in a wearable device; or it may exist independently and not incorporated into a wearable device.

[0119] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a wearable device, the wearable device: upon detecting that the MCU has entered startup mode, runs firmware data in the code execution area to start the MCU; if the MCU startup is abnormal, writes firmware data from the target backup area into the code execution area and returns to the step of running the firmware data in the code execution area until the MCU starts normally or a preset retry termination condition is met; wherein, the target backup area is any backup area in which data has not been retried and written into the code execution area.

[0120] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the modules themselves.

[0123] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described MCU startup method, thereby solving the technical problem of how to improve the robustness of MCU startup. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the MCU startup method provided in the above embodiments, and will not be repeated here.

[0124] Furthermore, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the steps of the MCU startup method described above.

[0125] The specific implementation method of the computer program product in this application is basically the same as the various embodiments of the above-mentioned MCU startup method, and will not be described again here.

[0126] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0127] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software sensor. This computer software sensor is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0129] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for starting up an MCU, characterized in that, The MCU is equipped with a code execution area and at least two backup areas, one containing the current latest firmware version data and the other containing historical successfully booted firmware version data. The MCU boot method includes the following steps: If the MCU is detected to have entered boot mode, the firmware data in the code execution area is executed to start the MCU; If the MCU fails to start, the firmware data in the target backup area is written into the code execution area, and the process returns to the step of running the firmware data in the code execution area until the MCU starts normally or the preset retry termination condition is met. The target backup area is any backup area in which data has not been retried to be written to the code execution area.

2. The MCU startup method as described in claim 1, characterized in that, Before the step of writing the firmware data from the target backup area to the code execution area, the method further includes: If the data in each of the backup areas is not retried and written to the code execution area, then the backup area that keeps data synchronized with the code execution area is determined as the target backup area.

3. The MCU startup method as described in claim 1, characterized in that, After the step of running the firmware data in the code execution area, the method further includes: If the MCU starts normally, the flag value of the preset upgrade flag bit is obtained; If the flag value is a first preset value, then the firmware data in the new version backup area is written into the code execution area, wherein the first preset value is a value indicating that the MCU needs to be upgraded with firmware, and the new version backup area is a backup area in each of the backup areas that backs up the current latest version firmware data; Set the flag value of the preset upgrade flag bit to a second preset value, and determine that the MCU enters the startup mode, wherein the second preset value is a value indicating that the MCU does not need to perform a firmware upgrade.

4. The MCU startup method as described in claim 3, characterized in that, After the step of obtaining the flag value of the preset upgrade flag bit, the method further includes: If the flag value is the second preset value, then the MCU is controlled to enter the application mode.

5. The MCU startup method as described in claim 4, characterized in that, After the step of controlling the MCU to enter application mode, the method further includes: If a firmware upgrade instruction is received, the firmware data for the upgrade version is obtained according to the firmware upgrade instruction; Write the upgraded firmware data into the old version backup area and set the preset upgrade flag to the first preset value. The old version backup is a backup area in each of the backup areas that has backed up the firmware data of the historically successfully started version. After detecting that the MCU is in an idle state, it is determined that the MCU enters the startup mode.

6. The MCU startup method as described in claim 5, characterized in that, Before the step of writing the upgraded firmware data to the first backup area or the second backup area, the method further includes: The integrity of the upgraded firmware data is verified to obtain the verification result, wherein the integrity verification includes CRC verification and / or signature verification. If the verification result indicates that the verification passed, then the step of writing the upgraded firmware data to the old version backup area is executed.

7. The MCU startup method according to any one of claims 1 to 6, characterized in that, Each of the backup areas can be located in the Flash memory of the MCU, or in an external memory associated with the MCU.

8. A wearable device, characterized in that, The device includes an MCU, the MCU including a memory, a processor, and a startup program of the MCU stored in the memory and executable on the processor, the startup program of the MCU being configured to implement the steps of the MCU startup method as described in any one of claims 1 to 7.

9. A readable storage medium, characterized in that, The readable storage medium includes a computer-readable storage medium storing a startup program for an MCU, which, when executed by a processor, implements the steps of the MCU startup method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a startup program for an MCU, which, when executed by a processor, implements the steps of the MCU startup method as described in any one of claims 1 to 7.

Images