Online self-recovery multi-node MCU multi-type firmware parallel upgrading method and system

Abstract

This invention relates to the field of online firmware upgrades for multi-node microcontrollers. More specifically, this invention relates to an online self-healing method and system for parallel firmware upgrades of multiple types of multi-node MCUs. The method includes dividing the flash memory into a read-only boot area and a single continuous application area, wherein the single continuous application area stores the application main code and a fixed composite verification field; digitizing firmware of different service types into static constant byte arrays and embedding them in a host computer; verifying the application main code; if the verification passes, the application program is run; if the verification fails, a fragmentation request is sent according to the service type, node address, and fragmentation sequence number, and the firmware fragmentation is returned. Compared with the prior art, this invention achieves parallel upgrades and autonomous recovery of multiple-node, multi-type firmware through a backup-free flash memory structure, accurate fragmentation retransmission, and joint verification after upgrade.

Description

Technical Field

[0001] This invention relates to the field of online firmware upgrades for multi-node microcontrollers. More specifically, this invention relates to an online self-healing method and system for parallel firmware upgrades of multiple types of multi-node MCUs. Background Technology

[0002] In the fields of embedded industrial control, intelligent terminals, and distributed field devices with multi-node MCU collaborative control, batch online firmware upgrades for multi-node MCUs have become a core functional requirement for equipment operation and maintenance. Currently, the mainstream upgrade architecture in the industry generally adopts an A / B dual-backup flash memory partitioning scheme, which means that the on-chip flash memory space of the MCU needs to be divided into a boot partition, an application firmware runtime partition, and an application firmware backup partition simultaneously. This results in the flash memory capacity being at least twice the size of the business firmware, significantly increasing hardware resource overhead, and the effective utilization rate of flash memory being less than 50%.

[0003] Taking the Chinese patent application with publication number CN116708319A as an example, although this scheme enables the main MCU to receive and unpack the fused data packet and simultaneously distribute it to each secondary MCU, allowing all MCUs to complete firmware upgrades at the same time and possessing a certain parallel upgrade capability, this scheme is essentially still a "host computer / master node centralized distribution" mode. Each secondary MCU passively receives firmware data issued by the master node and does not have the ability to actively request fragmentation on demand. At the same time, this scheme does not optimize the flash memory partitioning architecture and still relies on the traditional multi-partition redundant storage structure, and the problem of low flash memory resource utilization remains unresolved.

[0004] Furthermore, taking the Chinese patent application with publication number CN121579038A as an example, this scheme transmits firmware pages to nodes of the same type via CAN bus broadcast commands, realizing multi-node parallel upgrades based on the CAN bus. However, this scheme relies solely on a single verification during the fragment reception stage for firmware verification. After the upgrade, there is no independent whole-device firmware review process executed by the underlying bootloader, making it impossible to avoid the risk of incomplete firmware operation caused by momentary interference or implicit write errors during the upgrade process. Moreover, its firmware upgrade still relies on external firmware file parsing, resulting in multiple data transmission link layers and an increased number of potential failure sources.

[0005] Therefore, the existing technology mainly suffers from the technical problems of low storage utilization due to flash memory partition redundancy, and lack of the ability of the lower computer to actively request and resume interrupted transmission in the unidirectional push of the host computer. Summary of the Invention

[0006] To address the technical problems of low storage utilization due to flash memory partition redundancy and the lack of slave-device active request and breakpoint resume capability in unidirectional push from the host computer, this invention provides solutions in the following aspects.

[0007] In a first aspect, the present invention discloses an online self-healing multi-node MCU multi-type firmware parallel upgrade method, executed by a host computer and a slave computer, comprising:

[0008] S10: Divide the flash memory into a read-only boot area and a single continuous application area, wherein the single continuous application area stores the application main code and a fixed composite check field. S20: Digitize the firmware of different service types into static constant byte arrays and solidify them in the host computer; verify the main application code. If the verification passes, run the application. If the verification fails, send a fragmentation request according to the service type, node address and fragmentation sequence number, and return the firmware fragmentation. S30: Verify the received firmware fragment. If the verification passes, write it into a single continuous application area and request the next firmware fragment. If the verification fails, repeat the request for the current firmware fragment. S40: After completing the full firmware writing, perform firmware verification again. If the verification passes, run the application; otherwise, re-submit the firmware fragmentation request.

[0009] Compared to existing technologies, and upgrade methods that use dual application areas or firmware backup areas, this approach, which only sets up a read-only boot area and a single continuous application area, reduces the storage space required by two sets of firmware to that of a single set, improving the effective utilization of microcontroller flash memory. By embedding firmware of different service types on the host computer and performing fragmented interaction based on service type, node address, and fragment sequence number, it can meet the differentiated upgrade needs of multiple types and multiple nodes of devices. Employing fragmented verification, fragmented writing, and current fragment repeated request mechanisms, it eliminates the need to retransmit the complete firmware in case of transmission anomalies. The two integrity checks before and after the upgrade prevent the operation of abnormal firmware and automatically re-request firmware after verification failure, reducing the risk of device failure or on-site maintenance caused by upgrade interruption and providing a basis for parallel upgrades of multiple lower-level devices.

