A collaborative upgrade method and master station device based on EtherCAT bus

Abstract

The present invention relates to the technical field of firmware upgrade. Aiming at the problems of high cost, low efficiency and insufficient adaptability in the prior art, a collaborative upgrade method and master station device based on the EtherCAT bus are proposed. The EtherCAT master station encrypts the MCU and FPGA firmware and divides them into functional modules. The encrypted firmware package is transmitted to the MCU using the FoE function. After receiving and storing the firmware, the MCU resets and enters the boot program, decrypts the firmware, and upgrades it according to the modules. Modules that occupy less resources are upgraded first, and modules in the optimal state are skipped. After the upgrade is completed, the FPGA is reconfigured and the upgrade results are recorded. This achieves efficient and secure collaborative upgrade of the MCU and FPGA, and reduces maintenance costs. The modular design of the firmware package, the identification of the FPGA model, and the adjustment of the upgrade package enable adaptation to different FPGA models, effectively solving the problem of insufficient adaptability of FPGA firmware upgrades to different models in the prior art.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware upgrade, and in particular to a collaborative upgrade method and master station equipment based on an EtherCAT bus. Background Art

[0002] I / O modules, or input / output modules, are key devices in industrial automation systems used to collect and control field signals. They connect to the system master via communication buses such as EtherCAT and RS485. I / O modules typically consist of a microcontroller (MCU), a field-programmable gate array (FPGA), and input / output interfaces. The MCU is responsible for overall control logic, communication management, and status monitoring, while the FPGA specializes in complex signal processing, high-speed data processing, and hardware acceleration. With the continuous evolution of product technologies and the increasing diversity of user needs, MCU and FPGA firmware upgrades have become a critical and frequent requirement.

[0003] For the upgrade of IO modules, the existing technologies are divided into two types: relying on external upgraders and remote upgrades. Among them, the external upgrader method requires additional hardware tools, such as JTAG upgraders, JLink emulators, etc. During operation, a dedicated person is required 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 some remote upgrade methods, such as the invention patent No. CN202411480679.9 "IO module firmware upgrade method, device, equipment and readable storage medium" discloses an IO module firmware upgrade method, which generates a firmware package and FoE password instructions by receiving the firmware upgrade file sent by the master station, parsing the encryption header and instructions to determine the target IO module, and then sending the firmware package to the corresponding module to complete the upgrade. It is mainly aimed at the IO modules of the EtherCAT slave station, and does not distinguish between the collaborative upgrade of MCU and FPGA. At the same time, it focuses on transferring files through the FOE protocol, parsing the firmware package and determining the target module. The upgrade process is relatively general and suitable for upgrade scenarios of various IO modules, but No refined management is performed on resource usage and module status during the upgrade process; the invention patent CN118394393B, "A method for updating IO module firmware based on EtherCat coupler", discloses an IO module firmware update method, in which the EtherCat coupler receives the master station file, repackages it, and creates a firmware upgrade request file, which is sent to the plug-in IO through the backplane bus. The MCU module in the IO divides the space to receive the firmware package and decompresses the upgrade. This method mainly involves the upgrade of the MCU module, focusing on dividing a temporary area in the storage area of ​​the plug-in IO to store the firmware upgrade package, and verifying the firmware package. There is a clear fallback mechanism for upgrade failure, which is more suitable for the specific hardware architecture upgrade of the plug-in IO.

[0004] Traditional methods for remotely upgrading MCUs or FPGAs generally require an ISP program, or online system programming program, adapted for the MCU or FPGA. However, due to differences in chip architecture, interfaces, and communication protocols among different manufacturers, it is difficult to use a unified ISP program for firmware upgrades. Currently, although some universal ISP programs have been developed, achieving unified adaptation for multiple FPGA models remains a significant challenge due to significant differences in architecture, interfaces, and communication protocols among FPGA chips from different manufacturers. For example, the invention patent CN117149222A, "FPGA Image Loading Method, System, Terminal, and Storage Medium," discloses an FPGA image loading method, system, terminal, and storage medium. By adding a classification number representing the adapted FPGA model to the FLASH address table, it enables different FPGA classifications to select the image to be loaded and in what order, resolving the issue that traditional FPGA loading can only target a single FPGA type and that images are difficult to update.

[0005] In practice, external upgraders are often complex and costly to use, unable to upgrade multiple modules simultaneously and resulting in low efficiency. Furthermore, the system requires downtime during operation, impacting normal system operation. While existing remote upgrade methods offer ease of use and flexibility, they lack detailed management of resource usage and module status during FPGA and MCU upgrades, resulting in low upgrade efficiency and high error rates. Furthermore, engineers typically need to perform specific ISP operations based on the specific chip model and manufacturer's tools to ensure programming compatibility and stability. Switching between MCU or FPGA chips from different manufacturers requires reconfiguring the ISP tools and programming environment, limiting functionality and reducing efficiency. Summary of the Invention

[0006] In response to the problems of high cost, low efficiency and insufficient adaptability of existing technologies, the purpose of the present invention is to provide a collaborative upgrade method and master station device based on the EtherCAT bus, optimize the MCU and FPGA firmware upgrade method of the IO module, get rid of the dependence on external upgraders, improve the efficiency of IO firmware upgrades, reduce product maintenance costs, and improve adaptability to FPGA models from different manufacturers.

