Firmware updating method of embedded Internet of Things equipment and embedded Internet of Things equipment

Abstract

The invention provides a firmware updating method of embedded Internet of Things equipment and the embedded Internet of Things equipment. Firmware is divided into two parts, namely bottom layer firmware and application firmware according to functions; the device comprises a boot loading partition, a bottom layer firmware partition, an application firmware partition and a cache partition, the boot loading partition is used for storing a boot loader, the bottom layer firmware partition is used for storing bottom layer firmware, and the application firmware partition is used for storing application firmware; the method comprises the following steps that in response to a detected trigger event for updating firmware of equipment, firmware updating data are obtained and written into a cache partition, and the firmware updating data comprise at least one of bottom-layer firmware updating data and application firmware updating data; and processing and loading the firmware update data in the cache partition by utilizing a boot loader to execute firmware update. The method and the device can save transmission flow, save storage space and improve the success rate of firmware updating.

Description

Technical Field

[0001] The present application relates to the field of embedded technology, and in particular to a firmware update method for an embedded Internet of Things device, an embedded Internet of Things device, a computer program product, and a computer-readable storage medium. Background Art

[0002] Firmware is a software program designed by software developers, which is converted into a binary executable file that can be used in embedded systems and IoT devices after being compiled and linked by a compiler. This type of firmware is stored in non-volatile storage media (such as Flash memory, hard disk drive, and USB flash memory, etc.), and can be read by the central processing unit (CPU) and loaded into the memory unit (such as random access memory (RAM)) when the device is started or running, so as to execute the firmware.

[0003] Remote firmware update is a solution that uses various Over-the-Air (OTA) technologies to send firmware update data packets to the device, which then stores and runs the new firmware. Through remote firmware updates, devices can promptly fix functional and security vulnerabilities, upgrade device functions, and improve user experience.

[0004] Against the backdrop of the rapid development of artificial intelligence technology and the fifth generation mobile communication (5G) network, the concept of the intelligent Internet of Things (AIoT) has gradually emerged, which means that more and more smart devices will be connected to the network, and "intelligent Internet of Everything" has become a new blueprint for the development of the new generation of networks. However, as the functions of smart IoT devices become more and more complex, more and more functions are integrated into the software, which leads to larger and larger compiled firmware, and thus more and more storage space and memory resources are required to implement firmware updates. This not only leads to an increase in the hardware cost of the device, but also increases the maintenance cost of communication traffic. In particular, some devices are deployed in a communication environment with low bandwidth and high network interference, and there is an urgent need to improve the success rate of firmware updates and ensure user experience. Summary of the invention

[0005] The present application aims to solve at least one of the technical problems existing in the prior art or related technology. To this end, the present application provides a firmware update method for an embedded Internet of Things device and an embedded Internet of Things device.

[0006] According to a first aspect of the present application, a firmware update method for an embedded Internet of Things device is provided, wherein the firmware is divided into two parts, namely, underlying firmware and application firmware, according to functions; the device comprises a boot loading partition, an underlying firmware partition, an application firmware partition and a cache partition, wherein the boot loading partition is used to store a boot loader, the underlying firmware partition is used to store underlying firmware, and the application firmware partition is used to store application firmware; the method comprises the following steps: in response to detecting a triggering event for updating the firmware of the device, obtaining firmware update data and writing it into a cache partition, wherein the firmware update data comprises at least one of underlying firmware update data and application firmware update data; and using the boot loader to process and load the firmware update data in the cache partition to perform a firmware update.

[0007] As an example, the underlying firmware may include underlying components for providing underlying functions and functional interfaces for running the firmware.

[0008] As an example, the underlying component may include at least one of a real-time operating system RTOS component, a communication component, an application development component, and a device driver component.

[0009] As an example, the underlying component may include at least one functional interface, and each functional interface is stored at a corresponding address unit in the underlying component.

[0010] As an example, the application firmware may be configured to define the functionality of the business logic by calling a functional interface of the underlying firmware.

[0011] As an example, the firmware update data may be compressed data, and the processing includes decompressing the compressed data to perform the firmware update.

[0012] As an example, the firmware update data may be full data, and executing the firmware update includes executing a full update.

[0013] As an example, the processing may include: acquiring integrity check parameter information from the firmware update data, performing integrity check on the data written to the cache partition; and executing firmware update in response to passing the integrity check.

[0014] As an example, the method may further include identifying a function type of the firmware update data and performing firmware update according to the function type, wherein the function type includes an underlying firmware type or an application firmware type.

[0015] As an example, when the firmware update data may be application firmware update data, the step of using the boot loader to process and load the firmware update data in the cache partition to perform a firmware update may include: based on the application firmware update data, using the boot loader to perform verification and boot operation of the application firmware update data to perform an application firmware update.

