A software upgrading method and system based on FMQL

Abstract

This invention relates to the field of equipment upgrade technology, and discloses a software upgrade method and system based on FMQL. The method, applied to a first device integrating an FMQL chip, includes: powering on and running a firmware program to initialize the basic configuration parameters of the first device and loading an FSBL program; initializing the PS terminal based on the FSBL program and opening the communication port of the PS terminal, wherein the communication parameters of the communication port are pre-set in a second device, and the communication parameters of the target port corresponding to the access port on the second device are pre-set in the first device; controlling the first device to establish a communication connection with the second device through the communication port based on the FSBL program; receiving an upgrade file issued by the second device and using the upgrade file to update the target software of the FMQL chip. This invention achieves efficient online upgrades of FMQL chip software, effectively solving the problems of cumbersome operation and high dependence on hardware interfaces in traditional upgrade methods.

Description

Technical Field

[0001] This invention relates to the field of equipment upgrade technology, and specifically to a software upgrade method and system based on FMQL. Background Technology

[0002] The FMQL series of embedded microprocessors are domestically produced fully programmable PSoC chips. Each chip integrates several ARM cores as the Processing System (PS) and Programmable Logic (PL) components, fully leveraging the advantages of both ARM and FPGA (Field Programmable Gate Array). They have broad application prospects in aerospace, military equipment, and other fields. The maintenance and upgrading of FMQL software has gradually become a research hotspot in engineering applications. Typically, a JTAG interface is not provided for software upgrades when the product is delivered. When upgrading the PS and PL components, the emulator cable is usually plugged into the JTAG interface of the FMQL motherboard for debugging and program loading. This is because updating the FMQL software requires opening the product cover to connect the emulator to the JTAG interface, which significantly reduces product maintainability, upgrade efficiency, and reliability. Summary of the Invention

[0003] This invention provides a software upgrade method and system based on FMQL to solve the problems of low efficiency and low reliability in FMQL software upgrades.

[0004] In a first aspect, the present invention provides a software upgrade method based on FMQL, applied to a first device integrating an FMQL chip. The method includes: powering on and running a firmware program to initialize the basic configuration parameters of the first device and loading an FSBL program; initializing a PS terminal based on the FSBL program and opening the communication port of the PS terminal, wherein the communication parameters of the communication port are preset in a second device, and the communication parameters of a target port are preset in the first device, wherein the target port is a port deployed on the second device corresponding to the type of the communication port; controlling the first device to establish a communication connection with the second device through the communication port based on the FSBL program; and receiving an upgrade file issued by the second device based on the FSBL program and using the upgrade file to update the target software of the FMQL chip.

[0005] In some optional implementations, the old version of the target software before the update and the new version of the target software after the update are stored in different storage areas of the FMQL chip. The method further includes: when the target software of the FMQL chip is successfully updated using the upgrade file, the new version of the target software is loaded based on the FSBL program, and the operation of the first device is controlled by the new version of the target software; when the target software of the FMQL chip fails to be updated using the upgrade file, the old version of the target software is loaded based on the FSBL program, and the operation of the first device is controlled by the old version of the target software.

[0006] In some optional implementations, the FMQL chip's storage chip is divided into a boot image header, an image header table, a partition header table, an FSBL storage area, an image selection setting area, a first software image storage area, and a second software image storage area. The boot image header is used to record the address range of the FSBL storage area, which stores the FSBL program. The first software image storage area includes a first PL sub-area and a first PS sub-area, and the second software image storage area includes a second PL sub-area and a second PS sub-area. The first PL sub-area and the second PL sub-area are used to alternately store new and old versions of PL software in the new and old versions of the target software, and the first PS sub-area and the second PS sub-area are used to alternately store new and old versions of PS software in the new and old versions of the target software. The image selection setting area is used to record the loading flags selected from the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area as the software loading area. The image header table is used to describe the partition header table, which records the address range of the corresponding software in the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area.

[0007] In some optional implementations, receiving an upgrade file from a second device based on the FSBL program and using the upgrade file to update the target software of the FMQL chip includes: receiving a software upgrade request message from the second device, wherein the software upgrade request message describes whether the upgrade file is PL software and / or PS software, and the size of the corresponding software; responding to the software upgrade request message and identifying a target sub-region that has not been set with a load flag; receiving and verifying the upgrade file through the target sub-region; when the verification passes, it indicates that the upgrade file has successfully updated the target software of the FMQL chip; changing the load flag for the target sub-region through the image selection setting area; updating the partition header table and boot image header using the corresponding software address range in the target sub-region; when the verification fails, it indicates that the upgrade file has failed to update the target software of the FMQL chip.

[0008] In some optional implementations, the communication port is at least one of a serial port, an Ethernet port, or a CAN bus port, and receives and verifies the upgrade file, including: receiving data packets of the upgrade file sent by the second device; performing format verification on the data packets; when the format verification passes, storing the data packets in the target sub-area; when all data packets are stored in the target sub-area, performing integrity verification on the upgrade file; and determining that the upgrade file has passed verification when the integrity verification passes.

[0009] In some optional implementations, the FSBL program controls the first device to establish a communication connection with the second device through a communication port, including: controlling the first device to perform a handshake with the second device through the communication port; if the handshake is successful, the first device establishes a communication connection with the second device through the communication port; if the handshake fails, the FSBL program loads the outdated target software and controls the first device to run through the outdated target software.

[0010] In some optional implementations, controlling the first device to perform a handshake with the second device through a communication port includes: sending a handshake request message to the second device through the communication port; if a response message is received from the second device within a first preset time, checking whether the response message is correct; if the response message is correct, determining whether a preset number of consecutive correct responses has been reached; if the preset number of consecutive correct responses has been reached, determining that the handshake is successful; if the preset number of consecutive correct responses has not been reached, the response message is incorrect, or a response message is not received within the first preset time, determining whether the number of times the handshake request message has been sent has reached a preset number of handshakes; if the preset number of handshakes has not been reached, returning to the step of sending a handshake request message to the second device through the communication port; if the preset number of handshakes has been reached, determining that the handshake has failed.

[0011] In some optional implementations, detecting whether the response message is correct includes: within a first preset time after the handshake request message is sent, whether there is one and only one response message received; if there is one and only one response message received, then determining whether the response message matches a preset format; if the response message matches the preset format, then determining whether the content of the data area field of the response message is the same as that of the handshake request message; if the content of the data area field of the response message is the same as that of the handshake request message, then determining that the response message is correct.

[0012] Secondly, the present invention provides a software upgrade method based on FMQL, applied to a second device. The method includes: configuring communication parameters for several communication ports, wherein the communication ports are communication ports of the PS end in at least one FMQL chip, and the FMQL chip is integrated in the first device; establishing a communication connection with at least one first device through each communication port; and sending an upgrade file to the first device so that the first device can update the target software of the FMQL chip using the upgrade file through the FSBL program.

[0013] In some alternative implementations, the method further includes selecting that the upgrade file includes PL software and / or PS software before sending the upgrade file to the first device.

[0014] Thirdly, the present invention provides a software upgrade system based on FMQL, including a first device and a second device. The first device integrates an FMQL chip, and the second device is configured with communication parameters for several communication ports, wherein each communication port is a communication port of the PS end in at least one FMQL chip. The first device powers on and runs a firmware program to initialize basic configuration parameters and load an FSBL program. The first device initializes the PS end based on the FSBL program and opens the communication port of the PS end. Based on the FSBL program, the first device is controlled to establish a communication connection with the second device through the communication port. An upgrade file is sent to the first device. The first device uses the upgrade file to update the target software of the FMQL chip through the FSBL program.

[0015] The technical solution provided by this invention has the following advantages: This method is applied to a first device integrating an FMQL chip. Upon power-up, the firmware program completes basic configuration and loads the FSBL program. An improved FSBL program initializes the PS end and opens the communication port for the second device, establishing a communication connection between the upper and lower computers. This method eliminates the traditional method of opening the cover for JTAG interface upgrades. It utilizes the universal communication port on the FMQL chip's PS end for software upgrades, eliminating the need for a dedicated interface for upgrades, significantly improving device maintainability, reducing hardware interface usage, and enhancing device integration. The improved FSBL program controls and executes the entire upgrade process, deeply integrating upgrade logic with chip startup logic. No separate upgrade program needs to be run, simplifying the execution logic of device software upgrades. Furthermore, the communication port matches the second device's preset parameters, ensuring compatibility and stability of the upper and lower computer communication connection. This enables efficient online upgrades of the FMQL chip software, effectively solving the problems of cumbersome operation and high dependence on hardware interfaces in traditional upgrade methods. It is suitable for applications such as aerospace and military equipment where maintainability and ease of upgrade are crucial. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1This is a flowchart illustrating a software upgrade method based on FMQL according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the typical FMQL startup process for related technologies; Figure 3 This is a schematic diagram of a second process of a software upgrade method based on FMQL according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the storage space region division according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the third process of a software upgrade method based on FMQL according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the fourth process of a software upgrade method based on FMQL according to an embodiment of the present invention; Figure 7 This is a fifth flowchart illustrating a software upgrade method based on FMQL according to an embodiment of the present invention. Figure 8 This is a schematic diagram of the structure of a software upgrade system based on FMQL according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0020] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] As a domestically produced fully programmable PSoC chip, the FMQL series embedded microprocessor integrates multiple processing system (PS) terminals and one programmable logic (PL) terminal within a single chip. It can fully integrate the technical advantages of ARM and FPGA, and has broad application prospects in high-end application fields such as aerospace and military equipment. Consequently, the software maintenance and upgrade requirements of FMQL chips have also become a research hotspot in engineering applications.