[0010] Preferably, in step S20, firmware of different service types corresponds to a static constant byte array. The corresponding static constant byte array is determined according to the service type in the fragmentation request, and the corresponding firmware fragment is read from the static constant byte array according to the fragmentation sequence number and then returned.

[0011] Preferably, when the host computer has an application program with the main code of the slave computer application, and the firmware version number in the fixed composite verification field of the slave computer is inconsistent with the firmware version number of the corresponding firmware in the host computer, it includes: The host computer sends a switching command to the corresponding slave device. The lower-level machine enters the read-only boot area to run the boot program according to the switching instruction, and sends a fragmentation request according to the service type, node address and fragmentation sequence number.

[0012] Preferably, the sharding request includes service type, node address, and sharding sequence number, specifically: The host computer determines the corresponding static constant byte array based on the service type, and returns the firmware fragment after determining the fragment number; After receiving the fragmented message, the lower-level device matches it with the service type and node address, and only retains the firmware fragments that match the local service type and node address.

[0013] Preferably, it further includes: The highest bit of the segment sequence number is the end flag bit, and the remaining bits are the sequence number value; The firmware fragment is subjected to integrity verification. After the verification is passed, the write offset address is determined according to the sequence number value, and the firmware fragment is directly written into a single continuous application area. The request for the next firmware fragment is made when the end flag indicates that it is not the end fragment, and the request is stopped when the end flag indicates that it is the end fragment.

[0014] Preferably, when the firmware fragmentation verification fails, data transmission is abnormal, message is lost, or communication times out, the following applies: Maintain the current fragment sequence number and repeatedly send fragment requests for the current fragment sequence number until the current firmware fragment verification passes; During repeated requests, firmware fragments that have already been verified are not retransmitted.

[0015] Preferably, the fixed composite verification field in step S10 includes a length redundancy segment, a verification redundancy segment, and a service type, version, and specific identifier segment, specifically: The length redundancy segment includes the original length of the application main code, the result of swapping the high and low values ​​of the original length, and the result of bitwise inversion; The verification redundancy segment includes the original cyclic redundancy check value of the entire application area code, the high-low swap result of the original cyclic redundancy check value, and the bitwise inversion result; The service type, version, and specific identifier segment include the service type code, firmware version number, compilation time, and specific identifier.

[0016] Preferably, the fixed composite check field is read from a fixed position at the end of a single continuous application area, and the field length, arrangement order, high-low swap result, and bit-by-bit inversion result of the fixed composite check field are verified sequentially.

[0017] Preferably, it further includes: After verification, the original length and the original cyclic redundancy check value are extracted. The application main code is read from the starting address of a single continuous application area according to the original length. The actual cyclic redundancy check value is calculated and compared with the original cyclic redundancy check value. If any verification or comparison fails, resend the fragmentation request.

[0018] In a second aspect, the present invention discloses an online self-healing multi-node MCU multi-type firmware parallel upgrade system, including a host computer, slave computers and computer program instructions. The host computer is connected to multiple slave computers through a serial communication interface, a controller area network bus or Ethernet. When the computer program instructions are executed by the processor, the online self-healing multi-node MCU multi-type firmware parallel upgrade method described in the first aspect is implemented.

[0019] The beneficial effects of this invention lie in replacing the firmware backup structure with a read-only boot area and a single continuous application area, and solidifying various service firmwares in a static constant byte array on the host computer. The system completes firmware matching, slice-by-slice verification, and direct writing based on service type, node address, and slice sequence number; in case of anomalies, only the current slice is re-requested. Simultaneously, a fixed composite verification field is used to implement format redundancy verification and code integrity review; if verification fails, the system automatically re-upgrades. This balances flash memory saving, multi-node parallelism, breakpoint self-healing, prevention of erroneous upgrades, and reliable boot, making it suitable for centralized online maintenance of resource-constrained devices. Attached Figure Description

[0020] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the invention are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein: Figure 1 This is a flowchart of the online self-healing multi-node MCU multi-type firmware parallel upgrade method in Embodiment 1; Figure 2 This is a schematic diagram of the MCU flash memory partition in Embodiment 1; Figure 3 This is a schematic diagram of the application program and verification field in Embodiment 1; Figure 4 This is a diagram of the parallel upgrade topology architecture in Example 2. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] Example 1 like Figure 1 As shown, this embodiment discloses an online self-healing multi-node MCU multi-type firmware parallel upgrade method, executed by a host computer and a slave computer, including: S10: Divide the flash memory into a read-only boot area and a single continuous application area, where the single continuous application area stores the main application code and a fixed composite check field.

[0024] Reference Figure 2 In this implementation method, the storage space of the MCU flash memory of each lower-level machine is first divided.

[0025] In this embodiment, the flash memory is divided only into a read-only boot sector and a single continuous application sector, without a firmware backup sector for storing a second complete application firmware. The read-only boot sector is located in the starting address region of the flash memory and is used to store the boot program; the remaining space in the flash memory other than the read-only boot sector is used as a single continuous application sector to store the main application code and a fixed composite checksum field.

