Embedded equipment online upgrading method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of embedded software, in particular to an embedded equipment online upgrading method and device, electronic equipment and a storage medium, according to a preset time period, an ADB command is used for recognizing a currently connected embedded equipment list, and according to the list, the equipment type of equipment to be upgraded is determined; and automatically selecting an mmc-utils tool of a corresponding version according to the type of the device, carrying out FFU upgrading on the device to be upgraded, and after it is confirmed that the device is successfully upgraded, updating the state of the device in the embedded device list. According to the method, disassembly is not needed, the tedious process and the high damage rate of traditional disassembly upgrading are avoided, the method does not depend on addition of upgrading codes in a system kernel, the requirement for the ability of a software engineer is lowered, the application range is wider, and simple, convenient, efficient and universal online upgrading is achieved.

Description

Technical Field

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

[0002] Embedded Multimedia Cards (eMMCs) are a standard specification defined by JEDEC (Joint Electron Device Engineering Council) primarily for embedded memory in portable mobile devices such as smartphones, tablets, and cameras. They include at least one NAND flash memory chip and a controller chip, which contains firmware to manage the eMMC's operation. eMMCs are used as storage in Android / Linux-based electronic devices. Currently, embedded multimedia cards (eMMCs) and universal flash memory (UFS) are widely used in Android and Linux devices. However, after electronic products are manufactured, firmware iterations or new features may be required, necessitating upgrades and optimizations to the existing eMMC controller firmware. Since eMMC products are already soldered onto embedded devices, existing upgrade methods present numerous technical challenges. First, traditional disassembly and upgrade methods require disassembling the embedded electronic product, removing the motherboard, desoldering the eMMC component from the motherboard, re-balling the eMMC, updating the firmware using mass production tools, resoldering the eMMC back onto the motherboard, and finally reassembling the motherboard into the finished electronic device. This process is cumbersome and complex, has a high product failure rate, and is time-consuming. Second, adding upgrade code to the Android / Linux system kernel of the embedded electronic product is also labor-intensive and time-consuming, requiring highly skilled software engineers and often necessitating one-on-one development. Furthermore, the upgrade permissions for the Android / Linux code of embedded electronic products are controlled by the SOC manufacturer, meaning many terminal manufacturers cannot add upgrade code themselves and must rely on the SOC manufacturer's assistance. This results in low overall efficiency, a narrow range of applications, and is impractical in many real-world scenarios.

[0003] It is evident that the complexity and high failure rate of existing upgrade methods make firmware replacement both time-consuming and labor-intensive. While kernel code additions theoretically enable customized upgrades, their reliance on inter-enterprise cooperation and limited permissions hinders their universality and makes widespread application and large-scale implementation difficult in practice. Therefore, a simpler, more efficient, and widely applicable online upgrade method is urgently needed. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an online upgrade method, apparatus, electronic device, and storage medium for embedded devices. It eliminates the need for disassembly and does not rely on adding upgrade code to the system kernel, thus achieving a simple, efficient, and universal online upgrade.

[0005] A first aspect of this application provides an online upgrade method for an embedded device, the method comprising: The list of currently connected embedded devices is identified using ADB commands based on a preset time period. Determine the device type of the embedded device to be upgraded based on the embedded device list; Automatically select the corresponding version of the mmc-utils tool based on the device type to perform an FFU upgrade on the embedded device to be upgraded. Once it is confirmed that the embedded device to be upgraded has been successfully upgraded, the device status of the embedded device to be upgraded in the embedded device list is updated.

[0006] In an optional implementation, the step of automatically selecting the corresponding version of the mmc-utils tool based on the device type to perform an FFU upgrade on the embedded device to be upgraded includes: Using the mmc-utils tool, the extended configuration register of the embedded device to be upgraded is read by sending a CMD8 command to determine the device version and the supported FFU functions; The embedded device to be upgraded is switched to firmware upgrade mode using the SWITCH command. Read the firmware to be upgraded, and continuously write the firmware image data of the firmware to be upgraded into the temporary inactive firmware area inside the embedded device to be upgraded through the CMD23 and CMD25 commands. After the writing is complete, the embedded device to be upgraded is switched back to normal working mode using the SWITCH command; The embedded device to be upgraded is restarted using ADB commands so that the firmware to be upgraded can be upgraded. After the reboot is complete, send the CMD8 command to obtain the firmware version of the embedded device to be upgraded; The firmware version is compared with the device version before the upgrade to confirm whether the upgrade was successful.