[0022] During the R&D phase of FMQL chip-related products, technicians typically connect an emulator cable to the JTAG interface of the FMQL motherboard to complete the chip's program debugging and loading operations. However, after the product is officially delivered, to meet design requirements such as product structure and integration, a JTAG interface is generally not reserved for the FMQL chip as a software upgrade interface. Under these circumstances, if an FMQL chip software update is required, the product must be opened to connect the emulator cable to the motherboard's JTAG interface. This operation method introduces numerous technical defects into the FMQL chip software upgrade process, severely impacting the convenience, efficiency, and reliability of the upgrade. Specifically: First, it significantly reduces product maintainability. Upgrading via the JTAG interface requires opening the lid, which not only makes the software upgrade process cumbersome and increases the operational costs for maintenance personnel, but for highly integrated products, opening the lid also carries the risk of damaging the product's hardware structure and internal circuitry, further increasing the difficulty of product maintenance.

[0023] Secondly, it restricts the improvement of product integration. JTAG interfaces have multiple standard connection specifications, including standard pin configurations such as 14-pin and 20-pin. Some non-standard circuit designs may simplify to 10 pins. According to the IEEE 1149.1 standard, the pin pitch of JTAG interfaces is 2.54mm. All types of JTAG connectors occupy a certain amount of hardware space. As electronic devices develop towards higher integration, the layout space on the circuit board is becoming increasingly tight, making it difficult to reserve space for the installation and use of JTAG interfaces for FMQL chips, which contradicts the integrated design requirements of products.

[0024] Third, the JTAG interface suffers from poor versatility and high upgrade and adaptation costs. Currently, there is no unified standard for JTAG interface circuit design in the industry. Besides differences in the number of pins, pin definitions and voltage level designs also vary. Furthermore, the maximum supported frequency of the JTAG communication TCK clock signal differs significantly depending on the chip model, ranging from 1MHz to 33MHz. These design differences mean that the JTAG emulator used for software upgrades must be strictly matched to the product's JTAG interface circuit, preventing cross-device compatibility and increasing the adaptation and management costs of upgrade equipment.

[0025] Fourth, software upgrades are inefficient. In actual use after product delivery, FMQL chip software upgrades mostly involve changes to the PS-side program, with very few modifications needed to the PL-side program, and the PL-side program has a much larger data volume than the PS-side program. When upgrading software via the JTAG interface, it's impossible to upgrade the PS-side and PL-side programs separately; only the complete image file containing both PS and PL-side programs can be burned. Even if only a small portion of the PS-side program needs updating, it takes a significant amount of time to transfer and burn the complete image, greatly extending the upgrade time and reducing efficiency. This is determined by the emulator's capabilities; when upgrading software via the JTAG interface, the emulator can only overwrite the entire software image and does not have the ability to maintain specific partitions of the software image.

[0026] Fifth, the reliability of software upgrades is difficult to guarantee. The JTAG interface upgrade method is highly dependent on the hardware and software environment, which can easily lead to upgrade failure. If the transmission is interrupted or the image is corrupted due to an accident during the upgrade process, the software image will be incomplete. This will not only cause the upgrade operation to fail, but also damage the original software of the chip, making the product unable to work properly, or even making it impossible to perform the upgrade operation again.

[0027] Sixth, the upgrade method has poor scalability and is difficult to meet the needs of batch upgrades. The physical characteristics of the JTAG interface mean that it can usually only establish a connection with one emulator to realize the software upgrade of a single device.

[0028] In summary, the existing FMQL chip software upgrade methods based on the JTAG interface can no longer meet the actual needs of high maintainability, high integration, and efficient and reliable product upgrades. There is an urgent need to propose a new FMQL chip software upgrade method to solve the above-mentioned problems in the existing technology.

[0029] According to an embodiment of the present invention, an embodiment of a software upgrade method based on FMQL is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] This embodiment provides a software upgrade method based on FMQL, applied to a first device integrating an FMQL chip. Figure 1 This is a flowchart of a software upgrade method based on FMQL according to an embodiment of the present invention. The process includes the following steps: Step S101: Power on and run the firmware program to initialize the basic configuration parameters of the first device and load the FSBL program; Step S102: Initialize the PS terminal based on the FSBL program and open the communication port of the PS terminal. The communication parameters of the communication port are preset in the second device, and the communication parameters of the target port are preset in the first device. The target port is the port deployed on the second device according to the type of the communication port. Step S103: Based on the FSBL program, the first device establishes a communication connection with the second device through the communication port; Step S104: Receive the upgrade file sent by the second device based on the FSBL program, and use the upgrade file to update the target software of the FMQL chip.

[0031] Specifically, the software upgrade method based on FMQL disclosed in this embodiment is applied to a first device that integrates an FMQL chip. The first device can be a hardware carrier such as an embedded terminal or measurement and control equipment equipped with an FMQL chip in the fields of aerospace and military equipment. The second device that cooperates with it to complete the upgrade operation is a computer, industrial control host or other equipment with human-computer interaction and data transmission capabilities. Before explaining the specific execution steps of this method, the native software loading and startup logic of the FMQL chip is first described. The startup process of the FMQL chip after power-on is divided into two core stages: Stage 0: BootROM stage and Stage 1: FSBL (First Stage Boot Loader) stage. The BootROM is a read-only memory internal to the chip containing the boot program, which is the low-level firmware program burned into the chip at the factory and has the characteristic of being unmodifiable. After the chip powers on, the first ARM core on the PS side (e.g., CPU0) reads this program, completes the most basic hardware initialization configuration of the chip, and determines the startup medium through the pin level states. In this embodiment, the QSPIFlash of the FMQL chip is used as the startup medium. The chip reads the startup image header of the software image from a fixed starting address of this medium, verifies its integrity, loads the FSBL program into the on-chip memory, and executes it. Control of CPU0 is then transferred to the FSBL program. FSBL, or First Stage Boot Loader, is the first customizable program in the chip startup process. Figure 2 As shown, its native execution logic is to sequentially complete the hardware initialization of the PS side, the loading and configuration of the PL partition image, the loading of the PS partition image, and the running of the PS side software program. After completion, the control is transferred to the PS side software program, and the chip completes the complete boot process.

[0032] This invention improves and expands the FSBL program execution logic of the FMQL chip, integrating software upgrade control and execution logic into its native startup process, enabling online upgrades without relying on dedicated interfaces. The steps S101 to S104 of this method are described in detail below in conjunction with specific implementation scenarios.

[0033] First, the FMQL chip is powered on and its firmware is run to initialize the basic configuration parameters of the first device and load the FSBL program. When the first device with the integrated FMQL chip is powered on, the underlying firmware is triggered. This firmware is the basic driver for the device hardware, and its core function is to initialize the basic hardware configuration parameters of the first device, including the initial parameter configuration of the power management module, core hardware bus, and basic peripherals, ensuring that the device hardware is in a normal, ready-to-operate state. After the firmware completes the basic configuration, the device will execute according to the native BootROM stage logic of the FMQL chip. CPU0 reads the program embedded in the BootROM, completes the chip's underlying initialization, selects the QSPI Flash as the boot medium, reads the FSBL program software image from a fixed starting address on this medium, verifies its integrity, loads the FSBL program into the on-chip memory, and enters the FSBL stage, laying the foundation for subsequent upgrade operations based on the FSBL program.

[0034] Next, the PS terminal needs to be initialized based on the FSBL program, and its communication port needs to be opened. The communication port is a type supported by the second device, and its communication parameters are pre-set in the second device. After the FSBL program is successfully loaded and executed, it first completes the full initialization of the PS terminal according to its native logic. This involves configuring and activating the core hardware of the PS terminal, such as DDR memory, system clock, MIO multi-function interface, and data transmission bus, enabling the PS terminal to have complete data processing and peripheral communication capabilities. Unlike the native FSBL program execution logic, this step adds a communication port opening operation after completing the PS terminal initialization. The opened communication port is the communication port of the FMQL chip's PS terminal. In this embodiment, a serial port is used as an example. This serial port is a communication port type supported by both the first and second devices. The hardware and software of the second device are usually developed for or compatible with the first device. The communication interface design of the second device is based on the first device and must support or be compatible with the communication interface provided by the first device. Furthermore, its communication parameters, such as baud rate of 115200bps, 8 data bits, 1 stop bit, and no parity bit, have been pre-set in the human-machine interface of the second device to ensure parameter matching of the communication ports of the upper and lower devices, providing a reliable physical layer foundation for subsequent data transmission. In some optional implementations, the communication port can also be an Ethernet interface, a WIFI interface, etc., and the FSBL program can be improved according to the communication port that the user needs to open. The communication parameters are preset in both the first and second devices, and the set values ​​are consistent or corresponding to each other, ensuring that the two types of devices can communicate with each other.

[0035] Subsequently, the FSBL program controls the first device to establish a communication connection with the second device through the communication port. After the communication port on the PS side of the first device is successfully opened, the FSBL program leads the communication connection establishment process. Unlike the connection method that relies on a dedicated emulator in traditional upgrade methods, this step achieves a point-to-point communication connection between the first and second devices through a general communication port. The entire connection process is controlled by the FSBL program, without the need to run an additional independent communication control program. Figure 3 As shown, the communication link between the first and second devices only needs to be handshaked and established through the already opened serial port. Once the physical connection of the communication link and the data transmission handshake are completed, a stable communication connection between the two is established, providing a reliable communication channel for the subsequent transmission of upgrade files.

