Cooperative upgrading method based on EtherCAT bus and master station equipment

Abstract

The invention relates to the technical field of firmware upgrading, and provides a collaborative upgrading method based on an EtherCAT bus and master station equipment aiming at the problems of high cost, low efficiency and insufficient adaptability in the prior art, MCU and FPGA firmware are encrypted through an EtherCAT master station, functional modules are divided, an encrypted firmware packet is transmitted to an MCU by utilizing a FoE function, the MCU receives and stores the firmware and then resets to enter a bootstrap program, and the MCU is used for upgrading the firmware. The firmware is decrypted and upgraded according to the modules, the modules occupying few resources are preferentially upgraded, the modules in the optimal state are skipped, the FPGA is reconfigured after upgrading is completed, the upgrading result is recorded, efficient and safe MCU and FPGA collaborative upgrading is achieved, and the maintenance cost is reduced; through the modular design of the firmware package, the identification of the FPGA model and the adjustment of the upgrade package, the adaptation of different FPGA models is realized, and the problem that the adaptation of the FPGA firmware upgrade to different models is insufficient in the prior art is effectively solved.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware upgrade, and particularly relates to a collaborative upgrade method and a master device based on the EtherCAT bus. Background Art

[0002] The IO module, that is, the input / output module, is a key device in an industrial automation system for collecting and controlling on-site signals. It is connected to the system master station through communication buses such as EtherCAT and RS485. The IO module usually consists of an MCU, that is, a microcontroller, an FPGA, that is, a field programmable gate array, input / output interfaces, etc. Among them, the MCU is used for overall control logic, communication management, and status monitoring, while the FPGA focuses on complex signal processing, high-speed data processing, and hardware acceleration. With the continuous iteration of product technology and the increasing diversification of user needs, the firmware upgrade of the MCU and FPGA has gradually become an important and frequent requirement.

[0003] For the upgrade of the IO module, the existing technologies are divided into two types: relying on an external upgrader and remote upgrade. Among them, the external upgrader method requires additional hardware tools, such as a JTAG upgrader, a JLink emulator, etc. During the operation, a dedicated person needs to disassemble the shell of the IO module and connect the upgrader to the MCU or FPGA through a dedicated interface for manual upgrade. In addition, there are also some remote upgrade methods. For example, the invention patent "IO Module Firmware Upgrade Method, Device, Equipment and Readable Storage Medium" with the patent number CN202411480679.9 discloses an IO module firmware upgrade method. This method receives the firmware upgrade file sent by the master station, generates a firmware package and a FoE password instruction, parses the encrypted header and the instruction to determine the target IO module, and then sends the firmware package to the corresponding module to complete the upgrade. It mainly aims at each IO module of the EtherCAT slave station, does not distinguish the collaborative upgrade of the MCU and the FPGA, and focuses on transmitting files through the FOE protocol, the parsing of the firmware package and the determination of the target module. The upgrade process is relatively general and applicable to the upgrade scenarios of various IO modules, but it does not perform refined management on the resource occupation and module status during the upgrade process; the invention patent "An IO Module Firmware Update Method Based on an EtherCat Coupler" with the patent number CN118394393B discloses an IO module firmware update method. After the EtherCat coupler receives the master station file, it repackages and makes a firmware upgrade request file, and sends it to the plug-in type IO through the backplane bus. The MCU module in the IO divides the space to receive the firmware package and decompresses and upgrades it. This method mainly involves the upgrade of the MCU module, focuses on dividing a temporary area in the storage area of the plug-in type IO to store the firmware upgrade package, and verifies the firmware package, and has a clear fallback mechanism for upgrade failure, and is more suitable for the specific hardware architecture upgrade of the plug-in type IO.

[0004] Traditional methods for remotely upgrading MCUs or FPGAs generally require adapting to the ISP program of the MCU or FPGA, i.e., the in-system programming program. However, due to differences in chip architectures, interfaces, communication protocols, etc. among different manufacturers, it is difficult to use a unified ISP program for firmware upgrade. Currently, although there are some developments of general ISP programs, due to the significant differences in architectures, interfaces, and communication protocols of FPGA chips from different manufacturers, it still faces great challenges to achieve unified adaptation for multiple models of FPGAs. For example, the invention patent "FPGA Image Loading Method, System, Terminal and Storage Medium" with the patent number CN117149222A discloses an FPGA image loading method, system, terminal and storage medium. By adding a classification number representing the adapted FPGA model in the FLASH address table, it realizes the selection of the loaded image and order for different classified FPGAs, and solves the problems of traditional FPGA loading being only applicable to a single FPGA type and the image being not easily updated.

[0005] In practical applications, the external upgrader method is often complex in operation, high in cost, unable to upgrade multiple modules simultaneously, and low in efficiency; moreover, it requires system downtime during operation, affecting the normal operation of the system. Although the existing remote upgrade methods are simple in operation and strong in flexibility, they do not perform refined management on resource occupation and module status during the upgrade process of FPGAs and MCUs, resulting in low upgrade efficiency and high error rate; in addition, for different chip models, engineers usually need to perform specific ISP operations according to the specific chip model and the tools provided by the manufacturer to ensure programming compatibility and stability. When switching between MCUs or FPGA chips from different manufacturers, it is necessary to reconfigure the ISP tool and programming environment, with limited functions and low efficiency. Summary of the Invention

[0006] Aiming at the problems of high cost, low efficiency and insufficient adaptability in the prior art, the purpose of the present invention is to provide a collaborative upgrade method and a master device based on the EtherCAT bus, optimize the way of upgrading the firmware of MCUs and FPGAs in IO modules, get rid of the dependence on external upgraders, improve the efficiency of IO firmware upgrade, reduce the cost of product maintenance, and at the same time improve the adaptability to FPGA models from different manufacturers.

