Remote stable upgrading method for FPGA firmware

Abstract

The invention relates to a remote stable upgrading method for FPGA firmware, belongs to the technical field of integrated circuits, and solves the problems of low efficiency, high hardware damage risk, poor universality and the like of the existing upgrading scheme. The method comprises the following steps that: an upper computer establishes connection with an FPGA (Field Programmable Gate Array) through a communication interface, and the FPGA enters a communication ready state; a built-in FLASH control module of the FPGA executes an erasing operation on a target storage area of the FLASH memory according to an erasing instruction sent by the upper computer, and the FPGA continuously reads and reports real-time state information of the state register to the upper computer during an erasing period; writing a to-be-upgraded firmware program package into the target area, and powering off and restarting the FPGA; and the restarted FPGA runs the new firmware program written into the target storage area. According to the method, the upgrading efficiency can be improved, the hardware damage risk is reduced, the upgrading cost is reduced, and the universality of the scheme is improved so as to adapt to FPGAs of different types and brands.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of FPGA configuration and programming technology, in particular to a remote stable upgrading method of FPGA firmware. BACKGROUND

[0002] With the wide application of field programmable gate array (FPGA) in communication, industrial control, aerospace and other fields, developers usually use JTAG interface to complete online development, debugging and temporary configuration. During the project verification and debugging stage, the JTAG interface can not only realize real-time programming of FPGA, but also can realize online breakpoint debugging and logic analysis, which greatly improves the development efficiency. However, once the development and test work is completed, the final generated configuration file needs to be written into an external non-volatile memory (such as a FLASH chip) so as to realize automatic loading without attendance in subsequent products.

[0003] The traditional JTAG online burning scheme is limited by the bandwidth of JTAG bus, and it takes a long time to burn the full configuration file, and it is only convenient to operate on experimental platform or open development board. For the application scenario that the FPGA core is packaged inside the terminal product, the product needs to be disassembled to access JTAG, which not only takes time and effort, but also has the risk of mechanical damage or function failure. Especially in the case of precision instruments, embedded devices or aerospace payloads, which have very high requirements for structural integrity and long-term stability, disassembly and upgrading not only increases the on-site maintenance cost, but also may cause irreversible hardware damage.

[0004] In order to alleviate the above problems, the industry introduces auxiliary storage (such as DDR, eMMC, etc.) to download and temporarily store all configuration programs, and then writes them into the main memory by the internal controller of FPGA. Although this kind of scheme can avoid frequent disassembly, it puts forward additional requirements for hardware resources, which leads to significant increase of PCB design complexity and cost, and is helpless for the core board that has been put into production and has no reserved storage resources. Another kind of upgrading method for Xilinx 7 series FPGA directly erases and writes external flash memory in the chip by using its special Flash Writer IP core, which is not implemented by pure code logic, and is limited to Xilinx platform, which is difficult to promote to domestic FPGA or other series devices. In addition, some schemes use an ARM chip and a FLASH memory as peripherals, and the firmware program can receive the program every time it is powered on to realize the upgrading of the FPGA chip program. Although this scheme can be compatible with various platforms of FPGA, it also faces the problem of increasing cost due to redesign of the core board.

[0005] In summary, the main shortcomings of the existing various upgrading schemes in the process of FPGA firmware upgrading can be summarized as follows:

[0006] 1. Low upgrade efficiency: Traditional JTAG burning scheme requires disassembling hardware and reconnection, which is time-consuming and tedious, resulting in long downtime and increased maintenance costs;

[0007] 2. Risk of hardware damage: Disassembling the device shell during firmware upgrade increases the risk of hardware damage, especially in precision devices, which may result in the device being unable to return to its original state, increasing repair and device replacement costs;

[0008] 3. High cost: Existing solutions often require additional memory (such as DDR), resulting in a significant increase in hardware costs. For core boards that have already been designed and do not have redundant storage, this method is not applicable;