[0016] As an example, when the firmware update data may be underlying firmware update data, and the firmware update data to be loaded is used to repair a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform a firmware update may include: determining an address unit corresponding to the functional interface, and modifying the underlying functional data at the corresponding address unit.

[0017] As an example, when the firmware update data may be underlying firmware update data, and the firmware update data to be loaded is used to add a functional interface of a new underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform a firmware update may include: determining an unused address unit; and adding new underlying functional data at the unused address unit as a new functional interface.

[0018] As an example, when the firmware update data may be underlying firmware update data and application firmware update data, and when the firmware update data to be loaded is used to delete a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform a firmware update may include: updating the application firmware to stop using the functional interface to be deleted, and setting the interface at the address unit of the functional interface to be deleted to an unavailable state.

[0019] According to a second aspect of the present application, there is also provided an embedded Internet of Things device, comprising a processor, a memory and a non-volatile storage, wherein the memory is used to store a computer program, and the processor is used to implement any of the above-mentioned firmware update methods when executing the computer program.

[0020] As an example, the non-volatile storage includes: a system parameter partition, which is used to store system configuration information of the device; a boot loader partition, which is used to store a boot loader, and the boot loader is configured to load firmware update data and perform firmware updates; the firmware update data includes at least one of underlying firmware update data and application firmware update data; an underlying firmware partition, which is used to store the underlying firmware of the business logic and provide underlying functions and functional interfaces for applying the firmware; an application firmware partition, which is used to store the application firmware of the business logic and is configured to define the functions of the business logic by calling the functional interface of the underlying firmware; a cache partition, which is used to store the acquired firmware update data.

[0021] According to a third aspect of the present application, a computer program product is also provided, which includes a computer program, and when executed by a processor, implements any of the above-mentioned firmware update methods.

[0022] According to a fourth aspect of the present application, there is also provided a computer storage medium on which a computer program is stored, which implements any of the above-mentioned firmware update methods when executed by a processor.

[0023] The firmware update method for embedded IoT devices provided in the embodiment of the present application divides the firmware into two parts according to the function: the underlying firmware and the application firmware. The application firmware defines the business function by using the calling interface of each function provided by the underlying firmware. Since the firmware fragments transmitted and cached are smaller in size, the present application can save transmission traffic and storage space, thereby saving hardware resources, reducing equipment costs, and can improve the rate of firmware updates and increase the success rate of firmware updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. The drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0025] Figure 1 A schematic diagram showing the division of storage space of an embedded device during a full update is shown.

[0026] Figure 2 A schematic diagram showing the division of storage space of an embedded device during compression update is shown.

[0027] Figure 3 A schematic diagram showing the division of storage space of an embedded device during differential update is shown.

[0028] Figure 4 A schematic diagram showing the division of firmware components of an embedded Internet of Things device according to an embodiment of the present application is shown.

[0029] Figure 5 A schematic diagram showing the division of the storage area of ​​the embedded Internet of Things device in an embodiment of the present application is shown.

[0030] Figure 6 A schematic diagram of a process flow of a firmware update method for an embedded Internet of Things device provided in an embodiment of the present application is shown.

[0031] Figure 7 A flowchart of a firmware loading and running method provided in an embodiment of the present application is shown.

[0032] Figure 8 A flowchart of a firmware update method provided in an embodiment of the present application is shown.

[0033] Fig. 9 An application schematic diagram of the firmware operation of the embedded Internet of Things device according to an embodiment of the present application is shown.

[0034] Fig.10 An application schematic diagram of firmware update of an embedded Internet of Things device according to an embodiment of the present application is shown.

[0035] Fig.11 A schematic diagram of a first process for executing underlying firmware update provided in an embodiment of the present application is shown.

[0036] Fig.12 A schematic diagram of a second process for executing underlying firmware update provided in an embodiment of the present application is shown.

[0037] Fig.13 A schematic diagram of a second process for executing underlying firmware update provided in an embodiment of the present application is shown.

[0038] Fig.14 A schematic diagram of the structure of an embedded Internet of Things device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0040] Generally, according to the way of processing the transmitted data during the firmware update process, the firmware update methods of embedded devices (also called devices) can be divided into three types: full update, compressed update and differential update (also called incremental update).

[0041] Figure 1The diagram shows the division of storage space of embedded devices during full update, where full update means that the complete new firmware data is transmitted to the device, and the device receives and applies the new firmware data to complete the firmware update. Figure 1 This solution usually divides the device's storage space into four partitions, including system parameter partition, bootloader partition, first firmware partition (i.e. app_0 partition), and second firmware partition (i.e. app_1 partition). The basic process of implementing remote firmware update in this solution includes the following steps:

[0042] 1. The device first runs the firmware of the app_0 partition. When the remote firmware update is started, the app_0 partition receives the new firmware new_app and stores the new firmware new_app in the app_1 partition. Then, the boot identification data of the system parameter partition is set to app_1, and finally the device is restarted.

[0043] 2. After the device restarts, in the bootloader stage, the bootloader firmware is run, and the boot partition of the device is checked to be app_1. Then the new firmware new_app of the app_1 partition is loaded and the new firmware of the app_1 partition is run. This completes a remote firmware update.

[0044] 3. Similarly, when the device is running the firmware in the app_1 partition, download the new firmware new_app to the app_0 partition, set the boot identification data of the system parameter partition to app_0, and restart the device.

[0045] 4. After the device restarts, in the bootloader stage, check that the device's boot partition is identified as app_0, then load and run the new firmware new_app of the app_0 partition to complete the firmware update.

[0046] This remote firmware update process is called a “ping-pong” update solution, which can simply and reliably perform the firmware update function, but requires the use of at least two storage areas that are comparable in size to the firmware.

[0047] Figure 2 The diagram shows the division of storage space of embedded devices during compression update, where compression update means that the development end device compresses the new firmware data and sends it to the device. After receiving the compressed data, the device performs a decompression operation and then runs the decompressed new firmware data to complete the firmware update.

[0048] This compression update solution can save traffic, save required storage space, and reduce device costs to a certain extent. However, this solution compresses the entire firmware, resulting in a large storage space for storing the compressed firmware, which still cannot meet the usage requirements of resource-constrained devices with small storage space.

[0049] Figure 3 The diagram shows the division of the storage space of the embedded device during differential update, wherein differential update means that the development end device performs differential processing on the new firmware data and the old firmware data, generates patch data, and transmits the patch data to the device; the device combines the received old firmware data and patch data, performs differential decoding operation to recover the new firmware data, so as to complete the firmware update.

[0050] This compression update solution can avoid excessive traffic and time consumption by obtaining smaller patch files. However, this solution requires reverse differentiation on the device side, which has a large memory overhead and is not suitable for low-cost devices with limited storage and memory resources.

[0051] In this regard, during the invention process, the present application innovatively conceives to divide the firmware into functions, and quickly updates the firmware of designated functions in a targeted manner, in order to meet the usage requirements of resource-constrained devices with small storage space.

[0052] In some embodiments, the present application proposes a firmware update method for an embedded Internet of Things device, wherein the firmware is divided into two parts: underlying firmware and application firmware according to function; the device includes a boot loader partition, an underlying firmware partition, an application firmware partition and a cache partition, wherein the boot loader partition is used to store the boot loader, the underlying firmware partition is used to store the underlying firmware, and the application firmware partition is used to store the application firmware.

[0053] Specifically, Figure 4 The schematic diagram of the division of the firmware components of the embedded Internet of Things device according to the embodiment of the present application is shown. According to the function, the firmware of a typical embedded Internet of Things device mainly includes the bottom firmware 401 and the application firmware 402.

[0054] The bottom firmware 401 is the bottom component of the device firmware, which can include real-time operating system (RTOS) components, communication components, application development components, and device driver components. Specifically, the RTOS component is a system component of the firmware, which can be an operating system component suitable for running on an embedded device such as FreeRTOS, μClinux, μC / OS-II, HuaweiLiteOS, RT-Thread, etc., responsible for the management of threads and processes on the device. The communication component can include a Wi-Fi component, a Bluetooth Low Energy (BLE) component, a Zigbee component, etc. These communication components are built into the embedded device, so that the device itself is configured to implement the components of these communication functions, so that users can develop applications based on these communication functions. The application development component can include a lightweight TCP / IP protocol stack (Light Weight IP, LWIP) component and a transport layer security protocol (TLS) component. The LWIP component supports a variety of network protocols including ARP, ICMP, UDP, and TCP, and is designed for embedded devices to achieve complete network functions with less resource consumption. The TLS component is used to protect the confidentiality, integrity and authenticity of the transmitted data of both communicating parties, and ensure the safe operation of the device. The device driver (DRIVERS) component is closely related to the implementation of the chip, and directly reflects the functional information and usage of the chip. Exemplarily, the underlying firmware 401 may also include a power management component for coordinating and managing the power parameters of the device. In short, these components are often necessary for specific models of chips and devices with specific functions, and are components that are not easily changed frequently. They provide a bottom-level calling interface for the user's upper-level applications.

[0055] The application firmware 402 is the application logic part of the device firmware, which defines the usage of the device through the application program. As an example, the application firmware can define functions such as which server address to report data to, which secure link protocol to use, the range of image brightness value control, how often to test power consumption, and the rendering optimization of the image displayed on the screen. In short, the application firmware is an application of the underlying components, and defines the specific functions and usage methods of the device by using the calling interface provided by the underlying components.