[0036] After a stable communication connection is established between the first and second devices, this embodiment of the invention uses the FSBL program as the core for data reception and processing of the first device. It receives the FMQL chip upgrade file sent by the second device through the communication port. This upgrade file is a software image file adapted for the FMQL chip and can be directly recognized and loaded by the chip. The entire file reception process is controlled by the FSBL program. After receiving the complete upgrade file, it directly uses this upgrade file to overwrite and update the target software to be updated in the FMQL chip, completing the core operation of the software upgrade. The entire update process is completed based on the execution logic of the FSBL program, without the need for intervention from other program modules, achieving deep integration of the upgrade operation and the chip startup logic.

[0037] This invention improves and expands the execution logic of the FSBL program for FMQL chips, enabling online software upgrades for devices integrating FMQL chips. It abandons the traditional upgrade method relying on a dedicated JTAG interface, instead utilizing the general communication port on the PS side of the FMQL chip to complete the upgrade operation. This eliminates the need to open the device or reserve a dedicated hardware interface for the upgrade, significantly improving device maintainability and reducing the space occupied by hardware interfaces on the circuit board layout, aligning with the trend of highly integrated device design. This invention integrates the entire software upgrade process logic into the execution of the FSBL program. The FSBL program leads the process of opening the communication port, establishing the communication connection, receiving the upgrade file, and updating the software, eliminating the need to run a separate upgrade control program within the device, thus simplifying the device's software architecture and upgrade execution logic. Meanwhile, the communication port of the first device matches the preset parameters of the second device, ensuring the compatibility and stability of the communication connection between the upper and lower computers. This enables efficient and convenient online upgrades of the FMQL chip software, effectively solving the technical problems of cumbersome operation, high hardware dependence, and poor adaptability of traditional upgrade methods. It is especially suitable for application fields such as aerospace and military equipment, which have strict requirements for equipment maintainability and upgrade convenience, and has high engineering application value.

[0038] In some optional implementations, the old version of the target software before the update and the new version of the target software after the update are stored in different storage areas of the FMQL chip, and the method further includes: Step S105: When the target software of the FMQL chip is successfully updated using the upgrade file, the new version of the target software is loaded based on the FSBL program, and the operation of the first device is controlled by the new version of the target software. Step S106: When updating the target software of the FMQL chip using the upgrade file fails, the old version of the target software is loaded based on the FSBL program, and the operation of the first device is controlled by the old version of the target software.

[0039] Specifically, based on the aforementioned FMQL software upgrade method, this embodiment further optimizes the upgraded software loading and device operation control logic. By separating and storing the old version target software and the new version target software in different physical storage areas in the FMQL chip, adaptive software loading is achieved under different scenarios of upgrade success or failure, thus avoiding the technical risk of the device failing to operate normally due to upgrade failure from the bottom layer. This embodiment uses a measurement and control device integrating the FMQL20S400 chip as the first device and an industrial control host as the second device for illustration. The PS side of the FMQL20S400 chip integrates four Cortex-A7 architecture ARM cores, and its software loading and core startup logic is the core execution basis of this embodiment.

[0040] The core premise of this implementation is that the old version of the target software before the update and the new version of the target software after the update are stored in different storage areas of the FMQL chip. Through the isolation of physical storage areas, the old and new versions of the software form independent storage units, and both storage areas are valid program loading areas of the FMQL chip. Both can be recognized by the FSBL program and can complete the reading and running of the software image, providing a hardware storage foundation for differentiated loading after the success or failure of the subsequent upgrade. After completing the upgrade file reception and target software update operation, the FSBL program will determine the execution result of the update operation. Depending on whether the update is successful or unsuccessful, different software loading and device operation control logic will be executed. The entire determination and execution process is completed by the FSBL program without the need for external program intervention.

[0041] When the FSBL program determines that the upgrade file has been completely written to the target storage area and that there are no execution errors in the software update operation, the software update is considered successful. At this point, the FSBL program will read the software image from the storage area storing the new version of the target software according to the program loading logic of the FMQL chip, and complete the subsequent program loading and device operation control. If the new version of the target software is a bare-metal program with a single PS image partition, the FSBL program will select, according to the CPU configuration instructions within the program, whether to have Cpu0 run the program alone, or to have Cpu0 first complete the initialization of the other three ARM cores, and then start the entire PS-side program in AMP, SMP, or BMP multi-core running mode. If the new version of the target software includes an operating system, and its first PS image partition is SSBL (Second Stage Boot Loader), then after loading the SSBL program, the FSBL program will transfer control to the SSBL, which will then complete the subsequent loading and startup of the operating system. Finally, the loaded new version of the target software will take over all operation control of the first device, realizing the software version upgrade and normal operation of the device.

[0042] When the FSBL program detects incomplete upgrade file transfer, write process errors, or software image verification failure, it determines that the software update has failed. In this case, the FSBL program will abandon reading the storage area of ​​the new version target software and instead read the software image from the original storage area storing the old version target software. Its loading and running logic is completely consistent with the original logic. If the old version target software is a bare-metal program, the FSBL program will complete the single-core or multi-core boot according to its CPU configuration. If the old version target software contains an operating system, the FSBL program will load its SSBL program and transfer control, allowing the old version target software to continue operating the first device. Throughout the entire process, the storage area of ​​the old version target software is not modified by this upgrade operation, effectively ensuring its program integrity and operability, and ensuring that the device can still recover to its original normal working state after the upgrade fails.

[0043] This invention significantly optimizes the reliability of software upgrade methods based on FMQL chips by separating the storage of new and old software versions and differentiating loading after upgrade success or failure. It achieves isolation and protection of new and old software versions at the physical storage level. During the upgrade process, only the storage area of ​​the new version is written to, while the storage area of ​​the original old version software remains intact and unmodified. This fundamentally solves the technical problem of software image corruption and device inoperability caused by upgrade failure in traditional upgrade methods, and greatly improves the fault tolerance of FMQL chip software upgrades and the stability of device operation.

[0044] In some optional implementations, the FMQL chip's storage chip is divided into a boot image header, an image header table, a partition header table, an FSBL storage area, an image selection setting area, a first software image storage area, and a second software image storage area. The boot image header is used to record the address range of the FSBL storage area, which stores the FSBL program. The first software image storage area includes a first PL sub-area and a first PS sub-area, and the second software image storage area includes a second PL sub-area and a second PS sub-area. The first PL sub-area and the second PL sub-area are used to alternately store new and old versions of PL software in the new and old versions of the target software, and the first PS sub-area and the second PS sub-area are used to alternately store new and old versions of PS software in the new and old versions of the target software. The image selection setting area is used to record the loading flags selected from the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area as the software loading area. The image header table is used to describe the partition header table, which records the address range of the corresponding software in the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area.

[0045] Specifically, this implementation addresses the storage requirements of FMQL chip software upgrades by standardizing the functional partitioning design of its supporting storage chip and constructing a storage architecture that is deeply adapted to the FMQL software image format, providing underlying hardware support for reliable software storage, accurate loading, and version switching.

[0046] Before describing the storage partitioning of the embodiments of the present invention, the software image format of the FMQL chip will be explained first. The software image of the FMQL chip is a standardized binary file generated in a dedicated integrated development environment. It is not a single data block, but a structured image composed of multiple functional partitions. The core includes one FSBL partition, one PL partition, and one or more PS partitions. Each partition can choose encryption methods such as AES and HMAC according to security requirements, or it can adopt an unencrypted form. The header area of ​​the software image contains hierarchical index information, namely the boot image header, the image header table, and the partition header table. The boot image header is the core entry point of the image, recording key information such as image configuration information, integrity verification information, and the address, length, and memory load address of the FSBL partition. It is the first image area read after the chip powers on. The image header table is a partition overview index, storing common information of the image partitions, the number of partitions, and the offset address pointing to the partition header table. The partition header table is a detailed index list of each partition. Each partition corresponds to a partition header information, recording the offset address, length, memory load address, and encryption and signature information of that partition. The three form a hierarchical address index system, enabling the FMQL chip's boot program to quickly locate and parse each functional partition, achieving accurate loading of the software image.

[0047] This embodiment selects QSPI Flash as the boot storage device for the FMQL chip. This storage medium has the characteristics of fast erase and write speed, high integration, and strong anti-interference capability, making it suitable for the storage needs of embedded application scenarios such as aerospace and military equipment. This embodiment of the invention performs fine-grained functional partitioning of the continuous address space of the QSPI Flash, dividing it from low address to high address into a boot image header, image header table, partition header table, FSBL storage area, image selection setting area, first software image storage area, and second software image storage area.

[0048] The address offset of each region strictly follows the rule of 0x10000, which is an integer multiple of 64K bytes. This matches the hardware characteristics of QSPI Flash, which uses blocks as the smallest erase unit. This ensures hardware compatibility of storage operations, avoids fragmentation and waste of storage space, and improves storage resource utilization.

[0049] Each functional partition is defined with its own function based on the boot and upgrade logic of the FMQL chip, forming a storage system where each part performs its own function and works in concert. The boot image header, image header table, and partition header table continue the hierarchical index of the software image, serving as the core address guide for the storage architecture. In addition to recording the basic configuration and verification information of the software image, the boot image header is mainly used to mark the address range of the FSBL storage area, providing basic guidance for the FSBL program to read quickly. The image header table describes the storage address and data structure of the partition header table, enabling precise location of the partition header table. The partition header table records the address range of each sub-area under the first and second software image storage areas in detail, enabling the FSBL program to quickly identify the physical location of each software storage area, greatly improving the efficiency of program loading and upgrade file writing.

