Embedded device firmware update methods, embedded devices and development equipment

Abstract

This application discloses an embedded device firmware update method, an embedded device, a development device, and an embedded device firmware update system. The embedded device obtains patch data from a source device, decompresses it to obtain raw differentially encoded data, and then obtains data blocks from the raw differentially encoded data in stages. Based on a status flag indicating the current operation, corresponding operations are performed on each data block until differential decoding of the raw differentially encoded data is completed. This application can perform differential decoding in stages, and the data obtained after differential decoding can be written to a designated storage partition in a timely manner, avoiding the temporary storage of too much data in memory and thus reducing the consumption of device memory. This allows the incremental update method to run normally even on resource-constrained IoT devices with limited memory. Furthermore, the memory consumption in the incremental update scheme provided by this application can be flexibly controlled, and it can be used in conjunction with various algorithms that support streaming decompression, resulting in better scalability.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to an embedded device firmware update method, an embedded device, a development device, and an embedded device firmware update system. Background Technology

[0002] The rapid development of IoT technology has facilitated the widespread use of low-cost embedded devices. These devices are widely deployed in smart homes, smart industries, and healthcare applications, performing functions such as intelligent sensing, intelligent control, and intelligent networking. In embedded devices, firmware is typically stored on non-volatile storage devices such as flash memory, SD cards, and solid-state drives. After the device boots up, the stored firmware is loaded into RAM to execute the specified functions. Firmware defines the product's main functions, and device manufacturers frequently use FOTA (Firmware Over the Air) remote firmware update technology to rapidly iterate on the device software to meet market demands for product functionality, improve user experience, and remotely fix firmware security vulnerabilities.

[0003] One of the fundamental requirements for firmware updates is the transmission of the update firmware data to the device being updated. Based on the method of processing the transmitted update firmware data, firmware updates can be categorized into the following types:

[0004] (1) Full update: This firmware update method directly sends the compiled and generated update firmware to the device to be upgraded;

[0005] (2) Compression update: This firmware update method compresses the compiled update firmware data using a compression algorithm, and then sends the compressed data to the device to be upgraded.

[0006] (3) Incremental update (also known as differential update): such as Figure 1 As shown, this firmware update method can be divided into two processes: generating patch data and applying patch data. On the development device, patch data is obtained by differentially analyzing the updated firmware data and the old firmware data. On the embedded device, the updated firmware data is recovered by receiving the patch data and combining it with the old firmware data.

[0007] Among the methods described above, incremental firmware updates are more suitable for scenarios where the updated firmware data differs little from the old firmware data. When the differences between the updated and old firmware data are small, such as when only some system parameters are changed or a small piece of code is inserted, compared to full updates and compressed updates, incremental firmware updates only need to transmit the difference information between the updated and old firmware data. Therefore, the amount of data that needs to be transmitted is smaller, which can save firmware update bandwidth, improve update success rate, and ensure the stability of the IoT system.

[0008] However, since IoT systems typically consist of a series of devices with varying hardware and software resources, the available memory sizes of these devices differ, making it difficult to deploy the same incremental update scheme across devices with different resources. Furthermore, current methods for performing firmware updates using incremental updates consume significant memory, thus preventing this method from running on resource-constrained IoT devices.

[0009] Therefore, designing an incremental update scheme that allows for flexible configuration of resource consumption, good scalability, and operation on resource-constrained IoT devices is one of the urgent technical problems to be solved in this field.

[0010] It should be understood that the technical problems listed above are merely examples and not limitations on the present invention. The present invention is not limited to technical solutions that simultaneously solve all of the above-mentioned technical problems. The technical solutions of the present invention can be implemented to solve one or more of the above-mentioned or other technical problems. Summary of the Invention

[0011] To address the above and other issues, this application provides an embedded device firmware update method, applied to the embedded device, the method comprising:

[0012] Patch data is obtained from the source device. The patch data is data obtained after compressing the original differentially encoded data. The patch data is a part of the data in the patch file.

[0013] The patch data is decompressed to obtain the original differential encoded data. The original differential encoded data is the data after differential processing and encoding of the old firmware data and the updated firmware data. The original differential encoded data includes multiple data blocks, each of which includes control data, difference data and additional data.

[0014] Data blocks in the original differentially encoded data are acquired in stages, and corresponding operations are performed on the data blocks according to the status identifier used to indicate the current operation, until differential decoding of the original differentially encoded data is completed.

[0015] Optionally, performing corresponding operations on the data blocks based on the status identifier used to indicate the currently performed operation includes:

[0016] If the status identifier is a first identifier indicating that the operation of reading the control data is performed, then the control data is read;

[0017] If the status identifier is a second identifier indicating the operation of adding the difference data, then the difference data is read into a pre-allocated buffer in several steps according to the control data to perform the addition operation, wherein the data length of a single addition operation does not exceed the preset buffer length;

[0018] If the status identifier is a third identifier indicating the operation of copying the additional data, then the additional data is read into the buffer in batches according to the control data to perform the copy operation, wherein the data length of a single copy operation does not exceed the preset buffer length;

[0019] The data obtained after performing the addition or copy operation is written to the storage partition of the embedded device.

[0020] Optionally, the patch file further includes file header information, and after obtaining the patch data from the source device, it also includes:

[0021] Read the file header information from the patch file;

[0022] If the status identifier is a fourth identifier indicating that the file header information is to be verified, then the file header information is verified according to the file header information;

[0023] If the verification passes, the status identifier will be changed from the fourth identifier to the first identifier.

[0024] Optionally, after reading the control data, the method further includes:

[0025] After reading complete control data, the status identifier is changed from the first identifier to the second identifier.

[0026] Optionally, after reading the difference data into a pre-allocated buffer in stages according to the control data and performing the addition operation, the method further includes:

[0027] Based on the number of bytes of difference data in the data block indicated in the control data, determine whether the addition operation for the data block has been completed;

[0028] If so, the status identifier is changed from the second identifier to the third identifier.

[0029] Optionally, after the additional data is read into the buffer in installments according to the control data and the copy operation is performed, the method further includes:

[0030] Based on the number of bytes of additional data in the data block indicated in the control data, determine whether the copy operation for the data block is complete;

[0031] If so, the status identifier is changed from the third identifier to the first identifier.

[0032] Optionally, the preset buffer length can be adjusted according to the actual memory of the embedded device.

[0033] Optionally, the preset buffer length is stored in the file header information of the patch file.

[0034] Optionally, the state identifier is indicated by a set state machine.

[0035] Optionally, decompressing the patch data includes:

[0036] The patch data is decompressed using a decompression algorithm that supports streaming decompression.

[0037] This application also provides an embedded device, including: a first memory and a first processor, wherein the first memory is used to store a computer program, and the first processor is used to implement any of the above-described embedded device firmware update methods when executing the computer program.

[0038] This application also provides a firmware update method for an embedded device, applied to a development device, the method comprising:

[0039] Identify similar matching regions between old firmware data and updated firmware data, perform differential processing on the data in the similar matching regions, and encode them as difference data;

[0040] Encode the data between two similar matching regions as additional data;

[0041] Based on the difference data and the additional data, control data is generated;

[0042] The generated control data, difference data, and additional data are written into data blocks, and multiple data blocks are arranged to obtain the original differential encoded data.

[0043] The original differentially encoded data is compressed to generate patch data for firmware updates of the embedded device. The patch data is a portion of the data in the patch file.

[0044] Optionally, after generating the patch data for updating the embedded device firmware, the method further includes:

[0045] Package the patch data to generate a patch file;

[0046] The patch file is sent to the source device for storage so that the embedded device can obtain the patch data from the patch file from the source device.

[0047] Optionally, the patch file may also include file header information, which includes the decompression algorithm to be used by the embedded device, the decompression level, verification information for verification, and a preset buffer length.

[0048] This application also provides a development device, including: a second memory and a second processor, wherein the second memory is used to store a computer program, and the second processor is used to implement any of the above-described embedded device firmware update methods when executing the computer program.

[0049] This application also provides an embedded device firmware update system, including the aforementioned embedded device and a source device; the source device stores a patch file for updating the firmware of the embedded device, the patch data being a portion of the data in the patch file, and the patch data being data obtained by compressing the original differential encoded data.

[0050] Optionally, the source device can be a development device, a cloud device, or another device in the network where the embedded device is located.

[0051] The embedded device firmware update method provided in this application involves the embedded device obtaining patch data from a source device, decompressing the patch data to obtain raw differential encoded data, which is data obtained by differential processing and encoding of old firmware data and updated firmware data. The raw differential encoded data includes multiple data blocks, each of which includes control data, difference data, and additional data. The method involves obtaining data blocks from the raw differential encoded data in stages, and performing corresponding operations on each data block according to a status flag indicating the current operation, until differential decoding of the raw differential encoded data is completed.

[0052] The solution provided in this application allows embedded devices to obtain only a portion of the patch file data during firmware updates, instead of directly obtaining the complete patch file. This avoids excessive storage pressure on the device caused by the large amount of data temporarily stored when obtaining the patch file. Data can be obtained in stages and processed in a timely manner. By obtaining data blocks from the original differentially encoded data in stages and using status flags to indicate the current operation, corresponding operations can be performed on the control data, differential data, and additional data in each data block. Differential decoding processing is performed in stages, and the data obtained after differential decoding can be written to the designated storage partition in a timely manner, without needing to perform operations after obtaining the complete data block. This avoids storing too much data in memory, which would consume device memory. Therefore, this incremental update method can run normally even on resource-constrained IoT devices with limited memory.

[0053] Furthermore, the incremental update scheme provided in this application allows for flexible control of memory consumption, enabling it to run not only on devices with large memory resources but also on devices with smaller memory resources by setting the buffer value. Additionally, the scheme can be combined with various algorithms that support streaming decompression, resulting in better scalability.

[0054] In addition, this application also provides an embedded device, a development device, and an embedded device firmware update system that have the above-mentioned technical advantages. Attached Figure Description

[0055] In the following text, this application will be further explained with reference to the accompanying drawings and embodiments.

[0056] Figure 1 This diagram illustrates the incremental update process.

[0057] Figure 2 This illustration schematically shows the settings of the embedded device storage partition in the embedded device firmware update method provided in this application;

[0058] Figure 3 A flowchart illustrating a specific implementation of the embedded device firmware update method provided in this application is shown.

[0059] Figure 4 This diagram illustrates the generation of difference data and additional data in the original differentially encoded data.

[0060] Figure 5 This schematically illustrates a specific representation of the original differentially encoded data;

[0061] Figure 6This diagram illustrates the generation of updated firmware data based on old firmware data and raw differentially encoded data.

[0062] Figure 7 This diagram illustrates the process of generating patch data on the development device.

[0063] Figure 8 This schematically illustrates a flowchart of the incremental firmware update process in an embedded device.

[0064] Figure 9 A flowchart illustrating another specific embodiment of the embedded device firmware update method provided in this application is shown schematically.

[0065] Figure 10 This diagram illustrates the process of using the allocated memory according to the method provided in this application.