[0056] That is to say, the firmware of this application is divided into two parts according to the function: the underlying firmware and the application firmware. The underlying firmware is responsible for providing basic and dedicated functions of the device, such as task management, sending and receiving data, power consumption management and other functions. The application firmware is responsible for the specific business-related functions of the device by calling the interface of the underlying firmware. It should be noted that this application can split the above two types of firmware according to actual needs, and update the smaller firmware units that are split. This application does not make specific restrictions on this.

[0057] Specifically, Figure 5 The following is a schematic diagram showing the division of the storage area of ​​the embedded IoT device in the embodiment of the present application. The storage area can be divided into five parts, including:

[0058] 1. Bootloader partition: This partition is mainly used to store the bootloader program, which is mainly used to detect system parameters, determine whether to decompress, verify and load which application firmware to run.

[0059] 2. Bottom-level firmware partition: This partition is mainly used to store the bottom-level system firmware compiled and linked by the bottom-level components. As an example, the bottom-level system firmware refers to the firmware compiled by executing programs such as the bottom-level components of the device, including RTOS components, communication components, application development components, and device driver components.

[0060] 3. Application firmware partition: This partition is mainly used to store the application firmware of the device, which is used to define the business logic of the device and may also include the function of remotely downloading firmware.

[0061] 4. Cache partition: This partition is mainly used to store firmware downloaded remotely.

[0062] 5. System parameter partition: This partition is mainly used to store system configuration, network connection information, system boot parameters and other information. In actual devices, the data of this partition may be divided into multiple partitions for management. For the convenience of description, it is collectively referred to as the system parameter partition.

[0063] It should be noted that the underlying firmware partition of the present application is used to store part of the executable program, including the underlying executable data of the executable program such as RTOS, communication protocol stack, network protocol stack, etc. The system parameter partition is usually used to store system parameters that can be read and written (readable and writable, not executable) by the bootloader program, the underlying firmware of the application program, and the application firmware, such as the networking information of the storage device, the login information of the device, the radio frequency parameters of the device, and the address of the firmware of the application program to be loaded by the bootloader program.

[0064] Further, see Figure 6, which shows a schematic flow chart of a firmware update method for an embedded IoT device provided in an embodiment of the present application, the method comprising the following steps:

[0065] Step S601: in response to detecting a triggering event for updating the firmware of a device, obtaining firmware update data and writing the firmware update data into a cache partition, wherein the firmware update data includes at least one of underlying firmware update data and application firmware update data.

[0066] As an example, the triggering event may be: receiving a push message from the development end device indicating that there is an updated version of the firmware. The push message may include information such as the version number of the updated firmware, a download link for the updated firmware, and verification data. In addition, the triggering event may also be: sending a query request to the development end device to determine whether there is an updated version of the firmware, and receiving a reply message from the source device indicating that there is an updated version.

[0067] In some embodiments, the firmware update data may be full data, and executing the firmware update includes executing the full update. In some embodiments, the firmware update data may be compressed data, and the processing includes decompressing the compressed data to execute the firmware update. That is, the application firmware compiled by the development end device can be directly sent to the cache partition of the device end, or it can be sent to the cache partition of the device end after being compressed, so as to further reduce the size of the new firmware, thereby reducing the storage space consumption of the cache partition.

[0068] Step S602: Using the boot loader to process and load the firmware update data in the cache partition to perform firmware update.

[0069] In some embodiments, processing the firmware update data using the boot loader may include obtaining integrity check parameter information from the firmware update data, performing an integrity check on the data written to the cache partition; and executing a firmware update in response to passing the integrity check.

[0070] It can be understood that during the download phase of the firmware update, the firmware data can be resumable, and the downloaded firmware fragments can be decrypted, signed, and checked for verification codes. Similarly, during the boot loading phase, the firmware data can also be decrypted, signed, and checked for verification codes. This is not specifically explained here and is collectively referred to as data verification.

[0071] The following describes in detail the firmware loading and running method for the underlying firmware and application firmware of the present application, taking the firmware update process when the device leaves the factory and when the device is running as examples.

[0072] When the device leaves the factory, this application can pre-burn the firmware containing the block update function to the above partitions. As an example, when the device leaves the factory, the original bootloader firmware, the original underlying firmware, and the original application firmware are burned to the following partitions: Figure 5 The corresponding partitions shown. Among them, the functions in the bootloader firmware may include decompression, verification and other functions; the underlying firmware may include the underlying system functions required by the upper-level business logic, such as RTOS, LWIP, and OTA functional interfaces, and store the interfaces in different address sequences; the application firmware may include business logic functions and OTA download functions, and complete the business logic functions by calling the interfaces provided by the underlying firmware.

