OTA upgrade method and device, electronic device, and storage medium

CN122593813APending Publication Date: 2026-08-18FIBOCOM WIRELESS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610655120.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-05-12
Publication Date
2026-08-18

AI Technical Summary

Technical Problem

[0005]本申请提供了一种OTA升级方法和装置、电子设备和存储介质,以至少解决相关技术中存在效率低下且操作步骤繁琐的技术问题

Benefits of technology

[0015] In this embodiment, an upgrade package for OTA upgrade of a mobile terminal device is obtained, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; the target MCU version of the MCU upgrade package is determined; if the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device; the SoC upgrade of the mobile terminal device is performed according to the SoC upgrade package; and the OTA upgrade of the mobile terminal device is completed upon obtaining successful upgrade information from the MCU board and confirming the successful SoC upgrade. By automatically comparing whether the MCU upgrade package needs to be upgraded, invalid upgrades can be effectively avoided, and upgrade efficiency can be improved. In addition, the entire upgrade process does not require manual intervention, thereby achieving the goal of rapid upgrade. This achieves the technical effect of effectively improving upgrade efficiency and simplifying upgrade operations, thus solving the technical problems of low efficiency and cumbersome operation steps in related technologies.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122593813A_ABST
    Figure CN122593813A_ABST
Patent Text Reader

Abstract

This application provides an OTA upgrade method, apparatus, electronic device, and storage medium for a mobile terminal device. The method includes: obtaining an upgrade package for OTA upgrading the mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; determining the target MCU version of the MCU upgrade package; if the MCU upgrade package meets preset upgrade requirements based on the target MCU version, sending the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device; performing a SoC upgrade on the mobile terminal device according to the SoC upgrade package; and completing the OTA upgrade of the mobile terminal device upon receiving successful upgrade information from the MCU board and confirming the successful SoC upgrade. This application solves the technical problems of low efficiency and cumbersome operation steps existing in related technologies.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of OTA upgrade technology, and in particular to an OTA upgrade method and apparatus, electronic device and storage medium. Background Technology

[0002] Mobile terminal devices (such as lawnmower robots), as autonomous devices operating outdoors for extended periods, require continuous iteration of their software systems (including SoC application systems, MCU firmware, etc.) to fix vulnerabilities, improve performance, or add functionality. Traditional device upgrade methods have many limitations: 1. Traditional Solution 1: Equipment needs to be sent back to the manufacturer or service center for firmware flashing by professionals using specialized tools (such as JTAG or ISP programmers). This method is time-consuming, costly, and inefficient, severely impacting user experience and product maintenance efficiency.

[0003] 2. Traditional Solution Two: Manual Local Upgrade. Users download the upgrade package from the official website, copy it to the device via USB flash drive or SD card, and perform a series of complex manual operations (such as entering recovery mode, selecting files, and confirming the upgrade). This method requires a high level of technical skill from the user, involves cumbersome steps, and is prone to upgrade failure or even device bricking due to operational errors.

[0004] This shows that the relevant technologies suffer from inefficiency and cumbersome operation procedures. Summary of the Invention

[0005] This application provides an OTA upgrade method and apparatus, electronic device and storage medium to at least solve the technical problems of low efficiency and cumbersome operation steps in related technologies.

[0006] According to one aspect of the embodiments of this application, an OTA upgrade method is provided, including: Obtain an upgrade package for OTA upgrade of a mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; Determine the target MCU version for the MCU upgrade package; If the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device; The mobile terminal device is upgraded using the SoC upgrade package. Upon receiving successful upgrade information from the MCU board and confirming the successful SoC upgrade, the OTA upgrade of the mobile terminal device is completed.

[0007] Optionally, as described above, obtaining the SoC upgrade package and MCU upgrade package from the upgrade package includes: Check if the decompression directory pointed to by the decompression path of the upgrade package is empty; If the decompression directory of the upgrade package is determined to be non-empty, the historical version information on the decompression directory is retained, the decompression directory is cleared, and the upgrade package is decompressed to the decompression directory to obtain the SoC upgrade package and the MCU upgrade package located in the decompression directory. The historical version information includes the historical MCU version of the historical MCU upgrade package. If the decompression directory of the upgrade package is found to be empty, the upgrade package is decompressed to the decompression directory to obtain the SoC upgrade package and the MCU upgrade package located in the decompression directory.

[0008] Optionally, as described above, determining the target SoC version of the SoC upgrade package and the target MCU version of the MCU upgrade package includes: The target MCU version is obtained by parsing the upgrade package according to the parsing method corresponding to the upgrade package.

