ZYNQ Chip Remote Firmware Update System and Method Based on RS485 Serial Port

Abstract

The present invention discloses a remote firmware update system and method for ZYNQ chips based on RS485 serial ports in the field of remote firmware update. The system includes a host computer, an RS485 communication line, multiple ZYNQ chips, and a parallel AB line. One end of the RS485 communication line is connected to the host computer, and the other end is connected in parallel to multiple ZYNQ chips through the parallel AB line, and is used for the host computer to send instructions to the multiple ZYNQ chips respectively through the RS485 communication protocol to update the firmware. The technical solution of the present invention is a remote firmware update solution based on RS485 as the transmission method. By constructing a communication protocol, hardware connection, and update process, a firmware update system is built to ensure that users can remotely update the firmware at the ZYNQ end. At the same time, RS485 supports the update method of one master and multiple slaves, so it is possible to update multiple ZYNQ chip products simultaneously.

Description

Technical Field

[0001] The present invention relates to the field of remote firmware update, and specifically to a remote firmware update system and method for ZYNQ chips based on RS485 serial ports. Background Art

[0002] With the promotion of the trend of intelligent automation, various types of ARM and MCU chips are widely used in various types of products. And with the increasingly diverse changes in requirements and functions, the firmware upgrade function of products is essential. Among them, high-performance chips represented by ZYNQ are widely used in products in the industrial automation field. There are many interferences on site, and the requirements for function expansion and modification are relatively high. Then the function of remotely updating the firmware must be available.

[0003] The initialization firmware of ZYNQ chips is generally burned through JTAG in cooperation with large-scale software such as VIVADO, which requires a computer with relatively high configuration. Therefore, in many scenarios, there are methods for updating firmware using network ports and ordinary RS232 serial ports. For example, in the patent "A Method and Device for Upgrading ZYNQ SOC Firmware and Its Process" (application number 201810238392.3), R232 is used for serial port driving, but the transmission distance is short, about 30 meters at most, the transmission rate is low, up to 20 kb / s at most, the common-mode ability is poor, and the anti-interference ability is weak. Therefore, RS232 is only suitable for communication between local devices, and in the complex industrial field with interference, signal interference is likely to cause unstable transmission and high risk of remote update. In addition, using the methods of JTAG and RS232, only one ZYNQ chip firmware (subsequently uniformly named as the ZYNQ side) can be updated at a time, and the efficiency is very low. There is also a scheme for remote update using network communication protocols, but network communication requires a dedicated network port to connect the computer and the main chip, and the hardware cost is relatively high. Therefore, the prior art lacks a high-efficiency remote firmware update scheme for multiple ZYNQ chips. Summary of the Invention

[0004] The purpose of the present invention is to overcome the problems existing in the prior art, and provide a remote firmware update system and method for ZYNQ chips based on RS485 serial ports. To achieve the above purpose, the present invention provides the following technical solutions:

[0005] The first aspect of the present invention provides a remote firmware update system for ZYNQ chips based on RS485 serial ports, including a host computer, an RS485 communication line, multiple ZYNQ chips, and a parallel AB line; one end of the RS485 communication line is connected to the host computer, and the other end is connected in parallel to multiple ZYNQ chips through the parallel AB line, and is used for the host computer to send instructions to the multiple ZYNQ chips respectively through the RS485 communication protocol to update the firmware.

[0006] Preferably, a differential conversion module and a serial port communication module are provided on the ZYNQ chip. The ZYNQ chip is connected to the differential conversion module through the serial port communication module. The differential conversion module is connected to the parallel AB line. The ZYNQ chip realizes the conversion of serial single-ended signals to RS485 differential signals through the differential conversion module.

[0007] Preferably, the serial port communication module includes EN, RX, and TX. EN is a signal for the ZYNQ chip to control the input and output direction of the differential conversion module. RX is the serial port input signal of the ZYNQ chip, and TX is the serial port output signal of the ZYNQ chip.