[0007] To achieve the above objectives, the present invention proposes a collaborative upgrade method based on EtherCAT bus, which is used to remotely upgrade the firmware of the MCU and FPGA in the IO module connected via the EtherCAT bus, and is operated according to the following steps:

[0008] S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers. It uses an encryption algorithm to encrypt all MCU and FPGA firmware modules. The encrypted header contains the firmware type identifier and firmware model, and then merges them into a firmware upgrade package.

[0009] S2: Use the FoE function through the EtherCAT master station to transmit the firmware upgrade package to the MCU via the network cable;

[0010] S3: After receiving the firmware upgrade package, the MCU stores it in its own storage unit and writes the update flag in the storage unit after the storage is completed. Then the MCU resets and enters the boot program.

[0011] S4: The MCU decrypts the firmware upgrade package in the bootloader, determines whether the firmware belongs to an FPGA or MCU based on the firmware type identifier in the encrypted header, and reads the module identifier to determine the MCU and FPGA functional modules that need to be updated.

[0012] S5: If it is FPGA firmware, the MCU obtains the FPGA firmware model in the firmware encryption header and determines whether the upgrade package is compatible with the model. If so, it proceeds 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 based on the FPGA firmware model, modifies the original firmware package configuration strategy and repackages it to adapt to the model. Then, the MCU simulates the JTAG timing storage unit erase and write operation on the FPGA functional modules one by one according to the module identifier in the firmware package to complete the FPGA firmware upgrade. 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 MCU module one by one.

[0013] S6: After the firmware of the FPGA and MCU are upgraded, the MCU erases the update flag and resets to the new MCU firmware, completing the entire upgrade process.

[0014] 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 transmission during the update process very flexible and reliable.

[0015] Specifically, in S1, the functional module includes module information, namely, module identification, module status, update requirement information, and inter-module association information. The module identification is the module name and version number, which is used by the MCU to identify the specific module during the upgrade process. The module status is the module's operating or configuration status. The update requirement information indicates whether the module needs to be updated, where 0x01 indicates that an update is required and 0x00 indicates that an update is not required. 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 module information is used to assist the modular upgrade process, preparing for the subsequent module upgrades and skipping, thereby improving the efficiency and accuracy of the upgrade.

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

[0017] In S1, the EtherCAT master station obtains the hardware logic resource usage of the MCU and FPGA through a detection tool, and embeds the module identification and hardware logic resource usage into the encrypted header of the firmware upgrade package. The detection tool refers to a software tool that obtains the usage rate and memory occupancy of the MCU's central processing unit, as well as the usage of the FPGA's block memory, clock frequency, etc. The hardware resource usage refers to the usage rate and memory occupancy of the MCU's central processing unit, as well as the usage of the FPGA's block memory, clock frequency, etc. This allows the upgrade package to be upgraded according to the actual module status and hardware status, especially when resources are limited, which can significantly improve system performance while ensuring the security and integrity of the upgrade process.

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

[0019] Specifically, in S4, the MCU identifies the starting addresses of the FPGA and MCU firmware respectively based on 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 identification and hardware logic resource usage. Frame-by-frame decryption refers to a method of dividing the firmware package into multiple small units, namely data frames, for transmission, and decrypting each frame separately. The advantage of this is that if a failure occurs during the firmware upgrade process, only the current frame needs to be upgraded again; the ordinary whole-packet decryption method takes up a large amount of storage space, and if it fails at any time, the upgrade must be restarted.

[0020] Specifically, in S4, the MCU verifies the decrypted firmware data. If there is a firmware type mismatch, firmware damage, or version incompatibility, the upgrade is interrupted, and the MCU sends an error message to the host computer, including an upgrade interrupt signal and the error type. If there is no firmware type mismatch, firmware damage, or version incompatibility, the process proceeds to the next step. This design can effectively prevent erroneous firmware from being written to the device, avoid device failures, facilitate rapid problem location, and improve the upgrade success rate and system reliability.

[0021] Specifically, in S5, when the MCU adjusts the firmware package, the specific steps are as follows:

[0022] S51: Before the firmware upgrade, perform pre-compatibility analysis on FPGA chips from different manufacturers and assign an adaptive JTAG timing parameter configuration strategy for each model;

[0023] S52: Push the configuration policy in the form of a data packet to the MCU storage unit for storage;

[0024] S53: After the MCU receives the firmware adjustment instruction, the MCU retrieves the corresponding configuration policy from the storage unit according to the FPGA model identifier;

[0025] S54: The MCU writes the corresponding configuration policy into the firmware package and repackages the firmware upgrade package.

[0026] The JTAG timing parameter configuration strategy is a set of parameters designed to accommodate different FPGA chip models. It defines the specific timing requirements for the JTAG interface during data transmission and instruction control, including clock frequency, data sampling time, and instruction cycle. This ensures that the FPGA can correctly receive and execute JTAG instructions and complete firmware upgrades. This approach offers the advantage of enabling automatic fine-tuning of upgrade packages for each FPGA model through pre-adaptive and adjustment mechanisms. This reduces upgrade failures or repeated configurations caused by model mismatches, improves upgrade efficiency, reduces maintenance and upgrade complexity, and lowers product maintenance costs.