[0009] 4. Poor universality: Existing Xilinx series FPGA-specific IP core upgrade solutions are only applicable to specific brands and models of FPGAs, lacking cross-brand and cross-model universality, limiting their application scope.

[0010] Therefore, there is an urgent need in the industry for a universal technical solution that can remotely and quickly, efficiently, and reliably upgrade FPGA firmware without disassembling the product shell, which is compatible with different manufacturers and series of FPGAs and significantly reduces upgrade risks and operational costs without increasing hardware costs. SUMMARY

[0011] The purpose of the present application is to provide a FPGA firmware remote stable upgrade method without disassembling hardware, which can improve upgrade efficiency, reduce hardware damage risk, reduce upgrade cost, and improve the universality of the solution to adapt to different types and brands of FPGAs, solving many deficiencies in the prior art.

[0012] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0013] A FPGA firmware remote stable upgrade method, comprising the following steps:

[0014] Step 1: After the host computer receives the to-be-upgraded firmware program sent by the remote control software and completes the communication interface parameter configuration, the host computer sends a connection instruction to the FPGA through the communication interface, and the FPGA receives and parses the connection instruction and returns a handshake response message to the host computer, and enters a communication ready state;

[0015] Step 2: The host sends an erase instruction to the FPGA, and the FLASH control module built in the FPGA performs an erase operation on the target storage area of the FLASH memory according to the erase instruction, and the FPGA continuously reads and reports the real-time state information of the state register of the FLASH memory to the host during the erasing, and the host checks the erasing progress according to the real-time state information until the erasing is completed;

[0016] Step 3: The host performs packet processing on the to-be-upgraded firmware program, and sends data packets to the FPGA in sequence, and the FPGA writes the data packets into the target storage area through the FLASH control module, and after all the data packets are transmitted and verified, the FPGA is powered off and restarted;

[0017] Step 4: The FPGA after restarting runs the new firmware program written in the target storage area.

[0018] The application provides a general technical solution for remotely upgrading FPGA firmware quickly, efficiently and reliably without disassembling the product shell, which is compatible with FPGA of different manufacturers and series, and can greatly reduce the upgrade risk and operation and maintenance cost without expanding the hardware cost. Compared with the prior art, the application has the following beneficial effects:

[0019] (1) Remote quick upgrade with low operation and maintenance risk:

[0020] The application supports a series of automatic processes such as remote serial port handshake, packet transmission and jump start, and the entire upgrade process does not require disassembly of the shell or manual intervention, and can be quickly completed on site or remotely, greatly reducing the operation and maintenance cost and downtime risk;

[0021] (2) No need to expand hardware cost:

[0022] Traditional upgrade solutions often rely on external auxiliary storage (DDR, eMMC) or special IP cores, resulting in significant increase in PCB design complexity and cost; and the application directly uses the internal Multiboot mechanism and existing FLASH resources without the need for additional devices or storage reservation, and is fully compatible with existing hardware platforms;

[0023] (3) Strong universality and easy to promote:

[0024] The existing upgrade solution based on special IP cores is limited to Xilinx platforms, and the application uses a method combining a FLASH control module with a Multiboot module designed by pure logic, which can be directly transplanted to domestic FPGA and other series of devices, and for FPGA that does not support the Multiboot solution, a unified upgrade solution for multiple manufacturers and multiple series can also be realized by reprogramming the program every time the power is turned on;

[0025] (4) Real-time state monitoring throughout the process:

[0026] During the FLASH erase and write process, the status of the FLASH memory status register is continuously read and reported to ensure that each step is performed in a controlled state, greatly improving the reliability and predictability of the upgrade;

[0027] (5) Reliable rollback and retry mechanism:

[0028] For FPGAs that support multiple boot, by pre-writing the "Golden Region" with backup firmware that has been rigorously tested, the present application introduces a programmable watchdog timer to monitor the heartbeat signal during startup or upgrade: if the new firmware fails to start or times out without responding, it automatically reverts to the Golden Region firmware, supporting a second upgrade attempt, and fundamentally avoiding the device from falling into a dead loop or unusable state. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 For FPGAs that support multiple boot functionality, the flowchart of the FPGA firmware remote stable upgrade method of the present application;

[0030] Figure 2 For FPGAs that do not support multiple boot functionality, the flowchart of the FPGA firmware remote stable upgrade method of the present application;

[0031] Figure 3 For FPGAs that support multiple boot functionality, the overall principle block diagram of the FPGA firmware remote stable upgrade method of the present application;

[0032] Figure 4 For FPGAs that do not support multiple boot functionality, the overall principle block diagram of the FPGA firmware remote stable upgrade method of the present application;

[0033] Figure 5 State transition diagram for Multiboot module;

[0034] Figure 6 State transition diagram for FLASH control module. DETAILED DESCRIPTION

[0035] The technical solutions of the present application will be described in detail below in conjunction with the preferred embodiments and the accompanying drawings.

[0036] The remote stable upgrading method of FPGA firmware provided by the application contains two schemes, scheme 1 is a scheme for supporting FPGA multiboot technology, in the scheme, the FPGA external configuration flash memory is divided into two storage regions of a golden region and an update region: first, the golden region is pre-written with a backup firmware (Golden Code) that has been strictly tested to ensure that it can be quickly recovered in case of upgrade failure; when remote upgrading, the host computer sends a "connect device" instruction to the FPGA through a communication interface (such as a serial port), the FPGA returns a handshake response message after receiving the "connect device" instruction and enters a communication ready state; then, the host computer issues a FLASH (non-volatile memory) erase instruction, the FPGA executes an erase operation on the update region of the FLASH memory through its built-in FLASH control module, and the FPGA continuously reads and reports the real-time state of the status register of the FLASH memory during the erase period, the host computer real-time checks the erase progress according to the WIP (Write In Progress) bit (1 indicates that the erase is in progress, and 0 indicates that the erase is completed) of the status register until it confirms that the erase is completed; then, the host computer sends the binary firmware program to be deployed, i.e., the firmware program to be upgraded, to the FPGA in packets, the FPGA writes each data packet to the update region, and after the firmware program is completely transmitted and verified, the FPGA is powered off and restarted, after the FPGA is reset, the host computer sends a jump instruction to drive the FPGA to jump to the firmware in the update region to start through the multiboot module;

[0037] Scheme 2 is a scheme for a small number of FPGAs that do not support the Multiboot technology, which is based on the golden region code that has been designed, only needs to change the write address of the FLASH control module to start from 0, directly add to the original project, and can realize remote upgrading without affecting the function of the original project. Therefore, the design of the application does not need to expand any hardware cost, is compatible with multiple manufacturers and multiple series of FPGAs, has a full-time state monitoring, rollback and retry mechanism, realizes remote, fast, efficient and reliable firmware upgrading, and greatly reduces the operation and maintenance risk and cost.

[0038] In order to realize remote, safe and fast upgrading of FPGA firmware of various manufacturers and series under the premise of not relying on external hardware modification, the structure, working process and key module implementation of the application will be described in detail below with reference to the drawings.

[0039] Referring to Figure 1 The application provides a remote stable upgrading method for FPGA firmware, when the FPGA is an FPGA supporting multiple startup functions, the method specifically comprises the following steps:

[0040] Step 1: device connection and handshake.

[0041] When it is necessary to remotely upgrade the FPGA, the firmware program to be upgraded is first remotely sent to the host computer through common remote control software (for example, Sunflower, ToDesk, etc.), and the host computer needs to complete the configuration of the communication interface parameters. After the device, i.e., the FPGA, is powered on and started, the external host computer sends a connection instruction to the FPGA through a communication interface such as a serial interface. After the FPGA receives and analyzes the connection instruction, it reads its initial state information and returns a handshake response message to the host computer through the communication interface; then, the FPGA enters a communication ready state, waiting for subsequent commands to be issued. The communication interface can use one of UART, Ethernet, CAN bus, Wi-Fi, 4G module, and 5G module.