[0007] In an optional implementation, the method further includes: When an upgrade fails, check whether the current number of upgrade attempts meets the preset threshold. When it is determined that the current number of upgrades has not met the preset number of times threshold, the FFU upgrade operation is re-executed until the upgrade is successful or the preset number of times threshold is met. When it is determined that the number of upgrades meets the preset threshold and the upgrade result of the current FFU upgrade operation is an upgrade failure, then it is determined that the embedded device to be upgraded has failed to upgrade.

[0008] In an optional implementation, the method further includes: Hardware CRC check is performed on the composite data of the firmware image data and the attached CRC check code to determine whether there is an error in writing the firmware image data; the composite data with the attached CRC check code is a data unit formed by combining the firmware image data with the CRC check code calculated based on the firmware image data. The firmware image data is verified using the CRC checksum stored within it. When both the hardware CRC check and the CRC checksum check pass, the firmware image data is determined to have been successfully written.

[0009] In an optional implementation, the step of performing CRC checksum verification on the firmware image data based on the CRC checksum stored within the firmware image data includes: The current CRC value of the firmware image data is generated by modulo-2 division. Compare the current CRC value with the saved CRC checksum; When the current CRC value matches the saved CRC checksum, the CRC checksum verification is determined to be successful. When the current CRC value is inconsistent with the saved CRC checksum, it is determined that the CRC checksum verification has failed.

[0010] In an optional implementation, the method further includes: Based on the device serial number in the embedded device list, determine whether the target embedded device is a newly connected device or an upgraded device; When the target embedded device is determined to be a new connection device, it is displayed and marked as pending upgrade in the embedded device list; When the target embedded device is determined to be an upgraded device, it is marked as upgraded in the embedded device list.

[0011] A second aspect of this application provides an online upgrade device for embedded devices, the device comprising: The identification module is used to identify the list of currently connected embedded devices using ADB commands according to a preset time period; The determination module is used to determine the device type of the embedded device to be upgraded based on the embedded device list. The upgrade module is used to automatically select the corresponding version of the mmc-utils tool according to the device type to perform FFU upgrade on the embedded device to be upgraded; The update module is used to update the device status of the embedded device to be upgraded in the embedded device list after it is determined that the upgrade of the embedded device to be upgraded is successful.

[0012] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the embedded device online upgrade method.

[0013] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described online upgrade method for embedded devices.

[0014] In summary, the embedded device online upgrade method, apparatus, electronic device, and storage medium provided in this application have at least one of the following technical advantages: 1. Upgrading embedded devices online avoids the cumbersome process caused by disassembly and repeated soldering, and also greatly reduces the risk of product damage during disassembly and assembly. 2. Based on a preset time period, the system uses ADB commands to identify the list of currently connected embedded devices, determines the device type of the embedded device to be upgraded based on the device list, and automatically selects the corresponding version of the mmc-utils tool to perform an FFU upgrade on the embedded device to be upgraded. The entire process is highly automated, eliminating the need for software engineers to manually add a large amount of upgrade code to the kernel, reducing workload and shortening the upgrade cycle. At the same time, it does not rely on the SOC vendor's control over upgrade permissions, and terminal manufacturers do not need the assistance of the SOC vendor to add upgrade code. Attached Figure Description

[0015] Figure 1 This is a schematic flowchart illustrating an online upgrade method for an embedded device according to an embodiment of this application; Figure 2 This is a device relationship architecture diagram of an embedded device online upgrade system shown in an embodiment of this application; Figure 3 This is another schematic flowchart illustrating an online upgrade method for an embedded device according to an embodiment of this application; Figure 4 This is a schematic diagram of an interface for launching a visual upgrade program, as shown in an embodiment of this application; Figure 5 This is a schematic diagram of an interface for identifying embedded devices through a visual upgrade program, as shown in an embodiment of this application. Figure 6 This is a schematic diagram of an interface for upgrading firmware via a visual upgrade procedure, as shown in an embodiment of this application. Figure 7 This is a functional block diagram of an embedded device online upgrade apparatus shown in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0016] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0017] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0018] Reference Figure 1 The diagram shown is a flowchart illustrating an online upgrade method for an embedded device according to an embodiment of this application, including the following steps.