[0008] Preferably, when the ZYNQ chip receives a message, EN is set to the input mode, and when the ZYNQ chip sends a message, EN is set to the output mode.

[0009] Preferably, a USB interface is provided on the host computer and is connected to the RS485 communication line through the USB interface.

[0010] Preferably, the firmware program in the ZYNQ chip is stored in an external flash memory. The flash memory is divided into a basic data area, a boot program area, an APP1 area, and an APP2 area.

[0011] The boot program area is used to store the boot program;

[0012] The basic data area is used to store an update mode flag bit, and the update mode flag bit is used to control the state machine for program jump during the entire update process;

[0013] The APP1 area is used to store the firmware program;

[0014] The APP2 area is used to store the backup program of the firmware program.

[0015] The second aspect of the present invention provides a method for remotely updating the firmware of a ZYNQ chip based on an RS485 serial port, including the following steps:

[0016] S1. The host computer issues an update program jump instruction to multiple ZYNQ terminals respectively through the RS485 communication protocol. The instruction includes the slave address;

[0017] S2. Multiple ZYNQ terminals judge whether the instruction is sent to themselves according to the built-in slave address. If so, the corresponding ZYNQ terminal jumps to the boot program and enters the remote update preparation state, and starts the update process after the host computer issues an update instruction.

[0018] Preferably, the start of the update process includes:

[0019] S3. After receiving the update instruction sent by the host computer, the ZYNQ side returns the first message to the host computer, clears the flash and returns the second message, and enters the update state;

[0020] S4. After entering the update state, the host computer sends a data length message;

[0021] S5. After the ZYNQ side receives the data length N, it returns the third message and enters the data receiving state;

[0022] S6. The host computer sequentially sends the updated firmware data packets;

[0023] S7. After the ZYNQ side receives the data packet, it performs CRC verification. If there is an error, it returns an error message and waits for retransmission; if there is no error, it writes the data packet into the APP2 area of the flash, returns a message, and resumes to the data receiving state until the number of receptions is N, returns a message indicating that the reception is complete, and writes the updated firmware in the APP2 area into the APP1 area of the flash, and the update ends.

[0024] Preferably, both the instruction message sent by the host computer to the ZYNQ side and the message returned by the ZYNQ side include the slave address and multiple function codes, and the function codes are used to indicate the total length of the current data packet.

[0025] Preferably, after the ZYNQ side jumps to the boot program, it reads the update mode flag bit from the flash, and the flag bit includes the empty board mode, the waiting for update mode, the continuous update mode, the updating mode, and the update completed mode.

[0026] If the flag bit is the empty board mode, the update state is set to the remote update preparation state;

[0027] If the flag bit is the waiting for update mode, it automatically switches to the updating mode, and the update state is set to the update state to clear the flash;

[0028] If the flag bit is the continuous update mode, the update state is set to the copy state to implement writing the updated firmware in the APP2 area into the APP1 area of the flash. After the copy is completed, it automatically switches to the update completed mode, and the update ends;

[0029] If the flag bit is the updating mode, it is judged that there may be a problem with the updated firmware in the APP2 area, and it automatically switches to the update completed mode, and the update ends;

[0030] If the flag bit is the update completed mode, it jumps to start the program in the APP1 area.

[0031] Preferably, in step S4, the data length message sent by the host computer is specifically:

[0032] The host computer splits the firmware file of the program to be updated into N update firmware data packets and distributes them one by one. Two bytes of CRC check bits are added to each data packet. If the length of the Nth data packet is insufficient, it is padded. The ZYNQ side checks the CRC and returns a correct reception message or an error reception message;

[0033] If a correct reception message is returned, the next data packet is continued to be sent. If an error reception message is returned, the corresponding data packet is resent until all data is sent.