[0042] Step 2: erase the upgrade area of FLASH.

[0043] The host computer sends an erase instruction to the FPGA, and the FLASH control module built in the FPGA performs an erase operation on the target storage area, i.e., the upgrade area, of the FLASH memory based on the SPI bus protocol, to ensure the cleanliness of the writing area. The target storage area is different depending on whether the FPGA supports multiple startup functions. When the FPGA is an FPGA supporting multiple startup functions, the target storage area is the upgrade area of the FLASH memory, and the FLASH memory also contains a gold area pre-stored with a backup firmware program. When the FPGA is an FPGA not supporting multiple startup functions, the target storage area is the storage area of the FLASH memory starting from the starting address.

[0044] During the erasing process, the FLASH control module drives the FLASH memory through SPI (serial peripheral interface), continuously reads the real-time state information of its state register, and reports the real-time state information to the host computer. The host computer displays the state information of the received state register in real time for erasing progress monitoring. The WIP (write process) bit in the state register indicates the erasing progress: when the WIP bit is 0, it indicates that the erasing is completed; when WIP = 1, it indicates that the erasing operation is still in progress. When the FLASH control module reads the state register, if it finds that WIP = 0 and no new state feedback is received, it can be determined that the erasing operation is completed and the upgrade area is cleared to the predetermined state. The FPGA reports the read real-time state information, i.e., the state register value, to the host computer in real time through the serial interface for progress monitoring. The host computer checks the erasing progress according to the real-time state information until the erasing is completed.

[0045] Step 3: firmware writing.

[0046] The host computer configures the serial interface parameters as baud rate 115200, data bits 8, and stop bits 1. The host computer packetizes the firmware program to be upgraded, and then sends the data packets to the FPGA in sequence through the serial interface. The FLASH control module inside the FPGA receives the data packets and performs programming and writing on the upgrade area in address order until the firmware is completely burned. After all the data packets are transmitted and verified, the FPGA is powered off and restarted.

[0047] Step 4: start jump and rollback mechanism.

[0048] After the firmware writing is completed and the FPGA is powered off and restarted, the host computer sends a jump instruction to the FPGA to drive the FPGA to jump to the upgrade area to execute the new firmware program. During the startup process, the programmable watchdog timer monitors the running state of the new firmware program, judges whether a valid heartbeat signal is detected within the preset timeout limit, and if the new firmware program runs abnormally or fails to complete initialization within the preset watchdog timeout limit, i.e., no valid heartbeat signal is detected within the preset timeout limit, the FPGA will trigger the rollback mechanism to automatically rollback to the backup firmware program of the original firmware area for startup, and the above upgrade process can be re-executed until the upgrade is successful.