[0027] Specifically, in S5, when upgrading the MCU and FPGA firmware, the MCU checks the module identifier of each module. For modules that do not require an upgrade, the MCU skips updating them and stores the module identifier in its own storage unit. This reduces unnecessary updates and improves upgrade efficiency. The next time the device boots up, the MCU reads the identifier information in the storage unit and updates the modules that require an upgrade and were previously skipped. This ensures that all modules are ultimately updated to the latest version, safeguarding system stability.

[0028] Specifically, in S5, when upgrading the MCU and FPGA firmware, the MCU prioritizes upgrading modules with less resource usage based on logic resource usage and module identification, reducing pressure on logic resources. This optimization can significantly improve system performance, especially in resource-constrained environments.

[0029] Specifically, in S6, after the MCU completes the FPGA firmware upgrade, it reconfigures the FPGA. This step ensures that the FPGA is immediately operational after the upgrade. After completing the firmware upgrade for both the FPGA and MCU, the MCU records the upgrade results in its storage unit and sends them back to the EtherCAT master. The EtherCAT master generates a firmware upgrade log based on the upgrade results. This step ensures traceability of the firmware upgrade process and efficient problem location, while also providing reliable data support for subsequent maintenance and optimization.

[0030] Specifically, during the execution of the functional program, the MCU is responsible for handling the backplane bus connection with the coupler, receiving remote firmware upgrade data from the FPGA and MCU, transmitting data required for FPGA functions to the FPGA via the SPI bus, and detecting whether the firmware needs to be upgraded, thereby improving the system's automation and operational efficiency. During the execution of the functional program, the FPGA receives data from the MCU via the SPI bus, responds to the MCU's instructions, and performs tasks such as logical operations and data processing, ensuring efficient system operation.

[0031] The present invention also proposes a collaborative upgrade master station device based on the EtherCAT bus, comprising:

[0032] A processing unit, configured to implement each step of the collaborative upgrade method based on the EtherCAT bus as described above;

[0033] A readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements the steps of any one of the above-mentioned collaborative upgrade methods based on the EtherCAT bus.

[0034] The processing unit also includes a communication module, which sends the firmware upgrade log to the manufacturer's maintenance personnel of the FPGA and MCU via email or text message for later problem location and upgrade.

[0035] As can be seen from the above technical solution, this technical method provides a collaborative upgrade method and master station device based on the EtherCAT bus. The EtherCAT master station encrypts the MCU and FPGA firmware separately and divides them into functional modules. The encrypted firmware package is transmitted to the MCU using the FoE function. After receiving and storing the encrypted firmware package, the MCU resets and enters the bootloader, decrypts the firmware and upgrades it according to the module, prioritizing modules with low resource consumption and skipping modules in optimal state. After the upgrade is complete, the FPGA is reconfigured and the upgrade results are recorded, thus achieving efficient and secure collaborative upgrade of the MCU and FPGA. Among them, the optimal state module refers to the module that is already in the latest version and does not need to be upgraded.

[0036] In this technical approach, the collaborative work of the MCU and FPGA ensures the efficiency, stability, and reliability of the upgrade process. The MCU, as the main controller, manages the entire upgrade process, including receiving and storing firmware packages, decrypting and identifying firmware data, executing upgrade operations, and managing status. The FPGA receives upgrade data during the upgrade process, responds to the MCU's instructions, and reconfigures itself after the upgrade is complete to ensure the new firmware works properly. This collaborative approach not only improves upgrade efficiency but also enhances the system's stability and adaptability, meeting the demands of complex industrial automation tasks.

[0037] Through the technical solution described in the present invention, the technical effects brought about by the present invention are:

[0038] 1. The entire upgrade process does not require an additional external upgrader. Instead, the MCU is used as a built-in upgrader to control the FPGA and MCU upgrade mode, reducing dependence on traditional hardware devices. At the same time, through the modular design of the firmware package, FPGA model identification and upgrade package adjustment, adaptation to different FPGA models is achieved, effectively solving the problem of insufficient adaptability of FPGA firmware upgrades to different models in existing technologies and reducing product maintenance costs.

[0039] 2. Prioritize upgrading modules that occupy less resources based on hardware resource usage, reducing pressure on hardware resources and improving upgrade efficiency. This also avoids IO module downtime caused by using traditional external upgraders and improves system stability.

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

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0042] Figure 1 A schematic diagram of hardware connections for an application environment disclosed in an embodiment of the present application;

[0043] Figure 2 The working principle diagram of the interaction between the FPGA and MCU inside the IO module disclosed in the embodiment of this application;

[0044] Figure 3 This is a schematic diagram of data interaction based on the AES_ECB algorithm for encrypting the firmware upgrade package disclosed in the embodiment of the present application;

[0045] Figure 4 This is a flowchart of a collaborative upgrade method based on the EtherCAT bus disclosed in an embodiment of the present application;