[0034] Beneficial effects: The firmware remote update solution based on RS485 as the transmission method in the present invention builds a firmware update system by constructing a communication protocol, hardware connection, and update process, ensuring that users can remotely update the firmware of the ZYNQ side. At the same time, RS485 supports the update method of one master and multiple slaves, so multiple ZYNQ chip products can be updated simultaneously. Description of the Drawings

[0035] Figure 1 It is a schematic structural diagram of the remote firmware update system of the present invention;

[0036] Figure 2 It is the update process of the ZYNQ side slave in the embodiment of the present invention;

[0037] Figure 3 It is the update flowchart including the update mode and the jump of the update status flag bit in the boot program of the embodiment of the present invention. Detailed Embodiments

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

[0039] The first aspect of the embodiment of the present invention provides a ZYNQ chip remote firmware update system based on the RS485 serial port, as Figure 1 shown, including a host computer, an RS485 communication line, multiple ZYNQ chips, and a parallel AB line; one end of the RS485 communication line is connected to the host computer, and the other end is connected in parallel to the multiple ZYNQ chips through the parallel AB line, and is used for the host computer to issue instructions to the multiple ZYNQ chips respectively through the RS485 communication protocol to update the firmware.

[0040] Compared with the RS232 serial port, RS485 can make up for the deficiencies of RS232 such as short communication distance and low transmission rate. RS485 uses differential transmission mode, also called balanced transmission, which has high noise suppression ability. The maximum transmission distance is about 1200 meters, and the maximum transmission rate is 10 Mb / s. It has added two-way communication ability and is widely used in industrial fields. Adopting the RS485 communication protocol can realize the remote update of chips such as ZYNQ in industrial fields, and differential signals can ensure the update stability. And the RS485 interface can support the hardware connection of one master and multiple slaves, that is, multiple ZYNQ slave devices can be connected through RS485. Through the hardware communication protocol, it is possible to support a host computer to update the firmware of multiple slaves at the same time.

[0041] Further, a differential conversion module and a serial port communication module are provided on the ZYNQ chip. The ZYNQ chip is connected to the differential conversion module through the serial port communication module. The differential conversion module is connected to the parallel AB line. The ZYNQ chip realizes the conversion of serial single-ended signals to RS485 differential signals through the differential conversion module.

[0042] Further, the serial port communication module includes EN, RX, and TX. EN is the signal for the ZYNQ chip to control the input and output direction of the differential conversion module. RX is the serial port input signal of the ZYNQ chip, and TX is the serial port output signal of the ZYNQ chip. When the ZYNQ chip receives a message, EN is set to the input mode, and when the ZYNQ chip sends a message, EN is set to the output mode.

[0043] Further, as shown in Table 1, the firmware program in the ZYNQ chip is stored in an external flash memory. The flash memory is divided into a basic data area, a boot program area, an APP1 area, and an APP2 area.

[0044] The boot program area is used to store the boot program.

[0045] The basic data area is used to store the update mode flag bit, and the update mode flag bit is used to control the state machine for program jump during the entire update process.

[0046] The APP1 area is used to store the firmware program.

[0047] The APP2 area is used to store the backup program of the firmware program.

[0048] Table 1 Flash storage space partition and description

[0049]

[0050] The host computer is generally a PC or a common industrial control computer, and the host computer software is installed on it. The host computer is equipped with a USB port, and is connected to the differential conversion module at the ZYNQ end through a USB to RS485 communication line and a parallel AB line. The multiple ZYNQ ends are the actual program running ends. Hardware-wise, they include a serial communication module, which is connected to the differential conversion module through EN, RX, and TX. Through the differential conversion module, the serial single-ended signal is converted into an RS485 differential signal. Among them, EN is the signal for the ZYNQ end to control the input and output direction of the differential conversion module; for the ZYNQ end, RX is the serial input signal. When the ZYQN end receives a message, EN needs to be set to the input mode. The differential conversion module converts the differential signal in the parallel AB line sent by the host computer into the signal of RX for the ZYNQ to read and parse; for the ZYNQ end, TX is the serial output signal. When the ZYNQ end sends a message, EN needs to be set to the output mode. The signal is transmitted to the differential conversion module through TX, and after being converted into a differential signal, it is returned to the host computer through the parallel AB line and the USB to RS485 communication line.