[0049] Referring to Figure 3 which is the overall principle block diagram of the firmware remote upgrade of scheme 1, wherein the FPGA includes a built-in UART module, a FLASH control module, and a Multiboot module. The communication between the host computer and the FPGA generally uses a serial interface because it is simple to implement and is often used for instruction and data reception. The specific implementation of the principle of scheme 1 is as follows: when the FPGA needs to be remotely upgraded, the firmware program to be upgraded is remotely sent to the host computer through common remote control software (Sunflower, ToDesk, etc.). After the host computer receives the program, it is packetized according to the size of the serial interface buffer, and then sent to the FPGA through the serial interface. The FPGA receives the data packets and performs programming and writing on the upgrade area in address order until the firmware is completely burned. Figure 1The FPGA device is upgraded in the shown mode. The specific process is: the host computer initializes the connection with the device: after the host computer sets the baud rate parameters, it sends a connection instruction to the FPGA through the serial port. After the FPGA receives the connection instruction, it returns a handshake response message and enters the communication ready state. Then the erasing operation is performed: the host computer issues a FLASH erasing instruction. After the FPGA receives the FLASH erasing instruction, it starts to erase the upgrade area of the FLASH memory. The status during the erasing process is returned through the FLASH status register data, and the WIP bit thereof is monitored and returned to the host computer in real time to ensure the completion and synchronization of the erasing operation. Then, the upgraded firmware program is transmitted and written: after the upgraded firmware program is packaged by the host computer, it is sent to the FPGA through the serial port. After the FPGA receives each data packet, it is written to the upgrade area through the FLASH control module. Finally, power off and restart and start jump: after all the data packets are transmitted, the FPGA power off and restart operation is performed. After restarting, the Multiboot module in the FPGA jumps to the firmware program in the upgrade area according to the jump instruction of the host computer to start. Watchdog mechanism and rollback: during the startup process after the upgrade, the programmable watchdog timer in the FPGA monitors the system heartbeat signal. If no valid heartbeat signal is detected within the preset timeout period, the FPGA will automatically roll back to the standby firmware program in the gold area for startup and prepare to initiate the upgrade again.

[0050] For the FPGA supporting multiple startup functions, the Multiboot module is a highly reliable FPGA configuration management scheme. It realizes dynamic loading, verification, switching and rollback of multiple bit streams on external FLASH (such as SPI / QSPI, BPI, NOR) through the multi-selector, state machine and configuration register integrated in the design. After power-on, the FPGA will preferentially load the firmware program in the gold area. First, the Multiboot module writes the synchronization head word 32'hAA995566 into the FLASH memory according to the jump instruction sent by the host computer, then writes the starting address of the firmware program file to be jumped into the WBSTAR register, and finally writes the IPROG (internal FPGA chip reset operation) instruction. The FPGA logic drives IPROG. The specific state machine is as follows Figure 5The state machine waits for the start of the loading upgrade area from S_IDLE (idle state), transits to the read virtual data state for initialization, detects the frame header state to synchronize the firmware program data, transits to the short delay 1 state, then configures the WBSTAR (reserved instruction start address register of the upgrade area program) register and executes the WBSTAR register, then enters the write start command state, and finally enters the IPROG instruction state to activate the FPGA. After the configuration is completed, the state machine ensures the stability of the process in the delay 2 state, finally enters the stop state, and outputs the completion signal. If the verification fails in any stage and the retry is not completed, the automatic retry is performed; if the retry is still failed, the gold area firmware program offset address is switched to realize the fallback, so that the system can be recovered to the known available state. In the future, the Multiboot module can also be used to encrypt the firmware program to prevent unauthorized access or tampering, and to provide online upgrade, fault recovery and version management.

[0051] Referring to Figure 2 which is the firmware remote upgrade process of scheme 2, and the difference between scheme 2 and scheme 1 is that the target storage area and step 4 are different. In scheme 2, the target storage area is the storage area starting from the start address of the FLASH memory. In step 4, the FPGA runs the upgraded program after power-off restart, and the FPGA directly loads and runs the new firmware program from the start address of the FLASH memory.

[0052] Referring to Figure 4 which is the overall principle block diagram of the firmware remote upgrade of scheme 2. Compared with scheme 1, the FPGA in scheme 2 lacks the Multiboot module, and the other modules are the same as those in scheme 1. After the FPGA is power-off restarted, the host computer does not send a jump instruction, and the FPGA directly runs the upgraded program.

[0053] The built-in UART module of the FPGA is responsible for full-duplex data exchange with the host computer through the UART interface, receives the control commands and firmware data packets from the host computer, and returns the real-time FPGA internal state to the host computer; in addition, the protocol analysis: realizes the functions of frame header identification, command analysis, packet length verification and the like sent by the host computer, to ensure the integrity and correctness of the instructions and data packets;

