Multi-level embedded device upgrading method and system, electronic device and storage medium

Abstract

The embodiment of the application discloses a kind of multistage embedded device upgrade method, system, electronic equipment and storage medium, it is related to firmware upgrade technical field, the method includes: by writing Mailbox channel, the data frame that main station uses first bus to send, data frame includes the identification of target node, firmware block and the serial number of firmware block;If the identification of target node is the identification of parent node, first response data is generated and is written into read Mailbox buffer;If the identification of target node is the identification of child node, firmware block is sent to child node by second bus, the second response data that child node sends is received, and second response data is backfilled to read Mailbox buffer;In response to the read operation of main station, first response data or second response data is sent to main station by first bus.The embodiment of the application reduces hardware cost and system wiring complexity, and the software development cost of main station and parent node.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and more specifically, to a multi-level embedded device upgrade method, system, electronic device, and storage medium. Background Technology

[0002] Industrial robot and humanoid robot control systems are mostly distributed architectures with a large number of embedded functional nodes. As robot equipment is updated and iterated, the number of field nodes is huge and the distribution hierarchy is complex. The traditional method of disassembling and burning firmware has high maintenance costs and poor operability. Therefore, relying on the bus to realize remote firmware upgrade has become the mainstream method for version iteration, fault repair and function upgrade.

[0003] There are currently two mainstream technical solutions in the industry: the full EtherCAT flat solution, in which all first- and second-level nodes are equipped with ESC chips and connected to the EtherCAT bus, and unified management is achieved by allocating independent station addresses. The master station can directly complete firmware upgrades of any node based on the FoE protocol; the dual-protocol stack transparent transmission solution, which retains the tree topology. Second-level nodes do not need to be equipped with ESC chips. The parent node is upgraded first through the EtherCAT FoE protocol. After the parent node restarts and enters transparent transmission mode, the master station switches to the second-level bus private protocol and relies on the parent node relay to realize the step-by-step upgrade of the second-level nodes.

[0004] Both of the above solutions have obvious drawbacks. The full EtherCAT flat solution has high hardware costs and large equipment size, which does not meet the requirements of lightweight robot design. In addition, too many nodes will increase the bus load and reduce the real-time control accuracy of the system. The dual protocol stack transparent transmission solution has high coupling of upgrade levels, cumbersome process, and long time consumption. In addition, the parent node will exit EtherCAT real-time communication and stop normal operation during the transparent transmission stage, causing the branch system to shut down. It cannot achieve non-stop, batch parallel upgrades, which greatly reduces the efficiency of operation and maintenance and the continuity of operation. Summary of the Invention

[0005] This application provides a multi-level embedded device upgrade method, system, electronic device, and storage medium to solve the technical problems of high hardware material costs, difficult system wiring, and high software development costs caused by fragmented upgrade process protocols in the prior art.

[0006] According to a first aspect of the embodiments of this application, a multi-level embedded device upgrade method is provided. The method is applied to a multi-level embedded device upgrade system, the system including a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the parent node and includes: The data frame sent by the master station using the first bus is received through the Mailbox channel. The data frame includes the identifier firmware block of the target node and the sequence number of the firmware block. If the identifier of the target node is the identifier of the parent node, first response data is generated and written to the read Mailbox buffer; if the identifier of the target node is the identifier of a child node under the parent node, the firmware block is sent to the child node through the second bus, the second response data sent by the child node is received, and the second response data is filled back into the read Mailbox buffer; the first response data or the second response data includes a status code and the sequence number of the firmware block, and the status code is used to indicate the transmission status of the firmware block corresponding to the sequence number; In response to the read operation of the master station, the response data of the target node is sent to the master station through the first bus. The response data of the target node is either the first response data or the second response data.

[0007] As an optional implementation, the step of receiving the data frame sent by the master station further includes: The system receives a first instruction sent by the master station, which instructs the parent node to unbind the synchronization management (SM) channel from the process data object and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel. In response to the first instruction, the binding relationship between the SM channel and the process data object is released, and the SM channel is reconfigured as a read Mailbox channel and a write Mailbox channel; The buffer of the read Mailbox channel is used to write the response data generated by the parent node or the child node, and the buffer of the write Mailbox channel is used to write the data frames sent by the master station.

[0008] As an optional implementation, the step of unbinding the Synchronization Management (SM) channel from the process data object in response to the first instruction and reconfiguring the SM channel as a read Mailbox channel and a write Mailbox channel includes: The communication state of the parent node is switched sequentially from running state to safe running state and pre-running state; Close the SM0 and SM1 channels used for process data exchange; Clear the internal process data image buffer of the parent node's controller ESC; Configure the SM2 channel as the read Mailbox channel and the SM3 channel as the write Mailbox channel, and set the physical start address and length of the read Mailbox channel and the write Mailbox channel.

[0009] As an optional implementation, after sending the response data for the firmware chunk transmission command to the master station, the method further includes: The system receives a second instruction sent by the master station, which instructs the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channel and the process data object. In response to the second instruction, the communication state of the parent node is switched to the Init state; Enable the SM0 and SM1 channels for process data exchange, restore the configuration of the SM0 and SM1 channels, and rebind the SM channels to the process data object; Switch the communication status of the parent node back to running status.

[0010] As an optional implementation, when there are multiple target nodes, the multiple target nodes are divided into child node waves and parent node waves according to the dependency relationship of the multiple target nodes in the topology; the child nodes in the child node waves load the firmware blocks with priority over the parent nodes in the parent node waves. In the aforementioned sub-node wave, sub-nodes sharing the second bus serially load the firmware blocks; In the parent node wavelet, each parent node with an independent physical bus concurrently loads the firmware block.

[0011] As an optional implementation, after receiving the data frame sent by the master station through the write Mailbox channel of the parent node, the method further includes: The firmware is written in blocks to a temporary file, and the buffer data corresponding to the temporary file is forcibly written to the storage medium. The temporary file is renamed to the target configuration file through an atomic renaming operation, and the directory index record of the parent directory where the target configuration file is located is synchronously written to the storage medium.

[0012] According to a second aspect of the embodiments of this application, a multi-level embedded device upgrade method is provided. The system includes a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the master station and includes: A data frame is sent to the parent node via the first bus; the data frame includes the identifier of the target node, a firmware block, and the sequence number of the firmware block; the identifier of the target node is the identifier of the parent node or the identifier of a child node under the parent node; The response data of the target node is obtained through a read operation. The response data of the target node is either first response data or second response data. The first response data is the response data of the parent node, and the second response data is the response data of the child node. The first response data or the second response data is stored in the parent node's read Mailbox channel buffer. The first response data or the second response data includes a status code and the sequence number of the firmware block. The status code is used to indicate the transmission status of the firmware block corresponding to the sequence number.

[0013] As an optional implementation, the step of sending a data frame to the parent node via the write Mailbox channel further includes: Send a first instruction to the parent node, the first instruction being used to instruct the parent node to unbind the synchronization management SM channel from the process data object, and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel.

[0014] As an optional implementation, after obtaining the response data of the target node through a read operation, the method further includes: Send a second instruction to the parent node, the second instruction being used to instruct the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channels and the process data object.

[0015] As an optional implementation, the firmware block ends with signature information, which includes payload length and payload checksum; if any of the following conditions are met, no data frame is sent to the parent node: The field of the signature information is the first field; The actual length of the firmware block payload is inconsistent with the payload length included in the signature information; The actual verification value of the firmware block payload is inconsistent with the payload verification value included in the signature information.