[0046] Figure 5 This is a flowchart of the firmware upgrade for FPGA disclosed in the embodiment of this application;

[0047] Figure 6 This is a schematic diagram of the module resource evaluation process in the FPGA upgrade disclosed in the embodiment of the present application;

[0048] Figure 7 This is a firmware upgrade flowchart for MCU disclosed in an embodiment of this application. DETAILED DESCRIPTION

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

[0050] Before introducing this application, the related technologies of this application are first introduced.

[0051] EtherCAT is an Ethernet-based fieldbus communication protocol widely used in industrial automation for high-speed, real-time device communication. In the EtherCAT protocol, devices are categorized as masters and slaves. The master, typically a PC or other device supporting the EtherCAT protocol, serves as the network's control center, managing and coordinating communications across the entire EtherCAT network. Slaves are devices connected to the EtherCAT network, typically including couplers and I / O modules. They execute commands sent by the master and transmit data back to the master.

[0052] The In-System Programmer (ISP) program is a software tool used to upgrade and configure the firmware of electronic devices such as MCUs and FPGAs. ISP allows users to program the device directly after it has been installed on a circuit board through specific interfaces such as JTAG and SPI, without removing the chip from the circuit board, making it easier for users to upgrade their devices.

[0053] The following is an introduction to the application scenarios of this application.

[0054] Figure 1 A hardware connection diagram of an application environment disclosed in an embodiment of the present application.

[0055] This application can be applied to Figure 1 The environment shown here primarily communicates based on the EtherCAT protocol, an Ethernet-based fieldbus communication protocol widely used in industrial automation to achieve high-speed, real-time device communication. This environment primarily consists of an EtherCAT master, a coupler, and an I / O module containing an MCU and an FPGA. The EtherCAT master is the system's control core, connected to the coupler via the EtherCAT bus. It transmits encrypted firmware upgrade packages to the coupler, which then sends them to the MCU in the I / O module. The EtherCAT master also monitors the upgrade process, receiving feedback from the coupler to ensure a smooth upgrade. The coupler and I / O module are EtherCAT slaves. The coupler acts as an intermediary device, connecting to the I / O module via the backplane bus. It connects the EtherCAT master and multiple I / O modules, acting as a data transfer and signal distribution hub. The I / O module is the execution unit during the upgrade process and consists of two core components: an FPGA and an MCU. The FPGA is a programmable logic device that receives instructions from the MCU to complete its own upgrade. The MCU is a microcontroller that coordinates the operation of the I / O module and the firmware upgrade process. The IO module is connected to the coupler through the backplane bus, receives firmware data from the coupler, and feeds back the upgrade status to the coupler.

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

[0057] like Figure 2 As shown, the MCU in the IO module can work in two states: boot program and function program.

[0058] 1. The IO module is powered on and the MCU enters the boot program. The main tasks of the MCU are: (1) Determine whether there is a firmware update based on the update flag stored at a fixed address in the MCU's storage unit. This update flag is a four-byte hexadecimal value that indicates whether there is an update. For example: 0xA5A5AA55 indicates a firmware update, and 0x5A5A55AA indicates 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 establishment of the update flag occur during the operation of the MCU's functional program. (2) If there is an update, the FPGA and MCU firmware upgrade process will begin. If there is no update, the normal functional program will be entered.

[0059] 2. After the boot process is complete, the MCU performs the functional program. The main tasks of the MCU are: (1) processing the backplane bus connection between the processor and the coupler, responsible for receiving data, including remote firmware upgrade data for the FGPA and MCU; (2) transmitting data required for FPGA functions to the FPGA via the SPI bus; the SPI bus is a serial communication protocol that uses simple signal lines to achieve high-speed, full-duplex synchronous communication between the FPGA and MCU. (3) judging whether the firmware needs to be upgraded based on whether the status of the received data containing the FPGA and MCU firmware is received.

[0060] 3. During the update process, the interaction between FPGA and MCU includes: (1) MCU starts to initialize the resources required to upgrade FPGA; (2) identifies the starting address of FPGA and MCU firmware respectively according to the encryption header of the encrypted file; (3) starts to read the interval data from the start and end addresses identified in the second step in the storage unit, and starts the decryption algorithm to decrypt the original data before encryption; (4) If it is FGPA firmware, MCU starts to simulate JTAG timing and starts to upgrade FPGA. Repeat (3) and (4) until all firmware data is written into FPGA, and then reset the FPGA. (5) Continue to read MCU firmware from the storage unit for decryption. (6) Directly operate the MCU storage unit write operation to write the original firmware content to the area where the program is running. (7) Erase the update flag so that after entering the boot program, the upgrade process will not be looped.

[0061] Existing upgrade methods are divided into two categories: relying on an external upgrader and remote upgrade. The external upgrader method requires additional hardware support and manual intervention, increasing operational and time costs. Existing remote upgrade technology can only upgrade a single type of device, namely, the MCU or the FPGA. It lacks a mechanism for MCU and FPGA to work together, making it difficult to meet the requirements for coordinated upgrades of both MCUs and FPGAs. Existing methods do not support differentiated upgrades and version control during the upgrade process, meaning they cannot be updated according to the specific needs of the module.