[0054] Figure 6 The state transition diagram of the FLASH control module is shown. At present, special IP cores are provided by major FPGA manufacturers for FLASH control, but these IP cores are usually bound to specific FPGA chips, so that the design is difficult to be directly transplanted when the FPGA chip is replaced, and the compatibility is poor. In order to solve this problem, the FLASH control module in the application adopts pure logic design, avoiding the dependence on the special IP core of the manufacturer, thereby improving the universality and portability of the design. The logic design scheme of the FLASH control module is as follows:

[0055] The initial state is idle, at which time the system waits for an operation command triggered by the host computer or externally. After receiving a FLASH erase instruction, the FLASH control module enters the "sector erase write enable" state and begins to open the operation permission of the target address region, preparing for erasing the address region. The erase operation is performed in the FLASH memory by sector (the starting address of the erase in scheme 1 is from the upgrade area, and the starting address of the erase in scheme 2 is from the first address of the entire FLASH memory), at which time the FLASH control module continuously monitors the erase progress and reads the status register of the FLASH memory, especially the WIP bit, to determine whether the erase is complete. If the WIP is 0, it indicates that the erase is complete, and the FLASH control module will enter the reading state of the FLASH status register to confirm whether the erase is successful and prepare for writing data; if the WIP is 1, the FLASH control module will continue to stay in the erase state until the erase is complete. Specifically, after receiving a write operation instruction in the idle state, it jumps from the idle state to the "sector erase write enable" state, then to the "delay" state, and then to the "sector erase" state, and then back to the "sector erase write enable". The next cycle enters the delay -> sector erase -> reading of the status register of the FLASH until the sector erase is complete (the internal erase of the FLASH requires time), and then the next sector address starts to erase in the idle state, entering the cycle until all sector erases are complete.

[0056] After the erase operation is complete, the FLASH control module enters the page write initial state, at which time the system is ready to receive write data and prepare for page write operation. During the page write operation, the FLASH control module needs to perform the write enable operation each time to ensure that the FLASH memory allows data writing. At this time, the FLASH control module will ensure the smooth progress of the write enable operation according to the timing requirements of the FLASH memory, while also meeting certain delay requirements, i.e., maintaining a preset delay time before data writing to ensure that the FLASH memory has enough time to prepare before data writing. Next, the FLASH control module enters the page write state (the initial address of the write in scheme 1 is from the upgrade area, and the initial address of the write in scheme 2 is from the first address of the entire FLASH memory), and begins to write data into the FLASH memory page by page according to the instruction until the data writing is complete. The design of the entire state machine ensures the efficiency and reliability of the FLASH control module in performing erase and write operations. By performing the write enable operation each time and meeting the delay requirement, the correctness and consistency of the data are ensured. At the same time, the FLASH control module monitors the status register of the FLASH and switches the state according to the WIP bit, avoiding operation conflicts and resource waste, and ensuring the smooth execution of each step. This design not only improves the stability of data operation, but also enhances the fault tolerance of the system.

[0057] The application has been verified by experiments and good effects have been achieved. Specifically, in the imaging boards respectively designed for the GSENSE400BSI, GSENSE400FSI, GSENSE4040 and GSENSE6060BSI detectors based on the Changchun Changguangchen core, foreign Xilinx A7 series or K7 series FPGA chips or domestic Fudan Microelectronics JFM7K325T chips are respectively used. The remote stable upgrading method of the FPGA firmware provided by the application successfully completes the remote upgrading operation, and the system exhibits good stability and high efficiency after upgrading, and the imaging effect remains stable, and there is no performance degradation or abnormal situation caused by firmware upgrading.

[0058] The experimental results show that, by the technical scheme of the application, the remote upgrading process can successfully complete the updating of the FPGA firmware without disassembling the hardware on site. The erasing, writing, checking and starting after upgrading in the whole process are completed within the expected time, and the problems of repeated restarting or freezing of the equipment caused by interruption, power failure or checking failure in the traditional upgrading scheme are successfully avoided.