[0073] See also Figure 7 , which shows a flowchart of the firmware loading and running method provided in an embodiment of the present application. The process is particularly suitable for when the device leaves the factory or is in the burning stage, and specifically includes the following steps:

[0074] Step S701: The embedded device is powered on.

[0075] Step S702: Load the bootloader firmware and run it.

[0076] Step S703: Read the system update identifier of the system parameter partition.

[0077] Step S704: Determine whether to perform decompression update, if yes, proceed to step S705; if no, proceed to step S708.

[0078] Step S705: verify and check the compressed firmware of the cache partition.

[0079] Step S706: Determine whether the verification in step S705 is successful. If yes, proceed to step S707; if not, proceed to step S708.

[0080] Step S707: decompress the compressed firmware of the cache partition, and write the decompressed data into the firmware partition.

[0081] Specifically, the firmware partition includes an underlying firmware partition and an application firmware partition.

[0082] Step S708: Verify the firmware data of the underlying firmware and the application firmware.

[0083] Step S709: Determine whether the verification in step S708 is successful, if yes, proceed to step S710; if no, proceed to step S711.

[0084] Step S710: Load the application firmware to run and start executing the business logic.

[0085] Step S711: Execute exception handling.

[0086] As an example, exception handling may include not loading and running firmware that poses a security risk to ensure that the device is not cracked or attacked. Exception handling may also be restoring factory settings, which usually requires an additional partition to store a factory firmware. Exception handling may also be terminating device booting, automatically restarting, and attempting to decompress and load again after restarting. Exception handling may also be reporting an error and terminating operation. This application does not impose specific restrictions on this.

[0087] See also Figure 8 , which shows a flowchart of the firmware update method provided in an embodiment of the present application. The process is particularly suitable for a device after it leaves the factory or during operation, and specifically includes the following steps:

[0088] Step S801: The embedded device is powered on, the bootloader firmware is loaded and run, and the underlying firmware and application firmware are verified in the bootloader. If the verification passes, the process proceeds to step S802.

[0089] Step S802: Jump to the application firmware to execute the service function and wait for the message of OTA startup. If the message of OTA startup is received, go to step S803.

[0090] Step S803: Start the OTA task.

[0091] Step S804: Download the compressed OTA firmware fragment.

[0092] Specifically, the firmware fragment may be at least one of underlying firmware and application firmware.

[0093] Step S805: Store the downloaded OTA compressed firmware into the cache partition.

[0094] Step S806: verify and check the compressed firmware of the cache partition.

[0095] Step S807: Determine whether the verification in step S806 is successful, if yes, proceed to step S808; if no, proceed to step S810.

[0096] Step S808: Setting the system update flag of the system parameter partition.

[0097] Specifically, the system update identifier is used to at least indicate the underlying firmware partition or the application firmware partition. When the system update identifier indicates the underlying firmware partition, the new underlying firmware of the underlying firmware partition is loaded and run. When the system update identifier indicates the application firmware partition, the new application firmware of the application firmware partition is loaded and run.

[0098] Step S809: Execute device restart and enter the bootloader stage.

[0099] Specifically, the bootloader checks the system parameter partition and executes the firmware update. Optionally, the firmware update process includes executing the verification and decompression process, and performing verification on the decompressed data. If the verification is successful, it means that the updated new firmware is normal, and the new firmware program can be jumped to run. If the verification fails, it means that there is a security risk in the compressed firmware, and the exception handling program is entered.

[0100] Step S810: Report error information, where the error information indicates that the downloaded data is abnormal.

[0101] In some embodiments, the bottom firmware includes a bottom component for providing bottom functions and function interfaces for running the firmware. In some embodiments, the bottom component includes at least one of a real-time operating system (RTOS) component, a communication component, an application development component, and a device driver component. In some embodiments, the bottom component includes at least one function interface, and each function interface is stored at a corresponding address unit in the bottom component.

[0102] See also Fig. 9 , which shows an application diagram of the firmware operation of the embedded Internet of Things device of the embodiment of the present application. Taking the Internet of Things device that reports temperature data regularly as an example, the RTOS component of the underlying firmware provides a task creation interface task_create(), which is stored at the address unit 0x40000000, and the LWIP component provides a network sending interface lwip_send(), which is stored at the address unit 0x40001000. The application firmware is configured to define the functions of the business logic by calling the functional interface of the underlying firmware. As an example, continue to refer to Fig. 9 When running the firmware of the application firmware partition, the device can access the data at 0x40000000 and use the task_create() interface stored at this address unit to create a timed task with an interval of 2 seconds; the device can use the lwip_send() interface stored at the address unit 0x40001000 to send temperature data to the outside; similarly, the device can start the task of downloading the firmware fragment by calling ota_start() stored at the address unit 0x30000000 and store the firmware fragment in the cache partition.