[0051] Basic settings: The host computer software is installed on a computer or an industrial control computer; it is connected to the differential conversion module of the multiple ZYNQ ends through a USB to R485 communication line and a parallel AB line, and the update process is carried out according to the remote update protocol. The host computer issues an instruction with a slave address. The multiple ZYNQ ends judge whether the instruction is sent to themselves according to the built-in slave serial number. If so, the instruction is parsed, otherwise, no response is required. The instruction settings include the slave (ZYNQ end) address, function code, data, and CRC check code. Similar to the modbus protocol, two bytes of CRC check code are added according to the instruction.

[0052] Based on the above system, the second aspect of the embodiment of the present invention provides a method for remotely updating the firmware of a ZYNQ chip based on an RS485 serial port, as Figure 2 shown, including the following steps:

[0053] S1. The host computer issues an update program jump instruction to multiple slave ZYNQ ends respectively through the RS485 communication protocol, and the instruction includes the slave address;

[0054] S2. The multiple ZYNQ ends judge whether the instruction is sent to themselves according to the built-in slave address. If so, the corresponding ZYNQ end jumps to the boot program and enters the remote update preparation state. After the host computer issues an update instruction, the update process is started.

[0055] S3. After receiving the update instruction sent by the host computer, the ZYNQ end returns the first message to the host computer, clears the flash and returns the second message, and enters the update state.

[0056] S4. After entering the update state, the host computer issues a data length message;

[0057] Specifically, the host computer splits the firmware file of the program to be updated into N update firmware data packets and distributes them one by one. Two bytes of CRC check bits are added to each data packet. If the length of the Nth data packet is insufficient, it is padded. The ZYNQ side checks the CRC and returns a correct reception message or an error reception message;

[0058] If a correct reception message is returned, the next data packet is continued to be distributed. If an error reception message is returned, the corresponding data packet is re - distributed until all data is distributed.

[0059] S5. After the ZYNQ side receives the data length N, it returns the third message and enters the data reception state.

[0060] S6. The host computer distributes the update firmware data packets in sequence.

[0061] S7. After the ZYNQ side receives the data packet, it performs CRC check. If there is an error, it returns an error message and waits for re - transmission; if there is no error, it writes the data packet into the APP2 area of the flash, returns a message, and resumes to the data reception state until the reception count is N. Then it returns a reception complete message and writes the updated firmware in the APP2 area into the APP1 area of the flash, and automatically jumps to run the program in the APP1 area, and the update ends.

[0062] The firmware upgrade of the host computer and the ZYNQ side is flow - controlled through a remote update protocol, such as entering the sending of a remote update request; firmware frame transmission, etc. Exemplarily, the steps of the remote update protocol between the host computer and the slave ZYNQ side are as follows:

[0063] Step 1. Using the SDK of the ZYNQ integrated development environment Vivado, pack the boot program containing the RS485 communication protocol, slave address setting, and flash firmware burning together with the built - in FSBL to generate a boot.bin firmware file. And burn it into the flash memory of the ZYNQ, where the offset A1 in the flash memory needs to be set. At this time, restarting the power of the ZYNQ chip enters the boot program;

[0064] Step 2. Using the SDK of the ZYNQ integrated development environment Vivado, pack the APP1 containing the PS and PL - side running code programs actually required by the user together with the built - in FSBL and.bit to generate an APP1.bin firmware file;

[0065] Step 3. The host computer issues a remote update instruction for a certain slave. After the boot program running on the ZYNQ side corresponding to the slave number receives the instruction, it clears the flash memory and returns a message. At this time, it enters the update stage;