[0016] According to a third aspect of the embodiments of this application, a multi-level embedded device upgrade system is provided, the system including a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus; The master station is configured to send data frames to the parent node via the first bus. The data frame includes an identifier of the target node, a firmware block, and a sequence number of the firmware block. The identifier of the target node is either the identifier of the parent node or the identifier of a child node attached to the parent node. The master station also acquires response data from the target node via a read operation. The response data includes either first response data or second response data, where the first response data is the response data of the parent node and the second response data is the response data of the child node. The first response data or the second response data is stored in the parent node's read Mailbox channel buffer. The first response data or the second response data includes a status code and a sequence number of the firmware block, where the status code indicates the transmission status of the firmware block corresponding to the sequence number. The parent node is used to receive data frames sent by the master station using the first bus through the write Mailbox channel; the data frame includes the identifier of the target node, a firmware block, and the sequence number of the firmware block; if the identifier of the target node is the identifier of the parent node, first response data is generated and written to the read Mailbox buffer; if the identifier of the target node is the identifier of the child node, the firmware block is sent to the child node through the second bus, and the parent node sends second response data; in response to the read operation of the master station, the parent node sends the response data of the target node to the master station through the first bus, and the response data of the target node is either the first response data or the second response data.

[0017] According to a fourth aspect of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of any one of the first and second aspects.

[0018] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method as described in any one of the first and second aspects.

[0019] According to a sixth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the method as described in any one of the first and second aspects.

[0020] The beneficial effects of the technical solutions provided in this application are: This application provides a multi-level embedded device upgrade method, system, electronic device, and storage medium. In this application embodiment, the data frames sent by the master station only address the parent node, and node location is completed based on the child node identifier. The child node remains transparent to the EtherCAT bus, eliminating the need for a separate ESC chip configuration, effectively reducing hardware material costs, reducing bus communication load, and simplifying system wiring complexity. At the same time, relying on the parent node's data routing and response backfilling mechanism based on the node identifier, the master station only needs to run the EtherCAT protocol stack throughout the entire process, completing all interactions with the parent node through the Mailbox channel, significantly reducing the software development workload of the master station and parent node, and lowering program maintenance costs and software failure risks. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0022] Figure 1 This application provides a schematic diagram of the structure of a multi-level embedded device upgrade system according to an embodiment of the present application. Figure 2 A flowchart illustrating a multi-level embedded device upgrade method provided in an embodiment of this application; Figure 3 A schematic diagram of a single-packet two-level addressing process provided for an embodiment of this application; Figure 4 A timing diagram illustrating a single-node upgrade provided in an embodiment of this application; Figure 5 A comparative schematic diagram of online reconfiguration of a synchronization management channel provided in an embodiment of this application; Figure 6 A schematic diagram illustrating the scheduling of multi-node concurrent upgrades provided in an embodiment of this application; Figure 7 A flowchart illustrating another multi-level embedded device upgrade method provided in this application embodiment; Figure 8 A schematic diagram illustrating a multi-level embedded device upgrade process provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0024] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0025] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0027] Industrial robot and humanoid robot control systems are mostly distributed architectures with a large number of embedded functional nodes. With the iteration and upgrading of robot equipment, the number of field devices is huge and the distribution hierarchy is complex. The traditional method of disassembling and burning firmware has high maintenance costs and poor operability. Therefore, relying on the bus to realize remote firmware upgrade has become the mainstream method for equipment version iteration, fault repair and function upgrade.

[0028] There are currently two mainstream technical solutions in the industry: the full EtherCAT flat solution, in which all first- and second-level nodes are equipped with ESC chips and connected to the EtherCAT bus, and unified management is achieved by allocating independent station addresses. The master station can directly complete firmware upgrades of any node based on the FoE protocol; the dual-protocol stack transparent transmission solution, which retains the tree topology. Second-level nodes do not need to be equipped with ESC chips. The parent node is upgraded first through the EtherCAT FoE protocol. After the parent node restarts and enters transparent transmission mode, the master station switches to the second-level bus private protocol and relies on the parent node relay to realize the step-by-step upgrade of the second-level nodes.

[0029] Both of the above solutions have significant drawbacks. In the full EtherCAT tiling solution, each child node requiring direct EtherCAT network access must be equipped with an ESC chip (such as Beckhoff's ET1100 or a compatible chip) and necessary peripheral isolation devices (such as network transformers and PHY chips). In applications with dozens of distributed joints, such as humanoid robots, this directly leads to: a significant increase in single-node material costs; increased PCB wiring area, which is detrimental to space-constrained embedded module designs such as motor drive boards; and a surge in the number of nodes on the EtherCAT daisy chain, deepening the physical cascading depth of the distributed clock (DC) synchronization link and increasing the difficulty of master station clock compensation and jitter suppression. The dual-protocol stack pass-through solution has high coupling between upgrade layers, a cumbersome process, and long processing time. Furthermore, the parent node exits EtherCAT real-time communication and stops normal operation during the pass-through phase, causing branch system downtime. This makes it impossible to achieve non-stop, batch parallel upgrades, significantly reducing equipment maintenance efficiency and operational continuity.

[0030] The multi-level embedded device upgrade method, system, electronic device, and storage medium proposed in this application aim to solve the above-mentioned technical problems of the prior art.

[0031] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0032] In distributed real-time control systems such as industrial robots or humanoid robots, there are a large number of embedded nodes (such as motor drive boards and sensor acquisition boards). The parent node is directly connected to the master station through the first bus, and the child nodes are connected to the parent node through the second bus to form a tree topology. Figure 1 This is a schematic diagram of a multi-level embedded device upgrade system provided in an embodiment of this application. As shown in the figure, the master station is connected to parent node 1 and parent node 2 through a first bus, parent node 1 is connected to slave node 1, slave node 2 and slave node 3 through a second bus, and parent node 2 is connected to slave node 4 and slave node 5 through a second bus.

[0033] In some embodiments, the master station is upgrade management software running on the real-time controller; the parent node is a first-level device, including but not limited to: robot joint drive board and communication gateway board; the child node is a second-level device, including but not limited to: encoder acquisition board and end effector embedded sensor board.

[0034] In some embodiments, the first-level device is an embedded device equipped with an EtherCAT slave controller, which has the capabilities of bus protocol parsing, channel reconfiguration, data forwarding and response feedback processing, and can realize bus communication mode switching and unified scheduling management of lower-level devices; the second-level device is an embedded device mounted on the sub-bus of the first-level device, which is a resource-constrained micro embedded terminal that does not need to be equipped with a complete bus protocol stack, and only relies on the embedded boot program to complete instruction reception, firmware burning and response feedback.

[0035] In some embodiments, the first bus can be an EtherCAT bus, and the second bus can be an RS-485 bus.

[0036] It should be noted that, in this embodiment, the number of parent nodes under the main site and the number of child nodes under the parent nodes are not limited to... Figure 1 As shown in the diagram, those skilled in the art can determine the number of parent nodes under the main station and the number of child nodes under each parent node based on the actual situation.