[0009] Optionally, as described above, obtaining the upgrade package for OTA upgrade of the mobile terminal device includes one of the following: The removable terminal device is subjected to removable storage medium detection; if a target removable storage medium connected to the removable terminal device is detected, an inspection operation is performed on the target removable storage medium; the upgrade package is obtained from the target removable storage medium through the inspection operation; Download the upgrade package to the specified path via online access. Optionally, as described above, sending the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device includes: If the number of times the following steps are executed in a loop is within the target number, and the MCU upgrade package is successfully sent to the MCU board, the MCU board will update according to the MCU upgrade package; otherwise, the MCU board update will be stopped. The MCU upgrade package is split into multiple data packets of a preset size; If each of the plurality of data packets is successfully sent to the MCU board in sequence within a preset number of times through a sequential sending operation, it is determined that the MCU upgrade package has been successfully sent to the MCU board, so that the MCU board can be updated according to the MCU upgrade package; In the sequential sending operation, if a specified data packet fails to be sent among the multiple data packets, the sending of the specified data packet to the MCU board is stopped, and the update of the MCU board is exited. The specified data packet is the data packet that has failed to be sent to the MCU board within a preset limit of attempts.

[0010] Optionally, as described above, the method for determining that the data packet was successfully sent to the MCU board includes: After sending the data packet to the MCU board, wait for feedback information from the MCU board, wherein the feedback information is used to indicate that the MCU board has successfully acquired the data packet; If feedback information is received from the MCU board before the deadline for sending the data packet within a preset time period, it is determined that the data packet was successfully sent.

[0011] Optionally, as described above, after obtaining the upgrade package from the target removable storage medium through the inspection operation, the method further includes: If the inspection operation determines that no upgrade package exists in the target removable storage medium, then check whether a target flag file exists in the target removable storage medium. If it is determined that a target flag file exists in the target removable storage medium, the flag bit corresponding to the target flag file is reset after the target flag file is executed.

[0012] According to another aspect of the embodiments of this application, a mobile terminal device OTA upgrade apparatus is also provided, comprising: An acquisition module is used to acquire an upgrade package for OTA upgrade of a mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; The determination module is used to determine the target MCU version of the MCU upgrade package; The sending module is used to send the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device when it is determined that the MCU upgrade package meets the preset upgrade requirements based on the target MCU version. The SoC upgrade module is used to upgrade the SoC of the mobile terminal device according to the SoC upgrade package. The execution module is used to complete the OTA upgrade of the mobile terminal device when the successful upgrade information fed back by the MCU board is obtained and the SoC upgrade is successful.

[0013] According to another aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein the memory is used to store a computer program; and the processor is used to execute the method steps of any of the above embodiments by running the computer program stored in the memory.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the method steps of any of the above embodiments when running.

[0015] In this embodiment, an upgrade package for OTA upgrade of a mobile terminal device is obtained, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; the target MCU version of the MCU upgrade package is determined; if the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device; the SoC upgrade of the mobile terminal device is performed according to the SoC upgrade package; and the OTA upgrade of the mobile terminal device is completed upon obtaining successful upgrade information from the MCU board and confirming the successful SoC upgrade. By automatically comparing whether the MCU upgrade package needs to be upgraded, invalid upgrades can be effectively avoided, and upgrade efficiency can be improved. In addition, the entire upgrade process does not require manual intervention, thereby achieving the goal of rapid upgrade. This achieves the technical effect of effectively improving upgrade efficiency and simplifying upgrade operations, thus solving the technical problems of low efficiency and cumbersome operation steps in related technologies. Attached Figure Description

[0016] 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.

[0017] 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.

[0018] Figure 1 This is a schematic diagram of the hardware environment for an optional OTA upgrade method according to an embodiment of this application; Figure 2 This is a flowchart illustrating an optional OTA upgrade method according to an embodiment of this application; Figure 3 This is a flowchart illustrating another optional OTA upgrade method according to an embodiment of this application; Figure 4 This is a flowchart illustrating another optional OTA upgrade method according to an embodiment of this application; Figure 5 This is a schematic diagram of the core upgrade process in an optional OTA upgrade method according to an embodiment of this application; Figure 6 This is a schematic diagram of an MCU upgrade sub-process in another optional OTA upgrade method according to an embodiment of this application; Figure 7 This is a schematic diagram of an offline upgrade process in another optional OTA upgrade method according to an embodiment of this application; Figure 8 This is a structural block diagram of an optional OTA upgrade device according to an embodiment of this application; Figure 9 This is a structural block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows: 1. OTA: Over-The-Air, refers to data or software updates via wireless network.