[0007] To achieve the above object, the present invention proposes a collaborative upgrade method based on the EtherCAT bus for remotely upgrading the firmware of MCUs and FPGAs in IO modules connected through the EtherCAT bus, which operates according to the following steps: S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers; uses an encryption algorithm to encrypt all firmware modules of the MCU and FPGA, and the encryption header contains a firmware type identifier and a firmware model, and combines them into a firmware upgrade package; S2: Through the EtherCAT master host computer, use the FoE function to transfer the firmware upgrade package to the MCU via the network cable; S3: After receiving the firmware upgrade package, the MCU stores it in its own storage unit, and writes an update flag in the storage unit after the storage is completed. Subsequently, the MCU resets and enters the bootloader; S4: The MCU decrypts the firmware upgrade package in the bootloader, determines whether the firmware belongs to the FPGA or the MCU based on the firmware type identifier in its encryption header, and reads the module identifier to determine the MCU and FPGA function modules that need to be updated; S5: If it is FPGA firmware, the MCU obtains the FPGA firmware model in the firmware encryption header, determines whether the upgrade package is suitable for this model. If it is suitable, proceed to the next step; if not, the FPGA sends a firmware adjustment instruction to the MCU. The MCU retrieves the adapted JTAG timing parameter configuration strategy from the storage unit according to the FPGA firmware model, modifies the original firmware package configuration strategy and repackages it to adapt to this model; then the MCU performs the storage unit erase and write operation of the simulated JTAG timing for each FPGA function module according to the module identifier in the firmware package to complete the firmware upgrade of the FPGA; if it is MCU firmware, the MCU writes the upgrade package data and configuration data into its own storage unit according to the module identifier in the firmware package to complete the individual firmware upgrade of each module of the MCU; S6: After the firmware of the FPGA and the MCU are both upgraded, the MCU erases the update flag, resets and enters the new MCU firmware to complete the entire upgrade process.

[0008] The present invention selects the communication technology based on the EtherCAT bus because the EtherCAT bus protocol supports the FoE function, which makes the file transfer during the update process very flexible and the transmission reliable.

[0009] Specifically, in the S1, the function module contains module information, namely module identifier, module status, update requirement information, and inter-module association information; the module identifier is the name and version number of the module, which is used for the MCU to identify the specific module during the upgrade process; the module status is the running or configuration status of the module; the update requirement information is the identifier indicating whether the module needs to be updated, where 0x01 indicates that it needs to be updated, and 0x00 indicates that it does not need to be updated; the inter-module association information refers to the priority relationship between modules, where the priority relationship refers to the upgrade priority between modules. The design of the module information is used to assist the modular upgrade process, and can prepare for the individual upgrade and skipping of subsequent modules, improving the efficiency and accuracy of the upgrade.

[0010] In S1, the firmware type identifier is an identifier used to distinguish between FPGA or MCU firmware types. 0x01 represents MCU firmware, and 0x02 represents FPGA firmware.

[0011] In S1, the EtherCAT master obtains the usage of the hardware logic resources of the MCU and FPGA through a detection tool, and embeds the module identifier and the usage of the hardware logic resources into the encrypted header of the firmware upgrade package. The detection tool refers to a software tool that obtains the usage rate of the central processing unit of the MCU, the memory occupancy, and the usage of the block memory, clock frequency, etc. of the FPGA. The hardware resource usage refers to the usage rate of the central processing unit of the MCU, the memory occupancy, and the usage of the block memory, clock frequency, etc. of the FPGA. This enables the upgrade package to be upgraded according to the actual module status and hardware status. Especially in the case of limited resources, it can significantly improve the system performance while ensuring the security and integrity of the upgrade process.

[0012] Specifically, in S3, after writing the update flag in its own storage unit, the MCU also generates a configuration file containing the firmware package version information and the module identifier, which is used to quickly identify the content of the firmware package and the update requirement information in the bootloader. This reduces the waiting and judgment time of the bootloader during the upgrade process and significantly improves the recognition efficiency of the upgrade process.

[0013] Specifically, in S4, the MCU respectively identifies the start addresses of the FPGA and MCU firmware according to the firmware type identifier in the encrypted header, reads out the corresponding firmware data from the storage unit, and decrypts the read data frame by frame to decrypt the original firmware data and related information including the module identifier and the usage of the hardware logic resources. The frame-by-frame decryption refers to a method of splitting the firmware package into multiple small units, i.e., data frames, for transmission, and decrypting each frame separately. The advantage of this is that in the event of a failure during the firmware upgrade process, only the current frame needs to be re-upgraded; while in the case of ordinary whole-package decryption, it occupies a large amount of storage space, and in case of failure at any time, the upgrade must start all over again.

[0014] Specifically, in S4, the MCU verifies the decrypted firmware data. If there are firmware type mismatches, firmware damage, and version incompatibilities, the upgrade is interrupted, and the MCU sends an error message to the host computer, including the upgrade interruption signal and the error type; if there are no firmware type mismatches, firmware damage, and version incompatibilities, it proceeds to the next step; this design can effectively prevent incorrect firmware from being written into the device, avoid device failures, facilitate quick problem location, and improve the upgrade success rate and system reliability.

[0015] Specifically, in S5, when the MCU adjusts the firmware package, the specific steps are as follows: S51: Before firmware upgrade, perform pre - adaptability analysis on FPGA chips from different manufacturers, and allocate an adapted JTAG timing parameter configuration strategy for each model. S52: Push the configuration strategy to the MCU storage unit in the form of a data packet for storage. S53: After the MCU receives a firmware adjustment instruction, the MCU retrieves the corresponding configuration strategy from the storage unit according to the model identification of the FPGA. S54: The MCU writes the corresponding configuration strategy into the firmware package and repackages the firmware upgrade package.

[0016] The JTAG timing parameter configuration strategy is a set of parameters set to adapt to different FPGA chip models, defining the specific timing requirements of the JTAG interface during data transmission and instruction control, including clock frequency, data sampling time, and instruction cycle, to ensure that the FPGA can correctly receive and execute JTAG instructions and complete the firmware upgrade operation. The advantage of this is that through the pre - adaptability and adjustment mechanism, automatic fine - tuning of the upgrade package can be achieved for each FPGA model, reducing problems such as upgrade failures or repeated configurations caused by model mismatches, improving the upgrade efficiency, reducing the complexity of maintenance and upgrade, and lowering the product maintenance cost.