[0019] S11, identify the list of currently connected embedded devices using ADB commands according to a preset time period.

[0020] Refer to together Figure 2 The embedded device online upgrade system includes a host and an eMMC device. The host runs an automatic upgrade tool (i.e., a visual upgrade program). The eMMC device internally contains an eMMC controller and a NAND FLASH storage unit. The eMMC controller communicates with the host and controls read and write operations on the NAND FLASH. To facilitate understanding of the inventive concept, this embodiment implements the embedded device online upgrade method using a Python GUI visual upgrade program based on a Windows operating system. The visual upgrade program uses Python Tkinter to implement the GUI program, and the GUI APP uses adb commands to call mmc_utils to implement the eMMC firmware upgrade.

[0021] In some embodiments, the host can initiate a visual upgrade process based on a preset time period (e.g., 1 day), referring to... Figure 4 As shown. Users can click the start button to enter automatic upgrade mode, meaning the firmware upgrade will begin as soon as the eMMC device is inserted. Alternatively, users can select the desired FFU BIN file from the FFU BIN file, instead of selecting the FFU BIN file in the default FW directory. When an upgrade is needed, the visual upgrade program calls the adb devices command to check the connection status with the eMMC device every 2 seconds, confirming that the eMMC device is correctly connected and in a communicable state. If the connection is normal, the visual upgrade program will read the current version information and device type of the eMMC device to generate an embedded device list, referencing... Figure 5 As shown in the figure. The embedded device list records successfully connected eMMC devices and their corresponding device information, which may include device name, device type, device status, current version information, etc.

[0022] When any eMMC device (also known as the target embedded device) connects to the host, the visual upgrade program sends a command to the device to retrieve its serial number through communication interaction. Upon receiving this command, the embedded device's controller (such as the eMMC controller) reads the serial number from a specific area (such as EEPROM or a specific register area) where the serial number is stored internally and returns it to the host's visual upgrade program. Based on the embedded device list, the host can determine whether each successfully connected eMMC device is a newly connected device or an already upgraded device. That is, the visual upgrade program compares the retrieved target embedded device serial number with existing device serial numbers in the embedded device list. If the serial number does not exist in the list, the target embedded device is considered a newly connected device. For example, the visual upgrade program maintains a device serial number database (which can be a local file or a database system). By querying this database, it confirms whether the newly acquired serial number already exists; if not, it is determined to be a newly connected device, and the visual upgrade program adds the device's information to the embedded device list, displaying the device's serial number, name, and other basic device information in the corresponding row of the list, and marking the device status field as "pending upgrade". If the target embedded device serial number already exists in the embedded device list, the visual upgrade program will further query the corresponding upgrade record for that device. This upgrade record can be stored in a local file, database, or remote server, and records whether the device has already completed an upgrade operation. If the record shows that the device has successfully completed an upgrade, the target embedded device is determined to be an upgraded device. The visual upgrade program will then find the corresponding device entry in the embedded device list and mark the device status field as "upgraded".

[0023] After the embedded device list is displayed and marked, users can perform corresponding operations based on the device status in the list. For newly connected devices marked as needing upgrades or devices with new version releases (i.e., embedded devices needing upgrades), users can choose to perform upgrade operations, or the visual upgrade program can automatically perform firmware upgrades when it detects the embedded device needing upgrades.

[0024] S12, determine the device type of the embedded device to be upgraded based on the embedded device list.

[0025] Refer to together Figure 3From the retrieved list of embedded devices, the visual upgrade program can determine the device type of the embedded device to be upgraded. The program then searches for the corresponding version of the mmc-utils tool in a pre-stored tool library. This library stores different versions of the mmc-utils tool categorized by device type, each optimized for specific embedded device types. In other words, there is a mapping relationship between device type and mmc-utils version. The `adb shell uname -a` command is used to obtain the ARM architecture of the embedded device to determine its type. If the embedded device is ARM32, the 32-bit mmc-utils tool is used; if it is ARM64, the 64-bit mmc-utils tool is used. Different versions of mmc-utils are used for ARM32 and ARM64 devices respectively. S13, automatically select the corresponding version of the mmc-utils tool according to the device type to perform FFU upgrade on the embedded device to be upgraded.

[0026] S14, after determining that the embedded device to be upgraded has been successfully upgraded, update the device status of the embedded device to be upgraded in the embedded device list.