[0103] In some embodiments, the method includes identifying a functional type of the firmware update data and performing the firmware update according to the functional type, wherein the functional type includes an underlying firmware type or an application firmware type.

[0104] In some embodiments, when the firmware update data is application firmware update data, in step S602, the step of using the boot loader to process and load the firmware update data in the cache partition to perform the firmware update includes: based on the application firmware update data, using the boot loader to perform verification and boot operation of the application firmware update data to perform the application firmware update. That is, as long as the interface function stored in the designated address unit of the underlying firmware is not changed, different versions of application firmware can always obtain the calling interface of the designated function at the corresponding address unit.

[0105] refer to Fig.10 , which shows an application schematic diagram of firmware update of an embedded IoT device according to an embodiment of the present application. When the updated firmware is application firmware, it is only necessary to compress the application firmware containing the new changes on the development side, and then start the download and verification program on the device side.

[0106] Specifically, taking the functional module of implementing the periodic reporting of temperature to the server through Wi-Fi wireless communication on an embedded device as an example, according to the function, the firmware of the device can be divided into the underlying firmware and the application firmware. The underlying firmware includes at least RTOS components, Wi-Fi components and LWIP components. The application component is related to the device application logic, and it uses the task_create() interface provided by the RTOS component to create a timed task. In this task, the lwip_send() interface of the LWIP component is called every 2s to send temperature data to the server. As an example, suppose that a new business logic needs to be added through the new firmware, such as adding a task of reporting humidity at a timed interval of 1s. In this case, the content of the underlying firmware partition does not need to be changed. It only needs to create a task of reporting humidity at a timed interval in the development end device, and send the compiled application firmware containing the new changes to the device end to perform the application firmware update. As another example, when the device function needs to be updated through firmware update, such as changing the time interval of the scheduled transmission from 2s to 1s. In this case, the content of the underlying firmware partition does not need to be changed, and it can be achieved by updating the application firmware.

[0107] The following are the full update, compressed update and the functional partition update scheme of this application, refer to Figure 1-2 and Figure 5 , taking the original firmware of 1.2M as an example, the storage resource consumption of each update scheme on the storage space is analyzed.

[0108] In the case of a full update, the firmware that needs to be transferred is 1.2M, and the storage space consumed is 1.2M+1.2M, totaling 2.4M.

[0109] In the case of compressed update, assuming a compression rate of 50%, the compressed firmware that needs to be transmitted is 0.6M, and the storage space consumed is 1.2M+0.6M, totaling 1.8M.

[0110] In this application, the original complete firmware is divided according to function, the storage space required for the underlying firmware is 0.6M, and the storage space required for the application firmware is 0.6M.

[0111] Without using the compression process, the application firmware that needs to be transmitted is 0.6M, and its storage space consumption is 0.6M+0.6M+0.6M, totaling 1.8M.

[0112] In the case of using the compression process, assuming the compression rate is 50%, the compressed application firmware that needs to be transmitted is 0.3M, and the storage space consumed is 0.6M+0.6M+0.3M, totaling 1.5M.

[0113] It can be seen that the present application partitions according to firmware functions, and when the compression process is not used, the storage space required is equivalent to that required by traditional compression updates; when combined with the compression process, the size of the firmware to be transmitted can be reduced, further reducing the transmission traffic and reducing the required storage space.

[0114] Specifically, in terms of the storage space required for OTA, compared with the usual full update solution and compressed update solution, the compressed firmware fragments are smaller in size, so it can save more storage space and thus reduce equipment costs. In terms of the transmission traffic required for OTA, the compressed firmware fragments of this application are smaller in size and save more transmission traffic. In terms of the memory resource consumption required for OTA, compared with differential updates, after OTA receives the compressed fragments, it only needs to decompress it, and does not involve caching the decompressed data and performing the reverse differential operation, and the required memory overhead is very small. In addition, after the application is partitioned according to the firmware function, if the size of the application firmware itself is very small, only a small compressed package needs to be updated each time to quickly complete the firmware update, which is conducive to improving the user experience, reducing the power consumption of the firmware update process, and increasing the success rate of the firmware update.

[0115] Therefore, the firmware update method of the present application is more suitable for IoT devices with limited storage resources, low communication rates, and cost sensitivity. In addition, compared with the existing soft-linkable operating systems for Linux, this system often requires expensive hardware modules (such as memory management units), and the upper-layer application calls the underlying system automatically managed by the MMU; while the storage medium for storing executable firmware in the present application can be a storage device such as flash and hard disk, which is suitable for low-cost IoT devices with limited software and hardware resources. In other words, the update object of the present application is mainly application-type firmware, which can update the data of various partitions in a compressed form, thereby saving storage space of storage media such as Flash.