[0026] The boot sector is read-only and is prevented from being erased, programmed, or updated online via MCU hardware locking or corresponding storage protection mechanisms, ensuring that the boot program is not overwritten during application firmware upgrades. Therefore, even if the main application code experiences a write error, communication interruption, or sudden power loss during the upgrade process, the boot program can still take over the system after power is restored and continue executing subsequent firmware verification and upgrade request procedures.

[0027] The boot sector capacity can be configured based on the MCU hardware resources and the size of the bootloader. For example, for resource-constrained micro MCUs, the boot sector can be configured to 2KB; for MCUs with more functions or larger storage resources, the boot sector size can be increased according to the actual capacity of the bootloader. Regardless of the boot sector capacity, the remaining flash memory space maintains a continuous application area structure, without additional firmware backup areas. The boot sector can be flexibly configured as needed and can be as low as 2KB, while the remaining space forms a unique continuous application area.

[0028] Each single continuous application area stores the application main code and a fixed composite check field sequentially, starting from its initial address. The application main code consists of binary instruction data executed during normal MCU operation, while the fixed composite check field is located after the application main code and occupies a fixed length of storage space.

[0029] It should also be noted that with the above flash memory structure, application firmware upgrades do not require reserving another complete firmware storage space in the lower-level machine in advance. Therefore, with the same flash memory capacity, more space can be used to store the actual running application.

[0030] Preferably, the fixed composite verification field in step S10 includes a length redundancy segment, a verification redundancy segment, and a service type, version, and specific identifier segment, specifically: The length redundancy segment includes the original length of the application main code, the result of swapping the high and low lengths of the original length, and the result of bitwise inversion; The redundancy check segment includes the original cyclic redundancy check value of the entire application area code, the high and low swap results of the original cyclic redundancy check value, and the bitwise inversion result; The service type, version, and specific identifiers include the service type code, firmware version number, compilation time, and specific identifiers.

[0031] Reference Figure 3 This implementation method places the fixed composite check field at the end of the application main code and occupies a fixed 36 bytes. This means that in the complete firmware binary file generated by compilation, the last 36 bytes are this composite check field, and its starting address is fixed as "application area start address + application main code length".

[0032] In this embodiment, the 36-byte fixed composite check field is divided into three data segments, each with a length of 12 bytes: a length redundancy segment, a check redundancy segment, and a service type, version, and specific identifier segment.

[0033] The length redundancy segment is located in the first 12 bytes of the 36-byte fixed composite check field, and includes three consecutive 4-byte data fields: (1) The first field is used to store the original length of the application main code. The original length represents the number of bytes of the actual valid application main code.

[0034] (2) The second field is used to store the result of swapping the high and low 16 bits of the original length, that is, the 4-byte data formed by swapping the high 16 bits and low 16 bits of the original length.

[0035] (3) The third field is used to store the bitwise inversion result of the original length, that is, the 4-byte data formed by inverting each binary bit corresponding to the original length. The check redundancy segment is located in the middle 12 bytes of the 36-byte fixed composite check field, including three consecutive 4-byte data fields.

[0036] (4) The first field is used to store the original cyclic redundancy check value corresponding to the main application code; the second field is used to store the result of swapping the high and low 16 bits of the cyclic redundancy check value; the third field is used to store the result of bitwise inversion of the cyclic redundancy check value.

[0037] The cyclic redundancy check (CRUD) uses a 32-bit CRUD rule. During the firmware creation phase, the host computer generates the original CRUD value according to a unified CRUD algorithm, and the slave computer calculates the actual CRUD value using the same check rule during the firmware verification phase.

[0038] The service type, version, and specific identifier fields are located in the last 12 bytes of the fixed composite check field, which stores at least the service type code, firmware version number, compilation time, and specific identifier.

[0039] The service type code is used to identify the service type to which the current complete firmware belongs; the firmware version number is used to compare the version relationship between the existing application on the lower-level machine and the pre-installed firmware on the upper-level machine; the compilation time is used to record the firmware generation time information; the specific identifier is used to determine that the current tail data belongs to a fixed composite check field. For example, it can be a fixed magic number (such as 0x5A5A5A5A). The bootloader checks this identifier to quickly determine whether the check field exists or is valid.

[0040] The field arrangement order, field length, and operational relationships of the aforementioned 36 bytes are fixed, enabling the lower-level computer to determine whether the tail data belongs to a valid fixed composite check field based on these fixed relationships. This includes a length redundancy segment of bytes 0-11, a full-domain CRC32 redundancy segment of bytes 12-23, and a service type / version / specific identifier segment of bytes 24-35.

[0041] Preferably, a fixed composite check field is read from a fixed position at the end of a single continuous application area, and the field length, arrangement order, high-low swap result, and bit-by-bit inversion result of the fixed composite check field are verified sequentially.