[0037] Figure 2 This is a flowchart illustrating a multi-level embedded device upgrade method provided in an embodiment of this application. The method is applied to a multi-level embedded device upgrade system, which includes a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the parent node, as shown in the figure, and includes: S201. Receive data frames sent by the master station using the first bus through the Mailbox channel. The data frames include the identifier of the target node, firmware blocks, and the sequence number of the firmware blocks.

[0038] Specifically, in this embodiment, the write Mailbox channel is converted from the original EtherCAT real-time PDO channel through online configuration of the synchronization manager register. This results in a larger data buffer capacity, enabling stable transmission of large-size firmware blocks and overcoming the limitations of the original Mailbox channel's small buffer capacity and ability to transmit only short messages. The master station, based on a unified EtherCAT bus link, sends fully encapsulated data frames to the parent node's write Mailbox channel buffer via underlying FPWR messages. The parent node monitors and reads the buffer data in real time to complete message reception.

[0039] In some embodiments, the data frame is an upgrade command frame adapted to a multi-level tree topology upgrade architecture. The identifier of the target node carried in the frame is the node number, which is used to accurately locate the parent node to be upgraded or the child nodes under the parent node, and realize single-packet two-level addressing. The firmware block is a fixed-byte data block obtained by splitting the complete firmware file. The fragmented transmission mode avoids the bus stuttering and data packet loss caused by the large amount of data transmitted in a single transmission, and ensures the stability and integrity of firmware upgrade data transmission.

[0040] Figure 3 This is a flowchart illustrating a single-packet two-level addressing process provided in an embodiment of this application. As shown in the figure, when the master station constructs a data frame, it fills the data frame address into the parent node address and fills the data frame payload node_id into the identifier of the target node. Then, it sends the data frame to the parent node. After receiving the data frame, the parent node parses the node_id field in the payload: if the node_id is consistent with the logical identifier of the parent node itself, it determines that the command destination is itself and directly performs local Flash writing and other operations; if the node_id is inconsistent with itself, it determines that the command destination is a child node connected to its second bus. At this time, the parent node firmware forwards the original payload (including the complete command and parameters) to the second bus as is and waits for the response data from the child node. In this embodiment, when the master station constructs an EtherCAT frame, its physical addressing only points to the parent node address. The "node_id" field is embedded in the application layer Mailbox payload to uniquely identify the final target child node, making the child node completely transparent to the EtherCAT network. In this way, the child node does not need to integrate an EtherCAT slave controller (ESC) chip, nor does it need to occupy an independent EtherCAT bus station address. It is connected to the parent node only through a second bus physical interface such as RS-485, which has extremely low cost.

[0041] In some embodiments, the payload of a data frame includes the following fields: code_version / ota_version: Firmware version identifier; expect_mode: Expected target running mode, for example, 1 indicates bootloader mode, 2 indicates user application mode; node_id: The identifier of the target node, used to uniquely specify the final recipient of this command; com_cmd: Command type, including at least: mode jump command, upgrade start command (StartCode), firmware chunk transfer command (UpdateCode), upgrade end command (FinishCode), etc.; code_serial_num: The sequence number of the firmware block, which starts from 0 and increments. code_size: The length of the payload in bytes for the current block; flash_crc32: The CRC32 checksum value of the entire firmware image file; code_data[]: Firmware data block content; crc: The CRC8 checksum of the entire payload packet (excluding the frame header and frame trailer).

[0042] S202. If the identifier of the target node is the identifier of the parent node, generate first response data and write it into the read Mailbox buffer; if the identifier of the target node is the identifier of a child node under the parent node, send the firmware block to the child node through the second bus, receive the second response data sent by the child node, and fill the second response data back into the read Mailbox buffer; the first response data or the second response data includes a status code and the sequence number of the firmware block, and the status code is used to indicate the transmission status of the firmware block corresponding to the sequence number.

[0043] Specifically, in this embodiment, the parent node compares the identifier of the target node with its own node identifier. If the identifier of the target node is the same as its own node identifier, it means that the node to be upgraded is itself, and it directly performs local Flash writing and other operations. If the identifier of the target node is different from its own node identifier, the parent node forwards the original load to the child node through the second bus and waits for the child node's response data.

[0044] Specifically, in this embodiment, if the identifier of the target node is the identifier of the parent node, the parent node generates first response data and writes the first response data into the read Mailbox buffer; when the target node is a child node, the child node does not directly send the second response data to the master station, but sends the second response data to the parent node, and the parent node fills the second response data of the child node back into its own read Mailbox buffer. This process is completely transparent to the master station, and the master station does not need to be aware of the protocol conversion, thereby fundamentally solving the two-phase independent session problem caused by the separation of protocol stack and process, and significantly reducing the software development cost, maintenance cost and software defect risk of the master station and the parent node.

[0045] In some embodiments, when the master station transmits firmware blocks, the “com_cmd” field in the payload of the sent data frame is the firmware block transmission command (e.g., UpdateCode); the first response data or the second response data includes a status code (e.g., UpdateCodeOk) and the sequence number of the firmware block; wherein, the status code is used to indicate the transmission status of the firmware block corresponding to the sequence number, and the transmission status includes transmission success or transmission failure.

[0046] S203. In response to the read operation of the master station, the response data of the target node is sent to the master station through the first bus, wherein the response data of the target node is either the first response data or the second response data.

[0047] Specifically, in this embodiment, the master station initiates an EtherCAT read operation (e.g., FRMW command) on the parent node to obtain the response data of the target node from the Mailbox of the parent node, and sends the response data of the target node to the master station through the first bus, thereby completing a request / response closed loop.

[0048] Specifically, in this embodiment, the data frames sent by the master station only address the parent node, and the node location is completed by relying on the child node identifier. The child node remains transparent to the EtherCAT bus, and there is no need to configure an ESC chip separately, which effectively reduces hardware material costs, reduces bus communication load, and simplifies the complexity of system wiring. At the same time, relying on the data routing and response backfilling mechanism based on the node identifier of the parent node, the master station only needs to run the EtherCAT protocol stack throughout the process and complete all interactions with the parent node through the Mailbox channel, which greatly reduces the software development workload of the master station and the parent node, and reduces program maintenance costs and software failure risks.

[0049] To help those skilled in the art better understand the node upgrade process, the following description uses the upgrade of a single node as an example. Figure 4 This is a timing diagram illustrating a single-node upgrade according to an embodiment of this application. As shown in the figure, the node identifier of the master station is 100, the node identifier of the parent node is 200, and the node identifier of the child node is 310. The upgrade process includes the following steps: S401. The master station constructs an upgrade start command, determines the identifier of the target node (node_id=310) through the configuration table, writes the identifier of the target node into the upgrade start command, and then sends the upgrade start command to the parent node.

[0050] S402, The parent node discovers that the identifier 310 of the target node is not the same as its own node identifier 200, but is the same as the identifier of the child node it is attached to; therefore, it forwards the upgrade start command to the child node through the second bus.

[0051] S403. In response to the received upgrade start command, the child node sends an upgrade start reply to the parent node.

[0052] S404: The parent node writes the upgrade start response sent by the child node into the read Mailbox channel buffer, and the master station reads the upgrade start response from the child node through the SM2 channel.

[0053] S405. The master station sends a firmware block transmission command to the parent node, where node_id=310 and the firmware block sequence number is N.

[0054] S406. The parent node forwards the firmware block transmission command to the child node through the second bus.

[0055] S407. The child node sends a firmware block transmission response to the parent node via the second bus.