[0116] See also Fig.11 , which shows a schematic diagram of the first process of performing underlying firmware update provided by an embodiment of the present application. In this embodiment, when the firmware update data is underlying firmware update data, and the firmware update data to be loaded is used to repair a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform the firmware update includes the following sub-steps:

[0117] Sub-step S1101: Determine the address unit corresponding to the functional interface, and

[0118] Sub-step S1102: modify the underlying functional data at the corresponding address unit.

[0119] As an example, see Fig.10 , if the device needs to fix the error by updating the underlying firmware, for example, to fix the lwip_send() interface at address unit 0x40001000. In this case, the content of the application firmware partition does not need to be changed. You only need to create a task to modify the data at 0x0x40001000 in the development device, and send the compiled underlying firmware containing the new changes to the device to perform the underlying firmware update.

[0120] See also Fig.12 , which shows a second schematic diagram of the process of performing underlying firmware update provided by an embodiment of the present application. In this embodiment, when the firmware update data is underlying firmware update data, and the firmware update data to be loaded is used for a functional interface of a newly added underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform the firmware update includes the following sub-steps:

[0121] Sub-step S1201: determining unused address units; and

[0122] Sub-step S1202: adding new underlying functional data at the unused address unit to serve as a new functional interface.

[0123] As an example, see Fig.10 If the device needs to add a new underlying interface by updating the underlying firmware, for example, a new functional interface can be added at an unused address unit (such as 0x50000000). In this case, the content of the application firmware partition does not need to be changed. You only need to create a task to add a new functional interface at the address unit 0x50000000 in the development device, and send the compiled underlying firmware containing the new changes to the device to perform the underlying firmware update.

[0124] See also Fig.13 , which shows a third schematic diagram of a process for executing a bottom-level firmware update provided by an embodiment of the present application. In this embodiment, when the firmware update data is bottom-level firmware update data and application firmware update data, and when the firmware update data to be loaded is used to delete a functional interface of a bottom-level component, the step of using a boot loader to process and load the firmware update data in a cache partition to execute a firmware update includes the following sub-steps:

[0125] Sub-step S1301: updating the application firmware to stop using the functional interface to be deleted, and

[0126] Sub-step S1302: setting the interface at the address unit of the functional interface to be deleted to an unavailable state.

[0127] As an example, see Fig.10 If the device needs to delete an underlying interface, it is necessary to create a task including application firmware and underlying firmware in the development device, first update the application firmware to stop using the underlying interface to be deleted, then update the underlying firmware to set the interface at the address unit of the underlying interface to be deleted to an unavailable state, and send the compiled underlying firmware containing the new changes to the device to execute the application firmware update and the underlying firmware update respectively.

[0128] In summary, in the firmware update method for embedded IoT devices provided in the embodiments of the present application, the application firmware defines business functions by using the calling interface of each function provided by the underlying firmware. As long as the address of the corresponding function provided by the underlying firmware is not changed, no matter which version of the application firmware is, the function provided at that address can be used to complete the modification and update of the relevant business logic. This ensures that the business logic of the device can be redefined by only updating the application firmware; and by only updating the application firmware, a smaller, faster, and more storage-saving compressed update can be achieved. In addition, the present application also provides several processing strategies that require updating the underlying firmware to improve device functions. This solution is particularly suitable for embedded and IoT devices that are cost-sensitive, have limited storage resources, and have limited memory resources.

[0129] In this embodiment, the above modules can be implemented in whole or in part by software, hardware, or a combination thereof. The above modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to the above modules.

[0130] See also Fig.14 The embodiment of the present application also provides an embedded Internet of Things device 14, including a processor 1401, a memory 1402 and a non-volatile storage 1403. The memory 1402 stores a computer program. When the processor executes the computer program, the execution steps of the firmware update method in the above embodiments can be implemented.

[0131] In some embodiments, the non-volatile storage includes a system parameter partition, a boot loading partition, an underlying firmware partition, an application firmware partition, and a cache partition. The system parameter partition is used to store system configuration information of the device. The boot loading partition is used to store a boot loader, which is configured to load firmware update data and perform firmware updates; the firmware update data includes at least one of underlying firmware update data and application firmware update data. The underlying firmware partition is used to store the underlying firmware of the business logic, providing underlying functions and functional interfaces for applying the firmware. The application firmware partition is used to store the application firmware of the business logic, and is configured to define the functions of the business logic by calling the functional interface of the underlying firmware. The cache partition is used to store the acquired firmware update data.

[0132] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, can implement the execution steps of the firmware update method in the above-mentioned embodiments.

[0133] An embodiment of the present application also provides a computer storage medium on which a computer program is stored. When the computer program is executed by a processor, the execution steps of the firmware update method in the above-mentioned embodiments can be implemented.