[0042] In this embodiment, after the MCU is powered on or reset, the bootloader first determines the position of the fixed composite check field based on the fixed end address of the single continuous application area, and reads 36 bytes of data from the fixed position at the end of the single continuous application area.

[0043] After obtaining 36 bytes of data, the bootloader first determines whether the actual read length meets the preset byte length of the fixed composite check field; then, it determines the start and end positions of each field according to the fixed format, and determines whether the length redundancy segment, check redundancy segment, business type, version and specific identifier segment are arranged in the predetermined order.

[0044] Subsequently, the bootstrap program verifies each redundant data segment within the length redundancy segment.

[0045] For the original length and the result of swapping the high and low 16 bits, the bootloader reads the original length, performs the high and low 16 bit swap, and compares the calculated data with the data stored in the second field; for the original length and the result of bitwise inversion, the bootloader performs bitwise inversion on the original length and compares the calculated data with the data stored in the third field.

[0046] Similarly, for the original cyclic redundancy check value, the bootstrap program verifies both the result of swapping the high and low 16 bits and the result of bitwise inversion. When the above redundancy relationships all satisfy the fixed rules, the corresponding redundant fields are considered to be consistent.

[0047] Furthermore, the bootloader can perform format recognition on fields such as business type code and specific identifier to determine that the 36-byte data is indeed the fixed composite check field corresponding to the current firmware.

[0048] When any of the following does not conform to the preset fixed relationship: field length, arrangement order, high and low 16-bit swap relationship, or bitwise inversion relationship, the bootloader determines that the current fixed composite check field is invalid, stops reading the application main code according to the parameters in the abnormal check field, and instead keeps running in the read-only boot area and switches to the firmware request process.

[0049] By first verifying the structure of the fixed composite check domain and then using its original length and original cyclic redundancy check value, we can avoid directly using erroneous parameters to read the main application code when the check domain itself is missing or the data is abnormal.

[0050] Preferably, the method in this embodiment further includes: After verification, the original length and original cyclic redundancy check value are extracted. The application main code is read from the starting address of the single continuous application area according to the original length, the actual cyclic redundancy check value is calculated, and the actual cyclic redundancy check value is compared with the original cyclic redundancy check value. If any verification or comparison fails, resend the fragmentation request.

[0051] In this embodiment, after the field length, arrangement order and redundancy relationship of the fixed composite check field have all been verified, the bootstrap program extracts the original length from the length redundancy segment and extracts the original cyclic redundancy check value from the check redundancy segment.

[0052] The bootloader determines the effective reading range of the current complete application code based on the original length, and starts reading the application code data corresponding to the original length from the starting address of a single continuous application area.

[0053] During the reading process, the bootloader performs actual cyclic redundancy check (CRC) calculations on the read application code according to the same 32-bit CRC rule as during the firmware creation stage, thereby obtaining the actual CRC value.

[0054] Subsequently, the bootloader compares the actual cyclic redundancy check (CRC) value with the original CRC value pre-stored in the fixed composite check field.

[0055] When the two are consistent, it indicates that the current application main code is consistent with the valid code content corresponding to the firmware creation, and the application can enter the running stage; when the two are inconsistent, it indicates that the application main code may have omissions, errors, data corruption, or other changes, and therefore the current application firmware does not have the legal conditions to run.

[0056] Therefore, the legitimate operation of complete firmware requires simultaneous fulfillment of two levels of verification conditions: First, the structure and redundancy relationships of the fixed composite check field itself must be valid; second, the actual cyclic redundancy check value calculated based on the original length in the valid check field must match the original cyclic redundancy check value. Only when both of the above conditions are met will the MCU allow jumps from the read-only boot sector to execute the application program.

[0057] When the fixed composite check field verification fails or the actual cyclic redundancy check value comparison fails, the bootloader prohibits the application from loading and regenerates the sharding request according to the local business type, node address and current sharding sequence number.

[0058] Therefore, when the application firmware is incomplete, the system will not directly run the incomplete firmware because the data outside the boot sector still contains some executable code. Instead, the boot program will actively enter the recovery process.

[0059] Preferably, in step S20, firmware of different service types corresponds to a static constant byte array. The corresponding static constant byte array is determined according to the service type in the fragmentation request, and the corresponding firmware fragment is read from the static constant byte array according to the fragmentation sequence number and then returned.

[0060] In this embodiment, the host computer pre-acquires complete firmware corresponding to multiple different service types. Each complete firmware includes the application main code for the corresponding service type and a fixed composite verification field set at the end of the application main code.

[0061] The host computer converts each complete firmware into a static constant byte array in byte order, and compiles multiple static constant byte arrays together with the host computer's own software program, so that the complete firmware of different business types is stored directly inside the host computer program as program-fixed data.

[0062] For example, the first business type corresponds to the first static constant byte array, the second business type corresponds to the second static constant byte array, and other business types correspond to their respective static constant byte arrays in the same way. Different static constant byte arrays have independent business type correspondences.