[0066] Figure 11 This illustration schematically shows a decoding process in another specific embodiment of the embedded device firmware update method provided in this application;

[0067] Figure 12 A schematic block diagram of the embedded device provided in this application is shown.

[0068] Figure 13 A flowchart illustrating yet another specific embodiment of the embedded device firmware update method provided in this application is shown.

[0069] Figure 14 A schematic diagram of the development terminal device provided in this application is shown.

[0070] Figure 15 A schematic block diagram of the embedded device firmware update system provided in this application is shown. Detailed Implementation

[0071] The methods, apparatus, and systems of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments shown in the drawings and described below are merely illustrative and are not intended to limit the scope of this application.

[0072] Figure 2 This illustrates the settings of the embedded device storage partition in the embedded device firmware update method provided in this application. (Refer to...) Figure 2 The embedded device's storage area includes a first firmware partition, a second firmware partition, a bootloader partition, and a system parameter partition.

[0073] The bootloader partition stores the bootloader program, which is used to detect system parameters, verify firmware, and determine which firmware to load and run.

[0074] The system parameter partition is used to store system configuration, network connection information, system boot parameters, and other information. It is understood that this system parameter partition can be divided into multiple partitions for management in actual embedded devices; this is not a limitation here.

[0075] The first firmware partition is used to store the first firmware, and the second firmware partition is used to store the second firmware. It is understood that each firmware can implement the functionality of the embedded device firmware update method provided in this application.

[0076] The specific process of implementing embedded device firmware updates using the first firmware is as follows: When the embedded device runs the first firmware, patch data is obtained from the source device and combined with the firmware data in the first firmware to restore and update the firmware data in stages, and then the updated firmware data is written to the second firmware partition. System parameters are changed to set the second firmware as the bootable firmware. The system restarts, and after restarting, the bootloader loads and runs the updated firmware data in the second firmware partition according to the system parameters.

[0077] The specific process of implementing embedded device firmware updates via the second firmware is as follows: When the embedded device runs the second firmware, patch data is obtained from the source device and, combined with the firmware data in the second firmware, the updated firmware data is restored in stages and written to the first firmware partition. System parameters are changed to set the first firmware as the bootable firmware. The system restarts, and after restarting, the bootloader loads and runs the updated firmware data in the first firmware partition according to the system parameters.

[0078] Using the above method, a "ping-pong upgrade" of embedded devices can be achieved, so that the function of incrementally updating embedded devices can be executed stably.

[0079] Figure 3 A flowchart illustrating a specific embodiment of the embedded device firmware update method provided in this application is shown. Figure 3 As shown, this method is applied to embedded devices and specifically includes the following steps:

[0080] S101: Obtain patch data from the source device, wherein the patch data is data obtained by compressing the original differential coded data;

[0081] When performing firmware updates, embedded devices can obtain patch data from a source device. It should be understood that, in this document, "source device" refers to any computing device that provides patch data to the embedded device whose firmware is to be upgraded. For example, a source device can be a cloud server, a local server, a node in a mesh network, or a device in a Bluetooth Low Energy (BLE) network. It should be understood that the source device can be located in the cloud or locally. Communication between the source device and the embedded device can be achieved via Wi-Fi, Bluetooth, ZigBee, Ethernet, etc., and the specific implementation method is compatible with various communication methods and is not limited here.

[0082] Patch data can be generated by compressing the original differentially encoded data on the development device and stored on the development device, or the patch data can be sent to the source device. That is, the embedded device whose firmware is to be upgraded can obtain patch data directly from the development device, or it can obtain patch data from other devices that store patch data, and neither of these will affect the implementation of this application.

[0083] It is understood that the patch file is the complete data obtained after compressing the original differentially encoded data. The patch data, however, is a portion of the data within the patch file. In this application, when the embedded device updates its firmware, it can avoid directly obtaining the complete patch file, thus preventing excessive storage pressure on the device due to the large amount of data that needs to be temporarily stored. By obtaining the patch data, this application allows for timely, phased processing of the acquired data.

[0084] S102: Decompress the patch data to obtain the original differential encoded data.

[0085] The patch data is decompressed to obtain the raw differential encoded data. The raw differential encoded data is the data after differential processing and encoding of the old firmware data and the updated firmware data. The raw differential encoded data includes multiple data blocks, each of which includes control data, difference data, and additional data.

[0086] Specifically, this can be achieved by identifying similar matching regions between the old firmware data and the updated firmware data, performing differential processing on the data in these similar matching regions, and encoding them as diff data. The data between two similar matching regions is then encoded as extra data. For example... Figure 4 As shown, the diff1 and extra1 data are the original differential encoded data corresponding to the first similar matching region.

[0087] Based on the aforementioned difference data and additional data, control data (ctrl data) is generated. ctrl data can be a ternary array (x, y, z), where x represents the number of bytes in the diff data, y represents the number of bytes in the extra data, and z records the offset address of the original data corresponding to the diff data in the old firmware data.

[0088] The generated control data, differential data, and additional data are written into data blocks, and multiple data blocks are arranged to generate raw differential encoded data for firmware updates of the embedded device.

[0089] As one specific implementation method, the generated control data, difference data, and additional data can be written into a data block sequentially, and this operation can be repeated, continuously pressing Ctrl+... i diff i extra i (i = 0, 1, 2...) are written until the entire updated firmware is processed. A specific representation of this raw differentially encoded data is as follows: Figure 5 As shown.

[0090] S103: Acquire data blocks in the original differential encoded data in batches, and perform corresponding operations on the data blocks according to the status flag used to indicate the current operation, until differential decoding of the original differential encoded data is completed.