[0017] Specifically, in S5, when upgrading the MCU and FPGA firmware, the MCU checks the module identification of each module; for modules that do not need to be upgraded, the MCU skips the update of this module during this time and stores the identification information of this module in its own storage unit. This reduces unnecessary update operations and improves the upgrade efficiency. When the device is started up next time, the MCU reads the identification information in the storage unit and updates the modules that have upgrade requirements and were skipped before, ensuring that all modules can ultimately be updated to the latest version and guaranteeing the stability of system operation.

[0018] Specifically, in S5, when upgrading the MCU and FPGA firmware, the MCU selects to upgrade the modules that occupy less resources preferentially according to the usage of logical resources, in combination with the module identification, reducing the pressure on logical resources. Especially in the case of limited resources, this optimization can significantly improve the performance of the system.

[0019] Specifically, in S6, after the MCU completes the FPGA firmware upgrade, it performs a reconfiguration operation on the FPGA, which ensures that the FPGA can be put into use immediately after the upgrade; after completing the firmware upgrades of the FPGA and the MCU, the MCU records the upgrade results in its storage unit and sends the upgrade results back to the EtherCAT master station; the EtherCAT master station generates a firmware upgrade log based on the upgrade results. This step ensures the traceability of the firmware upgrade process and the efficiency of problem location, and at the same time provides reliable data support for subsequent maintenance and optimization.

[0020] Specifically, during the operation of the functional program, the MCU is used to handle the backplane bus connection with the coupler, receive the remote upgrade firmware data of the FPGA and the MCU, and transmit the data required for the FPGA function to the FPGA through the SPI bus. At the same time, it detects whether the firmware needs to be upgraded, thereby improving the automation degree and operation efficiency of the system. During the operation of the functional program, the FPGA receives data from the MCU through the SPI bus, responds to the instructions of the MCU, and performs tasks such as logical operations and data processing to ensure the efficient operation of the system.

[0021] The present invention also proposes a collaborative upgrade master station device based on the EtherCAT bus, comprising: A processing unit, which is used to implement each step of the collaborative upgrade method based on the EtherCAT bus as described in any one of the above; A readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements each step of the collaborative upgrade method based on the EtherCAT bus as described in any one of the above.

[0022] The processing unit further includes a communication module, which sends the firmware upgrade log to the manufacturer maintenance personnel of the FPGA and the MCU by means of email or text message for later problem location and upgrade.

[0023] From the above technical solutions, it can be seen that the present technical method provides a collaborative upgrade method and a master station device based on the EtherCAT bus. By encrypting the firmware of the MCU and the FPGA respectively and dividing the functional modules by the EtherCAT master station, the encrypted firmware package is transmitted to the MCU by using the FoE function. After the MCU receives and stores it, it resets and enters the bootloader, decrypts the firmware and upgrades according to the modules, preferentially upgrades the modules that occupy less resources, skips the optimal state modules, reconfigures the FPGA after the upgrade and records the upgrade results, realizing the efficient and secure collaborative upgrade of the MCU and the FPGA. Among them, the optimal state module refers to the module that has already been in the latest version state and does not require an upgrade operation.

[0024] In this technical method, the collaborative work of the MCU and FPGA ensures the efficiency, stability, and reliability of the upgrade process. Among them, the MCU serves as the main controller, responsible for the management of the entire upgrade process, including receiving and storing firmware packages, decrypting and identifying firmware data, executing upgrade operations, and status management. The FPGA receives upgrade data during the upgrade process, responds to the instructions of the MCU, and is reconfigured after the upgrade is completed to ensure that the new firmware can work properly. This collaborative work method not only improves the upgrade efficiency but also enhances the stability and adaptability of the system, meeting the requirements of complex industrial automation tasks.

[0025] Through the technical solutions described in the present invention, the technical effects brought by the present invention are as follows: 1. During the entire upgrade process, there is no need for an additional external upgrader. Instead, by using the MCU as a built-in upgrader and controlling the FPGA and MCU upgrade mode through the MCU, the dependence on traditional hardware devices is reduced. At the same time, through the modular design of the firmware package and the identification of FPGA models and adjustment of upgrade packages, the adaptation to different FPGA models is achieved, effectively solving the problem of insufficient adaptability to different models during FPGA firmware upgrade in the prior art and reducing the product maintenance cost.

[0026] 2. According to the usage of hardware resources, modules that occupy less resources are preferentially upgraded, reducing the pressure on hardware resources, improving the upgrade efficiency, and avoiding the downtime of the IO module caused by the traditional external upgrader method, thus improving the stability of the system.

[0027] 3. Through the application of encryption algorithms and the embedding of module identifiers, the security and integrity of firmware data are ensured, and the security of system operation is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0029] Figure 1 It is a schematic diagram of the hardware connection of an application environment disclosed in an embodiment of the present application; Figure 2 It is a schematic diagram of the working principle of the interaction between the FPGA and the MCU inside the IO module disclosed in an embodiment of the present application; Figure 3 It is a schematic diagram of data interaction of the firmware upgrade package encrypted based on the AES_ECB algorithm disclosed in an embodiment of the present application; Figure 4Flowchart of a collaborative upgrade method based on EtherCAT bus disclosed in an embodiment of the present application; Figure 5 Flowchart of firmware upgrade for FPGA disclosed in an embodiment of the present application; Figure 6 Schematic diagram of module resource evaluation process in FPGA upgrade disclosed in an embodiment of the present application; Figure 7 Flowchart of firmware upgrade for MCU disclosed in an embodiment of the present application. Detailed implementation manners

[0030] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0031] Before introducing the present application, the related technologies of the present application will be introduced first.

[0032] EtherCAT is a fieldbus communication protocol based on Ethernet, which is widely used in the field of industrial automation to achieve high-speed and real-time device communication. In the EtherCAT protocol, devices are divided into master stations and slave stations. Among them, the master station is the control center of the network, responsible for managing and coordinating the communication of the entire EtherCAT network. The master station is usually a PC host computer or other device that supports the EtherCAT protocol. The slave station is a device connected to the EtherCAT network, usually including a coupler, an IO module, etc. The slave station is responsible for executing the instructions sent by the master station and feeding back the data to the master station.

[0033] The ISP program, that is, the in-system programming program, is a software tool for firmware upgrade and configuration of electronic devices such as MCU and FPGA. The ISP program allows users to directly program the device through specific interfaces, such as JTAG, SPI, etc., after the device has been installed on the circuit board, without removing the chip from the circuit board, thus facilitating the device upgrade operation of users.