[0063] Based on this, the host computer does not need to open the external firmware binary file during the upgrade process, nor does it need to perform file format parsing or forward the complete firmware through an intermediate device during the upgrade. Instead, it directly reads the corresponding data from the static constant byte array that has been compiled and embedded within the host computer program. This is achieved by "converting the complete firmware binary code into a C language static array and compiling and embedding it together with the host computer program" to reduce external file parsing and intermediate forwarding steps.

[0064] When the host computer receives a fragmentation request from the slave computer, it first reads the service type carried in the fragmentation request and determines the corresponding static constant byte array based on the service type. Then, it determines the position of the firmware fragment in the complete firmware based on the fragmentation sequence number carried in the fragmentation request and reads the data at that position from the corresponding static constant byte array. Finally, it encapsulates the read firmware fragment into an acknowledgment message and returns it to the corresponding slave computer.

[0065] Therefore, the business type is used to select the firmware data source, and the fragment number is used to select the specific data location in the firmware data source. Together, they determine the firmware fragment corresponding to this request.

[0066] S20: Digitize the firmware of different service types into static constant byte arrays and solidify them in the host computer; verify the main application code. If the verification passes, run the application. If the verification fails, send a fragmentation request according to the service type, node address and fragmentation sequence number, and return the firmware fragmentation.

[0067] In this embodiment, each time the MCU is powered on or reset, it first runs the boot program in the read-only boot sector, instead of directly jumping to run the application program in a single continuous application sector.

[0068] The bootloader first verifies the fixed composite check field corresponding to the application's main code. After reading the check field from a fixed location, it performs an integrity check on the application's main code based on the application's main code length and cyclic redundancy check value recorded therein.

[0069] If the verification passes, the firmware corresponding to the current application's main code is deemed valid, and the MCU jumps to run the application. If the verification fails (e.g., due to initial flashing, firmware corruption, or upgrade interruption), the application is not loaded, but instead it remains running in the read-only boot sector. Based on the device's service type, node address, and fragment sequence number, it actively sends fragment requests to the host computer, thereby achieving autonomous "self-healing" upgrades after the device is powered on.

[0070] In another operating state, the lower-level device already has a legitimate, functional application running. In this state, the lower-level device can report its local service type, current firmware version number, and device status to the upper-level device during normal operation. The upper-level device determines the locally embedded target service firmware based on the service type, reads the corresponding firmware version number, and compares this version number with the firmware version number currently reported by the lower-level device.

[0071] Preferably, when the host computer has an application program with the main code of the slave computer application, and the firmware version number in the fixed composite verification field of the slave computer is inconsistent with the firmware version number of the corresponding firmware in the host computer, it includes: The host computer sends a switching command to the corresponding slave device. The lower-level machine enters the read-only boot area to run the application according to the switching instruction, and sends fragmentation requests according to the service type, node address and fragmentation sequence number.

[0072] S30: The lower-level machine verifies the received firmware fragment. If the verification passes, it writes it into a single continuous application area and requests the next firmware fragment. If the verification fails, it repeatedly requests the current firmware fragment.

[0073] Preferably, the sharding request includes the service type, node address, and sharding sequence number, specifically: The host computer determines the corresponding static constant byte array based on the service type, and returns the firmware fragments based on the fragment sequence number; After receiving the fragmented message, the lower-level device matches it with the service type and node address, and only retains the firmware fragments that match the local service type and node address.

[0074] In this example, after the lower-level machine enters upgrade mode, it forms a fragmentation request based on the current upgrade status and writes the local service type, node address and current fragmentation sequence number into the request message.

[0075] Among them, the service type is used to characterize the service category to which the target firmware belongs; the node address is used to characterize the target lower-level node; and the fragment sequence number is used to characterize the location of the firmware data that needs to be requested.

[0076] After receiving multiple fragmentation requests from lower-level devices, the host computer parses the service type, node address, and fragmentation sequence number from each request. Based on the service type, it selects the target firmware from multiple local static constant byte arrays, then retrieves the corresponding fragment from that firmware based on the fragmentation sequence number, and includes the corresponding service type and target node address in the response message.

[0077] Because multiple lower-level devices may initiate upgrade requests simultaneously, data corresponding to multiple service types and multiple node addresses may exist on the bus at the same time. After receiving a downlink fragmented message, the lower-level device does not directly write all the received data to its local flash memory, but first reads the service type and node address from the message. This dual filtering mechanism is one of the core features of this invention. 1. Service type matching: When the service type in the message is consistent with the service type configured on the local machine, and the node address is consistent with the local node address, the message is considered to belong to this node, and the firmware fragments in it are retained; 2. Node address matching: If any of the nodes does not match, the message is discarded and no further fragmentation is performed.

[0078] During further processing, the lower-level device can also verify whether the fragment sequence number in the fragmented message matches the fragment sequence number currently requested. Only when the service type, node address, and current fragment position all match will the current fragment proceed to the subsequent verification and writing steps.

[0079] Through the above processing, isolated data matching relationships are established between firmware of different service types and different node addresses, enabling multiple lower-level devices to independently request and receive their own target firmware fragments within the same communication network. The lower-level devices filter downlink fragments based on node address and service type, retaining only data matching their own node. This achieves parallel synchronous upgrades for multiple service types and multiple MCU nodes, with each node's upgrade process operating independently.