[0059] In addition, the system has been tested for many times, and the effectiveness of the rollback mechanism and the retry mechanism proposed in the application is verified. In the case that the upgrading fails or the firmware checking fails due to the human-made error program, the system can automatically recover to the backup gold area firmware, ensuring the high reliability of the equipment during the upgrading process and supporting the secondary upgrading operation.

[0060] The application is not limited to the combination of Xilinx A7 / K7 series FPGA and SPI / QSPI, BPI, NOR FLASH for realizing remote upgrading, but can also be equivalently applied to Intel (Altera) Cyclone or Lattice ECP5 / iCE40 FPGA. The external storage processing can also be eMMC, UFS or industrial SD card. The upgrading trigger mode can be through multiple lines such as Ethernet, UART, CAN, Wi-Fi, 4G module, 5G module, etc.

[0061] The main advantages of the application are embodied in the following aspects:

[0062] (1) Remote fast upgrading with low operation and maintenance risk:

[0063] The application supports a series of automatic processes such as remote serial port handshake, package transmission and jump starting, and the whole upgrading process does not need to disassemble the shell or manual intervention, and can be quickly completed on site or in a remote place, greatly reducing the operation and maintenance cost and downtime risk.

[0064] (2) No need to expand hardware cost:

[0065] Traditional upgrade solution often relies on external auxiliary storage (DDR, eMMC) or dedicated IP core, resulting in significant increase in PCB design complexity and cost; and the present application directly utilizes the internal Multiboot mechanism of FPGA and the existing resources of external FLASH, without additional devices or storage reservation, and is fully compatible with existing hardware platforms.

[0066] (3) Strong versatility, easy to promote:

[0067] The existing upgrade solution based on dedicated IP core is limited to Xilinx platform, and the present application adopts the method of combining the FLASH control module with the Multiboot module through pure logic design, and only needs simple changes to give two solutions, which can be directly transplanted to domestic FPGA and other series of devices. For FPGA that does not support the Multiboot solution, the unified upgrade solution of multiple manufacturers and multiple series can also be realized by reprogramming the program every time the power is turned on.

[0068] (4) Real-time state monitoring throughout the process:

[0069] During the FLASH erasing and writing process, the status of the status register of the FLASH memory is continuously read and reported, ensuring that each step is performed in a controlled state, greatly improving the reliability and predictability of the upgrade.

[0070] (5) Reliable rollback and retry mechanism:

[0071] For FPGA that supports Multiboot, by pre-writing the "golden region" (Golden Region) with backup firmware that has been rigorously tested, the present application introduces a programmable watchdog timer to monitor the heartbeat signal during startup or upgrade: if the new firmware fails to start or times out without responding, it automatically reverts to the golden firmware, supporting a second upgrade attempt, and fundamentally avoiding the device from falling into a dead loop or unusable state.

[0072] The technical features of the above-described embodiments can be combined in any manner. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described, but as long as the combinations of the technical features do not contradict, they should be considered within the scope of the present disclosure.

[0073] The above-described embodiments only express several embodiments of the present application, and the description is more specific and detailed, but it should not be construed as limiting the scope of the patent. It should be noted that for ordinary skilled persons in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of the present application. Therefore, the scope of protection of the present patent should be subject to the appended claims.

Claims