[0034] Next, the application scenarios of the present application will be introduced.

[0035] Figure 1 Hardware connection schematic diagram of an application environment disclosed in an embodiment of the present application.

[0036] The present application can be applied to, for example Figure 1In the shown environment, the environment mainly communicates based on the EtherCAT protocol. The EtherCAT protocol is an Ethernet-based fieldbus communication protocol, which is widely used in the industrial automation field to achieve high-speed and real-time device communication. This environment is mainly composed of an EtherCAT master station, a coupler, and IO modules containing an MCU and an FPGA connected together. Among them, the EtherCAT master station is the control core of the system. It is connected to the coupler through the EtherCAT bus, transmits the encrypted firmware upgrade package to the coupler, and then sends it to the MCU in the IO module. The EtherCAT master station is also responsible for monitoring the entire upgrade process and receiving feedback information from the coupler to ensure the smooth progress of the upgrade operation. The coupler and the IO module are EtherCAT slave stations. Among them, the coupler, as an intermediate device, is connected to the IO module through the backplane bus and is used to connect the EtherCAT master station and multiple IO modules, playing the role of data transfer and signal distribution. The IO module is the execution unit during the upgrade process and contains two core components, an FPGA and an MCU. The FPGA is a programmable logic device, which is responsible for receiving instructions from the MCU and cooperating to complete its own upgrade; the MCU is a microcontroller, which is responsible for coordinating the operation of the entire IO module and the firmware upgrade process. The IO module is connected to the coupler through the backplane bus, receives the firmware data from the coupler, and feeds back the upgrade status to the coupler.

[0037] Figure 2 This is the working principle diagram of the interaction between the FPGA and the MCU inside the IO module disclosed in the embodiment of the present application.

[0038] As Figure 2 shown, the MCU in the IO module can include two states, a bootloader and a functional program, during operation.

[0039] 1. When the IO module is powered on, the MCU enters the bootloader. The main tasks of the MCU are: (1) According to the update flag stored at a fixed address in the storage unit of the MCU, determine whether there is a firmware update. This update flag is a four-byte hexadecimal value indicating whether there is an update. For example, 0xA5A5AA55 indicates that there is a firmware update, and 0x5A5A55AA indicates that there is no firmware update. This update flag is marked after the IO module receives the complete FPGA and MCU firmware data, and the reception of the FPGA and MCU dual firmware and the setting up of the update flag occur during the operation of the functional program of the MCU. (2) If there is an update, the firmware upgrade process of the FGPA and the MCU starts; if there is no update, it enters the normal functional program.

[0040] 2. After the bootloader ends, the MCU runs the functional program. The main tasks of the MCU are as follows: (1) Handle the backplane bus connection with the coupler and be responsible for receiving data, including the remote upgrade firmware data for the FPGA and the MCU; (2) Transmit the data required for the FPGA functions to the FPGA via the SPI bus. The SPI bus is a serial communication protocol that enables high-speed, full-duplex synchronous communication between the FPGA and the MCU through simple signal lines; (3) Determine whether the firmware needs to be upgraded based on whether the status indicating the receipt of the FPGA and MCU firmware data is received.

[0041] 3. During the update process, the interaction between the FPGA and the MCU includes: (1) The MCU starts to initialize the resources required for upgrading the FPGA; (2) Identify the start addresses of the FPGA and MCU firmware respectively according to the encryption headers of the encrypted files; (3) Start reading the interval data from the start and end addresses identified in the second step within the storage unit, and start the decryption algorithm to decrypt the original data before encryption; (4) If it is the FPGA firmware, the MCU starts to simulate the JTAG timing and starts to upgrade the FPGA. Continuously repeat steps (3) and (4) until all the firmware data is written into the FPGA, and then perform a reset operation on the FPGA; (5) Continue to read the MCU firmware from the storage unit for decryption; (6) Directly operate the write operation of the MCU's storage unit to write the original firmware content into the area where the running program is located; (7) Erase the update flag so that the upgrade process will not be looped into after entering the bootloader.

[0042] The existing upgrade methods are divided into two types: relying on an external upgrader and remote upgrade. Among them, the external upgrader method requires additional hardware support and manual intervention, increasing the operation cost and time cost. The existing remote upgrade technology can only upgrade a single type of device, that is, only the MCU or only the FPGA, lacking a mechanism for the MCU and FPGA to work together, and it is difficult to meet the collaborative upgrade requirements of the MCU and FPGA at the same time. The existing methods do not support differential upgrade and version control during the upgrade process, that is, they cannot be updated according to the specific requirements of the module.

[0043] During the above upgrade process, the present invention uses the MCU as a built-in upgrader. When the MCU is in the functional program state, it processes normal business logic. When it enters the bootloader, the MCU is equivalent to a combined JTAG and JLink upgrader, initiating upgrade operations on itself and the FPGA. For the upgrade of the FPGA, the MCU simulates JTAG upgrader signals to upgrade the FPGA, eliminating the need for an external JTAG upgrader. For the upgrade of the MCU itself, the MCU upgrades itself through the bootloader, thus eliminating the need for a Jlink emulator and the need to disassemble the product housing for the upgrade. At the same time, the present invention selectively upgrades according to module identifiers, preferentially upgrading modules that occupy less resources, skipping modules in the optimal state, reconfiguring the FPGA and recording the upgrade results after the upgrade, achieving efficient and secure collaborative upgrade of the MCU and FPGA, reducing product maintenance costs, and meeting the complex and variable IO module upgrade requirements of industrial users.

[0044] Figure 3 It is a schematic diagram of data interaction for the encrypted firmware upgrade package based on the AES_ECB algorithm disclosed in the embodiments of the present application.