[0080] Preferably, it further includes: The highest bit of the fragment sequence number is the end flag bit, and the remaining bits are the sequence number value; The firmware fragments are subjected to integrity verification. After the verification is passed, the write offset address is determined according to the sequence number value, and the firmware fragments are directly written to a single continuous application area. The request for the next firmware fragment is made when the end flag indicates that it is not the end fragment, and the request is stopped when the end flag indicates that it is the end fragment.

[0081] In this embodiment, when the downstream device retains the current target firmware fragment after filtering by service type, node address, and fragment location, it further performs an integrity check on the firmware fragment.

[0082] Integrity verification can employ a fragment verification method corresponding to the communication message configuration to determine the correctness of the data in the currently received firmware fragment. This verification is performed only on the current firmware fragment to prevent individual fragments from being directly written to flash memory during communication due to data loss, transmission errors, or interference.

[0083] After the current firmware fragment verification passes, the lower-level machine parses the fragment sequence number. In this invention, the fragment sequence number is a 16-bit or 32-bit integer, with its highest bit defined as the end flag (e.g., a highest bit of 1 indicates the end fragment, and 0 indicates a non-end fragment), and the remaining bits serve as the sequence number value of the current firmware fragment. When the highest bit indicates a non-end fragment, it means that the current fragment belongs to the middle data in the complete firmware; when the highest bit indicates a end fragment, it means that the current fragment is the last segment of data in the complete firmware.

[0084] The lower-level device determines the write offset address of the current firmware fragment in a single continuous application area based on the sequence number value. Specifically, the write start position (offset address = sequence number value × fixed fragment length) can be calculated based on the fixed data length of a single fragment (e.g., each fragment is fixed at 128 bytes, 256 bytes, or 512 bytes) and the current sequence number value, so that different fragments are written to the application area in the original order of the complete firmware.

[0085] After obtaining the write offset address, the lower-level machine does not need to cache the entire firmware to the on-chip random access memory first. Instead, it directly writes the firmware fragments that have passed the integrity check to a single continuous application area.

[0086] After a single fragment is written, when the end flag indicates that the current fragment is not the last fragment, the lower-level device advances the current fragment sequence number to the next sequence number and sends the request for the next firmware fragment to the upper-level device again; when the end flag indicates that the current fragment is the last fragment, the lower-level device stops sending the request for the next fragment and transfers the current upgrade process to the complete firmware verification stage.

[0087] Therefore, flash memory writes are performed only at the corresponding location after the current fragment has been verified to be correct, thus avoiding erroneous communication data from directly overwriting the target storage area.

[0088] Preferably, when firmware fragmentation verification fails, data transmission is abnormal, message is lost, or communication times out, the following applies: Maintain the current fragment sequence number and repeatedly send fragment requests for the current fragment sequence number until the current firmware fragment verification passes; During repeated requests, firmware fragments that have already been verified are not retransmitted.

[0089] In this embodiment, if firmware fragment verification fails, data transmission is abnormal, message is lost, communication times out, or communication interference causes the current firmware fragment to fail to form valid data, the lower-level machine will not advance the current fragment sequence number.

[0090] In one implementation of this embodiment, the lower-level device is currently requesting firmware fragment with sequence number N. When the fragment verification corresponding to sequence number N fails, the lower-level device retains the fragment sequence number N and resends the request for sequence number N to the upper-level device. The upper-level device then selects the corresponding static constant byte array according to the service type and reads the firmware fragment at the same position according to the fragment sequence number N and returns it.

[0091] Once the newly received fragment N passes the integrity check again, the lower-level machine directly writes the fragment to the corresponding offset address and advances the next request position to fragment N+1.

[0092] During the above process, firmware fragments with sequence numbers less than N that have already been verified and successfully written will not be requested again, nor do they need to be rewritten. Therefore, exception handling only applies to the currently faulty fragment and will not cause retransmission from the beginning of the complete firmware.

[0093] In another implementation of this embodiment, the complete firmware includes multiple consecutive firmware fragments. After the first few fragments have been successfully written, if the current fragment experiences a transmission error, the lower-level machine maintains the current fragment sequence number and repeatedly requests the fragment. After the fragment is correctly received, the machine continues processing.

[0094] This processing method enables in-situ retransmission and breakpoint resumption of abnormal fragments, ensuring that local communication anomalies on a single node only affect the current upgrade position of that node and do not affect the upgrade progress already completed by other nodes. In the event of anomalies such as fragment verification errors, communication timeouts, packet loss, and electromagnetic interference, the current fragment sequence number should be locked and the current fragment should be requested cyclically, without needing to retransmit the firmware completely from the beginning.

[0095] Meanwhile, when multiple lower-level machines are upgraded simultaneously, each node maintains its own current fragment sequence number. Therefore, when a node is stuck on a faulty fragment and makes repeated requests, other nodes can still continue to receive and write their respective fragments, thus achieving parallel upgrades for multiple nodes.