[0056] S408: The parent node writes the firmware block transmission response sent by the child node into the read Mailbox channel buffer, and the master station reads the firmware block transmission response of the child node through the SM2 channel.

[0057] It should be noted that steps S405 to S408 are executed cyclically. That is, the master station sends firmware block transmission commands to the parent node in sequence according to the firmware block number, and obtains the firmware block transmission response stored in the Mailbox channel buffer by the parent node through read operation, until the firmware block transmission response of the firmware block is obtained.

[0058] S409. The master station sends an upgrade end command, with the target node's identifier node_id=310.

[0059] S410. After receiving the upgrade end command, the parent node finds that the target node's identifier is different from its own identifier, and forwards the upgrade end command to the child node through the second bus.

[0060] S411. After receiving the upgrade end command, the child node sends an upgrade end response to the parent node through the second bus.

[0061] In some embodiments, after the parent node or child node receives all the data blocks and writes them to the Flash, it calculates the CRC32 of the written area in the internal flash memory and compares it with flash_crc32. Only if the comparison matches can the upgrade be terminated.

[0062] S412, the parent node writes the upgrade completion response to the Mailbox channel buffer, and the master station reads the upgrade completion response through the SM2 channel.

[0063] Based on the above embodiments, as an optional embodiment, the step of receiving the data frame sent by the master station further includes: The system receives a first instruction sent by the master station, which instructs the parent node to unbind the synchronization management (SM) channel from the process data object and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel. In response to the first instruction, the binding relationship between the Synchronization Management (SM) channel and the process data object is released, and the SM channel is reconfigured as a read Mailbox channel and a write Mailbox channel; The buffer of the read Mailbox channel is used to write the response data generated by the parent node or the child node, and the buffer of the write Mailbox channel is used to write the data frames sent by the master station.

[0064] Specifically, this application uses SyncManager online reconfiguration technology to maintain the original EtherCAT physical network cable connection and device power supply without interruption. It directly rewrites the configuration register corresponding to the internal synchronization manager of the parent node, shuts down the SM channel that originally carried the periodic real-time PDO motion control service online, removes its binding relationship with the process data object, and then resets the memory address, buffer length and working mode of the SM channel to switch it to a high-capacity Mailbox read and write channel. It relies on the same bus to carry two types of communication services, real-time control and firmware upgrade, to achieve uninterrupted remote firmware updates.

[0065] In this embodiment, the SyncManager online reconfiguration technology enables the same EtherCAT bus link to carry two types of services in a time-division manner. During normal operation, the SM channel transmits real-time servo control commands, while during firmware upgrade, the same channel is reused to transmit firmware data packets. This achieves time-division multiplexing of the real-time control network and the upgrade communication network, allowing remote upgrades to be completed using existing control network cables. This solves the technical problem that existing firmware upgrades generally require shutting down and powering off the entire control system, modifying physical wiring, or using external dedicated burning tools to complete firmware writing, resulting in high manual operation costs, long downtime, and the inability to achieve remote automated operation and maintenance. This significantly improves the convenience of node upgrades and operation and maintenance.

[0066] Based on the above embodiments, as an optional embodiment, the step of releasing the binding relationship between the Synchronization Management (SM) channel and the process data object in response to the first instruction, and reconfiguring the SM channel as a read Mailbox channel and a write Mailbox channel includes: The communication state of the parent node is switched sequentially from running state to safe running state and pre-running state; Close the SM0 and SM1 channels used for process data exchange; Clear the internal process data image buffer of the parent node's controller ESC; Configure the SM2 channel as the read Mailbox channel and the SM3 channel as the write Mailbox channel, and set the physical start address and length of the read Mailbox channel and the write Mailbox channel.

[0067] Specifically, in this embodiment of the application, the ESC slave controller integrates multiple independent synchronization managers. Each synchronization manager corresponds to an independent SM channel. Each SM channel has a dedicated register group and DPRAM buffer, and has the ability to configure an independent working mode. The communication mode can be dynamically switched by rewriting the corresponding registers.

[0068] In some embodiments, standard EtherCAT devices are configured with four SM channels by default: SM0, SM1, SM2, and SM3. SM0 and SM1 are natively small Mailbox channels, only suitable for short command interactions, while SM2 and SM3 are high-capacity PDO real-time data channels. This application embodiment reuses SM2 and SM3 channels through online reconfiguration technology. Specifically, the PDO channels originally carrying periodic motion control data are temporarily switched to high-capacity Mailbox read / write channels. This allows for remote, non-intrusive firmware upgrades of multiple nodes using existing EtherCAT network cables without adding new hardware or interrupting bus power supply and physical wiring.

[0069] Figure 5 This is a schematic diagram illustrating an online reconfiguration of a synchronization management channel, as provided in this embodiment of the application. As shown, the master station switches the slave status of the parent node from the running state (OP) to the safe running state (SafeOp). The specific switching process is as follows: (1) Close the SM0 and SM1 channels that were originally used for process data (PDO) exchange. Specifically, write the configuration registers of SM0 and SM1 to length 0 or clear the enable bit. (2) Clear (e.g., write zero) the old process data image buffer associated with PDO inside ESC to prevent residual data from interfering with subsequent Mailbox operations; (3) Reconfigure SM2 as a Mailbox read channel, set its physical start address and length respectively. This area is used for the target node (or the parent node to backfill if it is a child node) to write response data. The master station reads it through commands such as FRMW. (4) Reconfigure SM3 as a write Mailbox channel, set its physical starting address and length, and the master station writes the upgrade command to this area through commands such as FPWR, which is then read by the target node (or parent node); (5) After reconfiguration, keep the slave station in SafeOp state so that Mailbox communication can proceed normally.

[0070] In some embodiments, the memory target addresses corresponding to the SM2 channel and the SM3 channel can be configured as 0x1400 and 0x1600 respectively. The above addresses are only illustrative settings, and the specific storage address values ​​of the channels are not limited in this application embodiment.

[0071] In this embodiment, the master station directly rewrites the synchronization manager configuration register in the slave station controller ESC, shuts down the SM channel originally used for real-time PDO control online, and reconfigures it as the Mailbox read / write channel. The entire upgrade can be transparently completed using only the existing EtherCAT control network cable, without any on-site disassembly, power outage, or cable reconnection. This meets the actual needs of commercial robot products for high availability, low maintenance, and remote unmanned operation and maintenance.

[0072] Based on the above embodiments, as an optional embodiment, after sending the response data for the firmware chunk transmission command to the master station, the method further includes: The system receives a second instruction sent by the master station, which instructs the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channel and the process data object. In response to the second instruction, the communication state of the parent node is switched to the Init state; Enable the SM0 and SM1 channels for process data exchange, restore the configuration of the SM0 and SM1 channels, and rebind the SM channels to the process data object; Switch the communication status of the parent node back to running status.