[0091] Data blocks from the raw differentially encoded data are acquired in stages, and corresponding operations are performed on the acquired data blocks according to their status identifiers. For data blocks in the raw differentially encoded data, a simultaneous download, decompression, and decoding operation can be performed. For example, if 30 bytes of data are acquired from the source device, these 30 bytes of data can be decompressed. If 60 bytes of raw differential data are obtained after decompression, then this 60 bytes of raw differential data are used to perform differential decoding operations.

[0092] Specifically, performing corresponding operations on the data blocks based on the status identifiers indicating the currently performed operation may include:

[0093] If the status identifier is a first identifier indicating that the operation of reading the control data is performed, then the control data is read;

[0094] If the status identifier is a second identifier indicating the operation of adding the difference data, then the difference data is read into a pre-allocated buffer in several steps according to the control data to perform the addition operation, wherein the data length of a single addition operation does not exceed the preset buffer length;

[0095] If the status identifier is a third identifier indicating the operation of copying the additional data, then the additional data is read into the buffer in batches according to the control data to perform the copy operation, wherein the data length of a single copy operation does not exceed the preset buffer length.

[0096] In this process, the data obtained after each addition or copy operation is written to the storage partition of the embedded device. It is understood that this storage partition corresponds to the storage partition used for firmware updates. For example, when running the first firmware, the data obtained after each addition or copy operation is written to the second firmware partition in real time. When running the second firmware, the data obtained after each addition or copy operation is written to the first firmware partition in real time. The solution provided in this application can promptly consume the data currently stored in the buffer, so that the buffer can be reused for subsequent data operations.

[0097] In one specific implementation, the Ctrl data in the data block can be read first. Then, an addition operation is performed, specifically by reading the diff data and retrieving the old firmware data based on the offset address of the original data corresponding to the diff data recorded in the Z-file of the control data within the old firmware data. For example... Figure 6 As shown, the old firmware data is added to the diff data to obtain the updated firmware data, which is then written to the embedded device's storage partition. Next, a copy operation is performed, specifically copying the extra data from the data block and writing it to the embedded device's storage partition. This process is repeated until all data blocks have undergone the corresponding operations, at which point the updated firmware is stored in the embedded device's storage partition.

[0098] The solution provided in this application allows embedded devices to obtain only a portion of the patch file data during firmware updates, instead of directly obtaining the complete patch file. This avoids excessive storage pressure on the device caused by the large amount of data temporarily stored when obtaining the patch file. Data can be obtained in stages and processed in a timely manner. Status flags are used to indicate the currently executed operation, allowing corresponding operations to be performed on control data, differential data, and additional data in each data block. Differential decoding is performed in stages, and the data obtained from differential decoding can be written to the designated storage partition in a timely manner, without needing to perform operations after obtaining the complete data block. This avoids storing too much data in memory, thus preventing excessive consumption of device memory. Therefore, this incremental update method can operate normally even on resource-constrained IoT devices with limited memory.

[0099] Furthermore, some existing incremental update methods can only handle firmware corresponding to certain embedded platform devices, requiring specific compilation techniques and firmware formats of the embedded device to function correctly. For example, the Courgette algorithm and the Exediff algorithm are used to update Google Chrome and Windows applications, respectively. The method provided in this application, however, is independent of the embedded device architecture and compiler, thus supporting cross-platform use.

[0100] Furthermore, in existing differential upgrade schemes, some schemes store the original differential encoded data (including in memory or physical storage space), which requires additional physical storage space; others require storing the entire received original differential encoded data in memory to run the incremental update algorithm. However, when the original differential encoded data is too large, the required memory space becomes very large, which may prevent the update or require breaking down the large changes involved in the update into multiple smaller changes and performing multiple incremental updates to complete the final update, leading to update failure or low efficiency. This also necessitates expanding physical storage space (such as RAM) and increases device costs. The scheme adopted in this application, by recording the status flags during the differential decoding process, executes the differential decoding operation in a timely manner. The differential decoded data can be written to a designated storage partition in real time, thus avoiding excessive data being temporarily stored in memory. Compared with existing incremental update schemes, this scheme also does not require setting up additional patch data storage space in physical storage space.

[0101] Understandably, patch data can be generated on development devices with abundant computing and memory resources. The generated patch data can be stored on the development device itself, meaning the development device can act as a source device. Alternatively, the generated patch data can be sent to other source devices for storage, such as cloud devices. Embedded devices can communicate with the source devices to obtain the patch data.

[0102] Furthermore, embodiments of this application can also add file header information to the compressed original differentially encoded data, such as... Figure 5 As shown, file header information is added before multiple data blocks.

[0103] like Figure 7 As shown, the process of generating patch data on the development device can specifically include:

[0104] S201: Differential processing and encoding are performed on the old firmware data and the updated firmware data to obtain uncompressed raw differential encoded data;

[0105] S202: Compress the uncompressed raw differential coded data to obtain compressed raw differential coded data;

[0106] S203: Add header information to the compressed raw differentially encoded data to obtain patch data that can be used for incremental upgrades of embedded device firmware. The patch data is a portion of the patch file. After generating the patch data, the process may also include packaging the patch data into a patch file.

[0107] In one specific implementation, the file header information may include the decompression algorithm to be used by the embedded device, the decompression level, verification information used for validation, and the preset buffer length. Of course, other information may also be included, which is not limited here.