[0062] In the above-mentioned upgrade process, the present invention uses the MCU as a built-in upgrader. When the MCU is in the functional program state, the MCU processes normal business logic; when it enters the boot program, the MCU is equivalent to a two-in-one upgrader of JTAG and JLink, initiating upgrade operations for itself and the FPGA. For the upgrade of the FPGA, the MCU simulates the JTAG upgrader signal to upgrade the FPGA, thereby eliminating the need for an external JTAG upgrader; for the upgrade of the MCU itself, the MCU upgrades itself through the boot program, thereby eliminating the need for a Jlink emulator and the need to disassemble the product shell for the upgrade. At the same time, the present invention selectively upgrades according to the module identification, prioritizes upgrading modules that occupy less resources, skips modules in the optimal state, reconfigures the FPGA after the upgrade is completed, and records the upgrade results, thereby achieving efficient and safe collaborative upgrades of the MCU and FPGA, reducing product maintenance costs, and meeting the complex and changeable IO module upgrade needs of industrial users.

[0063] Figure 3 This is a data interaction diagram of the firmware upgrade package encryption based on the AES_ECB algorithm disclosed in the embodiment of the present application.

[0064] 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 present invention can use algorithms including but not limited to AES or SM4 algorithms; 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 without authorization during transmission and use, thereby ensuring the security of the firmware. Among them, the AES encryption algorithm is an internationally used advanced symmetric encryption algorithm. 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 autonomous controllability.

[0065] Furthermore, this embodiment uses the AES algorithm in ECB mode, namely the AES_ECB algorithm, to implement data encryption. The AES algorithm supports multiple modes, including ECB, CBC, CFB, and OFB. ECB mode is suitable for short data and high-performance scenarios, CBC mode is suitable for long data and high-security scenarios, and CFB and OFB modes are suitable for streaming data encryption. Given the length of firmware data packets and the high real-time requirements of firmware upgrade tasks, this embodiment selects ECB mode, also known as the AES_ECB algorithm, to encrypt the firmware upgrade package.

[0066] like Figure 3 As shown, the working principle of the AES_ECB algorithm in this embodiment is as follows:

[0067] During the encryption process:

[0068] First, the EtherCAT master divides the plaintext data into fixed-size blocks, known as data frames, such as 128 bits. If the data length is not an integer multiple of the frame size, padding is required. For example, if the plaintext data is 1024 bytes and the frame size is 16 bytes (128 bits), the data will be divided into 64 frames.

[0069] 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. The order of the encrypted ciphertext frames remains unchanged.

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

[0071] During the decryption process,

[0072] First, the MCU in the IO module receives the encrypted data through the coupler.

[0073] Next, the MCU decrypts each frame using the AES algorithm and the same key. Each frame is decrypted independently of other frames, and the order of the decrypted plaintext frames remains unchanged. If padding was used during encryption, it must be removed after decryption to restore the original data.

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

[0075] Figure 4 This is a flowchart of a collaborative upgrade method based on the EtherCAT bus disclosed in an embodiment of the present application.

[0076] like Figure 4 As shown, the method may include:

[0077] S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers. It then uses an encryption algorithm to encrypt all MCU and FPGA firmware modules. The encrypted header carries the firmware type identifier and firmware model, and the modules are combined into a firmware upgrade package.

[0078] The functional module contains module information, namely module identification, module status, update requirement information and module association information, wherein the module identification is the name and version number of the module, which is used by the MCU to identify the specific module during the upgrade process; the module status is the operation or configuration status of the module; the update requirement information is an identification of whether the module needs to be updated, where 0x01 indicates that an update is required and 0x00 indicates that an update is not required; the module association information refers to the priority relationship between modules, wherein the priority relationship refers to the upgrade priority between modules.

[0079] In S1, the firmware type identifier is an identifier for distinguishing firmware types, 0x01 represents MCU firmware, and 0x02 represents FPGA firmware. The EtherCAT master station 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 encrypted header of the firmware upgrade package. The detection tool refers to a software tool that obtains the utilization rate of the central processing unit of the MCU, the memory occupancy, and the block memory, clock frequency, etc. of the FPGA. The hardware resource usage refers to the utilization rate of the central processing unit of the MCU, the memory occupancy, and the block memory, clock frequency, etc. of the FPGA. This allows the upgrade package to be upgraded according to the actual module status and hardware status, especially when resources are limited, which can significantly improve the performance of the system while ensuring the security and integrity of the upgrade process.

[0080] S2: Use the FoE function through the EtherCAT master station to transmit the firmware upgrade package to the MCU via the network cable;

[0081] FoE, or File over EtherCAT, is a feature that processes data units at the EtherCAT data link layer. It offers low latency and enables fast file transfers to meet the demands of real-time automation scenarios. During the file transfer process, the FoE client and server—the coupler and EtherCAT master—perform necessary handshakes and error detection to prevent data loss or corruption during the upgrade process and ensure transmission reliability and integrity.