[0045] The encryption and data transmission of the firmware upgrade package mainly involve three parts: the EtherCAT master station, the coupler, and the MCU of the IO module. Among them, the EtherCAT master station is used to encrypt all firmware modules using an encryption algorithm. The algorithms that can be used in the present invention include but are not limited to the AES or SM4 algorithm. The advantage of using the above encryption algorithms is that the firmware of the FPGA and MCU is not easily accessed, copied, or reverse-engineered during transmission and use, ensuring the security of the firmware. The AES encryption algorithm is an internationally common advanced symmetric encryption algorithm, and many FPGA chips have built-in AES decryption logic, with good compatibility, which not only improves the speed of encryption and decryption but also reduces the complexity of software implementation. In addition, SM4 is a symmetric algorithm that complies with national cryptographic standards. Its algorithm structure is relatively simple and can be directly integrated into the FPGA or MCU through hardware logic. Compared with AES, SM4 requires fewer hardware resources in some embedded systems and is more suitable for scenarios with higher requirements for autonomy and controllability.

[0046] Furthermore, this embodiment adopts the ECB mode based on the AES algorithm, namely the AES_ECB algorithm, to implement data encryption. Since the AES algorithm supports multiple modes such as the ECB mode, CBC mode, CFB mode, and OFB mode, among which the ECB mode is suitable for short data and scenarios with high performance requirements, the CBC mode is suitable for long data and scenarios requiring high security, and the CFB and OFB modes are suitable for stream data encryption. Considering the length of the firmware data packet and the high real-time requirement of the firmware upgrade task, this embodiment selects the ECB mode, also known as the AES_ECB algorithm, to encrypt the firmware upgrade package.

[0047] As Figure 3 shown, the working principle of the AES_ECB algorithm in this embodiment is as follows: During the encryption process: First, the EtherCAT master station divides the plaintext data into fixed-size blocks, namely data frames, such as 128 bits. If the data length is not an integer multiple of the frame size, padding is required. For example: Suppose the plaintext data is 1024 bytes and the frame size is 16 bytes, i.e., 128 bits, then the data will be divided into 64 frames.

[0048] Secondly, the master station encrypts each frame using the AES algorithm and the same key. The encryption of each frame is independent and does not depend on other frames, and the order of the encrypted ciphertext frames remains unchanged.

[0049] Finally, the master station concatenates all the encrypted frames to form a complete ciphertext and sends it to the coupler.

[0050] During the decryption process, First, the MCU in the IO module receives the ciphertext data through the coupler.

[0051] Secondly, the MCU decrypts each frame using the AES algorithm and the same key. The decryption of each frame is independent and does not depend on other frames, and the order of the decrypted plaintext frames remains unchanged. If padding was performed during encryption, the padding needs to be removed after decryption to restore the original data.

[0052] Finally, all the decrypted frames are concatenated to form a complete plaintext.

[0053] Figure 4 It is a flowchart of a collaborative upgrade method based on the EtherCAT bus disclosed in an embodiment of this application.

[0054] As Figure 4 shown, this method may include: S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers; uses an encryption algorithm to encrypt all firmware modules of the MCU and FPGA, and the firmware type identifier and firmware model are carried in the encryption header and merged into a firmware upgrade package; The functional module contains module information, namely module identifier, module status, update requirement information, and inter-module association information. Among them, the module identifier is the name and version number of the module, which is used for the MCU to identify specific modules during the upgrade process; the module status is the running or configuration status of the module; the update requirement information is an identifier indicating whether the module needs to be updated, where 0x01 indicates the need for update and 0x00 indicates no need for update; the inter-module association information refers to the priority relationship between modules, and the priority relationship refers to the upgrade priority between modules.

[0055] In S1, the firmware type identifier is an identifier used to distinguish firmware types. 0x01 indicates MCU firmware, and 0x02 indicates FPGA firmware. The EtherCAT master obtains the usage of the hardware logic resources of the MCU and FPGA through a detection tool, and embeds the module identifier and the usage of the hardware logic resources into the encryption header of the firmware upgrade package. The detection tool refers to a software tool that obtains the usage rate of the central processing unit of the MCU, the memory occupancy, and the usage of block memory, clock frequency, etc. of the FPGA. The hardware resource usage refers to the usage rate of the central processing unit of the MCU, the memory occupancy, and the usage of block memory, clock frequency, etc. of the FPGA. This enables the upgrade package to be upgraded according to the actual module status and hardware status. Especially in the case of limited resources, it can significantly improve the performance of the system and ensure the security and integrity of the upgrade process.

[0056] S2: Through the EtherCAT master upper computer, use the FoE function to transmit the firmware upgrade package to the MCU through the network cable; Here, FoE is the File over EtherCAT function, which is a data unit processed based on the data link layer of EtherCAT and has the characteristic of low latency. It can quickly complete file transmission to meet the automation scenarios with high real-time requirements. During the file transmission process, necessary handshakes and error detections will be carried out between the FoE client and the server, that is, the coupler and the EtherCAT master, to avoid data loss or damage during the upgrade process and ensure the reliability and integrity of the transmission.

[0057] S3: After receiving the firmware upgrade package, the MCU stores it in its own storage unit, and writes an update flag in the storage unit after the storage is completed. Subsequently, the MCU is reset and enters the bootloader; This update flag is a four-byte hexadecimal value indicating whether there is an update. For example, 0xA5A5AA55 indicates that there is a firmware update, and 0x5A5A55AA indicates that there is no firmware update. Here, after the MCU writes the update flag into its own storage unit, it also generates a configuration file containing the firmware package version information and module identification, which is used to quickly identify the content of the firmware package and the update requirement information in the bootloader. This enables the upgrade package to be upgraded according to the actual module status and hardware status. Especially in the case of limited resources, it can significantly improve the system performance while ensuring the security and integrity of the upgrade process.

[0058] S4: The MCU decrypts the firmware upgrade package in the bootloader, determines whether the firmware belongs to the FPGA or the MCU based on the firmware type identification in its encryption header, and reads the module identification in the firmware upgrade package to determine the MCU and FPGA function modules to be updated. Here, the MCU respectively identifies the starting addresses of the FPGA and MCU firmwares according to the firmware type identification in the encryption header, reads the corresponding firmware data from the storage unit, and decrypts the read data frame by frame to decrypt the original firmware data and related information including the module identification and the usage of hardware logic resources. The frame-by-frame decryption means that the firmware package is split into multiple small units, i.e., data frames, for transmission, and each frame is decrypted separately. The advantage of this is that in the process of firmware upgrade, if a failure occurs, only the current frame needs to be re-upgraded; while in the ordinary whole-package decryption method, it occupies a large amount of storage space, and in case of failure at any time, the upgrade must start over.