[0073] Specifically, in this embodiment, the parent node continuously listens for and receives a second instruction from the master station. This second instruction instructs the parent node to restore the configuration of the SM channel. Upon receiving the second instruction, the parent node switches its communication operation state from the secure operation state during the upgrade phase to the pre-operation state, and then from the pre-operation state to the Init initialization state. This provides a safe configuration switching condition for subsequent SM channel parameter reset, avoiding data read / write conflicts during dynamic configuration. Based on this, the parent node re-enables the SM0 and SM1 channels originally used for real-time process data interaction, cancels the Mailbox channel configuration temporarily effective during the upgrade phase, restores the original register parameters, DPRAM buffer addresses, and data interaction modes of the two synchronization manager channels, and fully restores the original communication attributes of the channels. Then, it re-establishes the binding mapping relationship between the reset SM0 and SM1 channels and the process data object, releasing the upgrade process from occupying the bus channels. After completing the channel configuration reset and the rebinding of the SM channels and process data objects, the parent node switches its communication state back to the normal operating state.

[0074] In this embodiment, the online reset process does not require power-off restart of the device, manual intervention, or modification of physical wiring. It can quickly and safely restore the real-time control bus function of the device, ensuring the stable continuity of core business such as robot joint motion control and status monitoring, and effectively improving the system's operational reliability and working continuity after the upgrade of multi-level embedded devices.

[0075] Based on the above embodiments, as an optional embodiment, when the target nodes include multiple targets, the multiple target nodes are divided into child node waves and parent node waves according to the dependency relationship of the multiple target nodes in the topology; the child nodes in the child node waves load the firmware blocks with priority over the parent nodes in the parent node waves. In the sub-node wave, sub-nodes sharing the second bus serially load the firmware blocks; In the parent node wavelet, each parent node with an independent physical bus concurrently loads the firmware block.

[0076] Specifically, in this embodiment of the application, when there are multiple devices to be upgraded (including both first-level and second-level nodes), this embodiment adopts a wave-based concurrent upgrade scheduling strategy to maximize upgrade efficiency while ensuring communication security and forwarding capabilities. This scheduling strategy includes the following steps: (1) Device grouping: The master station scans the configuration table and divides all devices to be upgraded into a set of child nodes and a set of parent nodes according to the has_parent flag; (2) Wave and sequence definition: The set of child nodes is the first wave; the set of parent nodes is the second wave. Since the parent node usually loses its second bus forwarding capability or at least has limited forwarding performance once it enters bootloader mode, it is necessary to upgrade all child nodes first and then upgrade the parent node; (3) Intrawave scheduling strategy: For the child nodes of the first wave, the child nodes of the same parent node need to be executed serially because they share the same physical bus; the child nodes under different parent nodes can theoretically be executed independently because they belong to different physical buses and parent nodes. However, at the EtherCAT level, all data frames share the same daisy chain. Therefore, the master station applies a mutex lock to the EtherCAT bus IO operation (such as EtherCAT frame sending and receiving) so that only one datagram is transmitted on the physical link at the same time; at the application layer, the process of each child node waiting for Mailbox to be ready, sending data blocks, and waiting for acknowledgment is designed to be pipelined concurrently promoted. When a child node is waiting for acknowledgment or Flash writing, the master station can send data blocks to other child nodes, thereby improving the link utilization. (4) For the parent nodes of the second wave, since the EtherCAT Mailbox channels of each parent node are independent of each other and have no shared resource dependencies, multiple devices can be upgraded concurrently on the basis of mutex locks. The concurrency limit is determined by the main station's capabilities, network bandwidth and system configuration, for example, it can be limited to N concurrent processes. (5) Anomaly handling and result summary: The failure of any device upgrade will not affect the continued execution of other devices in the same wave. The main station records the success / failure status code of each device and reports it uniformly after all waves are completed.

[0077] Figure 6 This is a schematic diagram of a multi-node concurrent upgrade scheduling provided in an embodiment of this application. As shown in the figure, the node to be upgraded includes child node 310, child node 320, parent node 200, and parent node 210. Child node 310 and child node 320 are both subordinate to parent node 200. Therefore, child node 310 and child node 320 are assigned to a child node set, and parent node 200 and parent node 210 are assigned to a parent node set. The child node set is set as the first wave, and the parent node set is set as the second wave. Since child node 310 and child node 320... Since they share the same physical bus, the upgrades must be performed serially. As shown in the figure, child node 310 starts upgrading at time T0 and finishes upgrading at time T2. Child node 320 starts upgrading at time T2 and finishes upgrading at time T4. At this point, all child nodes in the first wave have completed their upgrades. Parent nodes 200 and 210 are connected to the master station via independent buses. Therefore, parent nodes 200 and 210 can upgrade in parallel. As shown in the figure, parent nodes 200 and 210 start upgrading at time T4 and finish upgrading at time T6.

[0078] In this embodiment, the child nodes are upgraded first, followed by the parent nodes, to ensure that no abnormal issues such as communication loss or interruption of instruction forwarding occur during the upgrade process, thus ensuring the safety and controllability of bus communication throughout the multi-level topology. At the same time, the parallel upgrade of child nodes under different parent nodes can significantly shorten the firmware upgrade time of all joint modules of the robot, reduce equipment downtime for maintenance, and improve the operational efficiency of production line equipment.

[0079] Based on the above embodiments, as an optional embodiment, after receiving the data frame sent by the master station through the write Mailbox channel of the parent node, the method further includes: The firmware is written in blocks to a temporary file, and the buffer data corresponding to the temporary file is forcibly written to the storage medium. The temporary file is renamed to the target configuration file through an atomic renaming operation, and the directory index record of the parent directory where the target configuration file is located is synchronously written to the storage medium.

[0080] Specifically, in this embodiment, the parent node writes all received firmware to a temporary file, then performs a cache synchronization operation to forcibly solidify the buffered data related to the temporary file in memory to the local storage medium, preventing file corruption caused by sudden power outages. Next, the parent node replaces the official target configuration file with an atomic renaming operation from the operating system. This operation has no intermediate interruptions and will not damage the original usable firmware. Finally, the parent node synchronously writes the directory index record of the target configuration file's parent directory, permanently saving the file renaming information to storage to prevent the system from failing to recognize the updated firmware after a reboot. In essence, the received firmware data is first stored in an independent temporary file, and after data solidification, the official file is replaced by an uninterrupted atomic renaming operation. Even if a sudden power outage occurs during the upgrade, the system only has two stable states: the old firmware remains intact or the new firmware is fully functional. No incomplete or damaged firmware blocks are generated, fundamentally preventing device startup failures due to update malfunctions.

[0081] In this embodiment, a combination of temporary file storage, data synchronization, atomic renaming, and directory synchronization processes is used to avoid incomplete configuration files due to power outages during firmware updates, significantly reducing the probability of nodes failing to start due to firmware update failures, and effectively improving the storage security and operational reliability of the firmware upgrade process.

[0082] Figure 7 This is a flowchart illustrating another multi-level embedded device upgrade method provided in an embodiment of this application. The method is applied to a multi-level embedded device upgrade system, which includes a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the master station, and as shown in the figure, the method includes: S701, a data frame is sent to the parent node via the first bus; the data frame includes the identifier of the target node, a firmware block, and the sequence number of the firmware block; the identifier of the target node is the identifier of the parent node or the identifier of a child node under the parent node.