[0066] Step 4: After the host computer receives the return instruction in Step 3, it issues the APP1.bin file with a memory of M kb, and issues an instruction with a total number N of splits according to a single data packet length of K kb (N = Round(M / K), Round means rounding up). After the boot program running on the ZYNQ side receives the number of instructions N, it returns and confirms. At this time, it enters the receiving message preparation stage;

[0067] Step 5: After the host computer receives the return instruction in Step 4, it splits the data of the APP1.bin file into N updated firmware data packets. When the Nth packet is less than the length of K kb, the insufficient part is filled with 0xFF to the length of K kb, and two bytes of CRC check bits are added. The data sent each time is K * 1024 + 2 bytes to the ZYNQ side. If the CRC is correct after the ZYNQ side receives it, it returns a correct reception message; otherwise, it returns a CRC reception error message;

[0068] Step 6: After the host computer receives the return instruction in Step 5, if the reception is correct, it continues to issue the next piece of data. If the CRC reception is incorrect, it retransmits the just-issued data until all the data is issued. Then the ZYNQ returns a reception complete message, and writes the received APP1.bin to the address with a flash memory offset of A2. After the writing is completed, it jumps to the APP1 program on the ZYNQ side to run.

[0069] If, in the APP1 program, an update request issued by the host computer is received, the APP1 program jumps to Step 3 through the software reset method of the ZYNQ. Thus, the remote update ends.

[0070] Taking the zynq-7000 series as an example, the process of remotely updating the firmware of the ZYNQ chip based on the RS485 serial port supports NAND flash, parallel NOR flash, Serial NOR (Quad-SPI), SD flash, and JTAG as startup devices. Usually, the flash is used as the carrier of the program firmware for startup during remote update. Therefore, a write operation needs to be performed on the flash memory during firmware update. When the program starts, it detects whether there is program firmware in the flash and enters the main program to run. The remote update solution ensures that there are a boot program and the actual running program APP1 stored in the flash. The role of the boot program is for remote update, and APP1 is the program actually used by the user (the program that needs to be remotely updated). And the APP1 program needs to contain an entry to jump into the boot program. APP2 is used for backing up and buffering the program firmware in the embedded update solution to avoid abnormal situations such as power failure during the update that may cause the program to fail to start.

[0071] To ensure the security of remote updates to the ZYNQ embedded device, a boot program update process and state machine are designed. Specifically, the update mode state machine is controlled by the update_mode flag, and the update_state of the actual update process is controlled. The specific design is as follows:

[0072] The designed boot program includes the update process and state machine required for firmware update. Among them, the state machine that controls the program jump during the entire update process is controlled by the update mode flag update_mode, and the update state flag update_state is used to control the jump process of updating a single update firmware data packet. After the ZYNQ device jumps to the boot program, it reads the update mode flag from the flash. The flag includes the empty board mode, waiting for update mode, continuous update mode, updating mode, and update completed mode.

[0073] If the flag is the empty board mode, the update state is set to the remote update preparation state;

[0074] If the flag is the waiting for update mode, it automatically switches to the updating mode, and the update state is set to the update state to clear the flash;

[0075] If the flag is the continuous update mode, the update state is set to the copy state to implement writing the update firmware in the APP2 area to the APP1 area of the flash. After the copy is completed, it automatically switches to the update completed mode and the update ends;

[0076] If the flag is the updating mode and it is determined that there may be a problem with the update firmware in the APP2 area, it automatically switches to the update completed mode and the update ends;

[0077] If the flag is the update completed mode, it jumps to start the program in the APP1 area.

[0078] Exemplarily, as Figure 3 shown, when powering on, it first enters the boot program. The boot program reads the update state flag update_mode corresponding to the update mode in the corresponding area of the flash:

[0079] 1) If the update_mode at power-on is the empty board mode (in this mode, there is no program in both APP1 and APP2), the update state update_state is set to the waiting for update state, and then it waits for the upper computer to communicate with the embedded device for update interaction. At this time, power-off does not affect the update_mode still being the empty board mode.

[0080] 2) If the update_mode of the powered-on embedded device is the waiting-for-update mode, it will be further automatically switched to the updating mode. At this time, the update state update_state is set to the waiting-for-update state, waiting to clear the data in the APP2 area.

[0081] 3) After the process enters the waiting-for-update state of update_state and receives the start-update instruction from the host computer, update_state is further updated to the updating state. At the same time, the host computer will send a data frame containing the total number of frames N. After the chip receives it, it clears the stored data in the corresponding APP2 area. Then update_state is updated to the receiving-data state and starts receiving data.

[0082] 4) When update_state receives a complete frame in the receiving-data state, it performs CRC check and other frame judgments to determine if it is correct. If it is correct, it enters the parsing and splitting of the frame, and update_state is in the parsing state; otherwise, it sends a retransmission request to the host computer, and update_state remains in the receiving-data state.

[0083] 5) After update_state is in the parsing state, it performs frame processing, increments the frame count, and determines if the current frame number is equal to the total number N. If not, update_state returns to the receiving-data state to receive the next frame; if so, the parsing is completed, the firmware is written to the APP2 area, and update_mode is updated to the continuous-update mode.

[0084] 6) In the continuous-update mode, update_state is set to the COPY state. At this time, it continues to clear the data in the A1 area of APP1, and copies the program of APP2 to APP1 until it is completed. Then update_mode is switched to the complete-update mode, and the firmware update is completed.

[0085] 7) If the update process is skipped during power-on and directly enters the un-updated APP1, it can avoid spoiling the entire process with the wrong firmware. If it still needs to be updated, just restart the update process.

[0086] 8) If update_mode is the complete-update mode, it means that the previous update process has ended. Then the update state update_state is set to FINISH, and it jumps to the APP1 startup program.

[0087] 9) If the update_mode is the continuous update mode, it indicates that the power was lost during the last update process when migrating the firmware of APP2 to APP1. Then set the update_state to the COPY state and continue to execute step 6). At this time, continue to clear the data in area A1 of APP1, copy the program of APP2 to APP1 until completion, and then switch to the complete update mode to complete the firmware update. This avoids the situation where the update cannot be performed when APP1 is damaged.

[0088] Both the instruction message sent by the host computer to the ZYNQ side and the message returned by the ZYNQ side contain the slave address and multiple function codes. The function codes are used to indicate the total length of the current data packet. The key to implementing the remote firmware update method for embedded multiple slaves based on the RS485 bus lies in the design and management of the multi-slave frame. Its characteristic is that the design of the slave address and function codes is added to the traditional serial port instruction. When a specific slave needs to be updated, it checks whether the slave address in the transmission frame of the host computer corresponds to itself. If it corresponds, the update process is started. Then, multiple slaves can distinguish update instructions that are not related to themselves, and thus realize the independent APP update of each slave. Generally, a slave supports up to 64 slaves. Function codes A / B are reserved functions and can be used to indicate the total length of the data in the current frame, so as to accurately receive the data length of the frame.

[0089] In summary, the technical solution of the present invention is a firmware remote update solution based on RS485 as the transmission method. By constructing a communication protocol, hardware connection, and update process, a firmware update system is built, ensuring that users can remotely update the firmware of the ZYNQ side. It overcomes the problems of poor common-mode ability and weak anti-interference ability caused by using R232 for serial port driving in the traditional way, and effectively improves the anti-interference ability and stability of the system. At the same time, RS485 supports the update method of one master and multiple slaves, so it is possible to update multiple ZYNQ chip products simultaneously, improving the transmission rate and remote update efficiency. Based on the RS485 transmission protocol, it replaces the solution of using a network communication protocol for remote update, effectively reducing the hardware cost. The update logic designed in the present invention based on the boot program is controlled by two parameters, namely the update mode flag bit and the update state flag bit, of the corresponding state machine, ensuring the sequential execution of the update logic and avoiding the situation where the system cannot be restarted due to power loss during any update process, effectively improving the stability and robustness of the system update process.