[0108] After receiving patch data from the source device, the embedded device decompresses the patch data to obtain the original differentially encoded data, and then performs differential decoding operations corresponding to the differential encoding. Furthermore, in addition to the file header information included in the original differentially encoded data, the embedded device may optionally include operations to parse the file header information, and may further include operations to verify the file header information. Figure 8 As shown, the process of incremental firmware update in an embedded device can specifically include:

[0109] S301: After receiving the trigger event for executing the firmware incremental update, receive the file header information in the patch file;

[0110] The triggering event can be: receiving a push notification from the source device indicating that a firmware update exists. This push notification may include the firmware version number, download link, and verification data. Alternatively, the triggering event can be: sending a query request to the source device to check for a firmware update and receiving a response from the source device confirming the update exists. The embedded device can periodically or proactively send this query request to the source device upon each power-on. Upon receiving this triggering event, the subsequent steps for incremental firmware updates are initiated.

[0111] S302: Read the file header information and verify the file header information;

[0112] By verifying the file header information, we can confirm whether there are any errors in the file header data, thereby ensuring the security of the system.

[0113] S303: Obtain patch data from the source device, wherein the patch data is data obtained by compressing the original differential coded data;

[0114] S304: Decompress the patch data to obtain the original differential encoded data;

[0115] The decompression of the patch data includes using a decompression algorithm that supports streaming decompression. For example, any one or any combination of the xz algorithm, lz77 algorithm, and lzw algorithm can be used.

[0116] S305: Take the original differential encoded data as input, perform differential decoding, and write the decoded data to the specified storage partition;

[0117] S306: Determine whether the firmware update is complete. If not, return to S303; if yes, end.

[0118] Understandably, during incremental firmware updates in embedded devices, the main memory consumption occurs during decompression and differential decoding. The memory consumption for decompression can be adjusted by changing the compression level of the decompression algorithm or using different compression algorithms. Table 1 below lists the decompression memory required for different compression levels of common compression algorithms suitable for embedded platforms, such as xz and lzw. After determining the memory required for decompression, the memory consumption of the differential decoding process becomes the main factor affecting the overall memory consumption of embedded devices.

[0119] Table 1

[0120] name Compression levels Extract memory (KB) xz 8 32 xz 9 38 lzw 4 16 lzw 6 64

[0121] Reference Figure 9 A flowchart of another specific implementation of the embedded device firmware update method provided in this application elaborates on the decoding process performed by S305 in the above embodiment. This process may specifically include:

[0122] S401: Read file header information;

[0123] S402: If the status identifier is a fourth identifier indicating that the file header information is to be verified, then the file header information is verified according to the file header information;

[0124] S403: If the verification passes, the status identifier is changed from the fourth identifier to the first identifier;

[0125] S404: Control data for reading data blocks from the raw differential encoded data;

[0126] S405: After reading a complete set of control data, change the status identifier from the first identifier to the second identifier;

[0127] S406: The difference data is read into the buffer in batches according to the control data and an addition operation is performed, wherein the length of the data for a single addition operation does not exceed the preset buffer length;

[0128] S407: Based on the number of bytes of difference data in the data block indicated in the control data, determine whether the addition operation for the data block has been completed;

[0129] S408: If so, change the status identifier from the second identifier to the third identifier;

[0130] S409: The additional data is read into the buffer in batches according to the control data and a copy operation is performed, wherein the length of the data in a single copy operation does not exceed the preset buffer length;

[0131] S410: Based on the number of bytes of additional data in the data block indicated in the control data, determine whether the copying operation for the data block is complete;

[0132] S411: If so, change the status identifier from the third identifier to the first identifier;

[0133] S412: Determine whether differential decoding has been completed for all data blocks of the original differentially encoded data; if yes, return to S404; otherwise, end.

[0134] The data obtained after each addition or copy operation is written to the storage partition of the embedded device.

[0135] It is understood that, in this application, the buffer is a software entity that performs operations and is pre-allocated from the memory of the embedded device.

[0136] The buffer length can be preset. As an optional implementation, developers can determine the appropriate buffer length and set it accordingly after performing simulated OTA testing locally. Of course, the preset buffer length can also be dynamically adjusted based on the actual memory of the embedded device, thereby making full use of memory.

[0137] As one specific implementation, the buffer length to be used can be set in the file header information. The specific value of the buffer length can be obtained by reading the file header information.

[0138] After setting the buffer length, when the length of the difference or additional data in one segment of multiple data blocks exceeds the preset buffer length, the difference or additional data is processed in stages. Specifically, the length of data for a single addition or copy operation does not exceed the preset buffer length. By adopting the staged processing method of this application, even with a large amount of data, the received data can be consumed in a timely manner through staged processing, thereby ensuring that memory consumption is controllable.

[0139] IoT systems typically consist of a series of devices with varying hardware and software resources, resulting in inconsistent available memory sizes among these devices. Existing incremental update methods suffer from difficulties in assessing and adjusting memory consumption, leading to some incremental update algorithms being unable to run on resource-constrained IoT devices due to their high memory requirements. While some incremental update algorithms require relatively less memory, their compression performance is significantly limited. This application, through the setting of a preset buffer length, allows for a specific numerical assessment of the memory consumption of embedded devices and enables dynamic adjustments based on the actual memory of the embedded device. This fully utilizes the device's memory resources and computing power, making it applicable to various devices with significant differences in computing and memory resources, thus exhibiting better compatibility.