[0134] In the above embodiments, the implementation principles and beneficial effects of the embedded Internet of Things device, computer-readable storage medium, computer program product and computer storage medium can be found in the above description of the firmware update method for the embedded Internet of Things device, which will not be repeated here.

[0135] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magneto resistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0136] Although various embodiments of various aspects of the present application have been described for the purpose of the present disclosure, it should not be understood that the teachings of the present disclosure are limited to these embodiments. Features disclosed in a specific embodiment are not limited to that embodiment, but can be combined with features disclosed in different embodiments. For example, one or more features and / or operations of the method according to the present application described in one embodiment may also be applied individually, in combination or as a whole in another embodiment. Those skilled in the art should understand that there are also possible more optional embodiments and variations, and various changes and modifications can be made to the above-mentioned system without departing from the scope defined by the claims of the present application.

Claims

1. A firmware update method for an embedded Internet of Things device, characterized in that: The firmware is divided into two parts, the bottom firmware and the application firmware, according to the function; the device includes a boot loader partition, a bottom firmware partition, an application firmware partition and a cache partition, wherein the boot loader partition is used to store the boot loader, the bottom firmware partition is used to store the bottom firmware, and the application firmware partition is used to store the application firmware; the method includes the following steps: In response to detecting a triggering event for updating the firmware of the device, obtaining firmware update data and writing it into a cache partition, wherein the firmware update data includes at least one of underlying firmware update data and application firmware update data; The firmware update data in the cache partition is processed and loaded using the boot loader to perform a firmware update.

2. The method according to claim 1, characterized in that The underlying firmware includes underlying components for providing underlying functions and functional interfaces for running the firmware.

3. The method according to claim 2, characterized in that The underlying component includes at least one of a real-time operating system RTOS component, a communication component, an application development component, and a device driver component.

4. The method according to claim 3, characterized in that The underlying component includes at least one functional interface, and each functional interface is stored at a corresponding address unit in the underlying component.

5. The method according to claim 1, characterized in that The application firmware is configured to define the functions of the business logic by calling the functional interface of the underlying firmware.

6. The method according to claim 1, characterized in that The firmware update data is compressed data, and the processing includes decompressing the compressed data to perform the firmware update.

7. The method according to claim 1, characterized in that The firmware update data is full data, and executing the firmware update includes executing a full update.

8. The method according to claim 1, characterized in that The processing includes: Acquire integrity check parameter information from the firmware update data, and perform integrity check on the data written to the cache partition; In response to the integrity check passing, a firmware update is performed. 9 . The method according to claim 1 , further comprising identifying a function type of the firmware update data and performing firmware update according to the function type, wherein the function type comprises an underlying firmware type or an application firmware type.

10. The method according to claim 1, characterized in that When the firmware update data is application firmware update data, the step of using the boot loader to process and load the firmware update data in the cache partition to perform firmware update includes: Based on the application firmware update data, the boot loader is used to perform verification and boot operation of the application firmware update data to perform application firmware update.

11. The method according to claim 4, characterized in that When the firmware update data is underlying firmware update data, and the firmware update data to be loaded is used to repair a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform firmware update includes: Determine the address unit corresponding to the functional interface, and Modify the underlying function data at the corresponding address unit.

12. The method according to claim 4, characterized in that When the firmware update data is underlying firmware update data, and the firmware update data to be loaded is used to add a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform firmware update includes: determining unused address locations; and New underlying functional data is added at the unused address unit to serve as a new functional interface.

13. The method according to claim 4, characterized in that When the firmware update data is underlying firmware update data and application firmware update data, and when the firmware update data to be loaded is used to delete a functional interface of an underlying component, the step of using the boot loader to process and load the firmware update data in the cache partition to perform firmware update includes: Update the application firmware to stop using the functional interface to be removed, and The interface at the address unit of the functional interface to be deleted is set to an unavailable state.

14. An embedded Internet of Things device, characterized in that: include: A processor, a memory and a non-volatile storage, wherein the memory is used to store a computer program, and the processor is used to implement the firmware update method of the embedded Internet of Things device according to any one of claims 1 to 13 when executing the computer program.

15. The embedded Internet of Things device according to claim 14, characterized in that: The non-volatile storage includes: System parameter partition, which is used to store the system configuration information of the device; A boot loader partition for storing a boot loader, wherein the boot loader is configured to load firmware update data and perform firmware update; the firmware update data includes at least one of underlying firmware update data and application firmware update data; The underlying firmware partition is used to store the underlying firmware of the business logic and provide underlying functions and functional interfaces for applying the firmware; An application firmware partition, which is used to store application firmware of business logic and is configured to define the functions of the business logic by calling the functional interface of the underlying firmware; A cache partition is used to store acquired firmware update data.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.

17. A computer storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.

Images