[0090] Although this specification is described according to the embodiments, not every embodiment only contains an independent technical solution. This narrative way of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

[0091] Therefore, the above description is only a preferred embodiment of the present application and is not used to limit the scope of implementation of the present application; that is, all equivalent transformations made according to the scope of the claims of the present application are within the protection scope of the claims of the present application.

Claims

1. A ZYNQ chip remote firmware update system based on the RS485 serial port, characterized in that, It includes a host computer, an RS485 communication line, multiple ZYNQ chips, and a parallel AB line; one end of the RS485 communication line is connected to the host computer, and the other end is connected in parallel to the multiple ZYNQ chips through the parallel AB line, and is used for the host computer to issue instructions to the multiple ZYNQ chips respectively through the RS485 communication protocol to update the firmware; the firmware program in the ZYNQ chip is stored in an externally attached flash memory, and the flash memory is divided into a basic data area, a boot program area, an APP1 area, and an APP2 area. The boot program area is used to store the boot program. The APP1 area is used to store the firmware program. The APP2 area is used to store the backup program of the firmware program. The basic data area is used to store an update mode flag bit, and the update mode flag bit is used to control the state machine for program jump during the entire update process; the boot program contains the update process and state machine required for firmware update, where the state machine for program jump during the entire update process is controlled by the update mode flag bit, and the update status flag bit is used to control the jump process for updating a single firmware data packet; when power is on, it first enters the boot program, and the boot program reads the update status flag bit corresponding to the update mode in the corresponding area of the flash: If the update mode flag bit at power-on is the blank board mode and there is no program in both the APP1 area and the APP2 area, then set the update status flag bit to the waiting update status, and then wait for communication interaction between the host computer and the ZYNQ side for update. If the update mode flag bit of the ZYNQ side at power-on is the waiting update mode, it will be further automatically switched to the updating mode. At this time, set the update status flag bit to the waiting update status and wait to clear the data in the APP2 area; after the process enters the waiting update status of the update status flag bit, after receiving the start update instruction from the host computer, the update status flag bit is further updated to the update status. At the same time, the host computer will send a data frame containing the total number of frames N. After the ZYNQ side receives it, it clears the stored data in the corresponding APP2 area, and then the update status flag bit is updated to the receiving data status and starts to receive data; when the update status flag bit receives a complete frame in the receiving data status, it will perform CRC check and other frame judgments to determine whether it is correct. If it is correct, it will enter the parsing and splitting of this frame, and the update status flag bit is in the parsing state. Otherwise, it will send a retransmission requirement to the host computer, and the update status flag bit will remain in the receiving data status. After the update status flag bit is in the parsing state, frame processing is performed, the frame count is incremented by 1, and it is judged whether the current frame number is equal to the total number N. If not, the update status flag bit returns to the receiving data status to receive the next frame; if so, the parsing is completed, the firmware is written into the APP2 area, and the update mode flag bit is updated to the continuous update mode. In the continuous update mode, set the update status flag to the COPY status. At this time, continue to clear the data in the APP1 area, copy the program of APP2 to the APP1 area until completion, then the update mode flag switches to the completed update mode, and the firmware update is completed. If the power-on skips the update process and directly enters the unupdated APP1 area to prevent the wrong firmware from damaging the entire process, if an update is still required, just restart the update process. If the update mode flag is in the completed update mode, jump to the APP1 startup program. If the update mode flag is in the continuous update mode, set the update status flag to the COPY status, and continue to execute the steps in the continuous update mode. At this time, continue to clear the data in the APP1 area, copy the program of APP2 to the APP1 area until completion, then switch to the completed update mode, and the firmware update is completed.