[0050] like Figure 4 As shown, the FSBL storage area is a dedicated program storage area. Its function is to store the FSBL program required for the FMQL chip to start. The address range of this area is fixedly defined by the boot image header, ensuring that the FSBL program can be quickly read and loaded from a fixed location after the chip is powered on, laying the execution foundation for subsequent chip boot and software upgrade operations.

[0051] The image selection settings area is the core of the storage architecture's version control. Its core function is to record load flags, which are unique identifiers for software loading. These flags specify whether the FSBL program should read the PL and PS software from the first or second software image storage area. This is a crucial area for enabling rapid switching between old and new software versions, and the stored identifier information directly determines the software version that runs after the FMQL chip boots up. The first and second software image storage areas are symmetrical main software image storage areas, both with identical sub-area partitioning structures and storage capacities, forming a mutually redundant software storage system. The first software image storage area contains independent first PL and first PS sub-areas, while the second software image storage area contains second PL and second PS sub-areas. The PL sub-area is dedicated to storing the FMQL chip's PL-side configuration program bitstream, and the PS sub-area is dedicated to storing the PS-side running program. Sub-areas of the same type have identical address lengths, adapting to the FMQL software image partitioning structure and meeting the independent storage and separate upgrade requirements of the PL and PS software.

[0052] In this embodiment of the invention, the first PL sub-area and the second PL sub-area, and the first PS sub-area and the second PS sub-area, use an alternating storage rule to store the old and new versions of PL software and PS software. This rule achieves physical isolation and protection between the old and new versions of software. Taking the 32M-byte QSPIFlash that accompanies the FMQL20S400 chip as an example, in the initial state of the product after leaving the factory, the old version of PL software and PS software are stored in the first PL sub-area and the first PS sub-area, respectively. At this time, the loading flag of the mirror selection setting area points to each sub-area of ​​the first software mirror storage area. After the FSBL program starts, it loads the old version of software in this area. When the first software upgrade is completed, the new version of PL software and PS software will be written to the second PL sub-area and the second PS sub-area, respectively. After the upgrade operation is completely successful, the loading flag of the mirror selection setting area will be switched synchronously to each sub-area of ​​the second software mirror storage area. After the chip restarts, the new version of software will be loaded and run. When a second software upgrade is performed, the new version of software will be written back to each sub-area of ​​the first software mirror storage area, and the loading flag will switch again. This cycle is repeated to realize the alternating writing and storage of the old and new versions of software between the two mirror storage areas. It is worth noting that the loading flag in the image selection settings area is only modified after the software upgrade operation is completely successful. If problems such as file transfer failure, image verification error, or writing interruption occur during the upgrade process, the loading flag will remain unchanged to ensure that the FSBL program can always read the software version that can run normally.

[0053] Furthermore, in this implementation, the storage capacity of each region of the QSPIFlash needs to be dynamically adapted and planned based on the actual data volume of the FMQL software, taking into account both software storage requirements and storage resource utilization. Taking the FMQL20S400 chip as an example, its 32MB QSPIFlash can be planned with 22MB of space for software image storage. Considering the characteristic in actual applications that the image data volume of the PL part is much larger than that of the PS part, 8MB of storage capacity is allocated to the first and second PL sub-regions, and 2MB of storage capacity is allocated to the first and second PS sub-regions. The remaining space is reasonably allocated to the boot image header, image header table, partition header table, FSBL storage area, and image selection setting area, as shown in Table 1 below, which is an example table of storage area address allocation. This ensures complete storage for each version of the software while avoiding the ineffective waste of valuable Flash storage space, achieving optimal configuration of storage resources. At the same time, the storage capacity planning needs to reserve a certain amount of redundancy space to adapt to the expansion needs of subsequent software version iterations and improve the scalability of the storage architecture.

[0054] Table 1. Example table of storage area address allocation

[0055] This invention constructs a storage architecture that is deeply adapted to the software image format and enables reliable software upgrades by defining refined functional partitions and standardized rules for the FMQL chip storage chip. This storage architecture continues the hierarchical indexing design of the FMQL software image, achieving isolated storage and precise positioning of the boot program, index information, and software image. This allows the FSBL program to quickly complete address identification and data reading in each area, significantly improving the efficiency of chip program loading and software upgrades, meeting the efficiency requirements of embedded devices. The symmetrical dual software image storage area design and alternating storage rules achieve complete isolation between the old and new software versions at the physical level. During the upgrade process, only the backup storage area is written to, while the original running version's software storage area remains intact and unmodified. This fundamentally avoids the impact of the upgrade process on the software in use and solves the risk of software image corruption caused by overwrite writing in traditional upgrade methods. The loading flag control mechanism in the image selection settings area enables fast and seamless switching of software versions. The modification of the flag is only related to whether the upgrade is successful or not, ensuring that the chip can directly load the original old version of the software when the upgrade fails. This eliminates the technical problem of the device becoming inoperable due to upgrade failure, and greatly improves the reliability of software upgrades and the stability of device operation.

[0056] In some optional implementations, step S104 above includes: Step a1: Receive a software upgrade request message from the second device. The software upgrade request message describes whether the upgrade file is PL software and / or PS software, and the size of the corresponding software file. Step a2: In response to the software upgrade request message, determine the target sub-region that has not been marked with a load flag; Step a3: Receive and verify the upgrade file through the target sub-region; Step a4: When the verification passes, it means that the upgrade file has successfully updated the target software of the FMQL chip. Step a5: Select the settings area via mirroring and change the loading flag for the target sub-area; Step a6: Update the partition header table and boot image header using the corresponding software address range in the target sub-region; Step a7: If the verification fails, it means that the upgrade file failed to update the target software of the FMQL chip.

[0057] Specifically, the embodiments of the present invention have deconstructed and expanded the core execution steps of FMQL chip software upgrade.

[0058] like Figure 5 As shown, after the first device and the second device establish a stable communication connection, the first device sends a process start message to inform the second device that it is ready and can be upgraded at any time. The second device will generate and send a software upgrade request message according to the upgrade requirements. This message is a standardized instruction data frame, which is the core parameter carrier for the upper and lower computer to complete the upgrade collaboration. Its core contains two types of key information: first, the upgrade object identifier, which clarifies whether the file to be upgraded is PL software, PS software, or both, pointing to the software type to be updated on the FMQL chip; second, the byte size of the upgrade file, which provides a quantitative basis for the integrity verification of subsequent file transmission. The FSBL program of the first device, as the core control module for communication and upgrade, will receive the software upgrade request message in real time and complete the parsing, extract the upgrade parameters, and define the execution scope for subsequent upgrade operations. This process realizes the precise targeting of upgrade operations and avoids interference caused by indiscriminate writing to the original software of the chip.

[0059] After parsing the software upgrade request message, the FSBL program sets upgrade parameters based on the message and, in conjunction with the load marker stored in the image selection settings area, locates the target storage sub-area. The load marker serves as a unique identifier for the current software loading area, pointing to the storage sub-area of ​​the currently running software on the first device. To achieve physical isolation between the old and new software versions, the target sub-area for this upgrade will be a spare storage sub-area not pointed to by the load marker. This spare sub-area is a PL or PS sub-area of ​​the same type as the storage sub-area of ​​the currently running software, possessing completely identical storage capacity and address structure. Taking the product's initial factory state as an example, if the load marker points to both the first PL sub-area and the first PS sub-area, when the upgrade request message specifies upgrading PS software, the FSBL program will determine the second PS sub-area as the target sub-area for this upgrade; if it specifies upgrading PL+PS software, then both the second PL sub-area and the second PS sub-area will be simultaneously determined as target sub-areas. This positioning logic ensures from the bottom layer that the storage area of ​​the original running software remains unmodified during the upgrade process, avoiding the impact of the upgrade operation on the current operating state of the device.

[0060] After the target sub-region is determined, the FSBL program controls the first device to receive the upgrade file from the second device through the established communication port. The entire file transfer process is implemented using the Xmodem-1K protocol, which divides the large upgrade file into fixed 1024-byte data packets for chunked transmission, adapting to the communication bandwidth and data processing capabilities of embedded scenarios. The FSBL program sequentially writes the received data packets into the determined target sub-region, completing the storage of the entire upgrade file. During transmission and writing, dual verification is performed: first, data packet format and integrity verification, ensuring that each received data packet conforms to the Xmodem-1K protocol encapsulation specifications, with no transmission errors or data loss; second, the total byte count verification of the entire upgrade file, comparing the actual byte count of the received file with the file size described in the software upgrade request message to ensure that the upgrade file is received completely. This dual verification mechanism provides a solid technical guarantee for the validity of the upgrade file.

[0061] If the FSBL program completes the verification successfully, it indicates that the upgrade file has been written completely and error-free to the target sub-region. This signifies a successful update of the FMQL chip's target software. Subsequent version flag switching and image header table maintenance operations will then be triggered, ensuring the new software version is ready to be loaded and run. This determination logic relies solely on the actual transmission and writing status of the upgrade file, objectively and accurately reflecting the execution result of the upgrade operation and providing clear triggering conditions for subsequent operations.

[0062] After confirming the upgrade operation is successful, the software image status is maintained. First, the FSBL program modifies the load flag stored in the image selection settings area, switching it from the currently running software storage sub-area to the target sub-area for this upgrade, thus completing the targeted software version switch. Modifying the load flag is a lightweight parameter write operation, offering fast execution and high reliability. As the unique guide for the FSBL program to load software, its modification directly determines the software loading area during subsequent chip startup. For example, if the target sub-area for this upgrade is the second PL and second PS sub-areas, the FSBL program will change the load flag from pointing to the first PL and PS sub-areas to pointing to the second PL and PS sub-areas, ensuring that subsequent software loading operations directly point to the storage area of ​​the new software version, achieving seamless version switching.