[0027] Refer to together Figure 3 Based on the preset upgrade strategy (such as new version release, user-triggered upgrade, etc.), the visual upgrade program determines whether an upgrade operation is needed. When an upgrade is required, after finding the corresponding mmc-utils tool according to the device type, the visual upgrade program starts the FFU (Full Flash Update) upgrade process.

[0028] It should be noted that the visual upgrade program enables multi-channel concurrent upgrades, that is, FFU upgrades to multiple eMMC devices simultaneously. Specifically, this is achieved using a Python thread pool, and the device list in the visual upgrade program's interface displays the number of devices connected at the same time. To facilitate understanding of the inventive concept, this application uses a single-channel upgrade as an example. To ensure upgrade stability, the maximum concurrency of the Python thread pool is set to 6 within the visual upgrade program, allowing a maximum of 6 devices to be upgraded simultaneously. The simultaneous online upgrade of 6 devices is based on experimental results. If more than 6 embedded devices are connected to the host simultaneously, the stability of the USB port will decrease, easily causing upgrade failures. Therefore, in this application embodiment, the number of eMMC devices for multi-channel concurrent upgrades cannot exceed 6.

[0029] In an optional implementation, the step of automatically selecting the corresponding version of the mmc-utils tool based on the device type to perform an FFU upgrade on the embedded device to be upgraded includes: Using the mmc-utils tool, the extended configuration register of the embedded device to be upgraded is read by sending a CMD8 command to determine the device version and the supported FFU functions; The embedded device to be upgraded is switched to firmware upgrade mode using the SWITCH command. Read the firmware to be upgraded, and continuously write the firmware image data of the firmware to be upgraded into the temporary inactive firmware area inside the embedded device to be upgraded through the CMD23 and CMD25 commands. After the writing is complete, the embedded device to be upgraded is switched back to normal working mode using the SWITCH command; The embedded device to be upgraded is restarted using ADB commands so that the firmware to be upgraded can be upgraded. After the reboot is complete, send the CMD8 command to obtain the firmware version of the embedded device to be upgraded; The firmware version is compared with the device version before the upgrade to confirm whether the upgrade was successful.

[0030] In some embodiments, during the upgrade process, the eMMC controller divides the NAND FLASH into different regions, such as a temporary inactive firmware region and an active firmware region, to prepare for subsequent firmware writing and switching. Specifically, the FFU upgrade of an embedded device in the power-on state includes the following steps: Step 1: Confirm device version and functions.

[0031] After the visual upgrade program is launched on the host computer, it first sends a CMD8 (SEND_EXT_CSD) command to the embedded device. This command reads the FFU_FEATURES field from the device's Extended CSD register. Upon receiving this command, the embedded device's controller reads the corresponding data from the Extended CSD register and returns it to the host computer. The host computer parses the returned data to obtain the device's version information and the FFU functions supported by the device, such as encrypted upgrades and fast upgrade modes.

[0032] Step 2: Switch the device mode to FFU MODE.

[0033] Based on the device version and supported FFU functionality, after the host determines that the device supports FFU upgrades, it sends a SWITCH command (CMD6) to the device to switch the device's operating mode to firmware upgrade mode (FFU MODE). Upon receiving the SWITCH command, the embedded device's controller parses the command parameters and adjusts the relevant internal configurations accordingly, putting the device into FFU mode. FFU MODE refers to the dedicated upgrade mode to which the embedded device's main control chip is switched during firmware upgrades using the SWITCH command (CMD6). In this mode, the device allows external hosts (such as the host) to directly access and modify its internal firmware storage area, supports block writing of firmware image data, CRC double verification, and other operations, while blocking read / write requests unrelated to upgrades, ensuring the security and data integrity of the upgrade process.

[0034] Step 3: Firmware data writing and double verification.

[0035] The host reads the firmware to be upgraded (i.e., the firmware to be upgraded) from the specified storage location. Before reading the firmware, the host can determine whether an upgrade is necessary based on the firmware version iteration or whether there are any new features. If an upgrade is determined, the host divides the firmware into multiple data blocks. The size of the data block is determined based on the characteristics of the device and the transmission capacity of the communication interface, such as 512 bytes or 4KB.

[0036] The host sends the CMD23 (SET_BLOCK_COUNT) command to the eMMC device to set the number of data blocks to be transferred. Immediately afterwards, it sends the CMD25 (WRITE_MULTIPLE_BLOCK) command to begin continuously writing firmware image data blocks to the device. The data is written to a temporary, inactive firmware area within the device.