[0083] Specifically, in this embodiment, the master station maintains a configuration table that records a mapping relationship for each upgradeable node (including parent and child nodes): {ota_node, target_node_id, has_parent}. Here, ota_node represents the address value actually written to the EtherCAT frame header by the master station. For a parent node, ota_node equals the parent node's own EtherCAT address offset (typically embedded_id + 1). For a child node, ota_node equals its parent node's EtherCAT address offset. target_node_id is the final target identifier of the node_id field in the payload. has_parent indicates whether the node is a child node. When starting the upgrade, the master station determines the physical destination address (data frame address) and logical destination identifier (target node identifier) ​​of the data frame based on this configuration table, and segments it in units of a preset fixed block length (e.g., 1024 bytes). If the last block is insufficient, it is padded with 0x00. Furthermore, each data frame carries the expected value of the overall CRC32 of the firmware block: flash_crc32.

[0084] S702, the response data of the target node is obtained through a read operation. The response data of the target node is either first response data or second response data. The first response data is the response data of the parent node, and the second response data is the response data of the child node. The first response data or the second response data is stored in the parent node's read Mailbox channel buffer. The first response data or the second response data includes a status code and the sequence number of the firmware block. The status code is used to indicate the transmission status of the firmware block corresponding to the sequence number.

[0085] Specifically, in this embodiment, when the identifier of the target node is the identifier of the parent node, the parent node generates first response data and writes the first response data into the read Mailbox channel buffer; when the identifier of the target node is the identifier of the child node, the parent node forwards the data frame to the child node, waits for the child node's second response data, and after receiving the child node's second response data, fills the second response data back into the read Mailbox buffer. The master station initiates an EtherCAT read operation (e.g., FRMW command) to the parent node to obtain the target node's response data from the parent node's read Mailbox channel buffer, thereby completing a request / response closed loop.

[0086] In some embodiments, when the identifier of the target node is the identifier of the parent node, the response data of the target node obtained by the master station is the first response data generated by the parent node; when the identifier of the target node is the identifier of the child node, the response data of the target node obtained by the master station is the second response data generated by the child node.

[0087] In some embodiments, the response data includes a status code and a firmware block sequence number, wherein the status code is used to indicate whether the firmware block transmission was successful or failed; for example, if the response data includes a status code of UpdateCodeOk, the firmware block sequence number matches, and the parent node does not report a CRC error, it indicates that the firmware block transmission was successful.

[0088] In this embodiment, the data frames sent by the master station only address the parent node, and node location is completed by relying on the child node identifier. The child node remains transparent to the EtherCAT bus, and there is no need to configure an ESC chip separately, which effectively reduces hardware material costs, reduces bus communication load, and simplifies the complexity of system wiring. At the same time, relying on the data routing and response backfilling mechanism based on the node identifier of the parent node, the master station only needs to run the EtherCAT protocol stack throughout the process and complete all interactions with the parent node through the Mailbox channel, which greatly reduces the software development workload of the master station and the parent node, and reduces program maintenance costs and software failure risks.

[0089] Based on the above embodiments, as an optional embodiment, the step of sending a data frame to the parent node via the Mailbox channel further includes: Send a first instruction to the parent node, the first instruction being used to instruct the parent node to unbind the synchronization management SM channel from the process data object, and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel.

[0090] Specifically, in this embodiment of the application, in order to reuse the real-time control network for firmware upgrade communication without changing the physical connection or cutting off the system power supply, the SyncManager (SM) online reconfiguration technology is adopted. It directly operates the SM configuration register inside the parent node ESC and dynamically switches the working mode of the SM channel while keeping the EtherCAT link layer active.

[0091] In some embodiments, the master station sends a first instruction to the parent node, which instructs the parent node's master-slave state to switch sequentially from the running state (OP) to the pre-running state (PreOp) and then to the safe running state (SafeOp). Then, the SM0 and SM1 channels originally used for process data (PDO) exchange are closed, and the old process data image buffer related to PDO inside the ESC is cleared (e.g., written to zero) to prevent residual data from interfering with subsequent Mailbox operations. Subsequently, SM2 is reconfigured as a read Mailbox channel, and SM3 is reconfigured as a write Mailbox channel. After the reconfiguration is completed, the parent node is kept in the SafeOp state so that Mailbox communication can proceed normally.

[0092] In some embodiments, when reconfiguring the SM2 and SM3 channels, it is also necessary to set their physical start address and length respectively; wherein, the physical start address and length can be set to 0x1400 and 0x1600 respectively, for example.

[0093] In some embodiments, the master station writes upgrade commands and firmware data into the buffer of the SM3 channel using commands such as FPWR, which is then read by the target node and executes the corresponding upgrade operation; the SM2 channel is used by the parent node to write response data, which is then read by the master station using commands such as FRMW.

[0094] In this embodiment, based on the routing and response backfilling mechanism of the parent node, the master station interacts with the parent node only through a single Mailbox channel. The communication process between the parent node and the child node is transparent to the master station. The master station does not need to be aware of protocol conversion, which effectively solves the dual-session problem caused by multi-protocol fragmentation, simplifies the bus interaction logic, significantly reduces the software development and maintenance costs of the master station and parent node, and reduces the potential for software failure.

[0095] Based on the above embodiments, as an optional embodiment, after obtaining the response data of the target node through a read operation, the method further includes: Send a second instruction to the parent node, the second instruction being used to instruct the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channels and the process data object.

[0096] Specifically, in this embodiment, after the target node completes the upgrade, the master station switches the slave status of the parent node back to Init, restores the PDO configuration of SM0 / SM1, rebinds the process data object, and finally switches the status back to OP, thus seamlessly restoring real-time control. It can be understood that the above channel restoration process is the reverse process of the channel reconfiguration process, that is: after all the firmware fragmentation transmission, data verification, program burning and upgrade response feedback processes of all parent nodes and lower-level child nodes are completed, the master station actively initiates the bus status reset and channel restoration operation, and completely exits the firmware upgrade exclusive communication mode.

[0097] In some embodiments, the master station uses standard EtherCAT state switching instructions to switch the parent node's operating state from the pre-running state used for upgrades to the initialization state, releasing the Mailbox channel occupancy state during the upgrade phase. Subsequently, the master station uses FPWR low-level write instructions to rewrite the synchronization manager register of the parent node's ESC chip, canceling the Mailbox expansion configuration for SM2 and SM3 channels, clearing the cache parameters and communication modes of the upgrade channels, and restoring the native PDO real-time communication configuration of SM0 and SM1 channels. Then, it re-completes the binding and matching between the synchronization manager channels and each process data object, restoring the periodic real-time interaction functions such as motion control and data acquisition. After all configurations are reset, the master station issues state switching instructions again to stably switch the parent node to the OP normal operation state.

[0098] In this embodiment, the SM channel recovery process corresponds completely to the SM channel reconfiguration process. The entire process is completed online and dynamically without power interruption or restart, and does not rely on any manual plugging or unplugging of cables or external programmers, effectively improving the continuity and stability of system operation.

[0099] Based on the above embodiments, as an optional embodiment, the end of the firmware block includes signature information, which includes payload length and payload check value; if any of the following conditions are met, no data frame is sent to the parent node: The field of the signature information is the first field; The actual length of the firmware block payload is inconsistent with the payload length included in the signature information; The actual verification value of the firmware block payload is inconsistent with the payload verification value included in the signature information.

[0100] Specifically, in this embodiment of the application, to ensure the robustness of the upgrade and prevent the device from becoming unusable due to incomplete firmware files, transmission errors, or misoperation, this embodiment of the application introduces a multi-verification mechanism in the firmware preparation and file writing stages. Specifically, during the firmware image file generation stage, the compilation tool appends 8 bytes of signature information to the end of the firmware; the first 4 bytes store the length of the firmware payload (excluding the end signature) in little-endian format, and the last 4 bytes store the CRC32 checksum of the entire payload.