[0140] For example, for 1000 bytes of raw differentially encoded data, if device A has limited available memory (20KB), a resource-efficient decompression algorithm can be used, or the compression level of the compression algorithm can be set lower, and the preset buffer length for differential decoding can be set to a smaller value. Assuming the incremental update time is 500ms, this approach works. If device B has more available memory (50KB), a more powerful compression algorithm or a higher compression level can be used to generate a smaller patch file, saving more bandwidth and time. Furthermore, the preset buffer length for differential decoding can be set to a larger value, allowing the firmware update to be completed within 200ms after receiving the patch data. Therefore, the method provided in this application can update firmware for devices with different resource requirements, regardless of whether the available memory is small or large.

[0141] Understandably, setting the compression ratio of the compression algorithm to a higher level, or using a compression algorithm with a higher compression ratio, can increase the compression ratio, resulting in smaller patch files and thus saving transmission time and bandwidth. Therefore, for embedded devices with sufficient memory, the development device can increase the compression ratio to save transmission time and bandwidth. Alternatively, the preset buffer length of the embedded device can be set to a larger value to reduce decoding time. Conversely, for devices with limited memory, the development device can decrease the compression ratio. Alternatively, the preset buffer length of the embedded device can be set to a smaller value to ensure firmware updates can be performed even with insufficient memory.

[0142] For example, for 1000 bytes of raw differentially encoded data, Table 2 shows a comparison of the time required for embedded devices to receive, decompress, and decode different compression levels, compression ratios, decompression memory, and the length of the differential decoding buffer when the compression algorithm is LZW.

[0143] Table 2

[0144]

[0145] The following section provides a more detailed explanation of the specific process of differential decoding in the above embodiments. In this embodiment, differential decoding can be divided into two processes: an initialization process and a decoding process.

[0146] The initialization process, which forms the basis for subsequent decoding, primarily involves allocating memory space for the device. This may include the memory space required by the following objects:

[0147] (1) buffer_a: Size 'a', used to record the differential decoding status flags and patch file header information. Its required memory space is equal to the memory space needed for the status flags and file header information. The status flags indicate which step the decoding process has reached and can be represented by a 1-byte global variable. The file header information can contain firmware update version information, verification data, the decompression algorithm to be used by the embedded device, the decompression level, and the preset buffer length, etc., and its size can be customized. For example, with a 31-byte file header, the total memory space required to record the differential decoding status flags is 32 bytes.

[0148] (2) buffer_b: Size b, records the ctrl data required for decoding. As mentioned earlier, the ctrl data can be a ternary array (x, y, z), where x represents the number of bytes of diff data, y represents the number of bytes of extra data, and z records the offset address of the original data corresponding to the diff data in the old firmware data. In 8-bit or 32-bit processors, the firmware size is usually not too large, and this ternary array can be represented by three 4-byte variables. Larger firmware can be represented by 8-byte variables. In this embodiment, taking three 4-byte variables as an example, the size of the status flag of the ctrl data is 24 bytes.

[0149] (3) Two buffers of size m are used to temporarily store decoded data: a first buffer (buffer_m1) and a second buffer (buffer_m2), i.e., the preset buffer length is m. For example, if m = 4KB, then this part requires 8KB of buffer space.

[0150] The process of determining the required memory during initialization is as follows: establish a connection with the source device, allocate a buffer_p of size p to store the received data; allocate a buffer_q of size q to store the decompressed raw differential encoded data; allocate a buffer_a of size a to store the status flag and file header information; allocate a buffer_b of size b to store the ctrl data required for decoding; and allocate two buffers, buffer_m1 and buffer_m2, of size m to store the decoded data.

[0151] Reference Figure 10 The process of using the allocated memory provided in this application is illustrated in the following diagram. Specifically, the process of using the allocated memory when receiving patch data is as follows:

[0152] S501: Receive patch data and store the received patch data into buffer_p;

[0153] S502: Obtain patch data and determine the length of the data obtained after decompressing the patch data;

[0154] S503: Determine whether the length of the decompressed data is greater than the length of buffer_q; if yes, proceed to S504; if no, proceed to S505.

[0155] S504: Decompress part of the data, extract data with a length not greater than q and store it in buffer_q, then proceed to S506;

[0156] S505: Decompress all data in the current buffer_p, store it in buffer_q, and proceed to S506;

[0157] S506: Decode the raw encoded data obtained from decompression;

[0158] S507: Determine whether all the data stored in buffer_p has been decompressed; if yes, proceed to S508; if no, return to S504.

[0159] S508: Request to receive the next packet of patch data, returned S501.

[0160] Reference Figure 11 The decoding process specifically includes the following steps:

[0161] S601: Obtain the raw differential encoded data and proceed to S602;

[0162] S602: Read the status flag and proceed to S603;

[0163] In this embodiment, different numerical identifiers can be used to indicate different status indicators. For example, the first identifier can be represented by the number "1," which indicates that the current execution stage is reading control data. The second identifier can be represented by the number "2," which indicates that the current execution stage is adding difference data. The third identifier can be represented by the number "3," which indicates that the current execution stage is copying additional data. The fourth identifier can be represented by the number "0," which indicates that the execution stage is verifying the file header information. It is understood that other identifiers can also be used for the status indicators, and this is not limited here.

[0164] In one specific implementation, the status indicator is indicated by a set state machine.

[0165] S603: Determine if the status identifier is the fourth identifier; if yes, proceed to S604; if no, proceed to S605.

[0166] S604: Read the file header information and determine whether the complete file header information has been read from the original differential encoded data; if yes, proceed to S606; if no, proceed to S607.

[0167] Specifically, the file header information is read from the raw differentially encoded data. If the complete file header information is read, file header information verification is performed. Otherwise, the acquired data is temporarily stored, and more data is received until the complete file header information is obtained.