[0037] It should be noted that the device performs hardware CRC checks during data transmission. Specifically, for each received data block, the eMMC controller uses its own hardware circuitry to perform real-time CRC calculations on the transmitted firmware image data (composite data consisting of logical data and CRC values) and compares it with the CRC value sent by the host. If they match, it indicates that no errors occurred during transmission, and the device continues to receive subsequent data blocks. If the comparison results do not match, it indicates that an error occurred in the data transmission, and the device will send an error message to the host. The host can then decide whether to retransmit the data block based on the situation.

[0038] Once all data blocks, i.e., the firmware image data, have been transmitted and passed hardware CRC verification, the device receives the logical data. At this point, the host's visual upgrade program can, as needed, perform another CRC calculation (software CRC calculation) on the entire transmitted firmware image data, generating a unified CRC checksum and sending it to the eMMC device for subsequent secondary verification and comparison. Specifically, a modulo-2 division is performed on the logical data, i.e., the current CRC value is recalculated; if the remainder is zero (the current CRC value matches the saved CRC checksum), the data is considered error-free; if the remainder is non-zero (the current CRC value does not match the saved CRC checksum), the data is considered erroneous. If the secondary verification passes, it indicates that the firmware image data is complete and correct, and subsequent upgrade steps can continue; if the verification fails, the device will send a verification failure message to the host.

[0039] If both layers of CRC checks on the eMMC device pass, the host's visual upgrade program confirms that the data is complete and correct, and sends an upgrade completion confirmation command to the eMMC controller.

[0040] Step 4: Switch the device mode back to Normal MODE.

[0041] After the host computer completes the image data writing via CMD23 / CMD25, it sends a SWITCH command (CMD6) to the device again, switching the device's operating mode from FFU MODE back to normal operating mode (i.e., Normal MODE). Upon receiving the command, the device controller restores the device to its normal operating state, allowing it to resume other routine operations. Normal MODE refers to the default operating mode restored by the embedded device via the SWITCH command (CMD6) after a firmware upgrade. In this mode, the device's main control chip reloads the upgraded firmware, restores normal read / write control functions to the memory, and responds normally to various operation requests from the external host (such as file read / write, system startup, etc.), ensuring the device can stably execute its preset functions.

[0042] Step 5: Device restart and upgrade results confirmation.

[0043] Refer to together Figure 3The host computer sends a reboot command to the embedded device via ADB commands. Upon receiving the command, the device executes a reboot. During the reboot process, the device loads the newly upgraded firmware from the temporary inactive firmware area into the active area, making it the new firmware running on the device. After the device reboots, the host computer sends a CMD8 (SEND_EXT_CSD) command again to obtain the firmware version. The host determines whether the firmware upgrade was successful by reading the version number in the device's Extended CSD register and the device's accumulated FFU count (i.e., the preset threshold, set to 3). If the version number matches the newly upgraded firmware version and the accumulated FFU count increases correctly, the upgrade is considered successful; otherwise, the upgrade is considered failed. If the upgrade is successful, the visual upgrade program can update the status of the embedded device to be upgraded from "Pending Upgrade" to "Upgraded," and display the upgrade progress as 100% and the updated firmware version number after the upgrade. Figure 6 As shown. If the upgrade fails, the host will repeat steps 1 to 5 above to attempt the upgrade again. This process can be repeated a maximum of 3 times. If the upgrade still fails after 3 attempts, it is considered a failed upgrade. The host can record detailed information about the upgrade failure, including the device identifier, the failed steps, and the error code, for subsequent troubleshooting and analysis.

[0044] This application achieves compatibility through a visual upgrade program. This program obtains device information by calling the commands "adb shell cat / proc / cpuinfo" and "adb shell uname -a," and then uses different versions of the mmc_utils tool to directly update firmware on various Android / Linux platforms of numerous SoC models, including Qualcomm, MTK, RK, Unisoc, and Allwinner. This breaks through the limitations of existing technologies that can only upgrade a single SoC model or have cumbersome upgrade processes and high product damage rates. It has a wide range of applications and is simple and convenient to use, greatly improving upgrade efficiency. Furthermore, regarding upgrade efficiency, this application supports multi-path concurrency, allowing up to six devices to be upgraded online simultaneously. Compared to existing one-to-one upgrade solutions, when a large number of devices need to be upgraded online, no additional PC support is required, significantly improving online upgrade efficiency. Simultaneously, it achieves non-desoldering eMMC upgrades, avoiding the damage risks associated with desoldering eMMC products, reducing costs and time. Moreover, the entire upgrade process is automated, and the version detection function is automatically activated after a successful upgrade, avoiding the risk of missed or incorrect flashing that may occur when manually checking the versions before and after the upgrade in existing methods.