[0022] 2. SoC: System on a Chip, refers to the main application processor system of a device.

[0023] 3. MCU: Microcontroller Unit, refers to the microcontroller in a device that is responsible for controlling the underlying hardware (such as motors and sensors).

[0024] 4. Bin file: A binary file, usually referring to the executable firmware file of a microcontroller.

[0025] 5. MD5: Message-Digest Algorithm 5, a widely used cryptographic hash function for verifying file integrity.

[0026] 6. Glog: A global logging system used to record critical events during system operation and upgrades.

[0027] According to one aspect of the embodiments of this application, an OTA upgrade method is provided. Optionally, in this embodiment, the above-described OTA upgrade method can be applied to, for example... Figure 1 The hardware environment shown consists of terminal 1402 and server 1404. For example... Figure 1 As shown, server 1404 is connected to terminal 1402 via a network and can be used to provide services (such as game services, application services, etc.) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 1404.

[0028] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal may not be limited to PC, mobile phone, tablet computer, etc.

[0029] The OTA upgrade method of this application embodiment can be executed by a server, a terminal, or both. Alternatively, the OTA upgrade method of this application embodiment can be executed by a client installed on the terminal.

[0030] Taking the OTA upgrade method in this embodiment as an example, Figure 2 An OTA upgrade method provided in this application includes the following steps: Step S202: Obtain an upgrade package for OTA upgrade of the mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package.

[0031] The OTA upgrade method in this embodiment can be applied to scenarios involving OTA upgrades of smart mobile terminal devices. This embodiment uses a software upgrade scenario for a SoC and / or MCU as an example to illustrate the above-described OTA upgrade method for mobile terminal devices. For other types of software (e.g., upgrades of a specific application software), the above-described OTA upgrade method for mobile terminal devices is equally applicable, provided there is no contradiction. Optionally, the mobile terminal device can be a lawnmower robot, a humanoid robot, a robotic vacuum cleaner, etc. The upgrade package can be an OTA upgrade package downloaded to the mobile terminal device from the network or an OTA upgrade package downloaded to a mobile storage medium for upgrading the mobile terminal device.

[0032] Specifically, the method of this embodiment can be implemented through the SoC upgrade module on the SoC. For mobile terminal devices, they can obtain OTA upgrade packages online or offline. These upgrade packages are data packets used to upgrade the SoC or MCU of the mobile terminal device. That is, the upgrade package can be pre-downloaded to other storage media and then obtained by the mobile terminal device from those media, or it can be directly downloaded via the network if the mobile terminal device has network connectivity.

[0033] Specifically, the OTA (Over-The-Air) update may contain a compressed package, which includes a SoC upgrade package for upgrading the entire SoC system and / or applications, and an MCU upgrade package for upgrading the MCU firmware. The SoC upgrade module can decompress the upgrade package to obtain the SoC upgrade package and the MCU upgrade package.

[0034] Step S204: Determine the target MCU version of the MCU upgrade package.

[0035] Specifically, the SoC upgrade module can determine the target MCU version of the MCU upgrade package based on the version information file carried in the upgrade package that indicates the MCU upgrade package, or it can determine the target MCU version based on the version information carried in the MCU upgrade package itself.

[0036] Step S208: If the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device.

[0037] Specifically, after determining the target MCU version, the SoC upgrade module checks whether the current MCU firmware needs an upgrade by comparing the target MCU version with the current MCU version. If the target MCU version does not match the current MCU version, the current MCU firmware needs an upgrade; otherwise, no upgrade is required. Alternatively, the module can also check whether the system and / or applications installed on the current SoC need an upgrade by comparing the target SoC version with the current SoC version. If the target SoC version does not match the current SoC version, an upgrade is required; otherwise, no upgrade is required.

[0038] Once the SoC upgrade module determines that the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, it sends the MCU upgrade package to the MCU board to update the firmware (.bin file) of the MCU board of the mobile terminal device.

[0039] Step S210: Upgrade the SoC of the mobile terminal device according to the SoC upgrade package.

[0040] Specifically, since it is known that the SoC needs to be upgraded, the SoC upgrade module, after obtaining the SoC upgrade package, can update the entire system and / or applications of the mobile terminal device based on the SoC upgrade package. Optionally, the SoC upgrade can be implemented by calling a system upgrade command, and then waiting for the command to complete. After the upgrade command is successfully executed, the mobile terminal device automatically restarts. After restarting, the version information in the configuration file directory (i.e., the version information corresponding to the upgraded SoC) can be verified through the upgrade manager of the mobile terminal device, and the success of the SoC upgrade can be confirmed by comparing the compilation time (i.e., the time when the SoC upgrade was completed).