[0063] Secondly, the image header table and partition header table, as a hierarchical address indexing system for FMQL chip software loading, must maintain a high degree of consistency between the recorded address ranges and the actual storage location of the software to ensure accurate software loading by the FSBL program. After the loading flag is modified, the FSBL program extracts the actual physical address range of the target sub-region, including the start and end addresses, and synchronously updates the address records of the corresponding PL and PS sub-regions in the partition header table. Simultaneously, it recalculates the integrity verification information of the entire software image and updates the verification field in the boot image header, ensuring that the index information recorded in the boot image header and partition header table completely matches the actual storage state of the new version of the software in the target sub-region. This operation achieves dynamic synchronization between the software image index information and the actual storage content, ensuring that the FSBL program can quickly and accurately locate and load the new version of the software based on the updated header table information, avoiding software loading failures due to address information mismatches. This is a crucial step in ensuring the normal operation of the new version of the software. Furthermore, this step is also a necessary means for users to selectively upgrade the PS or PL software according to their individual needs.

[0064] If the FSBL program detects data packet format errors, transmission errors, or discrepancies between the actual file size and the described size during verification, it determines that there is an anomaly in the transmission or writing process of the upgrade file, and the verification fails. The update operation for the FMQL chip target software will then fail. At this point, the FSBL program will terminate all subsequent operations, without modifying the load flag in the image selection settings area, nor updating any information in the partition header table or boot image header. This ensures that all index information and software storage status in the storage chip remain in their original state before the upgrade, guaranteeing that the first device can continue to load and run the old version of the target software based on the original load flag.

[0065] This invention, through a detailed breakdown of the core steps of FMQL chip software upgrades, constructs a standardized and highly reliable software update execution logic. This logic uses software upgrade request messages to direct upgrade operations, allowing for individual or combined upgrades of the PL and PS software based on actual needs. This adapts to real-world application scenarios where PS software upgrades are the primary focus after product delivery, avoiding the time and storage resource waste associated with overall image burning and significantly improving software upgrade efficiency.

[0066] By storing the upgrade files in a spare target sub-area that is not marked as loaded, complete isolation between the old and new software versions is achieved at the physical level. During the upgrade process, the storage area and index information of the original running software remain unchanged, thus solving the risk of software image corruption caused by overwrite in traditional upgrade methods.

[0067] By leveraging the block transmission and verification of the Xmodem-1K protocol, the integrity and accuracy of upgrade file transmission and writing are ensured, guaranteeing the effectiveness of the upgrade operation from a data perspective.

[0068] The targeted modification of the loading marker and the synchronous update of the image header table achieve a high degree of matching between the new version software index information and the actual storage state, ensuring that the new version software can be accurately loaded by the FSBL program. At the same time, because the modification of the startup image header, image header table, and partition header table ensures that selectively updated software is subsequently read accurately without errors, it is also a necessary supporting measure to ensure that users can choose to upgrade PL and PS software individually or jointly according to their actual needs.

[0069] In addition, the design of this embodiment, which does not perform any operation when the upgrade fails, enables the device to quickly return to its normal working state before the upgrade, greatly improving the fault tolerance of the software upgrade and the stability of the device operation.

[0070] In some alternative implementations, the communication port is at least one of a serial port, an Ethernet port, or a CAN bus port. Step a3 includes: Step b1: Receive the data packet containing the upgrade file sent by the second device; Step b2: Perform format verification on the data packet; Step b3: When the format verification passes, the data packet is stored in the target sub-area; Step b4: When all data packets are stored in the target sub-area, perform an integrity check on the upgrade file; Step b5: If the integrity check passes, confirm that the upgrade file has passed verification.

[0071] Specifically, this embodiment of the invention provides a complete file transfer process based on the Xmodem-1K protocol for serial port, Ethernet port, or CAN bus port communication scenarios. The second device cuts large image files into fixed small data packets of 1024 bytes for transmission, avoiding errors when transmitting large files at once; each packet undergoes CRC16 / Xmodem verification to ensure the integrity and error-free content of the data packets; the upper and lower control computers interact through fixed control characters (such as ACK confirmation, NAK retransmission), and erroneous packets are automatically retransmitted, making the entire process controllable.

[0072] The following example uses a serial port. After the communication link is established, the first device sends the Xmodem-1K protocol start control character 0x43 (ASCII C) to the second device, indicating "I am ready to start transferring files". Upon receiving 0x43, the second device immediately begins processing the image file to be transferred (such as converting PL's .bit to .bin and PS's .hex to .bin), and splits the first data packet into 1KB segments.

[0073] If the total number of bytes in the upgrade file is not divisible by 1024, the last data packet will be padded with 0xFF to ensure the uniformity of the data packet format. The FSBL program of the first device will receive such data packets sent by the second device in real time through the initialized serial port. As an asynchronous serial communication interface, the serial port realizes the byte stream transmission between the upper and lower computers based on preset communication parameters such as baud rate, data bits, and stop bits. The FSBL program will complete the continuous reception and temporary storage of each data packet according to the transmission sequence of the data packets, providing a data basis for subsequent verification operations. This block reception method adapts to the communication bandwidth characteristics of the serial port and avoids problems such as packet loss and bit errors caused by transmitting large files in a single transmission.

[0074] If the FSBL program does not receive a single data packet within a predetermined time, it sends a serial port message to the second device, requesting the second device to retransmit the data packet frame. If the timeout has exceeded 5 times (this is just an example and is not a limit), the upgrade will terminate directly.

[0075] After receiving a single data packet from the serial port, the FSBL program immediately performs a standardized format verification. This verification is a basic data packet-level check, centered around the Xmodem-1K protocol's data packet encapsulation specifications. It parses and verifies the data frame format, checking the validity and consistency of key fields such as the frame header identifier, frame sequence number, frame sequence number inverse, data field length, and CRC16 checksum. Specifically, it verifies whether the frame header is the protocol-specified 0x02, whether the frame sequence number increments sequentially according to the transmission time, whether the frame sequence number and inverse are logically NOT, and whether the data field length is 1024 bytes (except for the last packet). Simultaneously, it recalculates the CRC16 checksum based on the valid data within the data packet and compares it with the checksum field at the end of the data packet. Only when all fields conform to the protocol specifications and the checksum matches is the data packet format verification considered successful. This step serves as the first line of defense for upgraded file transfer, fundamentally avoiding data packet format errors caused by serial port interference and mismatched communication parameters, ensuring that every data packet entering the storage stage is valid data.

[0076] If a single data packet passes the format verification, the FSBL program will immediately perform the data packet storage operation, writing it into the determined target sub-area one by one in the order of data packet transmission. The storage address is the physical address range of the target sub-area, and the storage address of the data packet increases continuously to ensure that the upgrade file forms a complete and continuous binary data block in the target sub-area, which is consistent with the storage format of the original software.

[0077] If the data packet format verification fails, the FSBL program will discard the data packet and send a retransmission command to the second device, requesting the second device to retransmit the data packet frame. It's important to note that if the number of retransmissions does not exceed 5 (this is just an example, not a limit), the second device will be asked to retransmit the data packet frame; if the number of retransmissions exceeds 5 (this is just an example, not a limit), the upgrade process will terminate directly. This retransmission mechanism further ensures the reliability of data reception under the serial port transmission link, avoiding the impact of a single packet error on the entire upgrade file.

[0078] Once the FSBL program receives the transmission completion instruction from the second device and confirms that all data packets have undergone format verification and been written to the target sub-area, it will initiate a comprehensive integrity verification of the upgrade file. This verification is a file-level global verification, validating the entire process of upgrade file transmission and storage. The core basis for the verification is the total number of bytes in the upgrade file described in the received software upgrade request message. The FSBL program will count the actual total number of bytes of the upgrade file already stored in the target sub-area and extract data features from the stored complete binary data blocks. The actual statistical results and data features will be compared comprehensively with the preset file size and feature values. This verification method overcomes the limitations of single-packet verification, verifying from an overall perspective whether the upgrade file has been transmitted and stored completely and without omission.

[0079] If the overall integrity verification result of the FSBL program is consistent, meaning the actual number of bytes stored in the upgrade file perfectly matches the preset value and there are no deviations in data characteristics, it will be determined that there were no abnormalities in the entire process of receiving and storing the upgrade file, and the overall verification of the upgrade file has passed. This determination result is the core basis for the end of file transfer and the success of the upgrade operation. Only after the upgrade file has completed the dual verification of "single packet format verification and overall integrity verification" will subsequent operations such as loading mark modification and image header table update be triggered, ensuring that the upgrade file entering the subsequent stages is a complete and valid software image, thus laying a solid foundation for the reliability of FMQL chip software upgrades from a data perspective.

[0080] This invention provides an upgrade file reception and verification method for communication scenarios, constructing a hierarchical, multi-dimensional verification system with significant technical advantages and engineering application value. This logic relies on the Xmodem-1K protocol to achieve chunked transmission of upgrade files, adapting to the bandwidth and transmission characteristics of asynchronous serial communication. It effectively solves the packet loss and bit error problems that easily occur when transmitting large files in a single serial transmission, improving data transmission adaptability. Through dual verification, a verification barrier is formed from local to global, avoiding format errors in individual data packets and verifying the overall integrity of the upgrade file. This eliminates software image corruption caused by incomplete transmission or data errors, significantly improving the reliability of upgrade file reception under serial transmission links. This invention solves the technical problem of insufficient reliability in software upgrade scenarios, providing a reliable file transmission solution adapted to general serial ports for devices based on FMQL chips.