[0101] In some embodiments, after loading the firmware file, the master station performs the following mandatory verification steps: (1) Read the last 8 bytes. If all of them are 0xFF, it is determined that the firmware is not signed. Any subsequent upgrade operation will be rejected and an error will be reported. (2) If it is not 0xFF, the declared length L and the declared CRC32 value C are parsed, and then the actual length L' of the firmware file is calculated. If L' is not equal to L, the verification fails and the upgrade is rejected. The CRC32 value C' of the first L bytes of the file is calculated. If C' is inconsistent with C, the verification also fails and the upgrade is rejected.

[0102] In some embodiments, the firmware file is divided into units of a preset fixed block length (e.g., 1024 bytes), and the last block is padded with 0x00 if it is not long enough. Each block command payload carries the overall CRC32 expected value of the block, flash_crc32. After receiving all the data blocks and writing them to Flash, the child or parent node calculates the CRC32 of the written area in the internal flash memory and compares it with flash_crc32. Only if the comparison matches can the upgrade be terminated.

[0103] In this embodiment, the main station performs mandatory verification on the firmware file, blocking invalid files at the source and ensuring that only complete firmware with proper signature can enter the upgrade process, effectively enhancing the robustness of the upgrade.

[0104] To facilitate a clearer and more intuitive understanding of the multi-level embedded device upgrade process by those skilled in the art, the embodiments of this application are described in conjunction with specific examples. Figure 8 A schematic diagram of a multi-level embedded device upgrade process provided in this application embodiment is shown in the figure. The upgrade process includes the following steps: S801, the main station loads the configuration file and firmware program.

[0105] In some embodiments, the master station reads the configuration table to obtain the ota_node, target_node_id, and has_parent of the device to be upgraded, and loads the firmware binary file.

[0106] S802. The main station verifies whether the firmware is valid. If valid, proceed to S803. If invalid, the upgrade fails.

[0107] In some embodiments, the master station performs end signature verification on the firmware binary file, such as verifying the length and CRC32; if the verification fails, the upgrade process is terminated.

[0108] S803, the master station reconfigures the parent node's SM channel as the Mailbox channel.

[0109] In some embodiments, the master station performs SM online reconfiguration on the EtherCAT slave (parent node or itself) pointed to by ota_node, disables the PDO channel, enables the Mailbox channel, and ensures that the slave is in the safe operating state SafeOp.

[0110] S804, the target node jumps to boot mode.

[0111] In some embodiments, the master station sends a "Read Current Mode" command via Mailbox to confirm that the application region and bootloader region of the target node (specified by node_id) are valid; then it sends a "Jump to bootloader" command, and the target node restarts and enters bootloader mode. If the target node is a child node, the command is forwarded through the parent node.

[0112] S805: The main station confirms whether the boot mode is normal; if normal, proceed to S806; if not, the upgrade fails.

[0113] In some embodiments, after the target node restarts and stabilizes, the master station re-initiates EtherCAT link establishment (ConfigureDataLink) and performs SM online reconfiguration again. Then, it confirms that it has successfully entered the bootloader by reading the mode information through Mailbox.

[0114] S806, The main station issues the upgrade start command.

[0115] In some embodiments, the master station constructs an upgrade start command (StartCode), fills the node_id into the target_node_id, and sends the command to the parent node (or the target itself) through the Mailbox write channel; after the target node completes the preparation work, it writes the StartCodeOk response into the Mailbox read buffer; the master station reads the Mailbox buffer in a loop until it obtains the response.

[0116] S807, the master station sends 1024-byte firmware blocks in a loop.

[0117] In some embodiments, the master station cyclically sends 1024-byte firmware blocks. Specifically, the master station constructs a firmware block transmission command (UpdateCode), filling the payload with the current block's sequence number, block content, overall CRC32, and block length. The command is then sent out via EtherCAT to the Mailbox. When the parent node determines that the target node's identifier matches the child node's identifier based on the node_id, it forwards the UpdateCode command to the child node via the second bus. The child node then replies to the parent node's read Mailbox via the parent node. The master station retrieves the response from the parent node's read Mailbox, thus achieving cross-level routing.

[0118] In some embodiments, the master station divides the firmware into 1024-byte blocks, padding with zeros if the block length is insufficient, and records the total number of blocks.

[0119] S808: The master station confirms whether it has received the firmware block response data; if it has, it executes S809; if it has not, the upgrade fails.

[0120] In some embodiments, the master station waits for the Mailbox to be ready and reads back the response; it verifies that the status code in the response is UpdateCodeOk, the sequence number matches, and the peer does not report a CRC error. If an error occurs, it stops and reports it; the master station may optionally report the progress code when the progress reaches 20%, 40%, 60%, and 80%.

[0121] S809, The main station issues the upgrade end command.

[0122] In some embodiments, after all block transfers are completed, the master station sends an upgrade end command (FinishCode) and waits for the target node to complete firmware verification and writing before returning an upgrade end command response (FinishCodeOk).

[0123] S810, Parent Node Restore Synchronization Management Channel and Process Data Object Configuration.

[0124] In some embodiments, after receiving the response of the upgrade end instruction, the master station switches the slave status of the parent node to Init, reconfigures the SM0 / SM1 channels and restores the original PDO channel settings, rebinds the process data object, and finally switches the status back to the running status OP, restores real-time control communication, and records the upgrade success result code or exception code.

[0125] In this embodiment, the data frames sent by the master station only address the parent node, and node location is completed by relying on the child node identifier. The child node remains transparent to the EtherCAT bus, and there is no need to configure an ESC chip separately, which effectively reduces hardware material costs, reduces bus communication load, and simplifies the complexity of system wiring. At the same time, relying on the data routing and response backfilling mechanism based on the node identifier of the parent node, the master station only needs to run the EtherCAT protocol stack throughout the process and complete all interactions with the parent node through the Mailbox channel, which greatly reduces the software development workload of the master station and the parent node, and reduces program maintenance costs and software failure risks.

[0126] Furthermore, by using SyncManager online reconfiguration technology in conjunction with a single-packet secondary addressing protocol, node upgrades can be completed remotely and non-intrusively without power outages, disassembly, or rewiring, relying solely on the existing EtherCAT network cable, thus meeting the needs of unmanned robot maintenance. Simultaneously, protocol routing and forwarding are handled by the parent node, eliminating the need for child nodes to carry a complete EtherCAT protocol stack; instead, a simplified bootloader is run, reducing the space occupied by upgrade-related code from tens of KB to hundreds of bytes, significantly freeing up storage and computing power for low-resource-driven MCUs. In addition, a layered, wave-based concurrent scheduling strategy for parent and child nodes ensures that child nodes sharing the same sub-bus are upgraded sequentially, while parent nodes with independent physical buses are upgraded synchronously and in parallel. This avoids communication failures caused by the parent node losing its sub-bus forwarding capability after entering the bootloader, significantly shortening the total upgrade time for batch devices while ensuring reliable bus communication.

[0127] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device 9000 includes a processor 9001 and a memory 9003. The processor 9001 and the memory 9003 are connected, for example, via a bus 9002. Optionally, the electronic device 9000 may further include a transceiver 9004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 9004 is not limited to one type, and the structure of the electronic device 9000 does not constitute a limitation on the embodiments of this application.