[0041] Step S212: Upon receiving successful upgrade information from the MCU board and confirming successful SoC upgrade, complete the OTA upgrade of the mobile terminal device.

[0042] In other words, after the MCU board is successfully upgraded, the MCU board will send back the corresponding successful upgrade information as a result to the SoC upgrade module. At the same time, if the SoC upgrade is successful, it can be determined that the mobile terminal device has completed the OTA upgrade.

[0043] In this embodiment, the method involves: obtaining an upgrade package for OTA upgrade of a mobile terminal device; obtaining a SoC upgrade package and an MCU upgrade package from the upgrade package; determining the target SoC version of the SoC upgrade package and the target MCU version of the MCU upgrade package; if the SoC upgrade package and the MCU upgrade package meet the preset upgrade requirements based on the target MCU version, sending the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device; performing a SoC upgrade on the mobile terminal device according to the SoC upgrade package; and completing the OTA upgrade of the mobile terminal device upon obtaining successful upgrade information from the MCU board and confirming a successful SoC upgrade. By automatically verifying the MOC (Modular Value Conversion), and by comparing the versions of the SoC upgrade package and the MCU upgrade package to determine whether an upgrade is needed, invalid upgrades can be effectively avoided, and upgrade efficiency can be improved. Furthermore, the entire upgrade process requires no manual intervention, thus achieving rapid upgrades. This effectively improves upgrade efficiency and simplifies upgrade operations, thereby solving the technical problems of low efficiency and cumbersome operation steps in related technologies.

[0044] like Figure 3 As shown, as an optional implementation, the method described above can be used to obtain the SoC upgrade package and MCU upgrade package from the upgrade package through the following steps: Step S302: Check if the decompression directory pointed to by the decompression path of the upgrade package is empty. Specifically, you can check the status of the decompression directory by scanning the files in the decompression directory to determine if it is empty.

[0045] Step S304: If the decompression directory of the upgrade package is not empty, retain the historical version information on the decompression directory, clear the decompression directory, decompress the upgrade package to the decompression directory, and obtain the SoC upgrade package and MCU upgrade package located in the decompression directory. The historical version information includes the historical MCU version of the historical MCU upgrade package.

[0046] In other words, if the SoC upgrade module determines that the decompression directory is not empty, it means that the mobile terminal device is not being upgraded for the first time. In this case, the decompression directory is cleared, but the critical version information log (i.e., historical version information) is retained. In addition, the historical version information may also include the historical SoC version of the historical SoC upgrade package.

[0047] Step S306: If the decompression directory of the upgrade package is determined to be empty, decompress the upgrade package to the decompression directory to obtain the SoC upgrade package and MCU upgrade package located in the decompression directory.

[0048] In other words, if the SoC upgrade module determines that the decompression directory is empty, it means that the mobile terminal device is being upgraded for the first time, and the upgrade package is directly decompressed to the decompression directory.

[0049] Furthermore, after decompression, information about the old and new versions (i.e., the target SoC version of the SoC upgrade package and the target MCU version of the MCU upgrade package, as well as the target SoC version of the updated SoC upgrade package and the target MCU version of the updated MCU upgrade package) can be recorded to the global log (Glog).

[0050] The method described in this embodiment provides an implementation for determining whether it is the first upgrade based on the decompression directory, and can effectively reduce the storage space occupied by the upgrade file while ensuring that the version information is clearly recorded.

[0051] As an optional implementation, the method described above can be used to determine the target MCU version of the MCU upgrade package through the following steps: The target MCU version is obtained by parsing the upgrade package according to the parsing method corresponding to the upgrade package.

[0052] Specifically, the target MCU version can be found in an MCU upgrade package. The first few bytes (e.g., 64 bytes) of the MCU upgrade package can be defined as a firmware header, containing the version number of the MCU upgrade package. Therefore, the SoC upgrade module can parse the target MCU version according to the bytes corresponding to the version number in the firmware header of the MCU upgrade package.

[0053] Furthermore, if the SoC version needs to be obtained, it can be achieved as follows: obtain the version information of the upgrade package and use the upgrade package version information as the target SoC version. In other words, the SoC upgrade module directly uses the upgrade package version information as the SoC version information. Then, after obtaining the upgrade package, the obtained upgrade package version information is directly compared with the current upgrade package version. If they do not match, an OTA upgrade is performed; otherwise, an OTA upgrade is not performed.