[0081] In some optional implementations, step S103 above includes: Step c1: Control the first device to perform a handshake with the second device through the communication port; Step c2: If the handshake is successful, the first device establishes a communication connection with the second device through the communication port; Step c3: If the handshake fails, load the outdated target software based on the FSBL program and control the operation of the first device through the outdated target software.

[0082] Specifically, in this embodiment of the invention, a measurement and control device integrating an FMQL20S400 chip is used as the first device, and an industrial control host is used as the second device. The serial port is used as the communication port for detailed explanation. This communication port is a general peripheral interface of the PS end of the FMQL chip. The communication parameters have been preset and matched with the second device, providing basic physical layer support for handshake interaction and connection establishment.

[0083] After the first device completes PS terminal initialization and communication port opening based on the FSBL program, the FSBL program will take the lead in initiating a handshake interaction with the second device. This handshake is a two-way verification process of the communication validity between the upper and lower computers. It is a core prerequisite for establishing a stable communication connection. In essence, the first device and the second device exchange and transmit standardized command messages through the communication port to verify whether the communication hardware, communication parameters, and data parsing capabilities of both parties are compatible and whether the communication link has stable data transmission conditions.

[0084] Specifically, the FSBL program controls the first device to send a standardized handshake request message to the second device through the opened serial port. This message is a command data frame conforming to a preset communication protocol, containing core fields such as device identifier, communication port type, and handshake request identifier, used to initiate a communication connection request to the second device. Simultaneously, the first device enters a handshake response waiting state, receiving the response message returned by the second device in real time, providing a basis for subsequent handshake result determination. This handshake initiation logic is directly driven by the FSBL program, eliminating the need for a separate communication control program, achieving deep integration of handshake operation and chip startup logic, and meeting the lightweight operation requirements of embedded devices.

[0085] When the first device receives a standardized handshake response message from the second device within the preset response waiting time, and the FSBL program parses the response message as valid, the handshake interaction is considered successful. A successful handshake means that the communication hardware of the first and second devices is matched, the communication parameters are consistent, and both the physical and data link layers of the communication link have stable data transmission capabilities. At this point, the FSBL program will confirm that the first and second devices have established a reliable point-to-point communication connection through the communication port, and both parties will enter a data transmission ready state, building a stable communication channel for the subsequent issuance of software upgrade request messages and the transmission of upgrade files.

[0086] If the handshake interaction fails, it indicates that there is an anomaly in the communication link between the two parties, or that the communication hardware and parameters are incompatible and the conditions for data transmission are not met. At this time, the FSBL program will terminate all subsequent software upgrade-related operations and instead load the original target software that has not been updated in the chip's storage area according to the FMQL chip's native startup and operation logic.

[0087] This invention provides a highly reliable and fault-tolerant technical solution through a handshake-based communication connection, ensuring stable data transmission capabilities and fundamentally solving problems such as packet loss and bit errors caused by communication mismatch in traditional upgrade methods. This significantly improves the reliability of the software upgrade communication link. Furthermore, this implementation provides robust handshake failure fault-tolerant logic. When communication anomalies prevent the establishment of a connection, the upgrade operation is directly terminated, and the existing, unupdated target software is loaded. This allows the device to quickly return to normal operation, completely avoiding the technical risks of device startup failure or malfunction due to communication failure, and significantly improving the stability and fault tolerance of device operation.

[0088] In some alternative implementations, step c1 above includes: Step d1: Send a handshake request message to the second device through the communication port; Step d2: If a response message from the second device is received within the first preset time, check whether the response message is correct. Step d3: If the response message is correct, determine whether the preset number of consecutive correct responses has been reached. Step d4: If the preset number of consecutive correct handshakes is reached, the handshake is considered successful. Step d5: If the preset number of consecutive correct responses is not reached, the response message is incorrect, or the response message is not received within the first preset time, then determine whether the number of times the handshake request message has been sent has reached the preset number of handshakes. Step d6: If the preset number of handshakes has not been reached, return to the step of sending a handshake request message to the second device through the communication port; In step d7, if the preset number of handshakes is reached, the handshake is deemed to have failed.

[0089] Specifically, such as Figure 6 As shown, this embodiment of the invention achieves accurate and reliable verification of the communication link through multiple determinations of response timeliness, message validity, and verification continuity. Simultaneously, it sets a threshold for the number of handshake requests to avoid wasting device resources due to unlimited requests. The first preset time, the preset number of consecutive correct responses, and the preset number of handshakes can all be flexibly configured based on the communication environment and reliability requirements of the actual application scenario. In this embodiment, the first preset time is 20ms, the preset number of consecutive correct responses is 3, and the preset number of handshakes is 5.

[0090] After the communication port of the first device is initialized and enabled, the FSBL program will generate a standardized handshake request message according to the preset communication protocol specifications. This message is a fixed-format instruction data frame containing core fields such as the device identifier of the first device, the FMQL chip model, the communication port parameter identifier, and the handshake request instruction code, possessing uniqueness and resolvability. Subsequently, the FSBL program will control the communication port to send the handshake request message to the second device, and simultaneously start the timing module and the request count statistics module to record the response waiting time and the number of handshake request transmissions in real time, providing data support for subsequent timeliness determination and count limits.

[0091] After the first device sends a handshake request message, it enters a response waiting window with a first preset time. In this embodiment, this window is 20ms, and the timing module counts the waiting time in real time. If the first device receives a response message from the second device through the communication port within this time, the FSBL program will immediately stop timing and start the validity check of the response message. If no response message is received after the first preset time, it will directly trigger a judgment on whether the number of handshake request messages sent has reached the preset number of handshakes. The validity check of the response message is the core step. The FSBL program will perform a comprehensive verification of the format, fields, and content of the response message according to the preset protocol, including whether the message frame header and footer conform to the specifications, whether the device identifier matches the interaction identifier in the handshake request message, whether the response command code is the preset handshake confirmation code, and whether the data field is free of redundancy or missing data. Only when all verification items meet the preset requirements is the response message judged to be correct; otherwise, it is judged to be incorrect. This step verifies the feasibility of communication interaction from two dimensions: link smoothness and message resolution, through the dual judgment of timeliness and validity, avoiding false verification caused by link delay and message corruption.

[0092] Once the FSBL program determines that a single received response message is correct, it will initiate a statistical determination of the number of consecutive correct responses. In this embodiment, the preset number of consecutive correct responses is 3, meaning that 3 consecutive interactions of "handshake request correct response" are required. The FSBL program will accumulate the number of consecutive correct responses. If the current accumulated result has not yet reached the preset value, it will continue to maintain a communication waiting state, waiting for the next handshake request to be sent and responded to; if the accumulated result has reached the preset value, it will directly trigger a handshake success determination. This embodiment eliminates special cases such as occasional smooth communication links and momentary interference-free periods through multiple consecutive effective interactions, making the handshake verification result more closely reflect the actual stable state of the communication link, and significantly improving the accuracy and reliability of the verification result.

[0093] When the number of consecutive correct responses counted by the FSBL program reaches the preset value, it indicates that the communication hardware of the first device and the second device are matched, the communication parameters are consistent, the communication link has a continuous and stable data transmission capability, and the message parsing and processing logic of both parties is fully compatible. At this time, the FSBL program will officially determine that the handshake operation is successful, and at the same time reset all data in the timing module, request count statistics module and consecutive correct response count statistics module to prepare for the subsequent communication connection establishment and data transmission.

[0094] Furthermore, for all unsuccessful interaction scenarios: firstly, the number of consecutive correct responses has not reached the preset value, and the system is still in the continuous verification phase; secondly, a single received response message is determined to be incorrect; and thirdly, no response message is received after the first preset time has elapsed. The FSBL program will no longer wait, but will instead call the request count statistics module to check whether the cumulative number of times the current handshake request message has been sent has reached the preset handshake count. In this embodiment, the preset value is 5 times. This serves as the boundary to implement the logical branching between "continue request" and "terminate handshake," avoiding infinite requests caused by continuous link anomalies and reducing the execution overhead of the FSBL program and the resource consumption of the device.

[0095] When the FSBL program determines that the cumulative number of handshake requests has not yet reached the preset handshake count, it indicates that there is still room for retry verification. At this time, the timing module will be reset, the response detection result of this time will be cleared, and then a standardized handshake request message will be sent to the second device again through the communication port to continue the handshake verification process. The retry mechanism provides a certain fault tolerance for the communication link, which can effectively avoid handshake failures caused by non-permanent anomalies such as momentary interference in the link and accidental packet loss, thereby improving the success rate of handshake operations and adapting to the actual needs of complex communication scenarios such as industrial sites and military environments.

[0096] When the FSBL program determines that the cumulative number of handshake requests has reached the preset number of handshakes and that a valid interaction has not yet been achieved for the preset number of consecutive correct attempts, it indicates that there is a persistent abnormality in the communication link between the first device and the second device, or that there is a problem with the communication hardware or parameters that cannot be matched. There is no practical significance in continuing to retry. At this time, the FSBL program will officially determine that the handshake operation has failed and terminate the operation of all modules related to the handshake.

[0097] This invention provides an extremely reliable pre-verification scheme for establishing communication connections during FMQL chip software upgrades. Through a triple judgment method of timeliness, effectiveness, and continuity, it comprehensively verifies the communication link from the dimensions of response waiting time, message format and content, and number of consecutive interactions. This eliminates interference from factors such as link delay, occasional smoothness, and message corruption, enabling the handshake verification results to accurately reflect the actual stable state of the communication link. This significantly improves the accuracy and reliability of handshake judgment and lays a solid communication foundation for subsequent stable data transmission.