[0082] S3: After receiving the firmware upgrade package, the MCU stores it in its own storage unit and writes the update flag in the storage unit after the storage is completed. Then the MCU resets and enters the boot program.

[0083] The update flag is a four-byte hexadecimal value that indicates whether an update is available. For example, 0xA5A5AA55 indicates a firmware update is available, while 0x5A5A55AA indicates no firmware update. After writing the update flag to the MCU's internal memory, it also generates a configuration file containing the firmware package version information and module identifiers. This allows the bootloader to quickly identify the firmware package contents and update requirements. This allows the update package to be updated based on the actual module and hardware status, significantly improving system performance, especially in resource-constrained environments, while ensuring the security and integrity of the update process.

[0084] S4: The MCU decrypts the firmware upgrade package in the boot program, determines whether the firmware belongs to an FPGA or MCU through the firmware type identifier in its encryption header, and reads the module identifier in the firmware upgrade package to determine the MCU and FPGA functional modules that need to be updated; here, the MCU identifies the starting address of the FPGA and MCU firmware respectively 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 the module identifier and the usage of hardware logic resources. The frame-by-frame decryption refers to a method of dividing the firmware package into multiple small units, namely data frames, for transmission, and decrypting each frame separately. The advantage of this is that during the firmware upgrade process, if a failure occurs, you only need to re-upgrade the current frame; while the ordinary whole-packet decryption method takes up a large storage space, and if it fails at any time, you must restart the upgrade.

[0085] Furthermore, in S4, the MCU verifies the decrypted firmware data. If a firmware type mismatch, firmware corruption, or version incompatibility is detected, the upgrade is interrupted and the MCU sends an error message to the host computer, including the upgrade interrupt signal and the error type. This design effectively prevents incorrect firmware from being written to the device, thus avoiding device failures and data corruption caused by incorrect firmware. It also facilitates rapid problem identification, improving upgrade success rates and system reliability.

[0086] S5: If it is FPGA firmware, the MCU obtains the FPGA firmware model in the firmware encryption header and determines whether the upgrade package is compatible with the model. If it is compatible, it proceeds 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 that is compatible with the model from the storage unit based on the FPGA firmware model. The MCU modifies the configuration strategy in the original firmware package and repackages the firmware package to adapt to the model. The MCU then performs a storage unit erase and write operation on the FPGA functional modules one by one to simulate the JTAG timing according to the module identifier in the firmware package, completing the FPGA firmware upgrade. 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, completing the firmware upgrade of each module of the MCU one by one.

[0087] Specifically, in S5, when the MCU adjusts the firmware package, the specific steps are as follows:

[0088] S51: Before the firmware upgrade, perform pre-compatibility analysis on FPGA chips from different manufacturers and assign an adaptive JTAG timing parameter configuration strategy for each model;

[0089] S52: Push the configuration policy in the form of a data packet to the MCU storage unit for storage;

[0090] S53: After the MCU receives the firmware adjustment instruction, the MCU retrieves the corresponding configuration policy from the storage unit according to the FPGA model identifier;

[0091] S54: The MCU writes the corresponding configuration policy into the firmware package and repackages the firmware upgrade package.

[0092] The benefit of this is that, through pre-adaptability and adjustment mechanisms, the upgrade package can be automatically fine-tuned for each FPGA model, reducing upgrade failures or repeated configurations due to model mismatches, improving upgrade efficiency, reducing the complexity of maintenance and upgrades, and lowering product maintenance costs.

[0093] S6: After the firmware of the FPGA and MCU are upgraded, the MCU erases the update flag and resets to the new MCU firmware, completing the entire upgrade process.

[0094] Specifically, after the MCU completes the FPGA firmware upgrade, it reconfigures the FPGA. This step is crucial to ensuring the FPGA is immediately operational after the upgrade and ensuring proper operation. After completing the firmware upgrade for both the FPGA and MCU, the MCU records the upgrade results in its storage unit and sends them back to the EtherCAT master. The EtherCAT master generates a firmware upgrade log based on the results. This step ensures traceability of the firmware upgrade process and efficient problem location, while also providing reliable data support for subsequent maintenance and optimization.

[0095] Specifically, Figure 5 This is a flowchart for upgrading FPGA firmware disclosed in an embodiment of this application.

[0096] like Figure 5 The FPGA firmware upgrade typically involves the following sub-steps:

[0097] a1. Initialize upgrade resources: The MCU initializes the hardware resources required for communication with the FPGA, including GPIO pins, JTAG interface, and clock signals; configures the pin functions of the JTAG interface to ensure that signals such as TMS, TCK, TDI, and TDO can work properly; initializes the access interface of the memory unit to ensure that the memory unit of the FPGA can be erased and written.

[0098] a2. Identify the firmware start address: The MCU parses the encrypted header of the encrypted firmware upgrade package to extract the start address and length information of the FPGA and MCU firmware. It also determines the location of the FPGA firmware in the firmware package to prepare for subsequent upgrade operations.

[0099] a3. Read and decrypt firmware data: The MCU reads the FPGA firmware data from the storage unit, such as reading 128-byte data blocks at a time; decrypts the read data blocks 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.