[0054] As an optional implementation, the upgrade package for OTA upgrades of mobile terminal devices can be obtained through one of the following methods: The system performs removable storage media detection on the removable terminal device. If a target removable storage media connected to the removable terminal device is detected, an inspection operation is performed on the target removable storage media. The upgrade package is then retrieved from the target removable storage media through this inspection. In other words, it can detect the presence of external removable storage media in real time. For example, by monitoring directories such as ` / media / sda1`, a mounted removable storage media is considered connected. The removable storage media can be a USB flash drive, external hard drive, or other pluggable storage media. When a specific target removable storage media is detected connected to the removable terminal device, an upgrade package scan is first performed to perform the inspection operation: traversing the root directory of the removable storage media (excluding hidden directories) to find upgrade packages that conform to the naming rules. Then, if an upgrade package is detected, it is verified: if an upgrade package is found, its MD5 value is checked to see if it matches an existing upgrade package on the device. If they do not match or the upgrade package does not exist locally, the retrieved upgrade package is considered a new upgrade package. When the upgrade package is obtained in this way, the removable terminal device is performing an offline upgrade.

[0055] The upgrade package is downloaded to a designated path via online acquisition. Specifically, while the mobile terminal device is connected to the internet (e.g., via Wi-Fi or cellular network), it actively connects to a remote server (e.g., the manufacturer's cloud platform) and requests and securely downloads the upgrade package based on the current firmware version and device model. The download process uses HTTPS protocol to ensure transmission security and supports breakpoint resumption and integrity verification (e.g., SHA256). The upgrade package is temporarily stored in a specific directory on the SoC's local storage (e.g., / userdata / ota / or / tmp / update / ). Optionally, this designated path has sufficient read and write permissions and is isolated from other system partitions to avoid interfering with normal operation. After the download is complete, a verification process can be triggered to confirm that the downloaded upgrade package is complete and error-free before proceeding to the subsequent parsing and upgrade stages, ensuring a reliable and rollbackable upgrade. When the upgrade package is obtained using this method, the mobile terminal device is performing an online upgrade.

[0056] like Figure 4 As shown, as an optional implementation, the method described above can be used to send the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device through the following steps: If the number of times the following steps are executed in a loop is within the target number, and the MCU upgrade package is successfully sent to the MCU board, the MCU board will update according to the MCU upgrade package; otherwise, the MCU board update will be stopped. Step S402: The MCU upgrade package is split into multiple data packets of a preset size; that is, the MCU upgrade package is split to obtain multiple data packets of a preset size. For example, the bin file corresponding to the MCU upgrade package can be split into multiple data packets of 512 bytes (i.e., an optional preset size).

[0057] Step S404: If each of the plurality of data packets is successfully sent to the MCU board in sequence within a preset number of times through the sequential sending operation, it is determined that the MCU upgrade package has been successfully sent to the MCU board, so that the MCU board can update according to the MCU upgrade package; Step S406: In the sequential sending operation, if a specified data packet fails to be sent among the multiple data packets, stop sending the specified data packet to the MCU board and exit the update of the MCU board. The specified data packet is a data packet that has failed to be sent to the MCU board within a preset maximum number of attempts.

[0058] In other words, steps S402 to S406 are executed at most a target number of times, which can be 2 times, 3 times, etc. Furthermore, the current data packet can be forwarded to the MCU board via the device's internal communication link UART (i.e., an optional preset communication link).

[0059] For example, when the preset maximum number of attempts is 20 and the target number of attempts is 3, for any data packet, if the SoC upgrade module fails to send it, it will retry, up to a maximum of 20 times (i.e., the preset maximum number of attempts is 20). In other words, if the data packet can be sent to the MCU board within 20 attempts, it is considered a successful transmission; otherwise, it is considered a failure and the data packet is recorded as the designated data packet. The entire upgrade process can be retried 3 times if it fails. If all data packets cannot be forwarded to the MCU board within 3 loops, the update of the MCU board will stop.

[0060] The method described in this embodiment can effectively reduce the resources consumed by updates and prevent the system of mobile terminal devices from getting stuck during the upgrade process.

[0061] As an optional implementation, the method described above, the method for determining that the data packet was successfully sent to the MCU board includes: After sending the data packet to the MCU board, the system waits for feedback information from the MCU board. This feedback information indicates that the MCU board has successfully received the data packet. In other words, after each data packet is sent to the MCU board, the MCU board will provide feedback upon receiving the data packet. If feedback information is received from the MCU board before the deadline for sending the data packet within a preset time period, it is determined that the data packet was successfully sent.

[0062] Specifically, for any data packet, after the SoC upgrade module sends the data packet to the MCU board, it will wait for feedback information from the MCU board. The feedback information can be ACK, and the waiting time is a preset time (the start time can be the time when the data packet is sent). For example, after sending data packet a to the MCU board, if an ACK is obtained within the preset time (e.g., 1ms), it indicates that data packet a was successfully sent, and the next data packet (e.g., data packet b) will continue to be sent.

[0063] As an optional implementation, the method described above, after obtaining the upgrade package from the target removable storage medium through an inspection operation, further includes: If the inspection operation determines that there is no arbitrary upgrade package in the target removable storage medium, check whether the target removable storage medium contains a target identifier file; If the target flag file is found to exist in the target removable storage medium, execute the target flag file and then reset the flag bit corresponding to the target flag file.

[0064] In other words, during offline upgrades, if the SoC upgrade module determines through checks that no upgrade package exists on the target removable storage medium, it indicates that the target removable storage medium cannot provide the data required for OTA upgrades. Therefore, it is possible to check whether a target flag file exists on the target removable storage medium. Optionally, this target flag file can be a specific flag file located on the target removable storage medium, such as `fibocom_adb_flag.txt`, `fibocom_log_flag.txt`, etc., used to trigger other maintenance functions of the device (such as switching ADB mode, pulling logs, pulling data packets, etc.). For any target flag file, its corresponding flag bit is reset after execution.

[0065] The following is an application example that applies any of the foregoing embodiments: I. Such as Figure 5 As shown, the core upgrade process (i.e., the process included in both offline and online upgrades) is as follows: a) Start and Pre-checks: The upgrade manager starts and confirms that the upgrade package to be upgraded exists (located in the specified path).