[0098] In some alternative implementations, step d2 above includes: Step e1: Within the first preset time after the handshake request message is sent, is there one and only one response message received? Step e2: If there is only one response message received, determine whether the response message matches the preset format. Step e3: If the response message matches the preset format, determine whether the content of the data area field of the response message is the same as that of the handshake request message; Step e4: If the data field content of the response message is the same as that of the handshake request message, then the response message is confirmed to be correct.

[0099] Specifically, after the FSBL program of the first device sends a handshake request message to the second device, it immediately opens a 5ms time window and starts the message counting module to perform real-time statistics on all messages received through the communication port within this time window. This step is the first barrier to verify the validity of the response message, and its core function is to verify the uniqueness and stability of the communication link transmission. If the message counting module counts 1 within 5ms, that is, only one response message has been received, it indicates that there is no message redundancy problem caused by message retransmission, random transmission, or interference from multiple devices, and the subsequent verification stage can proceed. If the count is 0, it indicates that there is no response from the link. If the count is greater than 1, it indicates that there is an abnormal message transmission in the link, which may be due to the simultaneous receipt of a previously unreceived message and a retransmitted message. In both cases, the response message is directly determined to be invalid, and the subsequent verification is terminated. By using quantity verification, the impact of multiple message interference on subsequent parsing verification is avoided at the transmission level, which is a basic prerequisite for ensuring the validity of the response message. The 5ms time threshold setting takes into account both the transmission delay of serial communication and avoids the occupation of device processing resources due to excessive waiting.

[0100] After confirming that only one response message has been received within 5ms, the FSBL program immediately initiates a standardized verification of the message format. This preset format is a handshake response message format pre-defined in the FMQL chip software upgrade communication protocol, containing fixed structured fields such as frame header identifier, frame trailer identifier, message length, command code segment, data segment, and checksum segment. The byte length, data type, and value range of each field are clearly and uniquely defined. The FSBL program will parse and verify the received response message field by field according to this preset format, checking whether the frame header and trailer are the fixed bytes specified by the protocol, whether the total message length is consistent with the preset value, whether the command code is a unique identifier for the handshake response, and whether the byte offset of each field conforms to the specification. Only when the parsing results of all fields completely match the preset format, and there are no issues such as missing fields, redundancy, or offsets, is the format verification considered successful. This embodiment is the core step in verifying the validity of the response message, ensuring that the received message is a legitimate handshake response message that conforms to the protocol specification, rather than garbled characters or other irrelevant command messages caused by link interference, thus guaranteeing the parsability of the message at the format level.

[0101] After the response message passes format verification, it enters the content consistency verification stage. The data area fields are the core interaction carriers of the handshake request message and response message, containing key information such as device identifier, communication port parameters, and interaction sequence number. These are the core basis for matching the communication identities and interaction intentions of the upper and lower computer. The FSBL program extracts all field content from the handshake response message data area and simultaneously retrieves the original data area content of the locally sent handshake request message, performing a byte-by-byte, full-content comparison verification. This comparison is a precise binary data comparison; only when the data area field content of the two is completely identical, with no byte differences, is the content consistency verification considered successful. This embodiment ensures that the received response message is an accurate response from the second device to the currently sent handshake request message, rather than a delayed response to a historical request message or an erroneous response from another device, achieving precise matching of the interaction intentions of the upper and lower computer at the content level.

[0102] Once the response message passes the above three verification steps, the full-dimensional validity verification is completed. At this point, the FSBL program will officially determine that the handshake response message is a correct, legal, and valid response message.

[0103] This invention provides an extremely rigorous and accurate validity determination scheme for the communication handshake process in FMQL chip software upgrades by constructing a three-level handshake response message verification system. It performs full-dimensional validity testing of the handshake response message from three dimensions: the uniqueness of communication transmission, the legality of the message format, and the consistency of the interaction content. This completely eliminates interference from various abnormal situations such as link interference, message garbled characters, multiple device responses, and historical message delays, ensuring that the correctness determination of the response message has sufficient and rigorous factual basis. This significantly improves the accuracy and reliability of handshake verification, laying a solid core verification foundation for the establishment of subsequent communication connections.

[0104] This invention also provides a software upgrade method based on FMQL, applied to a second device, such as... Figure 7 As shown, the method includes: Step S701: Configure the communication parameters of several communication ports. The communication port is the communication port of the PS end in at least one FMQL chip, and the FMQL chip is integrated in the first device. Step S702: Establish a communication connection with at least one first device through each communication port; Step S703: Select upgrade files including PL software and / or PS software; Step S704: Send the upgrade file to the first device so that the first device can use the upgrade file to update the target software of the FMQL chip via the FSBL program.

[0105] Specifically, this embodiment provides an FMQL-based software upgrade method for a second device. The second device, acting as the master control terminal for the software upgrade, first needs to configure parameters matching the communication port of the first device. The configured communication port is a physical port on the second device that matches the communication port type of the PS terminal of the FMQL chip in the first device. If the first device uses a serial port for upgrade communication, the second device will configure its own serial port communication parameters accordingly. Communication parameters are the core foundation for ensuring stable establishment of the communication link between the upper and lower devices and reliable data transmission. These parameters include key parameters such as baud rate, data bits, stop bits, and parity bits. For example, a standard serial port parameter with a baud rate of 115200bps, 8 data bits, 1 stop bit, and no parity bit can be configured. All configured parameters must be completely consistent with the preset parameters of the PS terminal communication port of the FMQL chip in the first device to avoid subsequent communication failures due to parameter mismatch. The second device supports simultaneous configuration of multiple communication ports. Each communication port can correspond to one first device. The communication parameters of multiple first devices can be configured independently through differentiated port numbers, providing a communication foundation for subsequent batch upgrades. After configuration, the communication port will be in a ready state and can initiate a communication connection establishment request with the first device at any time.

[0106] After configuring the communication port parameters, the second device will use each configured communication port to perform a handshake interaction with the corresponding first device, establishing a stable point-to-point communication connection. This connection establishment process is collaboratively completed by the second and first devices. The second device, acting as the master control unit, will monitor handshake request messages on each communication port in real time. Upon receiving a standardized handshake request message from the first device, it will generate a corresponding handshake response message according to the preset communication protocol and send it to the first device through the corresponding communication port, subsequently completing multiple rounds of handshake interaction verification with the first device. Once both parties have completed a valid handshake verification, the second device and the corresponding first device establish a reliable communication connection through that communication port. Both the physical and data link layers of the link are in a stable and ready state, supporting efficient transmission of subsequent upgrade request messages and upgrade files. If the second device is configured with multiple communication ports, it can perform handshake interactions and connection establishment with multiple first devices in parallel, enabling batch construction of communication links for multiple devices, significantly improving upgrade efficiency. Successfully established communication connections will remain open until the entire software upgrade process is completed before being actively disconnected.

[0107] After establishing a stable communication connection with the first device, the second device will enter the upgrade file selection phase. This phase is crucial for achieving accurate FMQL chip software upgrades. Based on actual upgrade requirements, the device can flexibly select the type of upgrade file to be issued, including standalone PL software, standalone PS software, or a combined upgrade file containing both PL and PS software. The PL software is the bitstream configuration program for the FMQL chip's programmable logic side, used to configure the hardware logic of the chip's PL side. The PS software is the runtime program for the chip's processing system side, which can be a bare-metal program or an embedded program containing an operating system. Both are standardized software image files adapted to the FMQL chip model and have been pre-stored on the second device's local storage medium. The second device provides a visual interface for technicians to select upgrade files. The upgrade file type can be selected individually for a single first device, or the same upgrade file type can be configured uniformly for multiple first devices to meet differentiated and batch upgrade needs. After selection, the second device will pre-parse the selected upgrade file, extracting key information such as file type and file size, providing data support for generating subsequent software upgrade request messages.

[0108] After selecting the upgrade file, the second device will, according to the preset communication protocol, first send a software upgrade request message containing key information such as the upgrade file type and size to the first device. This message serves as the core parameter basis for the first device to perform the upgrade operation. Upon receiving the message, the first device will complete preparatory work such as locating the target storage sub-area. Upon receiving the file reception ready message from the first device, the second device will process the selected upgrade file into blocks. Following the Xmodem-1K protocol, large upgrade files will be divided into standard 1024-byte data packets. If it is a combined upgrade file, it will be divided into blocks according to the storage logic of the PL and PS software. Then, through the established communication port, the data packets will be sent to the first device one by one. During the sending process, the second device will receive real-time data packet verification feedback from the first device. If a retransmission instruction is received, the corresponding data packet will be retransmitted immediately to ensure that each data packet can be effectively received by the first device. The second device will continue to send all data packets until the entire upgrade file is transmitted. The first device will then complete the receiving, verification, storage, and image header table update operations of the upgrade file through the FSBL program, ultimately achieving the update of the FMQL chip target software. If the second device establishes a communication connection with multiple first devices, it will send upgrade files to each first device sequentially or in parallel according to the preset upgrade strategy, thereby realizing the batch upgrade of the FMQL chip software of multiple devices. The entire file sending process is controlled by the second device to ensure the integrity and reliability of the upgrade file transmission.