[0059] Furthermore, in S4, the MCU verifies the decrypted firmware data. If there are firmware type mismatches, firmware damage, and version incompatibilities, the upgrade is interrupted, and the MCU sends an error message to the host computer, including the upgrade interruption signal and the error type. This design can effectively prevent incorrect firmware from being written into the device, avoid device failures and data damage caused by incorrect firmware, and at the same time facilitate quick problem location, improve the upgrade success rate and system reliability.

[0060] S5: If it is FPGA firmware, the MCU obtains the FPGA firmware model in the firmware encryption header, determines whether the upgrade package is compatible with this model. If it is compatible, proceed to the next step; if not, the FPGA sends a firmware adjustment instruction to the MCU. The MCU retrieves the pre-stored JTAG timing parameter configuration strategy compatible with this model from the storage unit according to the FPGA firmware model. The MCU modifies the configuration strategy in the original firmware package and repackages the firmware package to be compatible with this model. Then, according to the module identifier in the firmware package, the MCU performs a storage unit erasing operation with simulated JTAG timing on each FPGA functional module one by one to complete the firmware upgrade of the FPGA. If it is MCU firmware, the MCU writes the upgrade package data and configuration data into its own storage unit according to the module identifier in the firmware package to complete the firmware upgrade of each module of the MCU one by one; Specifically, in S5, when the MCU adjusts the firmware package, the specific steps are as follows: S51: Before the firmware upgrade, perform pre-adaptability analysis on FPGA chips from different manufacturers, and allocate an adapted JTAG timing parameter configuration strategy for each model; S52: Push the configuration strategy to the MCU storage unit in the form of a data packet for storage; S53: After the MCU receives the firmware adjustment instruction, the MCU retrieves the corresponding configuration strategy from the storage unit according to the model identifier of the FPGA; S54: The MCU writes the corresponding configuration strategy into the firmware package and repackages the firmware upgrade package.

[0061] The advantage of this is that through the pre-adaptability and adjustment mechanism, automatic fine-tuning of the upgrade package can be achieved for each FPGA model, reducing the problems of upgrade failure or repeated configuration caused by model mismatch, improving the upgrade efficiency, reducing the complexity of maintenance and upgrade, and lowering the product maintenance cost.

[0062] S6: After the firmware upgrades of both the FPGA and the MCU are completed, the MCU erases the update flag and resets to enter the new MCU firmware to complete the entire upgrade process.

[0063] Specifically, after the MCU completes the FPGA firmware upgrade, it performs a reconfiguration operation on the FPGA. This step is crucial to ensure that the FPGA can be immediately put into use after the upgrade, ensuring that the FPGA can work properly after upgrading to the new firmware. After the firmware upgrades of both the FPGA and the MCU are completed, the MCU records the upgrade results in its storage unit and sends the upgrade results back to the EtherCAT master station; the EtherCAT master station generates a firmware upgrade log according to the upgrade results. This step ensures the traceability of the firmware upgrade process and the efficiency of problem location, and at the same time provides reliable data support for subsequent maintenance and optimization.

[0064] Specifically, Figure 5 This is a flowchart for upgrading the FPGA firmware disclosed in the embodiments of this application.

[0065] As Figure 5 The FPGA firmware upgrade generally involves the following sub-steps: a1. Initialize upgrade resources: The MCU initializes the hardware resources required for communication with the FPGA, including GPIO pins, JTAG interfaces, and clock signals; configures the pin functions of the JTAG interface to ensure the normal operation of signals such as TMS, TCK, TDI, and TDO; initializes the access interface of the storage unit to ensure that the storage unit of the FPGA can be erased and written.

[0066] a2. Identify the starting address of the firmware: The MCU parses the encrypted header of the encrypted firmware upgrade package, extracts the starting address and length information of the FPGA and MCU firmware; determines the position of the FPGA firmware in the firmware package to prepare for subsequent upgrade operations.

[0067] a3. Read and decrypt the firmware data: The MCU reads the FPGA firmware data from the storage unit, e.g., reads a data block of 128 bytes each time; decrypts the read data block to restore the original firmware data; during the decryption process, the MCU verifies the integrity and correctness of the data to ensure that the decrypted data is correct.

[0068] a4. Identify the firmware model and determine if the upgrade package is compatible: The MCU obtains the FPGA firmware model in the firmware package and determines if the upgrade package is suitable for this model. If it is suitable, proceed to the next step; if not, the FPGA sends a firmware adjustment instruction to the MCU, and the MCU adjusts the firmware package to fit this model. Since different manufacturers' FPGAs use different ISP programs for firmware upgrade, it is difficult to adapt and upgrade multiple models of FPGAs using traditional methods. This method can solve this problem: Since the firmware upgrade package is read and decrypted within the MCU, and the FPGA only passively receives the firmware upgrade, we split the FPGA's firmware upgrade package into different software function modules. Through engineers' pre-adaptability learning of FPGA chips from manufacturers such as Anlu and Ziguang Tongchuang, the upgrade package adjustment strategy is set, including the JTAG timing parameter configuration matching a specific model of FPGA, and the strategy is pushed to the storage unit of the MCU in the form of a data packet for storage. When the FPGA enters the firmware upgrade process, the MCU can retrieve the corresponding strategy from the storage unit based on the model identification of the FPGA chip, match and apply the JTAG timing suitable for this model to upgrade the FPGA's firmware to adapt to different manufacturers and different models of FPGAs. This method supports adapting to different manufacturers and different models of FPGAs, including Anlu SALDRAGON 1, Ziguang Tongchuang Titan-2, etc.

[0069] Through the pre-adaptability and adjustment mechanism, this method can automatically fine-tune the upgrade package for each FPGA model, reducing problems such as upgrade failures or repeated configurations caused by model mismatches, improving the upgrade efficiency, reducing the complexity of maintenance and upgrade, and lowering the product maintenance cost. It should be noted that the MCU selected needs to have sufficient storage capacity and processing power to support the storage, decryption, and adjustment operations of the firmware package. The MCU models used in this embodiment include the Artel AT32F423 series and the GigaDevice GD32 series.