[0045] Reference Figure 7 The diagram shown is a functional block diagram of an embedded device online upgrade apparatus according to an embodiment of this application.

[0046] In some embodiments, the embedded device online upgrade device 70 may include multiple functional modules composed of computer program segments. The computer programs for each program segment of the embedded device online upgrade device 70 may be stored in the memory of the electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) The embedded device has an online upgrade function. Based on its function, it can be divided into multiple functional modules. These functional modules may include: an identification module 701, a determination module 702, an upgrade module 703, and an update module 704. The module referred to in this application is a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0047] The identification module 701 is used to identify the list of currently connected embedded devices using ADB commands according to a preset time period.

[0048] The determining module 702 is used to determine the device type of the embedded device to be upgraded based on the embedded device list.

[0049] The upgrade module 703 is used to automatically select the corresponding version of the mmc-utils tool to perform FFU upgrade on the embedded device to be upgraded according to the device type.

[0050] The update module 704 is used to update the device status of the embedded device to be upgraded in the embedded device list after it is determined that the embedded device to be upgraded has been successfully upgraded.

[0051] The upgrade module 703 is further configured to: read the extended configuration register of the embedded device to be upgraded by sending a CMD8 command according to the mmc-utils tool to determine the device version and supported FFU functions; switch the embedded device to be upgraded to firmware upgrade mode by sending a SWITCH command; read the firmware to be upgraded and continuously write the firmware image data of the firmware to be upgraded into the temporary inactive firmware area inside the embedded device to be upgraded by sending CMD23 and CMD25 commands; after writing is completed, switch the embedded device to be upgraded back to normal working mode by sending a SWITCH command; restart the embedded device to be upgraded by sending an ADB command to enable the firmware upgrade; after restarting, send a CMD8 command to obtain the firmware version of the embedded device to be upgraded; compare the firmware version with the device version before the upgrade to confirm whether the upgrade was successful.

[0052] The upgrade module 703 is further configured to: when an upgrade failure is determined, determine whether the current upgrade count meets a preset threshold; when the current upgrade count does not meet the preset threshold, re-execute the FFU upgrade operation until the upgrade is successful or the preset threshold is met; when the upgrade count meets the preset threshold and the upgrade result of the current FFU upgrade operation is an upgrade failure, then determine that the embedded device to be upgraded has failed to upgrade.

[0053] The upgrade module 703 is further specifically used for: performing hardware CRC verification on the composite data of the firmware image data and the attached CRC check code to determine whether there is an error in writing the firmware image data; the composite data with the attached CRC check code is a data unit formed by combining the firmware image data with the CRC check code calculated based on the firmware image data; performing CRC check code verification on the firmware image data based on the CRC check code stored in the firmware image data; when both the hardware CRC verification and the CRC check code verification pass, it is determined that the firmware image data was successfully written.

[0054] The upgrade module 703 is further configured to: generate the current CRC value of the firmware image data through modulo-2 division; compare the current CRC value with the saved CRC checksum; determine that the CRC checksum verification is successful when the current CRC value matches the saved CRC checksum; and determine that the CRC checksum verification fails when the current CRC value does not match the saved CRC checksum.

[0055] The identification module 701 is further configured to: determine whether the target embedded device is a newly connected device or an upgraded device based on the device serial number in the embedded device list; when the target embedded device is determined to be a newly connected device, display it in the embedded device list and mark it as pending upgrade; when the target embedded device is determined to be an upgraded device, mark it as upgraded in the embedded device list.

[0056] It should be understood that the various variations and specific embodiments of the embedded device online upgrade method provided in the above embodiments are also applicable to the embedded device online upgrade device of this embodiment. Through the foregoing detailed description of the embedded device online upgrade method, those skilled in the art can clearly understand the implementation method of the embedded device online upgrade device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0057] See Figure 8The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 8 includes a memory 81, at least one processor 82, and at least one communication bus 83.