[0096] S40: After completing the full firmware writing, perform firmware verification again. If the verification passes, run the application; otherwise, re-submit the firmware fragmentation request.

[0097] In this embodiment, after the last fragment completes verification and is written to a single continuous application area, the lower-level machine does not immediately jump to run the application. Instead, the boot program in the read-only boot area first re-executes the complete firmware joint verification process.

[0098] First, a 36-byte fixed composite check field is reread from a fixed position at the end of a single continuous application area, and its field length, arrangement order, and the results of swapping the high and low 16 bits of the length field and the cyclic redundancy check field, as well as the bitwise inversion result, are re-verified.

[0099] After the fixed composite check field passes the verification, the original length and the original cyclic redundancy check value stored therein are read again, and the application main code is read from the starting address of the single continuous application area according to the original length.

[0100] Subsequently, the actual cyclic redundancy check value of the current application's main code is recalculated and compared with the original cyclic redundancy check value stored in the fixed composite check domain.

[0101] When the fixed composite check field passes the verification and the actual cyclic redundancy check value is consistent with the original cyclic redundancy check value, it indicates that the complete firmware has been correctly written and the content is valid. The bootloader allows the MCU to jump to run the application.

[0102] If any of the verifications fails, the bootloader will prevent the user from jumping to the application and will re-enter the upgrade recovery process, resending the sharding request based on the local service type, node address, and current sharding sequence number.

[0103] Therefore, single fragment verification is only responsible for confirming that the current communication fragment is correct, and is not the sole basis for the complete firmware to run; after all fragments are written, the bootloader must perform a complete joint verification on the entire application firmware again.

[0104] In a further embodiment, it also includes: Preferably, the boot sector capacity can be adjusted according to the MCU hardware resources.

[0105] For MCUs with limited on-chip flash memory, the boot sector can be configured to have a smaller capacity, retaining only the boot program necessary for completing fragmentation requests, communication processing, flash memory writing, and firmware validity verification; for MCUs with larger on-chip flash memory, the boot sector capacity can be increased according to the functional expansion of the boot program.

[0106] Regardless of the capacity of the boot sector, the storage structure of "boot sector + single continuous application area" is maintained, and no firmware backup area is added. Therefore, this capacity change will not alter the basic technical architecture of the backup-free upgrade of this invention.

[0107] Preferably, firmware for different service types is directly stored as program data in the host computer.

[0108] At this point, the complete firmware used for the host computer upgrade is integrated with the host computer program in the same compilation process. There is no need to locate external firmware files during device operation, nor is it necessary to go through independent file management and secondary forwarding devices.

[0109] Preferably, the segmented transmission adopts an interactive mechanism in which the lower-level machine actively requests and the upper-level machine responds.

[0110] Under this mechanism, the lower-level machine can determine the specific fragment it needs to acquire next based on its current upgrade progress, thus enabling it to autonomously control its upgrade position. If the current fragment encounters an anomaly, the upgrade can be resumed simply by repeatedly requesting the current fragment.

[0111] Preferably, the fixed composite validation field adopts a fixed field layout and a fixed redundancy relationship.

[0112] Field positions, field lengths, high-low 16-bit swap operations, and bitwise NOT operations are kept consistent between the host and slave computers, forming a unified verification field parsing rule. Data that does not conform to this fixed rule is not used as a valid firmware verification field.

[0113] Example 2 like Figure 4 As shown, this embodiment discloses an online self-healing multi-node MCU multi-type firmware parallel upgrade system, including a host computer, slave computers, and computer program instructions. The host computer and multiple slave computers are connected through a serial communication interface, a controller area network bus, or an Ethernet. When the computer program instructions are executed by the processor, they implement the online self-healing multi-node MCU multi-type firmware parallel upgrade method described in Embodiment 1 of this invention.

[0114] The host computer stores complete firmware for multiple different service types and determines the corresponding service type, node address, and fragment number based on fragmentation requests from different slave devices, thereby returning the firmware fragment corresponding to the target slave device. The host computer can be an industrial control computer, an industrial computer, or an embedded control device capable of running firmware management and communication programs.

[0115] Multiple lower-level machines are located in different device nodes. Each lower-level machine includes a microcontroller, flash memory, random access memory, and a communication interface. The microcontroller is used to run the read-only bootloader and application programs; the flash memory is used to store the bootloader, application main code, and fixed composite check fields; the random access memory is used to temporarily store the firmware fragments currently being processed, and is not used to cache the complete firmware; the communication interface is used to make upgrade requests to the host computer and to transmit firmware fragments.

[0116] Each slave device has a unique node address and is configured with a service type corresponding to its business functions. Different service types can correspond to different application functions, such as different controlled objects, different device models, or different control logic. The host computer pre-stores the complete firmware corresponding to these service types, allowing slave devices with different service types to coexist within the same upgrade network.