[0070] a5. Simulate JTAG timing for upgrade: The MCU simulates JTAG timing and communicates with the FPGA through the TMS, TCK, TDI, and TDO signals; sends an erase instruction to erase the corresponding functional module area in the FPGA's storage unit; sends the decrypted firmware data in frames to the FPGA's storage unit to complete the firmware upgrade; during the upgrade process, the MCU monitors the status feedback of the FPGA to ensure the smooth progress of the upgrade operation.

[0071] a6. Module Status Check and Skip: The MCU checks the module identifiers of each FPGA functional module; if the version number of a certain module is already the latest version, or the module status indicates that no update is required, the upgrade operation for that module is skipped. In this way, unnecessary operations are reduced and the upgrade efficiency is improved. When the device is started next time, the MCU reads the identification information in the storage unit and only updates the modules that were skipped previously, ensuring that all modules can ultimately be updated to the latest version and ensuring the stability of system operation.

[0072] a7. Reconfigure the FPGA: After completing the FPGA firmware upgrade, the MCU sends a reconfiguration instruction to the FPGA to enable the FPGA to load the new firmware and enter the working state; this operation ensures that the FPGA can be put into use immediately, improving the reliability and stability of the system.

[0073] Furthermore, the firmware version number to be upgraded for the FPGA this time is V1.3.1, which is divided into 3 modules with version numbers V1.3.0, V1.3.1; V1.2.8 respectively. The MCU processes according to the following steps: The MCU first checks the current version number of each module and compares it with the firmware version number V1.3.1 to be upgraded. The comparison results are as follows: Module 1, version number V1.3.0 < V1.3.1, needs to be updated.

[0074] Module 2, version number V1.3.1 = V1.3.1, is already the latest version and does not need to be updated. Skip the upgrade operation for this module.

[0075] Module 3, version number V1.2.8 < V1.3.1, needs to be updated.

[0076] First, for the modules that need to be updated, including Module 1 and Module 3, the MCU will perform the following operations: simulate the JTAG timing, send an erase instruction to erase the old firmware of these modules in the FPGA storage unit; send the decrypted firmware data in frames to the FPGA storage unit to complete the firmware upgrade.

[0077] Second, the MCU skips the modules that are already the latest version, including Module 2, and does not perform the upgrade operation on it, reducing unnecessary operations and improving the upgrade efficiency.

[0078] Furthermore, Figure 6 This is a schematic diagram of the module resource evaluation process in the FPGA upgrade disclosed in the embodiment of this application.

[0079] When upgrading the FPGA firmware, the MCU will select to upgrade the modules that occupy less resources first according to the usage of logical resources, reducing the pressure on logical resources. Especially in the case of limited resources, this optimization can significantly improve the performance of the system.

[0080] In this embodiment, the FPGA to be upgraded is divided into 3 modules in total, and the proportion of logic resources occupied by each module is as follows: Module A: Sensor data processing, occupying 30% of the resources Module B: Data verification, occupying 20% of the resources Module C: Communication protocol processing, occupying 40% of the resources The new firmware version is V1.3.0, and all modules need to be updated.

[0081] As Figure 6 The process of module resource evaluation for FPGA upgrade is as follows: b1. The MCU first evaluates the usage of logic resources of each module in the current FPGA.

[0082] b2. According to the resource occupation situation, the MCU decides to upgrade Module B with less resource occupation first, because its resource occupation rate is 20%.

[0083] b3. The MCU simulates the JTAG timing and first upgrades Module B.

[0084] b4. Next, the MCU upgrades Module A because this module ranks second in resource occupation, accounting for 30%; the MCU simulates the JTAG timing and upgrades Module A.

[0085] b5. Next, the MCU upgrades Module C because this module ranks third in resource occupation, accounting for 40%; the MCU simulates the JTAG timing and upgrades Module C.

[0086] b6. After the upgrade is completed, the MCU sends a reconfiguration instruction to the FPGA to make the FPGA load the new firmware and enter the working state.

[0087] Specifically, Figure 7 This is the upgrade flowchart of the MCU firmware disclosed in the embodiment of the present application.

[0088] As Figure 7 The upgrade of the MCU firmware usually involves the following steps: c1. Initialize the upgrade resources: The MCU initializes the hardware resources required for communication with its own storage unit, including the storage unit controller and related pins; configures the access parameters of the storage unit to ensure that it can erase and write to its own storage unit.

[0089] c2. Identify the starting address of the firmware: The MCU parses the encrypted header of the encrypted firmware upgrade package, extracts the starting address and length information of the MCU firmware; determines the position of the MCU firmware in the firmware package to prepare for subsequent upgrade operations.

[0090] c3. Read and decrypt firmware data: The MCU reads the MCU firmware data from the storage unit. For example, it reads a data block of 128 bytes each time. It performs a decryption operation on the read data block to restore the original firmware data. During the decryption process, the MCU verifies the integrity and correctness of the data to ensure that the decrypted data is correct.

[0091] c4. Write firmware data: The MCU writes the decrypted firmware data into its own storage unit. During the writing process, the MCU dynamically adjusts the upgrade parameters and preferentially upgrades the modules that occupy less resources. In this way, the pressure on hardware resources is reduced. Especially in the case of limited resources, the system performance can be significantly improved.

[0092] c5. Module status check and skipping: The MCU checks the module identifiers of each MCU function module; if the version number of a certain module is already the latest version, or the module status indicates that no update is required, the upgrade operation of this module is skipped; The method for the MCU to evaluate its own hardware resources can refer to Figure 6 the module resource evaluation process for FPGA upgrade described above. In this way, unnecessary operations are reduced and the upgrade efficiency is improved; When the device is started next time, the MCU will read the identification information in the storage unit and only update the modules that were skipped before to ensure that all modules can ultimately be updated to the latest version and ensure the stability of system operation.

[0093] c6. Record key information: The MCU records the key information generated during the upgrade process into the storage unit, including the module version number, upgrade time, and upgrade result, thus providing an important basis for subsequent version management and fault troubleshooting.

[0094] c7. The MCU upgrade is completed.