[0058] Those skilled in the art should understand that Figure 8 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 8 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0059] In some embodiments, the electronic device 8 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 8 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0060] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, 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; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

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

[0062] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0063] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0064] 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 the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. 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 the present invention.

[0065] In the above embodiments, 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.

[0066] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for online upgrade of an embedded device, characterized in that, The method includes: The list of currently connected embedded devices is identified using ADB commands based on a preset time period. Determine the device type of the embedded device to be upgraded based on the embedded device list; Automatically select the corresponding version of the mmc-utils tool based on the device type to perform an FFU upgrade on the embedded device to be upgraded. Once it is confirmed that the embedded device to be upgraded has been successfully upgraded, the device status of the embedded device to be upgraded in the embedded device list is updated.

2. The embedded device online upgrade method according to claim 1, characterized in that, The step of automatically selecting the corresponding version of the mmc-utils tool based on the device type to perform FFU upgrade on the embedded device to be upgraded includes: Using the mmc-utils tool, the extended configuration register of the embedded device to be upgraded is read by sending a CMD8 command to determine the device version and the supported FFU functions; The embedded device to be upgraded is switched to firmware upgrade mode using the SWITCH command. Read the firmware to be upgraded, and continuously write the firmware image data of the firmware to be upgraded into the temporary inactive firmware area inside the embedded device to be upgraded through the CMD23 and CMD25 commands. After the writing is complete, the embedded device to be upgraded is switched back to normal working mode using the SWITCH command; The embedded device to be upgraded is restarted using ADB commands so that the firmware to be upgraded can be upgraded. After the reboot is complete, send the CMD8 command to obtain the firmware version of the embedded device to be upgraded; The firmware version is compared with the device version before the upgrade to confirm whether the upgrade was successful.

3. The embedded device online upgrade method according to claim 2, characterized in that, The method further includes: When an upgrade fails, check whether the current number of upgrade attempts meets the preset threshold. When it is determined that the current number of upgrades has not met the preset number of times threshold, the FFU upgrade operation is re-executed until the upgrade is successful or the preset number of times threshold is met. When it is determined that the number of upgrades meets the preset threshold and the upgrade result of the current FFU upgrade operation is an upgrade failure, then it is determined that the embedded device to be upgraded has failed to upgrade.

4. The embedded device online upgrade method according to claim 2, characterized in that, The method further includes: Hardware CRC check is performed on the composite data of the firmware image data and the attached CRC check code to determine whether there is an error in writing the firmware image data; the composite data with the attached CRC check code is a data unit formed by combining the firmware image data with the CRC check code calculated based on the firmware image data. The firmware image data is verified using the CRC checksum stored within it. When both the hardware CRC check and the CRC checksum check pass, the firmware image data is determined to have been successfully written.

5. The embedded device online upgrade method according to claim 4, characterized in that, The step of performing CRC checksum verification on the firmware image data based on the CRC checksum stored within the firmware image data includes: The current CRC value of the firmware image data is generated by modulo-2 division. Compare the current CRC value with the saved CRC checksum; When the current CRC value matches the saved CRC checksum, the CRC checksum verification is determined to be successful. When the current CRC value is inconsistent with the saved CRC checksum, it is determined that the CRC checksum verification has failed.

6. The online upgrade method for embedded devices according to claim 1, characterized in that, The method further includes: Based on the device serial number in the embedded device list, determine whether the target embedded device is a newly connected device or an upgraded device; When the target embedded device is determined to be a new connection device, it is displayed and marked as pending upgrade in the embedded device list; When the target embedded device is determined to be an upgraded device, it is marked as upgraded in the embedded device list.

7. An online upgrade device for embedded devices, characterized in that, The device includes: The identification module is used to identify the list of currently connected embedded devices using ADB commands according to a preset time period; The determination module is used to determine the device type of the embedded device to be upgraded based on the embedded device list. The upgrade module is used to automatically select the corresponding version of the mmc-utils tool according to the device type to perform FFU upgrade on the embedded device to be upgraded; The update module is used to update the device status of the embedded device to be upgraded in the embedded device list after it is determined that the upgrade of the embedded device to be upgraded is successful.

8. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the embedded device online upgrade method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the embedded device online upgrade method according to any one of claims 1 to 6.

Images