2. The system according to claim 1, characterized in that The ZYNQ chip is provided with a differential conversion module and a serial communication module. The ZYNQ chip is connected to the differential conversion module through the serial communication module. The differential conversion module is connected to the parallel AB line. The ZYNQ chip realizes the conversion of the serial single-ended signal to the RS485 differential signal through the differential conversion module.

3. The system according to claim 2, wherein The serial communication module includes EN, RX, and TX. EN is the signal for the ZYNQ chip to control the input and output direction of the differential conversion module. RX is the serial input signal of the ZYNQ chip, and TX is the serial output signal of the ZYNQ chip. When the ZYNQ chip receives a message, set EN to the input mode. When the ZYNQ chip sends a message, set EN to the output mode.

4. The system according to any one of claims 1-3, characterized in that, The host computer is provided with a USB interface and is connected to the RS485 communication line through the USB interface.

5. A method for remotely updating the firmware of a ZYNQ chip based on the RS485 serial port, characterized in that, The method realizes a ZYNQ chip remote firmware update system based on the RS485 serial port as described in any one of claims 1-4, and includes the following steps: S1. The host computer sends an update program jump instruction to multiple ZYNQ terminals respectively through the RS485 communication protocol. The instruction includes the slave address. S2. Multiple ZYNQ terminals judge whether the instruction is sent to themselves according to the built-in slave address. If so, the corresponding ZYNQ terminal jumps to the boot program and enters the remote update preparation state, and starts the update process after the host computer sends the update instruction.

6. The method according to claim 5, wherein The start of the update process includes: S3. After receiving the update instruction sent by the host computer, the ZYNQ terminal returns the first message to the host computer, clears the flash and returns the second message, and enters the update state. S4. After entering the update state, the host computer sends a data length message. S5. After the ZYNQ terminal receives the data length N, it returns the third message and enters the data receiving state. S6. The host computer sequentially sends the firmware update data packets. After the ZYNQ side receives the data packet, it performs CRC check. If there is an error, it returns an error message and waits for retransmission; if there is no error, it writes the data packet into the APP2 area of the flash, returns a message, and resumes to the receiving data state until the number of receptions is N. Then it returns a message indicating that the reception is complete, and writes the updated firmware in the APP2 area into the APP1 area of the flash to complete the update.

7. The method according to claim 6, characterized in that, Both the instruction message sent by the host computer to the ZYNQ side and the message returned by the ZYNQ side contain the slave address and multiple function codes. The function codes are used to indicate the total length of the current data packet.

8. The method according to claim 6 or 7, characterized in that After the ZYNQ side jumps to the boot program, it reads the update mode flag bit from the flash. The flag bits include the blank board mode, the waiting for update mode, the continuous update mode, the updating mode, and the update completed mode. If the flag bit is the blank board mode, the update status is set to the remote update preparation status. If the flag bit is the waiting for update mode, it automatically switches to the updating mode, and sets the update status to the update status to clear the flash. If the flag bit is the continuous update mode, the update status is set to the copy status to implement writing the updated firmware in the APP2 area into the APP1 area of the flash. After the copy is completed, it automatically switches to the update completed mode to end the update. If the flag bit is the updating mode and it is determined that there may be a problem with the updated firmware in the APP2 area, it automatically switches to the update completed mode to end the update. If the flag bit is the update completed mode, it jumps to start the program in the APP1 area.

9. The method according to claim 8, wherein In step S4, the data length message sent by the host computer is specifically as follows: The host computer splits the firmware file of the program to be updated into N update firmware data packets and sends them one by one. Two bytes of CRC check bits are added to each data packet. If the length of the Nth data packet is insufficient, it is padded. The ZYNQ side checks the CRC and returns a correct reception message or an error reception message. If a correct reception message is returned, the next data packet is continued to be sent. If an error reception message is returned, the corresponding data packet is resent until all data is sent.

Images