[0066] b) Unzip directory processing: Check the status of the unzip directory. If the unzip directory is not empty (not the first upgrade), clear the unzip directory but retain the critical version information log (i.e., historical version information); if the unzip directory is empty (first upgrade), directly unzip the OTA package to the unzip directory. After unzipping, record the old and new version information to the global log (Glog).

[0067] c) Version Decision: Compare the version information of the SoC and the MCU. Optionally, the SoC version can be forcibly upgraded; the MCU version is compared, and an MCU upgrade is triggered only if the target MCU version is inconsistent with the historical MCU version.

[0068] d) MCU upgrade sub-process as follows Figure 6 As shown: i. Obtain the MCU firmware version in the upgrade package (i.e., the target MCU version) and compare it with the currently running version (i.e., the historical MCU version).

[0069] ii. Check if the MCU firmware (.bin) file (i.e., the MCU upgrade package) exists in the decompressed directory.

[0070] iii. If the MCU firmware version is inconsistent with the currently running version, then start the MCU upgrade: split the bin file (i.e., the MCU upgrade package) into multiple data packets in 512-byte increments (i.e., the preset size).

[0071] iv. Forward data packets to the MCU board via the UART (Universal Artificial Radio Link) internal communication link of the mobile terminal device.

[0072] v. Achieve reliable transmission: After each data packet is sent, wait for an ACK. If it fails, retry a maximum of 20 times (i.e., the preset maximum number of attempts is 20). If the entire upgrade process fails, it can be retried 3 times (i.e., the target number of attempts is 3).

[0073] vi. After a successful upgrade, the MCU will send a feedback result (i.e., a successful upgrade message).

[0074] e) SoC upgrade sub-process: The upgrade module calls the system upgrade command and waits for the command to be executed.

[0075] f) Upgrade Result Verification and Reboot: After the upgrade command is successfully executed, the mobile terminal device automatically reboots. After rebooting, the upgrade manager in the upgrade module verifies the version information file in the configuration file directory and confirms whether the SoC upgrade was successful by comparing the compilation date and time.

[0076] II. As Figure 7 As shown, an offline upgrade process is also provided when using a USB flash drive as a portable storage medium, specifically as follows: a) USB drive detection: The upgrade module monitors directories such as ` / media / sda1`, and if a USB drive is detected as mounted, it is considered that the USB drive is connected.

[0077] b) Upgrade package scanning: Traverse the root directory of the USB drive (excluding hidden directories) to find upgrade packages that match the naming rules.

[0078] c) Upgrade Package Verification: If an upgrade package is found, check if its MD5 value matches that of an existing upgrade package on the mobile terminal device. If they do not match or the upgrade package does not exist locally, it is considered a new upgrade package.

[0079] d) Backup and preparation: Back up the old local upgrade package (if any), and copy the new upgrade package from the USB flash drive to the OTA-specific directory inside the device.

[0080] e) Trigger upgrade: After the copy is completed, the upgrade management program will start automatically and enter the core upgrade process described above.