[0168] S605: Determine if the status identifier is the first identifier; if yes, proceed to S610; if no, proceed to S619.

[0169] S606: Determine whether the file header information has passed verification; if yes, proceed to S608; if no, proceed to S609.

[0170] S607: Store the file header information in the buffer and return S604;

[0171] S608: Change the fourth identifier to the first identifier, then proceed to S610;

[0172] Specifically, after the file header information is verified, the status flag is changed from "0" to "1", and the process proceeds to the next step of reading Ctrl data.

[0173] S609: Returns an error code, stopping the download and execution of firmware updates.

[0174] S610: Receive Ctrl data and determine whether complete Ctrl data has been obtained for the currently processed data block; if yes, proceed to S611; if no, proceed to S612.

[0175] S611: Change the status identifier to the second identifier and proceed to S613.

[0176] Specifically, when the complete Ctrl data is read, the status indicator is changed from "1" to "2", and the process proceeds to the next step of adding the difference data. Otherwise, the already acquired data is temporarily stored, and more data is received until the complete Ctrl data is obtained.

[0177] S612: Store the acquired Ctrl data in the buffer and return to S610;

[0178] S613: Perform an addition operation. If the currently available raw differential encoded data is greater than m, then read m bytes of data from the old firmware data and the currently available raw differential encoded data into buffer 1 and buffer 2 respectively, perform the addition operation in batches, and enter S614.

[0179] If the available raw differential encoded data is greater than m, then read m bytes of data from the old firmware data and the currently available raw differential encoded data into buffer 1 and buffer 2 respectively, and perform the addition operation in several steps. Otherwise, perform the addition operation directly and write the resulting data to the specified storage partition.

[0180] S614: Determine whether the current addition operation has been completed; if yes, proceed to S615; if no, return to S613.

[0181] S615: Change the status identifier to the third identifier, then proceed to S616;

[0182] Specifically, based on the value of 'x' in the Ctrl data, determine whether the current addition operation has been completed. If completed, change the status indicator from "2" to "3" and proceed with the subsequent steps of copying the extra data. Otherwise, return and wait to receive more data until the current addition operation is complete.

[0183] S616: Perform a copy operation. If the currently available raw differential encoded data is greater than m, then read m bytes of data from the currently available raw differential encoded data into buffer 1, perform the copy operation in batches, and proceed to S617.

[0184] If the available raw differential encoded data is greater than m, then read m bytes of data from the available raw differential encoded data into buffer 1, perform copy operations in batches, and write the data written to buffer 1 to the specified storage partition.

[0185] S617: Determine whether the copy operation has been completed; if yes, proceed to S618; if no, return to S616.

[0186] S618: Change the status flag to the first flag, and return to S605;

[0187] Specifically, the completion status of the copy operation can be determined by the value of the y-coordinate in the Ctrl data. If so, the status flag is changed from "3" to "1," and the Ctrl data for the next data block is read. Otherwise, the process returns to wait for more data until the copy operation is complete.

[0188] S619: Determine if the status identifier is the second identifier. If yes, proceed to S613; otherwise, proceed to S620.

[0189] S620: Determine if the status identifier is a third identifier; if so, proceed to S616.

[0190] The method provided in this application embodiment can promptly write the data obtained from addition and copy operations to the storage partition of the embedded device. This storage partition can be a specified non-volatile storage device, such as flash memory, avoiding the consumption of device memory by temporarily storing the data obtained from addition and copy operations in memory. In this way, the original differential decoding data to be processed can be decoded immediately, and the memory consumption required for the entire differential decoding is only the memory consumption during initialization, i.e., a+b+2m. The memory consumption of a+b is configurable and is usually small. Furthermore, the size of m can also be configured. For example, if the size of the difference data in a certain addition operation is 8192 bytes and the size of m is 4095 bytes, then this addition operation can be performed twice, processing 4096 bytes at a time. Increasing the size of m will increase memory consumption, but it can save time consumption caused by batch processing. Through the adjustable buffer, this embodiment facilitates the evaluation of memory consumption during incremental updates and can achieve a balance between memory space consumption and time consumption while fully considering memory consumption.

[0191] This application also provides an embedded device 11, such as Figure 12 The structural block diagram of the embedded device provided in this application shows that the embedded device 11 includes: a first memory 111 and a first processor 112. The first memory 111 is used to store a computer program, and the first processor 112 is used to implement any of the embedded device firmware update methods described above when executing the computer program.

[0192] It is understandable that the firmware update process performed by this embedded device corresponds to the firmware update method for embedded devices described above, and can be referred to the above content, so it will not be repeated here.

[0193] This application also provides a method for updating firmware in an embedded device, such as... Figure 13 As shown, this method is applied to the development device and may specifically include the following steps:

[0194] S701: Determine the similar matching area between the old firmware data and the updated firmware data, perform differential processing on the data in the similar matching area, and encode it as difference data.

[0195] Specifically, string matching algorithms such as hash algorithms and suffix sorting algorithms can be used to find similar matching areas in old firmware data and updated firmware data.

[0196] S702: Encode the data between two similar matching regions as additional data;

[0197] S703: Generate control data based on the difference data and the additional data;

[0198] S704: The generated control data, difference data, and additional data are written into data blocks, and multiple data blocks are arranged to obtain the original differential coded data;

[0199] S705: Compress the original differential encoded data to generate patch data for firmware updates of the embedded device. The patch data is a portion of the patch file.