[0128] Processor 9001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 9001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0129] Bus 9002 may include a pathway for transmitting information between the aforementioned components. Bus 9002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 9002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0130] The memory 9003 may be ROM (Read-Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read-Only Memory), CD-ROM (Compact Disc Read-Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0131] The memory 9003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 9001. The processor 9001 executes the computer programs stored in the memory 9003 to implement the steps shown in the foregoing method embodiments.

[0132] The electronic device package may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0133] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0134] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium, a computer-readable medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0135] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0136] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.

[0137] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0138] The above are only optional implementation methods for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A method for upgrading multi-level embedded devices, characterized in that, The method is applied to a multi-level embedded device upgrade system, the system including a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the parent node, and the method includes: The system receives data frames sent by the master station using the first bus through the Mailbox channel. The data frames include the identifier of the target node, firmware blocks, and the sequence number of the firmware blocks. If the identifier of the target node is the identifier of the parent node, first response data is generated and written to the read Mailbox buffer; if the identifier of the target node is the identifier of a child node under the parent node, the firmware block is sent to the child node through the second bus, the second response data sent by the child node is received, and the second response data is filled back into the read Mailbox buffer; the first response data or the second response data includes a status code and the sequence number of the firmware block, and the status code is used to indicate the transmission status of the firmware block corresponding to the sequence number; In response to the read operation of the master station, the response data of the target node is sent to the master station through the first bus. The response data of the target node is either the first response data or the second response data.

2. The multi-level embedded device upgrade method according to claim 1, characterized in that, Before receiving the data frame sent by the master station, the process also includes: The system receives a first instruction sent by the master station, which instructs the parent node to unbind the synchronization management (SM) channel from the process data object and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel. In response to the first instruction, the binding relationship between the SM channel and the process data object is released, and the SM channel is reconfigured as a read Mailbox channel and a write Mailbox channel; The buffer of the read Mailbox channel is used to write the response data generated by the parent node or the child node, and the buffer of the write Mailbox channel is used to write the data frames sent by the master station.

3. The multi-level embedded device upgrade method according to claim 2, characterized in that, The step of responding to the first instruction to unbind the Synchronization Management (SM) channel from the process data object and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel includes: The communication state of the parent node is switched sequentially from running state to safe running state and pre-running state; Close the SM0 and SM1 channels used for process data exchange; Clear the internal process data image buffer of the parent node's controller ESC; Configure the SM2 channel as the read Mailbox channel and the SM3 channel as the write Mailbox channel, and set the physical start address and length of the read Mailbox channel and the write Mailbox channel.

4. The multi-level embedded device upgrade method according to claim 3, characterized in that, The response data after sending the firmware chunk transmission command to the master station also includes: The system receives a second instruction sent by the master station, which instructs the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channel and the process data object. In response to the second instruction, the communication state of the parent node is switched to the Init state; Enable the SM0 and SM1 channels for process data exchange, restore the configuration of the SM0 and SM1 channels, and rebind the SM channels to the process data object; Switch the communication status of the parent node back to running status.

5. The multi-level embedded device upgrade method according to any one of claims 1 to 4, characterized in that, When there are multiple target nodes, the multiple target nodes are divided into child node waves and parent node waves according to the dependency relationship of the multiple target nodes in the topology; the child nodes in the child node waves load the firmware blocks with priority over the parent nodes in the parent node waves. In the aforementioned sub-node wave, sub-nodes sharing the second bus serially load the firmware blocks; In the parent node wavelet, each parent node with an independent physical bus concurrently loads the firmware block.

6. The multi-level embedded device upgrade method according to claim 5, characterized in that, After receiving the data frame sent by the main station through the write Mailbox channel of the parent node, the process further includes: The firmware is written in blocks to a temporary file, and the buffer data corresponding to the temporary file is forcibly written to the storage medium. The temporary file is renamed to the target configuration file through an atomic renaming operation, and the directory index record of the parent directory where the target configuration file is located is synchronously written to the storage medium.

7. A method for upgrading a multi-level embedded device, characterized in that, The method is applied to a multi-level embedded device upgrade system, the system including a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The method is executed by the main station, and the method includes: A data frame is sent to the parent node via the first bus; the data frame includes the identifier of the target node, a firmware block, and the sequence number of the firmware block; the identifier of the target node is the identifier of the parent node or the identifier of a child node under the parent node; The response data of the target node is obtained through a read operation. The response data of the target node is either first response data or second response data. The first response data is the response data of the parent node, and the second response data is the response data of the child node. The first response data or the second response data is stored in the parent node's read Mailbox channel buffer. The first response data or the second response data includes a status code and the sequence number of the firmware block. The status code is used to indicate the transmission status of the firmware block corresponding to the sequence number.

8. The multi-level embedded device upgrade method according to claim 7, characterized in that, Before sending the data frame to the parent node via the Mailbox channel, the following steps are also included: Send a first instruction to the parent node, the first instruction being used to instruct the parent node to unbind the synchronization management SM channel from the process data object, and reconfigure the SM channel as a read Mailbox channel and a write Mailbox channel.

9. The multi-level embedded device upgrade method according to claim 8, characterized in that, After obtaining the response data of the target node through a read operation, the process further includes: Send a second instruction to the parent node, the second instruction being used to instruct the parent node to restore the read Mailbox channel and the write Mailbox channel to SM channels, and to restore the binding relationship between the SM channels and the process data object.

10. The multi-level embedded device upgrade method according to any one of claims 7 to 9, characterized in that, The firmware block ends with signature information, which includes payload length and payload checksum. If any of the following conditions are met, no data frame will be sent to the parent node: The field of the signature information is the first field; The actual length of the firmware block payload is inconsistent with the payload length included in the signature information; The actual verification value of the firmware block payload is inconsistent with the payload verification value included in the signature information.

11. A multi-level embedded device upgrade system, characterized in that, The system includes a master station, a parent node directly connected to the master station via a first bus, and child nodes connected to the parent node via a second bus. The master station is configured to send data frames to the parent node via the first bus. The data frame includes an identifier of the target node, a firmware block, and a sequence number of the firmware block. The identifier of the target node is either the identifier of the parent node or the identifier of a child node attached to the parent node. The master station also acquires response data from the target node via a read operation. The response data includes either first response data or second response data, where the first response data is the response data of the parent node and the second response data is the response data of the child node. The first response data or the second response data is stored in the parent node's read Mailbox channel buffer. The first response data or the second response data includes a status code and a sequence number of the firmware block, where the status code indicates the transmission status of the firmware block corresponding to the sequence number. The parent node is used to receive data frames sent by the master station using the first bus through the write Mailbox channel; the data frame includes the identifier of the target node, a firmware block, and the sequence number of the firmware block; if the identifier of the target node is the identifier of the parent node, first response data is generated and written to the read Mailbox buffer; if the identifier of the target node is the identifier of the child node, the firmware block is sent to the child node through the second bus, and the parent node sends second response data; in response to the read operation of the master station, the parent node sends the response data of the target node to the master station through the first bus, and the response data of the target node is either the first response data or the second response data.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method of any one of claims 1 to 6, or the method of any one of claims 7 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6, or the method of any one of claims 7 to 10.

14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6, or the method of any one of claims 7 to 10.

Images