[0081] f) Functional file processing: Specific flag files (such as `fibocom_adb_flag.txt`, `fibocom_log_flag.txt`) can also be placed on the USB flash drive to trigger other maintenance functions of the device (such as switching ADB mode, pulling logs, pulling data packets, etc.). After execution, the corresponding flag bits are reset. Flag bits may include, but are not limited to, those mentioned above. Figure 7 The flags shown are: adb mode flag, ap mode flag, LOG flag, version number flag, and bag flag. The adb mode flag enables / disables PC debugging; the ap mode flag indicates that it is running on the main application processor; the LOG flag controls the log output on / off switch / level; the version number flag identifies the firmware version and compilation type; and the bag flag logs critical exceptions.

[0082] This embodiment of the method realizes an integrated online and offline upgrade channel, which can provide a unified core upgrade logic and simultaneously serve two upgrade sources: network download and offline copy, providing full-scenario upgrade capabilities for mobile terminal devices.

[0083] According to another aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein the memory is used to store a computer program; and the processor is used to execute the method steps of any of the above embodiments by running the computer program stored in the memory.

[0084] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the method steps of any of the above embodiments when running.

[0085] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to 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 product. This computer software product is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), magnetic disk, optical disk), 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.

[0087] According to another aspect of the embodiments of this application, an OTA upgrade apparatus for a mobile terminal device for implementing the above-described OTA upgrade method for a mobile terminal device is also provided. Figure 8 This is a structural block diagram of an optional OTA upgrade device for a mobile terminal device according to an embodiment of this application, such as... Figure 8 As shown, the device may include: The acquisition module 81 is used to acquire an upgrade package for OTA upgrade of a mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; Module 82 is used to determine the target SoC version of the SoC upgrade package and the target MCU version of the MCU upgrade package; The sending module 83 is used to send the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device, provided that the SoC upgrade package is determined based on the target MCU version and the MCU upgrade package meets the preset upgrade requirements. SoC upgrade module 84 is used to upgrade the SoC of a mobile terminal device according to the SoC upgrade package; The execution module 85 is used to complete the OTA upgrade of the mobile terminal device when the successful upgrade information is received from the MCU board and the SoC upgrade is successful.

[0088] It should be noted that the acquisition module 81 in this embodiment can be used to perform the above step S202, the determination module 82 in this embodiment can be used to perform the above step S204, the sending module 83 in this embodiment can be used to perform the above step S206, the SoC upgrade module 84 in this embodiment can be used to perform the above step S208, and the execution module 85 in this embodiment can be used to perform the above step S210.

[0089] In addition to the modules described above, the apparatus in this embodiment may also include modules that execute any method as described in any of the embodiments of the aforementioned mobile terminal device OTA upgrade method.

[0090] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of a device, can operate in environments such as... Figure 1 The hardware environment shown can be implemented through software or hardware, and the hardware environment includes the network environment.

[0091] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described mobile terminal device OTA upgrade method is also provided. The electronic device may be a server, a terminal, or a combination thereof.

[0092] According to another embodiment of this application, an electronic device is also provided, comprising: Figure 9 As shown, the electronic device may include: a processor 1501, a communication interface 1502, a memory 1503, and a communication bus 1504, wherein the processor 1501, the communication interface 1502, and the memory 1503 communicate with each other through the communication bus 1504.

[0093] Memory 1503 is used to store computer programs; When processor 1501 executes the program stored in memory 1503, it performs the following steps: Step S202: Obtain an upgrade package for OTA upgrade of the mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package.

[0094] Step S204: Determine the target SoC version of the SoC upgrade package and the target MCU version of the MCU upgrade package.

[0095] Step S206: If the SoC upgrade package is determined based on the target MCU version and the MCU upgrade package meets the preset upgrade requirements, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device.

[0096] Step S208: Perform SoC upgrade on the mobile terminal device according to the SoC upgrade package.

[0097] Step S210: Upon receiving successful upgrade information from the MCU board and confirming successful SoC upgrade, complete the OTA upgrade of the mobile terminal device.

[0098] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used to represent it in the figure, but this does not mean that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic device and other devices.

[0099] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0100] As an example, the memory 1503 described above may include, but is not limited to, the first acquisition module 81, the second acquisition module 82, the determination module 83, the sending module 84, the SoC upgrade module 85, and the execution module 86 of the mobile terminal device OTA upgrade device described above. Furthermore, it may include, but is not limited to, other module units of the mobile terminal device OTA upgrade device described above, which will not be elaborated in this example.

[0101] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0102] This application also provides a computer-readable storage medium, which includes a stored program, wherein the program executes the method steps of the above method embodiments when it runs.

[0103] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0104] 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.