[0100] a4. Identify the firmware model and determine whether the upgrade package matches: The MCU obtains the FPGA firmware model from the firmware package and determines whether the upgrade package is compatible with the model. If so, it proceeds to the next step. If not, the FPGA sends a firmware adjustment instruction to the MCU, and the MCU adjusts the firmware package to adapt to the model. Because FPGAs from different manufacturers use different ISP programs for firmware upgrades, traditional methods are difficult to adapt and upgrade multiple FPGA models. This method addresses this challenge: since the firmware upgrade package is read and decrypted within the MCU, the FPGA passively accepts the firmware upgrade. Therefore, we split the FPGA firmware upgrade package into distinct software functional modules. Our engineers pre-trained FPGA chips from manufacturers like Anlu and Unisplendour, then configured an upgrade package adjustment policy, including JTAG timing parameter configurations tailored to the specific FPGA model. This policy is then pushed to the MCU's memory unit for storage in the form of a data packet. When the FPGA enters the firmware upgrade process, the MCU retrieves the corresponding policy from the memory unit based on the FPGA chip model identifier, matches the JTAG timing parameters for that model, and applies the firmware upgrade to the FPGA, adapting it to different FPGA models from different manufacturers. This method supports adaption to FPGAs of different models from different manufacturers, including the Anlu SALDRAGON 1 and Unisplendour Titan-2.

[0101] This method, through pre-adaptation and adjustment mechanisms, automatically fine-tunes the upgrade package for each FPGA model. This reduces upgrade failures and duplicate configurations caused by model mismatches, improves upgrade efficiency, reduces maintenance and upgrade complexity, and lowers product maintenance costs. It's important to note that the MCU must have sufficient storage capacity and processing power to support firmware package storage, decryption, and adjustment. The MCU models used in this example include the Arteli AT32F423 series and the GigaDevice GD32 series.

[0102] a5. Simulate JTAG timing for upgrade: The MCU simulates JTAG timing and communicates with the FPGA through TMS, TCK, TDI, and TDO signals; sends an erase instruction to erase the area corresponding to the functional module 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 FPGA's status feedback to ensure the smooth progress of the upgrade operation.

[0103] 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. By this means, 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.

[0104] a7. Reconfigure the FPGA: After the FPGA firmware 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; this operation ensures that the FPGA can be put into use immediately, improving the reliability and stability of the system.

[0105] 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 as follows:

[0106] 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:

[0107] Module 1, version number V1.3.0 < V1.3.1, needs to be updated.

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

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

[0110] 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 storage unit of the FPGA to complete the firmware upgrade.

[0111] Secondly, 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.

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

[0113] When upgrading the FPGA firmware, the MCU prioritizes upgrading modules that consume less resources based on logic resource usage, reducing the pressure on logic resources. This optimization can significantly improve system performance, especially when resources are limited.

[0114] In this embodiment, the FPGA to be upgraded is divided into three modules, and the proportion of logic resources occupied by each module is as follows:

[0115] Module A: Sensor data processing, occupies 30% of resources

[0116] Module B: Data verification, occupies 20% of resources

[0117] Module C: Communication protocol processing, occupies 40% of resources

[0118] The new firmware version is V1.3.0, which requires updating all modules.

[0119] like Figure 6 The module resource evaluation process for FPGA upgrade is as follows:

[0120] b1. The MCU first evaluates the logic resource usage of each module in the current FPGA.

[0121] b2. Based on the resource usage, the MCU decides to upgrade module B first, which occupies less resources, because its resource usage is 20%.

[0122] b3. MCU simulates JTAG timing and upgrades module B first.

[0123] b4. Next, the MCU upgrades module A, which ranks second in resource usage, accounting for 30%. The MCU simulates JTAG timing to upgrade module A.

[0124] b5. Next, the MCU upgrades module C, which ranks third in resource usage, accounting for 40%. The MCU simulates JTAG timing to upgrade module C.

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

[0126] Specifically, Figure 7 This is a flowchart for upgrading the MCU firmware disclosed in the embodiment of this application.

[0127] like Figure 7 The MCU firmware upgrade usually involves the following steps:

[0128] c1. Initialize upgrade resources: The MCU initializes the hardware resources required to communicate 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.

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

[0130] c3. Reading and decrypting firmware data: The MCU reads the firmware data from the storage unit, for example, in 128-byte blocks at a time. It decrypts the read data blocks 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.

[0131] c4. Write Firmware Data: The MCU writes the decrypted firmware data to its own memory unit. During the write process, the MCU dynamically adjusts upgrade parameters, prioritizing modules that consume less resources. This reduces pressure on hardware resources, significantly improving system performance, especially in resource-constrained environments.

[0132] c5. Module status check and skip: The MCU checks the module identification of each MCU functional module; if the version number of a module is already the latest version, or the module status indicates that no update is required, the upgrade operation of the module is skipped; the method for MCU to evaluate its own hardware resources can be referred to Figure 6 The module resource evaluation process described above for FPGA upgrades reduces unnecessary operations and improves upgrade efficiency. The next time the device boots up, the MCU reads the identification information in the storage unit and only updates the modules that were previously skipped, ensuring that all modules are ultimately updated to the latest version, ensuring system stability.

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