[0200] After generating the patch file data for firmware updates of the embedded device, the process further includes: packaging the patch data into a patch file; and sending the patch file to a source device for storage, so that the embedded device can obtain the patch data from the patch file on the source device. The patch file also includes file header information, which includes the decompression algorithm to be used by the embedded device, the decompression level, verification information for validation, and a preset buffer length.

[0201] This application also provides a development terminal device 12, such as Figure 14 The structural block diagram of the development device provided in this application shows that the development device 12 includes: a second memory 121 and a second processor 122. The second memory 121 is used to store a computer program, and the second processor 122 is used to implement any of the above-described embedded device firmware update methods when executing the computer program.

[0202] It is understandable that this development device can correspond to the aforementioned embedded device firmware update method, which can be referred to above and will not be repeated here.

[0203] This application also provides an embedded device firmware update system 1, such as... Figure 15 The structural block diagram of the embedded device firmware update system provided in this application includes the aforementioned embedded device 11 and source device 13.

[0204] The source device stores a patch file for firmware updates of the embedded device. The patch data is a portion of the data in the patch file, and the patch data is data obtained by compressing the original differentially encoded data. Data transmission between the embedded device 11 and the source device 13 can be performed using various communication protocols. The source device 13 can be a development device, a cloud device, or another device in the network where the embedded device 11 is located. The embedded device 11 can be updated using the firmware update method described in this application; specific implementation details can be found in the method description and will not be repeated here.

[0205] While various embodiments of various aspects of this application have been described for the purposes of this disclosure, they should not be construed as limiting the teachings of this disclosure to these embodiments. Features disclosed in one 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 this application described in one embodiment can also be applied individually, in combination, or in whole in another embodiment. Those skilled in the art will understand that there are many more possible alternative implementations and variations, and various changes and modifications can be made to the above system without departing from the scope defined by the claims of this application.

Claims

1. A firmware update method for an embedded device, characterized in that, Applied to the embedded device, the method includes: Patch data is obtained from the source device. The patch data is data obtained after compressing the original differentially encoded data. The patch data is a part of the data in the patch file. The patch data is decompressed to obtain the original differential encoded data. The original differential encoded data is the data after differential processing and encoding of the old firmware data and the updated firmware data. The original differential encoded data includes multiple data blocks, each of which includes control data, difference data and additional data. Data blocks in the original differentially encoded data are acquired in stages. In response to whether the data block is control data, difference data, or additional data, differential decoding operations are performed on the data block according to the status flag indicating the current operation, until differential decoding of the original differentially encoded data is completed.

2. The embedded device firmware update method as described in claim 1, characterized in that, In response to whether the data block is control data, differential data, or supplementary data, performing differential decoding operations on the data block according to a status identifier indicating the currently performed operation includes: If the status identifier is a first identifier indicating that the operation of reading the control data is performed, then the control data is read; If the status identifier is a second identifier indicating the operation of adding the difference data, then the difference data is read into a pre-allocated buffer in several steps according to the control data to perform the addition operation, wherein the data length of a single addition operation does not exceed the preset buffer length; If the status identifier is a third identifier indicating the operation of copying the additional data, then the additional data is read into the buffer in batches according to the control data to perform the copy operation, wherein the data length of a single copy operation does not exceed the preset buffer length; The data obtained after performing the addition or copy operation is written to the storage partition of the embedded device.

3. The embedded device firmware update method as described in claim 2, characterized in that, The patch file also includes file header information, and after obtaining the patch data from the source device, it also includes: Read the file header information from the patch file; If the status identifier is a fourth identifier indicating that the file header information is to be verified, then the file header information is verified according to the file header information; If the verification passes, the status identifier will be changed from the fourth identifier to the first identifier.

4. The embedded device firmware update method as described in claim 2, characterized in that, Following the reading of the control data, the following is also included: After reading complete control data, the status identifier is changed from the first identifier to the second identifier.

5. The embedded device firmware update method as described in claim 2, characterized in that, After reading the difference data into a pre-allocated buffer in stages according to the control data and performing the addition operation, the method further includes: Based on the number of bytes of difference data in the data block indicated in the control data, determine whether the addition operation for the data block has been completed; If so, the status identifier is changed from the second identifier to the third identifier.

6. The embedded device firmware update method as described in claim 2, characterized in that, After the additional data is read into the buffer in installments according to the control data and the copy operation is performed, the method further includes: Based on the number of bytes of additional data in the data block indicated in the control data, determine whether the copy operation for the data block is complete; If so, the status identifier is changed from the third identifier to the first identifier.

7. The embedded device firmware update method according to any one of claims 2 to 6, characterized in that, The preset buffer length can be adjusted according to the actual memory of the embedded device.

8. The embedded device firmware update method as described in claim 7, characterized in that, The preset buffer length is stored in the header information of the patch file.

9. The embedded device firmware update method according to any one of claims 1 to 6, characterized in that, The status identifier is indicated by the set state machine.

10. The embedded device firmware update method according to any one of claims 1 to 6, characterized in that, The process of decompressing the patch data includes: The patch data is decompressed using a decompression algorithm that supports streaming decompression.

11. An embedded device, characterized in that, include: A first memory and a first processor, the first memory being used to store a computer program, and the first processor being used to implement the embedded device firmware update method as described in any one of claims 1 to 10 when executing the computer program.

12. An embedded device firmware update system, characterized in that, Includes the embedded device as described in claim 11 and the source device; the source device stores a patch file for firmware updates of the embedded device, the patch data being a portion of the data in the patch file, and the patch data being data obtained by compressing the original differentially encoded data.

13. The embedded device firmware update system as described in claim 12, characterized in that, The source device can be a development device, a cloud device, or another device in the network where the embedded device is located.

Images