[0105] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0106] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0107] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0108] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the solution provided in this embodiment, depending on actual needs.

[0109] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0110] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An OTA upgrade method, characterized in that, include: Obtain an upgrade package for OTA upgrade of a mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; Determine the target MCU version for the MCU upgrade package; If the MCU upgrade package meets the preset upgrade requirements based on the target MCU version, the MCU upgrade package is sent to the MCU board to update the MCU board of the mobile terminal device. The mobile terminal device is upgraded using the SoC upgrade package. Upon receiving successful upgrade information from the MCU board and confirming the successful SoC upgrade, the OTA upgrade of the mobile terminal device is completed.

2. The method according to claim 1, characterized in that, The step of obtaining the upgrade package for OTA upgrade of the mobile terminal device includes: Check if the decompression directory pointed to by the decompression path of the upgrade package is empty; If the decompression directory of the upgrade package is determined to be non-empty, the historical version information on the decompression directory is retained, the decompression directory is cleared, and the upgrade package is decompressed to the decompression directory to obtain the SoC upgrade package and the MCU upgrade package located in the decompression directory. The historical version information includes the historical MCU version of the historical MCU upgrade package. If the decompression directory of the upgrade package is found to be empty, the upgrade package is decompressed to the decompression directory to obtain the SoC upgrade package and the MCU upgrade package located in the decompression directory.

3. The method according to claim 1, characterized in that, Determining the target MCU version of the MCU upgrade package includes: The target MCU version is obtained by parsing the upgrade package according to the parsing method corresponding to the upgrade package.

4. The method according to claim 1, characterized in that, The method of obtaining the upgrade package for OTA upgrade of the mobile terminal device includes one of the following: The removable terminal device is subjected to removable storage medium detection; if a target removable storage medium connected to the removable terminal device is detected, an inspection operation is performed on the target removable storage medium; the upgrade package is obtained from the target removable storage medium through the inspection operation; Download the upgrade package to the specified path via online access.

5. The method according to claim 1, characterized in that, Sending the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device includes: If the number of times the following steps are executed in a loop is within the target number, and the MCU upgrade package is successfully sent to the MCU board, the MCU board will update according to the MCU upgrade package; otherwise, the MCU board update will be stopped. The MCU upgrade package is split into multiple data packets of a preset size; If each of the plurality of data packets is successfully sent to the MCU board in sequence within a preset number of times through a sequential sending operation, it is determined that the MCU upgrade package has been successfully sent to the MCU board, so that the MCU board can be updated according to the MCU upgrade package; In the sequential sending operation, if a specified data packet fails to be sent among the multiple data packets, the sending of the specified data packet to the MCU board is stopped, and the update of the MCU board is exited. The specified data packet is the data packet that has failed to be sent to the MCU board within a preset limit of attempts.

6. The method according to claim 5, characterized in that, The methods for determining that the data packet was successfully sent to the MCU board include: After sending the data packet to the MCU board, wait for feedback information from the MCU board, wherein the feedback information is used to indicate that the MCU board has successfully acquired the data packet; If feedback information is received from the MCU board before the deadline for sending the data packet within a preset time period, it is determined that the data packet was successfully sent.

7. The method according to claim 4, characterized in that, After obtaining the upgrade package from the target removable storage medium through the inspection operation, the method further includes: If the inspection operation determines that no upgrade package exists in the target removable storage medium, then check whether a target flag file exists in the target removable storage medium. If it is determined that a target flag file exists in the target removable storage medium, the flag bit corresponding to the target flag file is reset after the target flag file is executed.

8. An OTA upgrade device, characterized in that, include: An acquisition module is used to acquire an upgrade package for OTA upgrade of a mobile terminal device, wherein the upgrade package includes a SoC upgrade package and an MCU upgrade package; The determination module is used to determine the target MCU version of the MCU upgrade package; The sending module is used to send the MCU upgrade package to the MCU board to update the MCU board of the mobile terminal device when it is determined that the MCU upgrade package meets the preset upgrade requirements based on the target MCU version. The SoC upgrade module is used to upgrade the SoC of the mobile terminal device according to the SoC upgrade package. The execution module is used to complete the OTA upgrade of the mobile terminal device when the successful upgrade information fed back by the MCU board is obtained and the SoC upgrade is successful.

9. An electronic device comprising a processor, a communication interface, a memory, and a communication bus, wherein, The processor, the communication interface, and the memory communicate with each other via the communication bus, characterized in that... The memory is used to store computer programs; The processor is configured to perform the method of any one of claims 1 to 7 by running the computer program stored in the memory.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 7 when run on a processor.