[0117] The host computer and multiple slave computers can communicate via serial communication interfaces, controller area network buses, RS485 buses, or Ethernet. For different communication media, the data organization logic of upgrade requests and firmware fragments remains consistent, meaning it must at least carry the service type, node address, and fragment sequence number, thus ensuring consistent firmware matching logic across different communication media. Industrial communication buses such as RS232, RS485, CAN, and Ethernet are supported. Of course, this embodiment is merely an example and does not impose specific limitations.

[0118] In this embodiment, the system does not rely on secondary devices to forward firmware data, nor does it rely on parsing complete firmware from an external file system during the upgrade process. Instead, the host computer directly stores complete firmware for multiple service types and responds to on-demand fragmentation requests from each lower-level device.

[0119] The system also includes other components well known to those skilled in the art, such as communication interfaces, the settings and functions of which are known in the art and will not be described in detail here.

[0120] In the description of this specification, "multiple" means at least two, such as two, three or more, etc., unless otherwise expressly and specifically defined.

[0121] While this specification has shown and described numerous embodiments of the invention, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and essence of the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in the practice of this invention.

Claims

1. A method for online self-healing multi-node MCU parallel firmware upgrade, characterized in that, Executed by the host computer and the slave computer, including: S10: Divide the flash memory into a read-only boot area and a single continuous application area, wherein the single continuous application area stores the application main code and a fixed composite check field. S20: Digitize the firmware of different service types into static constant byte arrays and solidify them in the host computer; verify the main application code. If the verification passes, run the application. If the verification fails, send a fragmentation request according to the service type, node address and fragmentation sequence number, and return the firmware fragmentation. S30: Verify the received firmware fragment. If the verification passes, write it into a single continuous application area and request the next firmware fragment. If the verification fails, repeat the request for the current firmware fragment. S40: After completing the full firmware writing, perform firmware verification again. If the verification passes, run the application; otherwise, re-submit the firmware fragmentation request.

2. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 1, characterized in that, In step S20, firmware of different service types corresponds to a static constant byte array. The corresponding static constant byte array is determined according to the service type in the fragmentation request, and the corresponding firmware fragment is read from the static constant byte array according to the fragmentation sequence number and then returned.

3. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 1, characterized in that, When the host computer has an application program with the main code of the slave computer application, and the firmware version number in the fixed composite verification field of the slave computer is inconsistent with the firmware version number of the corresponding firmware in the host computer, it includes: The host computer sends a switching command to the corresponding slave device. The lower-level machine enters the read-only boot area to run the boot program according to the switching instruction, and sends a fragmentation request according to the service type, node address and fragmentation sequence number.

4. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 3, characterized in that, The sharding request includes the service type, node address, and sharding sequence number, specifically: The host unit determines the corresponding static constant byte array based on the service type, and returns the firmware fragment after determining the fragment number; After receiving the fragmented message, the lower-level device matches it with the service type and node address, and only retains the firmware fragments that match the local service type and node address.

5. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 4, characterized in that, Also includes: The highest bit of the segment sequence number is the end flag bit, and the remaining bits are the sequence number value; The firmware fragment is subjected to integrity verification. After the verification is passed, the write offset address is determined according to the sequence number value, and the firmware fragment is directly written into a single continuous application area. The request for the next firmware fragment is made when the end flag indicates that it is not the end fragment, and the request is stopped when the end flag indicates that it is the end fragment.

6. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 5, characterized in that, When the firmware fragmentation verification fails, data transmission is abnormal, message is lost, or communication times out, the following situations occur: Maintain the current fragment sequence number and repeatedly send fragment requests for the current fragment sequence number until the current firmware fragment verification passes; During repeated requests, firmware fragments that have already been verified are not retransmitted.

7. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 1, characterized in that, The fixed composite verification field mentioned in step S10 includes a length redundancy segment, a verification redundancy segment, and a service type, version, and specific identifier segment, specifically: The length redundancy segment includes the original length of the application main code, the result of swapping the high and low values ​​of the original length, and the result of bitwise inversion; The verification redundancy segment includes the original cyclic redundancy check value of the entire application area code, the high-low swap result of the original cyclic redundancy check value, and the bitwise inversion result; The service type, version, and specific identifier segment include the service type code, firmware version number, compilation time, and specific identifier.

8. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 7, characterized in that, The fixed composite check field is read from a fixed position at the end of a single continuous application area, and the field length, arrangement order, high-low swap result, and bit-by-bit inversion result of the fixed composite check field are verified in sequence.

9. The online self-healing multi-node MCU multi-type firmware parallel upgrade method according to claim 8, characterized in that, Also includes: After verification, the original length and the original cyclic redundancy check value are extracted. The application main code is read from the starting address of a single continuous application area according to the original length. The actual cyclic redundancy check value is calculated and compared with the original cyclic redundancy check value. If any verification or comparison fails, resend the fragmentation request.

10. An online self-healing multi-node MCU multi-type firmware parallel upgrade system, characterized in that, It includes a host computer, slave computers, and computer program instructions. The host computer is connected to multiple slave computers via a serial communication interface, a controller area network bus, or an Ethernet. The computer program instructions are used to implement the online self-healing multi-node MCU multi-type firmware parallel upgrade method according to any one of claims 1-9.

Images