TCP protocol-based zynq bare core fast and stable upgrade method
By adopting a TCP-based ZYNQ bare core upgrade method, combined with data verification and the underlying API functions of the QSPI FLASH chip, the problems of slow upgrade speed and low reliability of ZYNQ bare core are solved, and fast and reliable multi-batch upgrades are achieved.
Patent Information
- Application Number
- CN202510099975.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-22
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2045-01-22
AI Technical Summary
Existing ZYNQ bare core upgrade methods suffer from slow upgrade speed, unreliable transmission, and complex operation, making it difficult to achieve fast and stable upgrades, especially in large-scale upgrade scenarios.
The upgrade method adopts a TCP protocol-based approach, which transmits the BIN file through the network port and performs data verification on the PS end. It combines the underlying API functions of the QSPI FLASH chip to perform upgrade operations, including data verification, erasure, programming, and readback, ensuring the reliability and speed of the upgrade process.
It achieves a 12.5-fold increase in ZYNQ bare core upgrade speed, reducing upgrade time from 5 minutes to 24 seconds, and ensures the reliability and stability of the upgrade through dual verification, making it suitable for multi-batch upgrade scenarios.
Smart Images

Figure CN120104168B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the technical field of communication, and particularly relates to a ZYNQ bare core fast and stable upgrading method based on a TCP protocol. BACKGROUND
[0002] ZYNQ is a new generation of all-programmable system on chip launched by Xilinx, which combines a dual-core ARM Cortex-A9 processor (PS) and a traditional field programmable gate array logic component (PL), and provides unparalleled system performance, flexibility and scalability, and has been widely used in the fields of communication, aerospace, etc. Meanwhile, in order to iteratively upgrade the software in time to meet the user demand, the ZYNQ bare core program needs to be updated from time to time. In the case that the product may be widely arranged and the upgrading workload is large, the development of the ZYNQ bare core fast and stable upgrading method becomes the key to the batch application of the ZYNQ chip.
[0003] At present, for the software upgrading of the ZYNQ chip bare core, there are mainly the traditional upgrading using a JTAG emulator, serial port remote upgrading, UDP network protocol remote upgrading, etc. With the miniaturization trend of the equipment, the JTAG external interface is often not reserved for upgrading; the serial port upgrading has a slow transmission speed and a long time consumption; the UDP network protocol upgrading has a risk of packet loss, and the upgrading file needs to be transmitted for many times, so it becomes a difficult problem to realize the fast and stable upgrading of the ZYNQ chip bare core. SUMMARY
[0004] The application proposes a ZYNQ bare core fast and stable upgrading method based on a TCP protocol, which does not depend on the traditional use of the emulator, and the BIN file to be upgraded is quickly sent to the PS of the ZYNQ bare core through a network port by using the TCP protocol. The PS verifies the received data area, and after success, the ZYNQ bare core bottom API function is called to operate the QSPIFLASH chip to upgrade the program. The upgrading process of the ZYNQ bare core is simple, flexible, fast, reliable and stable, and can cope with the multi-batch ZYNQ bare core upgrading scene.
[0005] The technical solution for realizing the application is as follows: a ZYNQ bare core fast and stable upgrading method based on a TCP protocol, and the steps are as follows:
[0006] Step 1: The user interface reads the BIN file to be upgraded, converts it into binary data, calculates the 1-byte cumulative sum check value, appends the 4-byte data length and the 1-byte cumulative sum check value after the binary data, and transmits the binary data to the PS end of the ZYNQ bare core through the network.
[0007] Step 2, the binary data sent by the user interface is received at the ZYNQ bare core PS end, the binary data area is saved in the PS end cache area, the checksum and data length attached to the end of the message are intercepted, the PS end carries out accumulation and calculation on the binary data area, the received data length is compared with the data length in the intercepted message, and the calculated checksum is compared with the checksum in the intercepted message, and the comparison result is returned to the user interface after the comparison is completed.
[0008] Step 3, according to the binary data length, the memory area of the corresponding QSPI FLASH chip is erased, the ZYNQ bare core bottom API function XQspiPs_PolledTransfer is called, the erase instruction has two kinds of BULK_ERASE_CMD and SEC_ERASE_CMD, and the erase result and the required time are reported to the user interface through the UDP protocol after erasing.
[0009] Step 4, according to the binary data length, the memory area of the corresponding QSPI FLASH chip is programmed, the ZYNQ bare core bottom API function XQspiPs_PolledTransfer is called, the programming instruction is WRITE_CMD, and programming is carried out page by page, N pages are calculated according to the data length, and each page is different according to the QSPI FLASH model, the programming result and the required time are reported to the user interface through the UDP protocol after programming.
[0010] Step 5, after the file programming of step 4 is successfully completed at the ZYNQ bare core PS end, the ZYNQ bare core bottom API function XQspiPs_PolledTransfer is called, the read-back instruction is READ_CMD, and the binary file in the receiving cache area is compared, the binary file burned in is consistent with the binary file read back, and it is considered that the program is burned in; the read-back comparison result and the required time are reported to the user interface through the UDP protocol after read-back.
[0011] Step 6, after the read-back comparison of step 5 is successfully completed at the ZYNQ bare core PS end, the system software is reset, the ZYNQ chip is restarted, the ZYNQ chip loads the new program solidified into the QSPI FLASH chip, and the software version number of the new program solidified is returned to the user interface after loading, indicating that the upgrade is successful.
[0012] Compared with the prior art, the present application has the following advantages:
[0013] (1) The ZYNQ bare core software upgrade speed is fast, from the beginning of data transmission to the completion of programming, it takes about 24 seconds, which is 12.5 times faster than the traditional JTAG programming time of 5 minutes.
[0014] (2) Reliability is strong, stability is high, the scheme process contains two steps of checking, the first step is the checking after data transmission, the second step is the checking of reading back after data upgrading, only when the two checks are successful, it is considered that the upgrading is completed, otherwise, the upgrading is performed again.
[0015] (3) The operation is simple, and the flexibility is strong, and the multi-batch ZYNQ bare core upgrading scene is coped with. BRIEF DESCRIPTION OF DRAWINGS
[0016] Figure 1 It is a TCP data transmission flow chart.
[0017] Figure 2 It is a binary file receiving processing flow chart.
[0018] Figure 3 It is a ZYNQ bare core erasing flow chart.
[0019] Figure 4 It is a ZYNQ bare core programming flow chart.
[0020] Figure 5 It is a whole framework diagram. DETAILED DESCRIPTION
[0021] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.
[0022] The specific embodiments, technical difficulties and points of the present application will be further introduced below in combination with the design examples.
[0023] In combination with Figures 1-5 , the ZYNQ bare core fast and stable upgrading method based on the TCP protocol has the following steps:
[0024] Step 1, in combination with Figure 1 , the user interface reads the BIN file to be upgraded, converts the BIN file into binary data, calculates the 1-byte cumulative sum check value, appends the 4-byte data length and the 1-byte cumulative sum check value to the binary data, and transmits the binary data to the PS end of the ZYNQ bare core through the network. The ZYNQ bare core PS end adopts the TCP protocol to interact with the user interface, so that the communication is fast, and the reliability of data transmission is also guaranteed. The ZYNQ bare core program automatically configures the TCP under the LWIP protocol stack after power-on, sets appropriate parameters to make the TCP receiving of the ZYNQ bare core reach the optimal performance, and the setting is as shown in the following table.
[0025] Table 1 ZYNQ bare core under Lwip protocol stack TCP receive optimal parameter configuration table
[0026]
[0027]
[0028] Bind IP and port number, wait for the user interface to send remote upgrade file. The technical difficulty of this step is how to configure the ZYNQ bare core to make the TCP receive optimal, and the dependence on the network shortens the transmission time of the upgrade file transmission to the ZYNQ bare core, the length and cumulative checksum of the additional upgrade file, and increases the robustness and reliability of the file transmission.
[0029] Step 2, combination Figure 2 After receiving the binary data (BIN file) sent by the user interface in step 1 at the PS end of the ZYNQ bare core, save the binary data area into the PS end cache area, intercept the checksum (1 byte) and data length (4 bytes) attached at the end of the message, and at the same time, the PS end calculates the checksum of the binary data area, compares the received data length with the data length in the intercepted message, and at the same time, compares the calculated checksum with the checksum in the intercepted message. After the comparison is completed, the comparison result is returned to the user interface; if the user interface displays that the comparison result is incorrect, repeat step 1 to send a new upgrade file again. The significance of this step is to ensure the consistency of the data sent by the user interface and received by the PS end. If there is a checksum failure, multiple transmissions can be repeated to prevent irreversible program upgrade operations.
[0030] Step 3, combination Figure 3 According to the binary data length (BIN file size), erase the memory area of the corresponding QSPI FLASH chip, call the ZYNQ bare core bottom API function XQspiPs_PolledTransfer, and the erase instruction has two types, BULK_ERASE_CMD (sector one-time full erase) and SEC_ERASE_CMD (erase by sector). When the binary data length is an integer multiple of the chip sector, it is directly erased according to the instruction BULK_ERASE_CMD, and if the data length is not an integer multiple of the chip sector, it is erased by sector according to the instruction SEC_ERASE_CMD. After erasing, report the erasing result and the required time to the user interface through the UDP protocol. The significance of this step is that the FLASH chip needs to be erased before being written according to the rules, and the number of FLASH sectors to be erased is calculated according to the data length, preventing multiple erasing and missing erasing operations.
[0031] Step 4, combination Figure 4, according to the binary data length (BIN file size) burn corresponding QSPI FLASH chip memory area, call ZYNQ bare core bottom API function XQspiPs_PolledTransfer, burn instruction is WRITE_CMD, burn by Page (each Page is 512 bytes), according to the data length calculation need to burn N Page (N = data length / 512, can't be divided by 1 up +1 integral), each Page according to QSPI FLASH model different Page byte also different, burn after through the UDP protocol to the user interface report burn result and the time required.
[0032] Step 5, after the ZYNQ bare core PS end successfully completes the file burning of step 4, call ZYNQ bare core bottom API function XQspiPs_PolledTransfer, read back instruction is READ_CMD, and compare with the binary file in the receiving buffer, the binary file burned in and the binary file read back are consistent, which is considered that the program burning is completed. After reading back, report the read back comparison result and the time required to the user interface through the UDP protocol.
[0033] Step 6, after the ZYNQ bare core PS end successfully completes the read back comparison of step 5, use system software reset, restart ZYNQ chip, ZYNQ chip loads the new solidified program from QSPI FLASH chip, after loading, return the new solidified software version number to the user interface, indicating that the upgrade is successful.
Claims
1. A ZYNQ bare core fast and stable upgrade method based on TCP protocol, characterized in that, The steps are as follows: Step 1: The user interface reads the BIN file that needs to be upgraded, converts it into binary data, calculates the 1-byte cumulative checksum, appends the 4-byte data length and the 1-byte cumulative checksum to the binary data, and transmits the binary data to the PS end of the ZYNQ bare core through the network; Step 2: The PS end of the ZYNQ bare core receives the binary data sent by the user interface, saves the binary data area into the PS end cache area, intercepts the checksum and data length appended at the end of the message, and calculates the cumulative checksum of the binary data area. The received data length is compared with the data length in the intercepted message, and the calculated checksum is compared with the checksum in the intercepted message. After the comparison is completed, the comparison result is returned to the user interface; Step 3: According to the binary data length, erase the memory area of the corresponding QSPIFLASH chip, call the ZYNQ bare core bottom layer API function XQspiPs_PolledTransfer, the erase instruction has two types of BULK_ERASE_CMD and SEC_ERASE_CMD, and after erasing, report the erasing result and the required time to the user interface through the UDP protocol; Step 4: According to the binary data length, write the memory area of the corresponding QSPIFLASH chip, call the ZYNQ bare core bottom layer API function XQspiPs_PolledTransfer, the write instruction is WRITE_CMD, and the write is performed page by page. According to the data length, N pages need to be written. Each page has different page bytes according to the QSPI FLASH model. After writing, the writing result and the required time are reported to the user interface through the UDP protocol; Step 5: After successfully completing the file writing of step 4 in the PS end of the ZYNQ bare core, call the ZYNQ bare core bottom layer API function XQspiPs_PolledTransfer, the read instruction is READ_CMD, and the binary file in the receiving cache area is compared. The binary file written in is consistent with the binary file read out, and it is considered that the program writing is completed. After reading, the read comparison result and the required time are reported to the user interface through the UDP protocol; Step 6: After successfully completing the read comparison of step 5 in the PS end of the ZYNQ bare core, the system software is reset, the ZYNQ chip is restarted, the ZYNQ chip loads the new solidified program from the QSPI FLASH chip, and after loading is completed, the new solidified software version number is returned to the user interface, indicating that the upgrade is successful.
2. The TCP protocol-based ZYNQ bare core fast stable upgrade method according to claim 1, characterized in that, In step 1, the user interface reads the BIN file that needs to be upgraded, converts it into binary data, calculates the 1-byte cumulative checksum, appends the 4-byte data length and the 1-byte cumulative checksum to the binary data, and transmits the binary data to the PS end of the ZYNQ bare core through the network, as follows: The ZYNQ bare core PS end adopts the TCP protocol to interact with the user interface, the ZYNQ bare core program is powered on to automatically configure the TCP under the LWIP protocol stack, and the parameters are set to make the TCP reception of the ZYNQ bare core reach the optimal performance; Bind the IP and the port number, and wait for the user interface to send the remote upgrade file.
3. The TCP protocol-based ZYNQ bare core fast stable upgrade method according to claim 1, characterized in that, In step 2, the calculated check sum is compared with the check sum in the intercepted message, and the comparison result is returned to the user interface after the comparison is completed, and the specific steps are as follows: if the user interface shows that the comparison result is incorrect, step 1 is repeated to send a new upgrade file again.
4. The TCP protocol-based ZYNQ bare core fast stable upgrade method according to claim 1, characterized in that, In step 3, when the binary data length is an integer multiple of the chip sector, it is directly erased once according to the instruction BULK_ERASE_CMD, and if the data length is not an integer multiple of the chip sector, it is erased according to the instruction SEC_ERASE_CMD.
5. The TCP protocol-based ZYNQ bare core fast stable upgrade method according to claim 1, characterized in that, In step 4, N = data length / 512, and the remainder is rounded up to 1.
Citation Information
Patent Citations
Remote firmware upgrading method based on FPGA
CN113867771A
FPGA (Field Programmable Gate Array) online upgrading method
CN115408035A