[0134] c7. MCU upgrade completed.

[0135] This embodiment includes a collaborative upgrade master station device based on the EtherCAT bus, including:

[0136] A processing unit is used to implement the various steps 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 maintenance personnel; when abnormal conditions such as firmware damage, firmware version mismatch, and communication interruption occur during the firmware upgrade process, the processing unit can take measures such as interrupting the upgrade and attempting to reconnect.

[0137] A readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the various steps of the collaborative upgrade method based on the EtherCAT bus of the present application are implemented.

[0138] The processing unit also includes a communication module. When the firmware upgrade is successful, or a firmware version mismatch occurs, or communication is interrupted, the processing unit immediately sends an alarm message to the FPGA and MCU manufacturer maintenance personnel through the communication module; the firmware upgrade log is sent to the FPGA and MCU manufacturer maintenance personnel via email or text message for subsequent problem location and upgrade.

[0139] While the present invention has been disclosed above with reference to preferred embodiments, this is not intended to limit the present invention. Persons skilled in the art will readily appreciate that various modifications and variations can be made without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A collaborative upgrade method based on EtherCAT bus, used to remotely upgrade the firmware of MCU and FPGA in IO modules connected via EtherCAT bus, characterized in that: Follow these steps to run: S1: The EtherCAT master divides the MCU and FPGA firmware into multiple functional modules with module identifiers. It uses an encryption algorithm to encrypt all MCU and FPGA firmware modules. The encrypted header contains the firmware type identifier and firmware model, and then merges them into a firmware upgrade package. S2: Use the FoE function through the EtherCAT master station 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 the update flag in the storage unit after the storage is completed. Then the MCU resets and enters the boot program. S4: The MCU decrypts the firmware upgrade package in the bootloader, determines whether the firmware belongs to an FPGA or MCU based on the firmware type identifier in the encrypted 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 in the firmware encryption header, and the MCU determines whether the upgrade package is compatible with the model. If it is compatible, it proceeds to the next step; if not, the MCU retrieves the adapted JTAG timing parameter configuration strategy from the storage unit based on the FPGA firmware model, modifies the original firmware package configuration strategy and repackages it to adapt to the model; then, according to the module identifier in the firmware package, the MCU performs a storage unit erase and write operation simulating JTAG timing on the FPGA functional modules one by one to complete the FPGA firmware upgrade; 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, completing the firmware upgrade of each MCU module one by one; S6: After the firmware of the FPGA and MCU are upgraded, the MCU erases the update flag and resets to the new MCU firmware, completing the entire upgrade process.

2. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that: In S1, the functional module contains module information, namely, module identification, module status, update requirement information and inter-module association information; the module identification is the name and version number of the module, which is used by the MCU to identify the specific module during the upgrade process; the firmware type identification is an identification to distinguish the firmware type as FPGA or MCU; the EtherCAT master station obtains the hardware logic resource usage of the MCU and FPGA through a detection tool, and embeds the module identification and hardware logic resource usage into the encrypted 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 including firmware package version information and module identification for quickly identifying the content and update requirements of the firmware package in the boot program.

4. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that: In S4, the MCU identifies the starting addresses of the FPGA and MCU firmware respectively 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 firmware original data and related information, including the module identifier and the usage of hardware logic resources.

5. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that: In S5, when the MCU adjusts the firmware package, the specific steps are as follows: S51: Before the firmware upgrade, perform pre-compatibility analysis on FPGA chips from different manufacturers and assign an adaptive JTAG timing parameter configuration strategy for each model; S52: Push the configuration policy in the form of a data packet to the MCU storage unit for storage; S53: After the MCU receives the firmware adjustment instruction, the MCU retrieves the corresponding configuration policy from the storage unit according to the FPGA model identifier; S54: The MCU writes the corresponding configuration policy 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 will check the module identification of each module; for modules that do not need to be upgraded, the MCU will skip the update of the module and store the identification information of the module in its own storage unit; the MCU will choose to upgrade the modules that occupy less resources first based on the usage of logic resources to reduce the pressure on logic resources.

7. The collaborative upgrade method based on EtherCAT bus according to claim 1, characterized in that: In S6, after the MCU completes the FPGA firmware upgrade, the FPGA is reconfigured; after completing the firmware upgrade of the FPGA and MCU, the MCU records the upgrade result in a storage unit and sends the upgrade result back to the EtherCAT master station; the EtherCAT master station generates a firmware upgrade log based on the upgrade result.

8. The 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 between the coupler, receive remote firmware upgrade data from the FPGA and MCU, and transmit data required for the FPGA function to the FPGA via 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 via the SPI bus, responds to the MCU's instructions, and performs logical operations and data processing tasks.

9. A collaborative upgrade master station device based on EtherCAT bus, characterized in that: Include: A processing unit, configured to implement the steps of the method for collaborative remote firmware upgrade of IO modules based on an EtherCAT bus as described in any one of claims 1 to 8; A readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements the steps of the collaborative upgrade method based on the EtherCAT bus as described in any one of claims 1 to 8.

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

Images