[0109] This invention provides a master-level control system for upgrading FMQL chip software using a second device. The second device centrally configures the communication port parameters, enabling simultaneous configuration of multiple ports and batch connection with multiple first devices. This significantly improves the efficiency of FMQL chip software upgrades, making it particularly suitable for upgrading multi-device clusters in industrial measurement and control, military equipment, and other applications. Flexible upgrade file type selection allows for individual upgrades of PL or PS software based on actual needs, avoiding the time and bandwidth waste associated with whole-image burning and achieving precise software upgrades. Standardized communication protocols and data transmission enable chunked distribution and retransmission of upgrade files, ensuring the integrity and reliability of upgrade file transmission and providing effective data support for software updates on the first devices. Simultaneously, the second device, acting as the master controller, centrally manages the entire upgrade process, monitoring the link status and file distribution progress of each communication port in real time. This facilitates management and maintenance of upgrade operations by technicians, reducing the operational complexity of multi-device upgrades. This method is compatible with common communication ports such as serial ports, eliminating the need for dedicated upgrade hardware and resolving the issue of opening the device cover for FMQL upgrades.

[0110] In some optional implementations, the formats of various communication protocols between the first device and the second device can be understood with reference to the following: 1. General Part: Bit conventions and multi-byte conventions: Regarding the definition of data bits in a byte, bit0 represents the least significant bit, and bit7 represents the most significant bit.

[0111] Unless otherwise specified, multi-byte data is sent in big-endian mode, with the high byte sent first and the low byte sent later.

[0112] Data transmission method: Data is transmitted in frames, which means that all data from the frame header to the frame tail is packaged into a complete data frame according to the frame format requirements, and then the data is sent out continuously in one go using the serial communication physical layer protocol.

[0113] Data type table:

[0114] Protocol format: Data frames have a fixed format, consisting of six parts: frame header, address, data area length, data area, data checksum, and frame trailer. See the table below for details:

[0115] The following describes the different parts of the data frame: The frame header of the communication protocol is fixed as the hexadecimal number 0xEB90AA55.

[0116] The address indicates the source address for sending data and the destination address for receiving data. Device addresses are shown in the table below.

[0117]

[0118] The data area length represents the length of valid data in bytes, and its value is a multiple of 4, ranging from 4 to 512.

[0119] Data verification involves generating a CRC16 / XMODEM checksum from the frame header to all data before verification, using the polynomial: .

[0120] 2. Software upgrade communication format: Command word:

[0121] Handshake request message:

[0122] Handshake in response to the message:

[0123] The process start message sent from the lower-level machine to the upper-level machine:

[0124] Software upgrade request message:

[0125] Operation method:

[0126] When the operation mode is 0x03, the "auxiliary flag" represents the partition number of the PS. If the only or first PS partition is being upgraded, the "auxiliary flag" is set to 0; if the second PS partition is being upgraded, the "auxiliary flag" is set to 1; if the third PS partition is being upgraded, the "auxiliary flag" is set to 2, and so on. When the operation mode is not 0x03, the "auxiliary flag" is set to 0, and in this case, the first device will ignore the "auxiliary flag" field.

[0127] This embodiment also provides a software upgrade system based on FMQL, such as Figure 8 As shown, the device includes a first device and a second device. The first device integrates an FMQL chip. The second device configures communication parameters for several communication ports, each of which is a communication port on the PS side of at least one FMQL chip. The first device powers on and runs a firmware program to initialize basic configuration parameters and load the FSBL program. The first device initializes the PS side based on the FSBL program and opens the communication port on the PS side. Based on the FSBL program, the first device establishes a communication connection with the second device through the communication port. An upgrade file is sent to the first device. The first device updates the target software of the FMQL chip using the upgrade file through the FSBL program.

[0128] Specifically, the principles and technical effects of the FMQL-based software upgrade system can be found in the descriptions of the aforementioned method embodiments, and will not be repeated here.

[0129] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0130] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0131] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A software upgrade method based on FMQL, characterized in that, Applied to a first device integrating an FMQL chip, the method includes: Power on and run the firmware program to initialize the basic configuration parameters of the first device and load the FSBL program; The PS terminal is initialized based on the FSBL program, and the communication port of the PS terminal is opened. The communication parameters of the communication port are preset in the second device, and the communication parameters of the target port are preset in the first device. The target port is the port deployed on the second device according to the type of the communication port. Based on the FSBL program, the first device establishes a communication connection with the second device through the communication port; The FSBL program receives the upgrade file sent by the second device and uses the upgrade file to update the target software of the FMQL chip.

2. The method according to claim 1, characterized in that, The old version of the target software before the update and the new version of the target software after the update are stored in different storage areas of the FMQL chip, and the method further includes: When the target software of the FMQL chip is successfully updated using the upgrade file, the new version of the target software is loaded based on the FSBL program, and the first device is controlled to run through the new version of the target software. When updating the target software of the FMQL chip using the upgrade file fails, the old version of the target software is loaded based on the FSBL program, and the operation of the first device is controlled by the old version of the target software.

3. The method according to claim 2, characterized in that, The FMQL chip's storage chip is divided into a boot image header, an image header table, a partition header table, an FSBL storage area, an image selection setting area, a first software image storage area, and a second software image storage area. The boot image header records the address range of the FSBL storage area, which stores the FSBL program. The first software image storage area includes a first PL sub-area and a first PS sub-area, and the second software image storage area includes a second PL sub-area and a second PS sub-area. The first PL sub-area and the second PL sub-area are used to alternately store new and old versions of PL software from new and old versions of the target software, and the first PS sub-area and the second PS sub-area are used to alternately store new and old versions of PS software from new and old versions of the target software. The image selection setting area records the loading flags selected from the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area as software loading areas. The image header table describes the partition header table, which records the address range of the corresponding software in the first PS sub-area, the second PS sub-area, the first PL sub-area, and the second PL sub-area.

4. The method according to claim 3, characterized in that, The step of receiving the upgrade file from the second device based on the FSBL program and updating the target software of the FMQL chip using the upgrade file includes: Receive a software upgrade request message sent by the second device, wherein the software upgrade request message is used to describe whether the upgrade file is PL software and / or PS software, and the software size corresponding to the upgrade file; In response to the software upgrade request message, determine that there is no target sub-region with the loading flag set; The upgrade file is received and verified through the target sub-region; When the verification passes, it indicates that the upgrade file has successfully updated the target software of the FMQL chip. The loading flag is changed for the target sub-region by selecting the mirror settings area; Update the partition header table and the boot image header using the corresponding software address range in the target sub-region; If the verification fails, it indicates that the upgrade file has failed to update the target software of the FMQL chip.

5. The method according to claim 4, characterized in that, The communication port is at least one of a serial port, an Ethernet port, or a CAN bus port, and the receiving and verification of the upgrade file includes: Receive the data packet containing the upgrade file sent by the second device; Perform format validation on the data packet; When the format verification passes, the data packet is stored in the target sub-area; When all data packets are stored in the target sub-region, the integrity of the upgrade file is verified. The upgrade file is deemed to have passed verification when the integrity check passes.

6. The method according to claim 1, characterized in that, The step of controlling the first device to establish a communication connection with the second device through the communication port based on the FSBL program includes: The first device is controlled to perform a handshake with the second device through the communication port; If the handshake is successful, the first device establishes a communication connection with the second device through the communication port; If the handshake fails, the FSBL program loads the outdated target software and controls the operation of the first device through the outdated target software.

7. The method according to claim 6, characterized in that, The control of the first device to perform a handshake with the second device through the communication port includes: A handshake request message is sent to the second device through the communication port; If a response message is received from the second device within a first preset time, then check whether the response message is correct; If the response message is correct, then determine whether the preset number of consecutive correct responses has been reached; If the preset number of consecutive correct handshakes is achieved, the handshake is considered successful. If the preset number of consecutive correct responses is not reached, the response message is incorrect, or the response message is not received within a first preset time, then it is determined whether the number of times the handshake request message has been sent has reached the preset number of handshakes. If the preset number of handshakes is not reached, return to the step of sending a handshake request message to the second device through the communication port; If the preset number of handshakes is reached, the handshake is deemed to have failed.

8. The method according to claim 7, characterized in that, The detection of whether the response message is correct includes: Within a first preset time after the handshake request message is sent, is there one and only one response message received? If there is one and only one response message received, then determine whether the response message matches the preset format; If the response message matches a preset format, then it is determined whether the content of the data area field of the response message is the same as that of the handshake request message; If the data field content of the response message is the same as that of the handshake request message, then the response message is considered correct.

9. A software upgrade method based on FMQL, characterized in that, Applied to a second device, the method includes: Configure communication parameters for several communication ports, wherein the communication port is a communication port of the PS end in at least one FMQL chip, and the FMQL chip is integrated in the first device; Establish a communication connection with at least one of the first devices through each communication port; An upgrade file is sent to the first device so that the first device can use the upgrade file to update the target software of the FMQL chip via the FSBL program.

10. The software upgrade method according to claim 9, characterized in that, Before sending the upgrade file to the first device, the method further includes: The upgrade files selected include PL software and / or PS software.

11. A software upgrade system based on FMQL, characterized in that, It includes a first device and a second device, wherein the first device integrates an FMQL chip. The second device is configured with communication parameters for several communication ports, wherein the communication port is a communication port of the PS end in at least one FMQL chip; The first device powers on and runs the firmware program to initialize basic configuration parameters and load the FSBL program; The first device initializes the PS terminal based on the FSBL program and opens the communication port of the PS terminal; Based on the FSBL program, the first device establishes a communication connection with the second device through the communication port; Send the upgrade file to the first device; The first device updates the target software of the FMQL chip using the upgrade file via the FSBL program.

Images