[0095] This embodiment includes a collaborative upgrade master device based on the EtherCAT bus, including: A processing unit, which is used to implement each step of the collaborative upgrade method based on the EtherCAT bus of the present application; After the firmware upgrade is successful, the processing unit is responsible for confirming the upgrade status, saving the upgrade log, and notifying the maintenance personnel; When abnormal situations such as firmware damage, firmware version mismatch, and communication interruption occur during the firmware upgrade process, the processing unit can take measures such as upgrade interruption and attempt to reconnect.

[0096] A readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements each step of the collaborative upgrade method based on the EtherCAT bus of the present application.

[0097] The processing unit also includes a communication module. When the firmware upgrade is successful, or there is a firmware version mismatch, or a communication interruption, the processing unit immediately sends alarm information to the maintenance personnel of the FPGA and MCU manufacturers through the communication module; and sends the firmware upgrade log to the maintenance personnel of the FPGA and MCU manufacturers by means of e-mail or text message for later problem location and upgrade use.

[0098] Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. Those with ordinary knowledge in the technical field to which the present invention pertains can make various modifications and refinements without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to what is defined by the claims.

Claims

1. A collaborative upgrade method based on the EtherCAT bus, used for remotely upgrading the firmware of the MCU and FPGA in the IO module connected through the EtherCAT bus, characterized in that Run according to the following steps: S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers; uses an encryption algorithm to encrypt all firmware modules of the MCU and FPGA. The encryption header contains the firmware type identifier and firmware model number, and combines them into a firmware upgrade package; S2: Through the EtherCAT master host computer, use the FoE function to transmit the firmware upgrade package to the MCU via the network cable; S3: After receiving the firmware upgrade package, the MCU stores it in its own storage unit, and writes an update flag in the storage unit after the storage is completed. Then the MCU resets and enters the bootloader; S4: The MCU decrypts the firmware upgrade package in the bootloader, determines whether the firmware belongs to the FPGA or MCU based on the firmware type identifier in its encryption header, and reads the module identifier to determine the MCU and FPGA functional modules that need to be updated; S5: If it is FPGA firmware, the MCU obtains the FPGA firmware model number in the firmware encryption header, determines whether the upgrade package is compatible with the model. If it is compatible, proceed to the next step; if not, the FPGA sends a firmware adjustment instruction to the MCU. The MCU retrieves the compatible JTAG timing parameter configuration strategy from the storage unit according to the FPGA firmware model number, modifies the original firmware package configuration strategy and repackages it to be compatible with the model; then the MCU performs a storage unit erase and write operation of the simulated JTAG timing for each FPGA functional module according to the module identifier in the firmware package to complete the firmware upgrade of the FPGA; if it is MCU firmware, the MCU writes the upgrade package data and configuration data into its own storage unit according to the module identifier in the firmware package to complete the individual firmware upgrade of each MCU module; S6: After the firmware of the FPGA and MCU are both upgraded, the MCU erases the update flag, resets and enters the new MCU firmware to complete the entire upgrade process.

2. The collaborative upgrade method based on EtherCAT bus according to claim 1, wherein In S1, the functional module contains module information, namely module identifier, module status, update requirement information and inter-module association information; the module identifier is the name and version number of the module, which is used for the MCU to identify specific modules during the upgrade process; the firmware type identifier is an identifier that distinguishes the firmware type as FPGA or MCU; the EtherCAT master obtains the hardware logic resource usage of the MCU and FPGA through a detection tool, and embeds the module identifier and hardware logic resource usage into the encryption header of the firmware upgrade package.

3. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that, In S3, after writing the update flag in its own storage unit, the MCU also generates a configuration file containing the firmware package version information and module identifier, which is used to quickly identify the content and update requirements of the firmware package in the bootloader.

4. A collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that, In S4, the MCU respectively identifies the starting addresses of the FPGA and MCU firmware according to the firmware type identifier in the encryption header, reads the corresponding firmware data from the storage unit, decrypts the read data frame by frame, and decrypts the original firmware data and related information, including module identifier and hardware logic resource usage.

5. The collaborative upgrade method based on EtherCAT bus according to claim 1, wherein In S5, when the MCU adjusts the firmware package, the specific steps are as follows: S51: Before firmware upgrade, perform pre - adaptability analysis on FPGA chips from different manufacturers, and allocate an adapted JTAG timing parameter configuration strategy for each model; S52: Push the configuration strategy to the MCU storage unit in the form of a data packet for storage; S53: After the MCU receives the firmware adjustment instruction, the MCU retrieves the corresponding configuration strategy from the storage unit according to the model identification of the FPGA; S54: The MCU writes the corresponding configuration strategy into the firmware package and repackages the firmware upgrade package.

6. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that, In S5, when upgrading the MCU and FPGA firmware, the MCU checks the module identification of each module; for modules that do not need to be upgraded, the MCU skips the update of this module this time and stores the identification information of this module in its own storage unit; the MCU will select to upgrade the module that occupies less resources first according to the usage of logical resources, reducing the pressure on logical resources.

7. A collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that, In S6, when the MCU completes the FPGA firmware upgrade, perform a re - configuration operation on the FPGA; after completing the firmware upgrade of the FPGA and MCU, the MCU records the upgrade result in the storage unit and sends the upgrade result back to the EtherCAT master station; the EtherCAT master station generates a firmware upgrade log according to the upgrade result.

8. A collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that, During the operation of the functional program, the MCU is used to handle the backplane bus connection with the coupler, receive the remote upgrade firmware data of the FPGA and MCU, and transmit the data required for the FPGA function to the FPGA through the SPI bus, while detecting whether the firmware needs to be upgraded; during the operation of the functional program, the FPGA receives data from the MCU through the SPI bus, responds to the instructions of the MCU, and executes logical operation and data processing tasks.

9. A collaborative upgrade master device based on the EtherCAT bus, characterized in that, Comprising: A processing unit, which is used to implement each step of a collaborative upgrade method based on the EtherCAT bus as described in any one of claims 1 to 8; A readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements each step of a collaborative upgrade method based on the EtherCAT bus as described in any one of claims 1 to 8.

10. The collaborative upgrade master device based on EtherCAT bus according to claim 9, characterized in that, The processing unit further includes a communication module, and the communication module sends the firmware upgrade log to the manufacturer maintenance personnel of the FPGA and MCU by email or text message for later problem location and upgrade use.

Images