1. A method for remote and stable firmware upgrade of an FPGA, characterized in that, Includes the following steps: Step 1: After the host computer receives the firmware program to be upgraded remotely sent by the remote control software and completes the communication interface parameter configuration, the host computer sends a connection command to the FPGA through the communication interface. After the FPGA receives and parses the connection command, it returns a handshake response message to the host computer and enters the communication ready state. Step 2: The host computer sends an erase command to the FPGA. The FPGA's built-in FLASH control module performs an erase operation on the target storage area of ​​the FLASH memory according to the erase command. During the erase process, the FPGA continuously reads and reports the real-time status information of the FLASH memory's status register to the host computer. The host computer checks the erase progress based on the real-time status information until the erase is completed. Step 3: The host computer processes the firmware program to be upgraded into packets and sends the data packets to the FPGA in sequence. The FPGA writes the data packets into the target storage area in sequence through the FLASH control module. After all data packets have been transmitted and verified to be correct, the FPGA is powered off and restarted. Step 4: The restarted FPGA runs the new firmware program written to the target memory area.

2. The method for remote and stable upgrade of FPGA firmware according to claim 1, characterized in that, When the FPGA supports multiple boot functions, the target storage area is the upgrade area of ​​the FLASH memory, and the FLASH memory also includes a gold area that pre-stores backup firmware programs. In step 4, the multi-boot module inside the FPGA drives the FPGA to jump to the firmware program in the upgrade area according to the jump instruction sent by the host computer. During the boot process, the programmable watchdog timer monitors the running status of the new firmware program and determines whether a valid heartbeat signal is detected within the preset timeout period. If not, the FPGA automatically falls back to the backup firmware program in the gold area for boot.

3. The method for remote and stable upgrade of FPGA firmware according to claim 2, characterized in that, The multi-start module performs the following operations to complete the jump: Write the synchronization header word according to the jump instruction; Write the starting address of the upgrade area into the WBSTAR register; Executing the IPROOG instruction triggers FPGA reconfiguration and starts from the address specified in the WBSTAR register.

4. The method for remote and stable upgrade of FPGA firmware according to claim 3, characterized in that, The multi-start module is implemented by a state machine, and its state transition process includes idle state, virtual data reading state, frame header synchronization detection state, delay 1 state, WBSTAR register configuration state, start command writing state, IPROG instruction start state, delay 2 state, and stop state.

5. The method for remote and stable upgrade of FPGA firmware according to claim 1, characterized in that, When the FPGA does not support multiple boot functions, the target storage area is the storage area of ​​the FLASH memory starting from the start address; In step 4, the FPGA loads and runs the new firmware program directly from the starting address of the FLASH memory.

6. The method for remote stable upgrade of FPGA firmware according to claim 1, characterized in that, The real-time status information is the WIP bit in the status register. When the WIP bit is 0, it indicates that the erasure has been completed. When the WIP bit is 1, it indicates that the erasure has not been completed, and the FLASH control module continues to perform the erasure operation.

7. The method for remote stable upgrade of FPGA firmware according to claim 1, characterized in that, The FLASH control module uses a state machine approach to control the entire operation process, and its state transition process includes: Idle state: Waiting for operation commands triggered by the host computer or external sources; Sector erase write enabled state: Enables operation permissions for the target address region, preparing for erasing the address region; Read the status register of the FLASH memory: Read the status register to confirm whether the erase was successful and to prepare for writing data; Page write initial state: Receive write data and prepare for page write operation; Page write enable state: Enable write operation to ensure that the FLASH memory allows data to be written; Delay status: Maintain a preset delay time before writing data; Page write status: Start writing data to the FLASH memory page by page according to the instructions until the data writing is complete.

8. The method for remote and stable upgrade of FPGA firmware according to claim 1, characterized in that, The FPGA is a programmable logic chip from the Xilinx A7 / K7, Intel Cyclone, or Lattice ECP5 / iCE40 series; the FLASH memory is any one of SPI FLASH, QSPI FLASH, BPI FLASH, or NOR FLASH.

9. The method for remote stable upgrade of FPGA firmware according to claim 1, characterized in that, The communication interface is one of UART, Ethernet, CAN bus, Wi-Fi, 4G module, or 5G module.

10. A remote stable upgrade method for FPGA firmware according to claim 9, characterized in that, When the communication interface is a UART serial port, the communication interface parameters include baud rate, data bits, and stop bits.

Images