A CAN bus-based method for reverse firmware update in FPGA

Abstract

This invention proposes a reverse-order firmware update method for FPGAs based on a CAN bus, belonging to the technical field of FPGA firmware update. The invention includes: a host computer sending an upgrade start command to the FPGA via the CAN bus; the FPGA returning parameters from its Flash memory; data fragmentation from the end of the firmware file to be updated on the FPGA, forming a reverse-order fragment queue from the firmware end to the firmware beginning; the host computer sending firmware fragments sequentially according to the reverse-order fragment queue; the FPGA receiving the firmware fragments and verifying them; if verification fails or times out, the current firmware fragment is retransmitted; the FPGA writing the verified firmware fragments sequentially from high address to low address in the Flash memory; the FPGA recording the fragment number of successfully written firmware fragments; triggering a breakpoint resume processing path after an abnormal interruption; the host computer sending an upgrade completion flag frame, and the FPGA performing overall verification. This invention achieves high reliability, high efficiency, and high security for remote FPGA upgrades without increasing hardware costs.

Description

Technical Field

[0001] This invention relates to the technical field of FPGA firmware updates, and more particularly to an FPGA reverse firmware update method based on a CAN bus. Background Technology

[0002] Existing FPGA firmware remote update solutions based on CAN bus mainly adopt the following methods:

[0003] 1. Sequential Slicing and Sequential Programming: The host computer slices the firmware in ascending order of address, and the FPGA writes it into the Flash memory in the same order.

[0004] 2. Simple packet transmission: Most CAN bus communication firmware update schemes use simple packet transmission, without strict acknowledgment and timeout retransmission mechanisms, or rely solely on the underlying CAN bus hardware acknowledgment.

[0005] 3. Dual backup partition switching: Existing technologies generally prevent bricking by dividing the Flash memory into dual backup partitions (primary partition + backup partition). During the update, the backup partition is written first, and the boot pointer is switched after the verification is successful. This ensures that the original firmware is not damaged during the entire update process. The boot partition is switched only after the new firmware has been completely verified to be correct, thus avoiding the interruption of the update and bricking of the device.

[0006] 4. UDS Protocol Upgrade: Some solutions are based on the UDS (Unified Diagnostic Service) protocol to update the Bootloader, but they also use a sequential write method.

[0007] The above solution has the following problems:

[0008] 1. Prone to "Bricking": In sequential flashing, the update process starts from the low address. If power is lost or communication is interrupted during the process, the low address bootloader may have been partially erased or written with incomplete data, causing the device to fail to boot again and become "bricked". Although the existing dual backup solution solves this problem, it requires twice the Flash space.

[0009] 2. Lack of reliable transmission mechanism adapted to CAN bus: CAN bus has low bandwidth (maximum 1Mbps), is susceptible to electromagnetic interference, and has a high packet loss rate. Existing solutions lack response, retransmission, and breakpoint resumption mechanisms specifically designed for CAN bus, resulting in a low update success rate.

[0010] 3. Weak ability to resume interrupted transmission: Existing solutions usually require retransmitting all firmware from scratch after an interruption, which significantly prolongs the upgrade time on the low-bandwidth CAN bus.

[0011] 4. Poor fault tolerance for upgrade failures: The lack of a multi-level verification mechanism makes it difficult to guarantee firmware integrity, which can easily lead to device failure and high maintenance costs.

[0012] 5. High Flash resource consumption: The dual backup partition scheme requires the Flash capacity to be at least twice the firmware size, resulting in high hardware costs in resource-constrained embedded FPGA systems.

[0013] Therefore, the existing technologies have the following technical difficulties:

[0014] 1. Challenges to transmission reliability under low bandwidth of CAN bus: The bandwidth of CAN bus is usually only 125kbps~1Mbps, and the electromagnetic interference in industrial environment is strong, resulting in a high probability of frame loss and frame errors. The core challenge is how to ensure transmission reliability while avoiding excessive retransmission overhead.

[0015] 2. Challenges in the security mechanism against bricking: How to fundamentally prevent power outages during upgrades from damaging the boot sector without using dual backup partitions (i.e., without increasing Flash capacity) is a long-standing technical problem in this field.

[0016] 3. Engineering difficulties in implementing the reverse order update mechanism: Reverse order writing requires address calculation, sector erasure, and data writing to be performed in reverse order, and it must be coordinated with the CAN bus receiving process, resulting in high engineering complexity.

[0017] 4. Challenges of multiple verifications for update integrity: The connection between single-frame verification and overall verification, and the rollback process after verification failure, must be reliably implemented under limited hardware resources.

[0018] Therefore, the technical problems that existing research needs to solve are:

[0019] (1) During the firmware update process based on the CAN bus, the bootloader is easily damaged if the power is cut off or communication is abnormal during the upgrade, causing the device to become "bricked" and unable to start again.

[0020] (2) Although the traditional dual backup partition scheme can prevent bricking, it requires double the Flash space, resulting in high hardware cost and low resource utilization in resource-constrained embedded FPGA systems.

[0021] (3) The CAN bus has low bandwidth and is susceptible to electromagnetic interference. The firmware transmission packet loss rate is high. Existing solutions lack a fragmented response and timeout retransmission mechanism adapted to the CAN bus, resulting in a low update success rate.

[0022] (4) Existing firmware updates lack precise breakpoint resume capability. After the upgrade is interrupted, the transmission needs to be started from scratch, which seriously prolongs the upgrade time on the low-bandwidth CAN bus.

[0023] (5) The update process lacks multi-level verification, making it difficult to guarantee the integrity of the firmware and prone to abnormal operation after the update. Summary of the Invention

[0024] To address the technical problem that traditional sequential writing can easily damage the low-address bootloader, leading to device "bricking," this invention proposes an FPGA reverse firmware update method based on the CAN bus. The host computer segments, numbers, and sends the firmware from the end, and the FPGA writes it sequentially from the highest address to the lowest address in the Flash memory. This achieves reverse firmware segmentation and reverse writing, preventing device bricking even without backup partitions and saving Flash resources.

[0025] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0026] It is important to note that the "reverse order" described in this invention has a specific meaning: firstly, it refers to the reverse order of fragment content extraction: the host computer starts from the end of the FPGA firmware file and fragments and sends data towards the beginning of the file, rather than starting from the beginning; secondly, it refers to the reverse order of the target write addresses—the Flash target address corresponding to each fragment is allocated sequentially from high to low address, rather than the traditional low to high address. The fragment number can be sequentially increased from the beginning to the end of the file, or sequentially increased from the end to the beginning of the file. The CAN bus sends data in reverse order from the end to the beginning of the file for FPGA reception and progress management. Therefore, the "reverse order update" of this invention is essentially a reversal of the writing direction of firmware data in the Flash storage space, and this reversal is the technical basis for preventing bricking.

[0027] Before being sent, the firmware fragment is split into multiple physical frames by the host computer according to a preset multi-frame transmission protocol, which conforms to the single-frame payload length limit of the CAN bus. After receiving the fragment, the FPGA reassembles the physical frames into a complete firmware fragment according to the multi-frame transmission protocol, and then performs verification and writing.

[0028] An FPGA reverse firmware update method based on CAN bus includes the following steps:

[0029] Step 1: The host computer sends an upgrade start command to the FPGA via the CAN bus, and the FPGA returns the parameters of the Flash memory;

[0030] Step 2: The host computer reads the FPGA firmware file to be updated, and starts from the end of the FPGA firmware file to divide the data into segments according to a preset fixed length, and sequentially numbers them to form a reverse order segment queue from the end of the firmware to the beginning of the firmware.

[0031] Step 3: The host computer sends firmware fragments sequentially through the CAN bus according to the order of the reverse fragment queue. After receiving each firmware fragment, the FPGA performs verification. If the verification is successful, it replies to the host computer with a verification success response frame. If the verification fails, it replies to the host computer with a verification failure response frame. If the verification fails or no response is received within the timeout period, the host computer retransmits the current firmware fragment.

[0032] Step 4: The FPGA writes the verified firmware fragments sequentially from the high address to the low address of the Flash memory.

[0033] Step 5: The FPGA records the fragment number of the successfully written firmware fragment in the non-volatile memory area; after an abnormal interruption, the breakpoint resume processing path is triggered, and the process returns to step 3.

[0034] Step 6: The host computer sends an upgrade completion flag frame, and the FPGA performs an overall verification.

[0035] Preferably, the upgrade start command carries the total firmware length and the overall firmware checksum; the Flash memory parameters include the Flash start address, Flash end address, and sector size; after receiving the upgrade start command, the FPGA automatically jumps to the bootloader program, clears and initializes the format of the breakpoint record area in the non-volatile memory used to store breakpoint information; the bootloader program calls the on-chip Flash driver interface to obtain the storage parameters corresponding to the Flash memory, and returns them to the host computer via the CAN bus;

[0036] The FPGA firmware file contains all the logic configuration code, bootloader and application data required for FPGA operation; the FPGA reads the FPGA firmware from the Flash memory; the data of each firmware chip is further divided into multiple CAN data according to the effective data length of a single frame, and the effective data length of a single frame is the effective data payload length that a single CAN bus can carry;

[0037] The firmware header is the starting position of the FPGA firmware file, which includes power-on boot information, bootloader startup code, and address base address information. The firmware tail is the end position of the FPGA firmware file, which contains the firmware backend application logic data.

[0038] Preferably, each firmware segment includes a segment number, a Flash target address, data content, and a single-segment checksum, and the response frame includes the segment number that has been successfully received, the receiving status, and the current Flash write progress information;

[0039] The upgrade completion flag frame is a CAN command frame sent by the host computer, carrying a fixed identifier code, the total firmware length, and the overall check value.

[0040] Preferably, the fragment number is used to identify the order of firmware fragments in the reverse fragment queue, the Flash target address mark needs to be written to the corresponding physical address of the FPGA internal Flash, the data content is the original valid firmware data corresponding to the firmware fragment, and the single-chip check code is the CRC16 check value generated by the single-chip data of the firmware fragment.

[0041] The verification method is as follows: after the FPGA receives the data content of the firmware fragment, it recalculates the CRC16 check value and compares it with the single-chip check code carried in the fragment. If they match, the verification passes; otherwise, the data transmission is determined to be faulty.

[0042] Preferably, a fixed address range is pre-divided in the on-chip Flash memory of the FPGA, and the lowest address segment of the Flash is defined as a fixed start area for storing the bootloader program; during the writing process, the host computer and the FPGA agree on updating the write address boundary by combining the obtained Flash start address and Flash end address; the fixed start area located in the lowest address segment of the Flash memory is not erased or written.

[0043] Preferably, when an interruption occurs and the process restarts during the upgrade, the FPGA reads the segment number recorded in the non-volatile memory area to obtain the breakpoint segment number, and reports the breakpoint information to the host computer. The host computer then continues to send subsequent firmware segments from the interruption location based on the breakpoint segment number.

[0044] After receiving the upgrade completion flag frame, the FPGA performs verification on all firmware in the Flash memory. If the verification passes, it jumps to the application program to run, sets the completion flag, and clears the non-volatile memory area; if the verification fails, it reports the failure status and waits for a new update.

[0045] Preferably, the method by which the FPGA writes the verified firmware fragments sequentially from high address to low address in the Flash memory is as follows:

[0046] Determine if the Flash target address of the current segment is located in a new Flash sector; if so, perform Flash sector erasure.

[0047] Write the data fragmented from the solid-state chip into the Flash application area corresponding to the Flash target address;

[0048] After writing, immediately read back and compare with the original cached data. If they match, the write is successful; if they do not match, the write is considered abnormal, an error is marked, and retransmission is requested.

[0049] Update the current fragment number to the breakpoint record area of ​​the Flash memory.

[0050] Preferably, the host computer reads the FPGA firmware binary file to be updated and constructs a reverse-order update package as follows: starting from the end of the FPGA firmware binary file, each preset fixed-length byte is divided into a firmware fragment, numbered sequentially from the end of the file to the beginning in descending or ascending order; the target address corresponding to the last firmware fragment = the highest Flash address - fragment data length + 1; the target addresses of subsequent firmware fragments decrease sequentially; the host computer sends the firmware fragments in the order from the end of the file to the beginning of the file; after each firmware fragment is sent, a timeout timer is started: if an ACK response is received, the next firmware fragment is sent; if a NAK response is received or a timeout occurs, the current firmware fragment is retransmitted; the same fragment can be retransmitted a maximum of a preset fixed number of times, after which an upgrade failure is reported to the host computer;

[0051] The FPGA sets the firmware update completion status bit preset in the non-volatile memory area to 1, thus solidifying the status indicator of this successful update.

[0052] The host computer retransmits all CAN physical frames corresponding to the firmware fragment, and sets the reverse order update flag in the ID of the CAN physical frame;

[0053] The bootloader reads the latest completed segment number from the breakpoint record area of ​​the Flash memory; reports the breakpoint information via the CAN bus; after receiving the breakpoint information, the host computer obtains the breakpoint location and continues to send subsequent firmware segments starting from the breakpoint segment number +1 or the breakpoint segment number -1.

[0054] Perform CRC32 verification on all firmware in the Flash application area; compare the verification result with the overall verification value of the firmware sent by the host computer; if the comparison is inconsistent, maintain Bootloader mode, report the failure status, and wait for a new update.

[0055] An FPGA reverse firmware update system based on CAN bus includes a host computer for remote updates, a CAN bus transceiver, and an FPGA node device with Flash memory. The host computer is connected to the FPGA node device through the CAN bus transceiver.

[0056] The host computer includes a firmware reversal and fragmentation module, a CAN driver module, an acknowledgment processing and retransmission module, a breakpoint management module I, and an overall verification module; the CAN driver module is connected to the CAN bus transceiver.

[0057] The FPGA node device includes: a CAN communication module, a bootloader module, a reverse addressing control module, a Flash storage control module, a verification module, and a breakpoint management module II. The CAN communication module is connected to the CAN bus transceiver. The CAN communication module, the verification module, and the breakpoint management module II are all connected to the bootloader module. The bootloader module is connected to the reverse addressing control module. The reverse addressing control module is connected to the Flash storage control module. The Flash storage control module is connected to an external Flash memory.

[0058] Preferably, the firmware reversal fragmentation module splits the FPGA firmware file in reverse order from tail to head, generating firmware fragments with sequentially numbered segments, and assigns a corresponding Flash target address to each firmware fragment; the CAN driver module implements the CAN bus underlying message transmission and reception driver, and encapsulates the upgrade start command, fragment data, address information, length information, and checksum according to the protocol; the response processing and retransmission module receives the response messages returned by the FPGA node device in real time, identifies the fragment reception status and verification results, and automatically triggers retransmission for abnormal firmware fragments with verification errors or packet loss; the breakpoint management module receives the breakpoint fragment information uploaded by the FPGA node device, parses the current update progress, and automatically resumes sending firmware fragments from the next fragment after the breakpoint; the overall verification module performs a global CRC32 verification on the entire firmware, generates an overall firmware verification value, and sends it to the FPGA node;

[0059] The CAN communication module completes CAN frame transmission, reception, and parsing; the bootloader module is responsible for firmware update process control, verification, jump, and exception recovery; the Flash storage control module is used to store FPGA configuration firmware; the reverse addressing control module is used to execute data reception and writing from high to low address; the verification module supports single-chip CRC16 verification and overall CRC32 verification; the breakpoint management module records the currently completed segment number in the non-volatile storage area of ​​the Flash memory; the Flash memory is the storage medium for FPGA firmware files, divided into a fixed boot area and an application area.

[0060] The beneficial effects of this invention are:

[0061] (1) The mechanism prevents upgrades from bricking the device, greatly improving security: The firmware is written in reverse order, from high address to low address in the Flash, and the low address boot area is never overwritten during the entire update process. Even if there is a power outage or communication interruption at any time during the upgrade process, the Bootloader remains intact, fundamentally solving the problem of FPGA remote updates being prone to "bricking". At the same time, there is no need to divide the dual backup partition, saving 50% of Flash resources.

[0062] (2) Adapting to CAN bus characteristics, significantly improving transmission reliability: Through fragmented response, timeout retransmission, and single-chip CRC16 verification mechanism, it is specially optimized for the characteristics of low bandwidth, easy interference, and easy frame loss of CAN bus. FPGA only needs to cache single-chip data, which greatly improves the firmware transmission success rate and meets the requirements of harsh electromagnetic environments such as vehicle and industrial control.

[0063] (3) Precise breakpoint resumption, significantly shortening upgrade time: Supports precise breakpoint resumption based on fragment number. After an upgrade interruption, there is no need to retransmit the entire firmware from scratch, significantly reducing the upgrade time of large-volume FPGA firmware on the low-bandwidth CAN bus and improving update efficiency. It should be noted that the breakpoint resumption mechanism of this invention saves more transmission time and bandwidth resources the later the interruption occurs during the update process (i.e., the more fragments have been successfully transmitted). When an interruption occurs when the update is close to completion, the retransmission scheme from scratch needs to retransmit almost the entire firmware, while this invention only needs to transmit the remaining few fragments, with a relative efficiency improvement of over 90%.

[0064] (4) No need for dual backup partitions, saving hardware resources: The boot area is protected by the reverse order mechanism, and no additional backup partition is needed. The Flash capacity requirement is reduced by about 50%, which is suitable for resource-constrained embedded FPGA systems and reduces hardware costs.

[0065] (5) Dual verification ensures firmware integrity and stable and reliable operation: The dual verification strategy of single-chip CRC16 verification + overall firmware CRC32 verification is adopted to ensure that the data is error-free throughout the transmission and writing process, and effectively avoid problems such as firmware damage and program crashes.

[0066] (6) The upgrade completion flag frame realizes the final confirmation of the upgrade integrity: After all firmware data is written, the host computer sends the upgrade completion flag frame to clearly distinguish between the two states of "transmission completed" and "upgrade successful", so as to avoid the problem of incomplete upgrade due to the loss of the last frame.

[0067] In summary, this invention achieves high reliability, high efficiency, and high security for remote FPGA upgrades without increasing hardware costs through reverse order updates, CAN response retransmission, breakpoint resumption, and a mechanism-based anti-brick design. It solves the technical defects of traditional upgrade methods, such as high failure rate, easy equipment damage, and low upgrade efficiency, and has extremely high engineering application value. Attached Figure Description

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

[0069] Figure 1 This is a flowchart of the present invention.

[0070] Figure 2 This is a system block diagram of the present invention.

[0071] Figure 3 This is a schematic diagram comparing reverse writing and sequential writing in this invention.

[0072] Figure 4 This is a timing diagram for CAN bus fragmented response and timeout retransmission according to the present invention.

[0073] Figure 5 This is a flowchart of the breakpoint resume mechanism of the present invention. Detailed Implementation

[0074] 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, and 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.

[0075] Example 1

[0076] like Figure 1 As shown, an FPGA reverse firmware update method based on CAN bus is proposed, which includes a dual security upgrade mechanism of "firmware reverse packetization and reverse burning + final transmission of upgrade completion flag frame", and a reliable transmission protocol of "fragmented acknowledgment + timeout retransmission + precise breakpoint resumption" designed for the characteristics of CAN bus. This invention includes the following steps:

[0077] Step 1, Upgrade Handshake and Parameter Exchange: The host computer sends an upgrade start command to the FPGA via the CAN bus, and the FPGA returns the parameters from the Flash memory.

[0078] The host computer sends an upgrade start command to the FPGA via the CAN bus. The upgrade start command carries the total firmware length and overall verification value. After receiving the upgrade start command, the FPGA enters the bootloader and returns the start address, end address and sector size parameters of the Flash memory via the CAN bus to complete the handshake.

[0079] After receiving the upgrade start command from the host computer, the FPGA first parses and verifies the command, extracting the total firmware length and overall firmware checksum. Then, the system triggers an upgrade interrupt, pausing the currently running user program, responding to the upgrade start command, and entering firmware upgrade mode to await subsequent data transmission and update operations. Once the FPGA recognizes a valid upgrade start command, the hardware automatically jumps to the Bootloader program. The Bootloader program calls the on-chip Flash driver interface to directly read the underlying Flash hardware registers, thereby obtaining the corresponding storage parameters of the Flash memory.

[0080] The starting address defines the lowest physical address of the firmware storage area, limiting the lower bound of the update range and preventing accidental erasure of the FPGA's underlying boot sector and protected area addresses. The ending address defines the highest physical address of the firmware storage area, serving as the starting reference for reverse-order updates in this invention. The host computer uses this to determine the end-of-write position of the firmware, enabling reverse-order programming from high to low addresses. The sector size is the smallest erase unit of Flash memory, used for subsequent firmware fragment alignment, sector-level erase control, and CAN transmission breakpoint progress marking, ensuring that the address matches the erase granularity during reverse-order writing.

[0081] Step 2, Firmware Reverse Fragmentation: The host computer reads the FPGA firmware file to be updated, and starts from the end of the FPGA firmware file to fragment the data according to a preset fixed length, numbering them sequentially to form a reverse fragmentation queue arranged from the end of the firmware to the beginning of the firmware.

[0082] The FPGA firmware file is a complete program image to be burned into the chip, containing all the logic configuration code, bootloader, and application data required for FPGA operation. It is the complete update source data to be distributed and written in this remote update. The FPGA firmware file will eventually be completely written into the FPGA's on-chip Flash memory for hardening and storage. When the device powers on, the FPGA reads the firmware image from the Flash memory and loads it for operation. The entire update process involves splitting the firmware file for transmission and then writing it into the corresponding storage area of ​​the Flash memory. The FPGA firmware file is divided into segments of a preset fixed length. Each segment is further divided into multiple CAN data frames according to the single-frame effective data length. The single-frame effective data length is the effective data payload length that a single CAN bus can carry, and its value is adapted to the CAN 2.0 message specification: the single-frame effective data length ranges from 1 to 8 bytes. The actual segment length is set according to the CAN bus frame load to ensure that each segment of data can be encapsulated into multiple CAN message frames for transmission. Data fragmentation adapts to the hardware limitations of short-frame transmission on the CAN bus, enabling the transmission of large-volume firmware packets. This facilitates fragment-by-fragment verification, frame loss retransmission, and breakpoint resumption. It also facilitates data reassembly by fragment number, avoiding out-of-order transmission and data incompleteness. Furthermore, it reduces the amount of data transmitted per transmission and adapts to the low-bandwidth, high-interference bus environment of CAN. The firmware header, the starting point of the firmware file, contains power-on boot information, bootloader startup code, and address base information, and is a critical area prioritized for device power-on. The firmware tail, the end of the firmware file, contains backend application logic data and is not a critical area for power-on startup. The reverse-order fragment queue serves as the data sequence for subsequent CAN bus transmissions, sending fragments sequentially starting from the firmware tail. The FPGA receives and reassembles the fragments in reverse order according to their numbers. During updates, the higher address of the Flash memory is written first, followed by the lower address, completing the reverse-order firmware update of this invention. This protects the boot area of ​​the firmware header from premature erasure, preventing update interruptions and device bricking.

[0083] Step 3: Fragmented transmission and acknowledgment based on CAN bus: The host computer sends firmware fragments sequentially through the CAN bus according to the order of the reverse fragmented queue. After receiving each firmware fragment, the FPGA performs verification. If the verification is successful, it replies to the host computer with a verification success acknowledgment frame. If the verification fails, it replies with a verification failure acknowledgment frame. If the verification fails or no acknowledgment is received within the timeout period, the host computer retransmits the current firmware fragment.

[0084] Firmware fragmentation breaks down a large-capacity complete FPGA firmware into multiple smaller data fragments, adapting to the short frame transmission limitations of the CAN bus. This facilitates frame-by-frame transmission, fragment-by-fragment verification, and block-by-block writing to Flash memory, while also enabling breakpoint recording and abnormal retransmission. Each firmware fragment contains a fragment number, a target Flash address, data content, and a single-fragment checksum. The fragment number identifies the fragment's order in the reverse queue, facilitating FPGA reception sorting and transmission progress positioning. The target Flash address marks the corresponding physical address where the fragment data needs to be written to the FPGA's internal Flash, providing a basis for address positioning during reverse writing. The data content is the original valid firmware data corresponding to the fragment, representing the program information ultimately burned into Flash. The single-fragment checksum is a CRC16 checksum value generated separately for the current single-fragment data, used by the FPGA to determine whether the received data is erroneous or has suffered frame loss distortion.

[0085] After receiving the segmented data, the FPGA recalculates the CRC16 checksum based on the received data content and compares it with the single-chip checksum carried within the segment. If they match, the check passes; otherwise, a data transmission error is determined. This check can detect frame loss, frame errors, and data distortion caused by electromagnetic interference during CAN bus transmission, ensuring the accuracy of data written to the Flash memory and preventing incorrect firmware from being written to the chip.

[0086] The FPGA sends response frames to the host computer to report the current segment reception and verification results, informing the host computer whether the reception was successful and thus coordinating the transmission rhythm. The response frame includes the segment number that has been successfully received, the reception status (success / failure), and the current Flash write progress information. For abnormal segments that fail verification, time out, or do not receive a response, automatic retransmission is performed, compensating for the CAN bus's susceptibility to interference and high packet loss rate, ensuring complete and reliable transmission of all segments, and improving the firmware update success rate.

[0087] Step 3-1: Firmware fragmentation and CAN physical frame splitting and reassembly

[0088] Since the CAN 2.0 protocol specifies that the maximum data field of a single frame is 8 bytes, and the total length of the operation code, fragment number, target address, data length, data content and CRC16 checksum carried by each firmware fragment far exceeds 8 bytes, it is necessary to split a firmware fragment into multiple CAN physical frames for transmission.

[0089] Frame type definition:

[0090] This upgrade process uses a lightweight, custom multi-frame transmission protocol, defining the following three CAN physical frame types:

[0091] (1) First frame: When the total length of firmware fragments exceeds the single-frame CAN carrying capacity, the host computer sends the first frame first. The 8-byte data field structure of the first frame is shown in Table 1.

[0092] Table 1 First Frame Data Field Definition Table

[0093]

[0094] (2) Data Frames: After the first frame, several data frames are sent sequentially, carrying the actual data content of the firmware fragments. The 8-byte data field structure of the data frame is shown in Table 2.

[0095] Table 2 Data Frame Data Field Definition Table

[0096]

[0097] (3) Check Frame: After all data frames have been sent, a check frame is sent, carrying the lower 16 bits of the destination address and the CRC16 checksum. The 8-byte data field structure of the check frame is shown in Table 3.

[0098] Table 3. Verification Frame Data Field Definition Table

[0099]

[0100] Sending process:

[0101] The host computer executes the following CAN physical frame transmission process for each firmware segment:

[0102] ① Calculate the total length of firmware fragments = 10 (fixed header: 2-byte fragment number + 4-byte destination address + 1-byte data length + 2-byte CRC16 + 1-byte opcode) + the actual number of bytes of data content. When the data content is 256 bytes (full load), the total length is 266 bytes.

[0103] ② Calculate the required number of data frames based on each data frame carrying 6 bytes of valid segmented payload (if the tail frame is less than 6 bytes, only the remaining bytes are carried, and the receiver calculates the number of valid bytes in the tail frame based on the total length).

[0104] ③ Send the first frame to announce the segment number, the total number of CAN physical frames, and the total data length to the FPGA;

[0105] ④ Send the 1st, 2nd, ..., Nth data frames in sequence. The frame sequence number is incremented in the lower 4 bits of the frame type field. The sequence number ranges from 0 to 14, and a maximum of 15 frames are supported (that is, a maximum of 15 × 6 = 90 bytes of segmented payload). If the number is exceeded, it will return to 0 in a loop.

[0106] ⑤ After all data frames have been sent, send a check frame, carrying the complete CRC16 checksum and the lower 16 bits of the target address.

[0107] Receiving and Reassembling Process:

[0108] For each firmware segment, the FPGA performs the following CAN physical frame reception and reassembly process:

[0109] ① The CAN communication module of the FPGA listens to the CAN bus. When it receives a CAN physical frame with opcode 0x02, it determines the frame type based on the high 4 bits of the frame type field.

[0110] ② If it is the first frame (high 4 bits = 0b0001), extract the fragment number and total frame number information, initialize the reassembly buffer, record the current fragment number, and clear the receive counter;

[0111] ③ If it is a data frame (high 4 bits = 0b0010), extract the low 4 bits of the frame sequence number, and write the 6-byte segmented payload into the corresponding offset position of the reassembly buffer in sequence according to the sequence number - the data frame with frame sequence number 0 corresponds to offset 0~5 bytes, the data frame with frame sequence number 1 corresponds to offset 6~11 bytes, and so on.

[0112] ④ If it is a check frame (high 4 bits = 0b0011), extract the CRC16 check code and the low 16 bits of the target address, and concatenate them with the high 16 bits of the target address already received in the first frame to restore the complete 32-bit target address; at this point, the complete firmware fragment logical data packet (fragment number + target address + data length + data content + CRC16 check code) is reassembled.

[0113] ⑤ After receiving the verification frame, the FPGA recalculates the CRC16 checksum of the reconstructed data and compares it with the CRC16 checksum carried in the verification frame:

[0114] If the comparison is consistent, it is determined that the firmware fragment was successfully received, an ACK response frame is sent, and the reverse writing process continues.

[0115] If the comparison is inconsistent, it is determined that the transmission is faulty, and a NAK response frame is sent back. The host computer triggers a segment-level retransmission (all CAN physical frames corresponding to the firmware segment are retransmitted, not just the faulty frame).

[0116] ⑥ If the FPGA fails to receive all CAN physical frames (including check frames) within the preset timeout period (typically 50ms) after receiving the first frame, it will determine that the transmission has timed out, discard the incomplete fragment data, and wait for the host computer to retransmit the fragment at the fragment level.

[0117] Retransmission strategy:

[0118] In this invention, retransmission is based on firmware fragments as the smallest retransmission unit (rather than CAN physical frames). That is, after a verification failure or transmission timeout, the host computer retransmits all CAN physical frames corresponding to that firmware fragment. The same firmware fragment can be retransmitted at a maximum of 3 times at the fragment level. If this number is exceeded, the host computer determines that the upgrade has failed and reports an error to ensure bus efficiency.

[0119] Step 4: Reverse writing to Flash memory: The FPGA writes the verified firmware fragments sequentially from the high address to the low address in the Flash memory.

[0120] Firmware is written sequentially from high address to low address in the Flash memory. This ensures that firmware tail data is written to the high address first, and firmware header data is written to the low address last. Throughout the update process, non-critical application areas are written first, while the underlying boot area is updated later. This fundamentally solves the problem of device bricking caused by power outages or communication interruptions during the update process. It also eliminates the need for additional dual backup partitions, saving Flash storage space. During the writing process, the fixed boot area located in the low address segment of the Flash memory is not erased or written. A fixed address range is pre-defined in the FPGA's on-chip Flash, with the lowest address segment defined as a dedicated fixed boot area. This area stores the bootloader program; the address range is factory preset and cannot be arbitrarily modified by software. This is the core area that the device prioritizes for reading and execution upon power-up. Combining the Flash start address and end address parameters obtained during the handshake phase, the host computer and FPGA jointly agree on the update write address boundary; this update only opens the Flash high address to middle address range for firmware writing, locking the low address fixed boot area; the update write direction is high address to low address in reverse order, and the write range will never touch the low address boot area address boundary; at the software level, address protection shielding is set to prohibit erasing and writing operations on the boot area, thereby protecting this area from being modified throughout the process.

[0121] Step 5, Resume interruption and recovery from an error: The FPGA records the fragment number of the successfully written firmware fragment in the non-volatile memory area; after an abnormal interruption, the resume interruption processing path is triggered, and the process returns to step 3.

[0122] A dedicated area is pre-allocated in the FPGA's on-chip Flash memory as a breakpoint recording area. This breakpoint recording area is independent of the fixed boot area and the application area. This address range is outside the firmware update address boundary and is strictly write-protected. Block write operations are only performed by the bootloader when recording progress.

[0123] After successfully writing each firmware fragment, the FPGA records the currently completed fragment number in the non-volatile memory area. When an interruption occurs during the upgrade process and the FPGA restarts, it reads the fragment number recorded in the non-volatile memory area and reports the breakpoint information to the host computer. The host computer then continues to send subsequent firmware fragments from the interrupted position based on the fragment number, i.e., returns to step 3.

[0124] The process of triggering breakpoint resumption after an abnormal interruption includes FPGA restart, reading the breakpoint segment number, reporting the breakpoint information, and the host computer continuing the transmission from the interrupted position.

[0125] When encountering anomalies such as power outages, CAN bus interruptions, or communication loss during the upgrade process, there is no need to retransmit the entire firmware from scratch, avoiding redundant transmissions that waste bus resources and improving update efficiency. The FPGA stores the successfully written segment numbers in a non-volatile memory area, ensuring data is not lost in the event of a power outage and allowing for precise location of the update breakpoint after a restart. Adapting to the unstable, packet-loss-prone, and interruption-prone characteristics of the CAN bus, it significantly reduces the time spent on repeated updates, further improving the stability and success rate of remote firmware updates. Combined with an overall reverse-order write mechanism, updates continue along the original reverse-order path after anomaly recovery, maintaining the write order and ensuring the entire update process is safe and reliable.

[0126] Step 6, Final Confirmation and Overall Verification: The host computer sends an upgrade completion flag frame, and the FPGA performs an overall verification.

[0127] After all firmware fragments have been sent, the host computer sends an upgrade completion flag frame to the FPGA. This flag frame is a dedicated CAN command frame issued by the host computer, carrying a fixed identifier, the total firmware length, and an overall checksum. It informs the FPGA that all firmware fragments have been transmitted. The upgrade completion flag frame explicitly tells the FPGA that the firmware fragment transmission process has terminated, triggering the subsequent overall firmware verification process. This distinguishes between the fragment transmission phase and the final verification phase, preventing misjudgments that the update is complete.

[0128] After receiving the upgrade completion flag frame, the FPGA performs a complete verification of the firmware in the Flash memory. (Since the total firmware length is known (obtained from the upgrade start command), the FPGA calculates the CRC32 value of the data within the total firmware length range from the highest address of the Flash memory downwards, and compares it with the value sent by the host computer. If the verification passes, it jumps to the application program to run and sets the completion flag. If the verification fails, it reports a failure status and waits for a re-update.)

[0129] The FPGA sets the firmware update completion status bit, which is preset in the non-volatile memory area, to 1, thus solidifying the status of this successful update. This completion flag marks the official completion of the entire remote update process; the FPGA then normally jumps to the newly written application firmware for execution; subsequent power-ups will directly recognize the successful update status, eliminating the need to repeatedly enter upgrade mode; this achieves a closed-loop update process, confirming that the firmware is complete, error-free, and capable of normal startup and operation.

[0130] Example 2

[0131] like Figure 1 As shown, an FPGA reverse firmware update method based on CAN bus specifically includes:

[0132] (1) Upgrade startup and handshake

[0133] The host computer sends an upgrade start command with opcode 0x01 to the FPGA via the CAN bus, carrying the total firmware length (4 bytes), the total number of fragments (2 bytes), and the overall CRC32 checksum (4 bytes). Upon receiving the upgrade start command, the FPGA performs the following operations:

[0134] The bootloader takes over system control, suspends user logic execution, and enters update mode.

[0135] The Flash start address, end address, sector size, block length, and other storage parameters are returned to the host computer via the CAN bus (opcode 0x01 response).

[0136] Initialize the breakpoint recording area and record the current status as "updating". After the FPGA enters the Bootloader upgrade mode, the dedicated storage area in the non-volatile memory used to store breakpoint information is cleared and formatted; the original historical breakpoint data and abnormal residual markers are cleared, and a dedicated storage address is allocated to prepare for the subsequent recording of the segment number and updating of the status bit.

[0137] The operation code is a special instruction code for the upgrade process, used to distinguish different work instruction types such as upgrade handshake, fragment transmission, breakpoint reporting, completion verification, and abnormal reset. The FPGA identifies the operation code to determine the meaning of the host computer instruction and executes the corresponding process action, realizing CAN bus instruction recognition and process jump control.

[0138] (2) Reverse order fragment generation and transmission

[0139] The host computer reads the FPGA firmware binary file (in .bin format) to be updated and constructs a reverse-order update package as follows:

[0140] Starting from the end of the FPGA firmware binary file, each 256 bytes is divided into a firmware fragment, which is numbered sequentially as fragment 0, fragment 1, ..., fragment N-1;

[0141] The target address corresponding to fragment 0 = the highest address of Flash - fragment data length + 1;

[0142] The target addresses of subsequent fragments decrease sequentially.

[0143] The host computer sends data fragments (opcode 0x02) in ascending order of fragment number (i.e., from the end of the firmware to the beginning of the firmware). A timeout timer (typically 50ms) is started after each firmware fragment is sent.

[0144] If an ACK response is received (operation code 0x03, status = 0x00), the next firmware fragment is sent.

[0145] If a NAK response (opcode 0x03, status = 0xFF) is received or a timeout occurs, the current firmware fragment will be retransmitted.

[0146] The same data segment can be retransmitted a maximum of 3 times. If this number is exceeded, an upgrade failure will be reported to the host computer.

[0147] For the timing relationship between fragmented acknowledgments and timeout retransmissions in CAN bus fragmented transmission, please refer to the appendix. Figure 4 The diagram illustrates the interaction between the host computer and the FPGA using a timing sequence, including three typical scenarios: normal fragment transmission and ACK response, timeout retransmission after frame loss due to CAN bus interference, and NAK response and retransmission after FPGA verification failure. The diagram also illustrates the processing logic of the host computer starting a timeout timer after sending a fragment, sending the next fragment upon receiving an ACK response, and retransmitting the current fragment upon receiving a NAK response or a timeout. During the transmission of fragment 1 from the host computer to the FPGA, CAN bus interference causes fragment data frame loss, and no response is received after a timeout, so the host computer retransmits fragment 1. When fragment 2 fails verification on the FPGA, it sends a NAK response, the host computer retransmits fragment 2, and sends an ACK response after successful verification.

[0148] (3) Write to Flash in reverse order

[0149] After the FPGA successfully receives and verifies each fragment, it performs a reverse write operation:

[0150] The system determines whether the target address of the current fragment is located in a new Flash sector. If so, it first erases that sector. This adapts to the hardware characteristic that Flash must erase before writing, ensuring valid data writing and avoiding write errors. On-demand sector-level erasure only erases the target sector where data is about to be written, without erasing unrelated storage areas, maximizing the protection of existing firmware data. Combined with a high-address to low-address reverse write direction, it accurately matches sector boundaries, ensuring orderly reverse fragment writing and address consistency. This further ensures that the low-address fixed boot area is not accidentally erased throughout the process, continuously maintaining anti-bricking effects and improving update security.

[0151] Write the fragmented data to the application area of ​​the Flash memory corresponding to the target address;

[0152] Immediately after writing, the data is read back and compared with the cached data. If they match, the write operation is successful. After the FPGA writes the fragmented data to the Flash target address, it actively reads back the stored data from the Flash target address that was just written. At the same time, it retrieves the original fragmented data temporarily stored in the on-chip cache before this write operation and compares the read-back Flash data with the original cached data byte by byte. If the two are completely consistent, the write operation is considered valid and the write is successful; if they are inconsistent, the write operation is considered abnormal, an error is marked, and retransmission is requested.

[0153] Update the current fragment number to the breakpoint record area of ​​Flash. Solidify the latest update progress, saving successfully written fragment information in the non-volatile Flash breakpoint area, ensuring data is not lost in the event of power failure. In subsequent upgrades, during power outages, bus interruptions, or device restarts, the latest fragment number can be directly read to accurately locate the update breakpoint and enable resume transmission. This avoids duplicate transmission and writing of completed firmware fragments, reducing CAN bus transmission pressure and improving update efficiency. It ensures that after recovery from an anomaly, subsequent writing continues in the original reverse order, without disrupting the update process.

[0154] Because the writing direction is from high address to low address, the low-address start area is not touched throughout the process. Flash hardware rules limit that the Flash must be erased in its entirety before writing can begin; erasing will clear all data in the entire sector, making it impossible to erase only the middle and preserve the boundaries. The fatal problem with traditional low-address → high-address forward writing is that as long as the writing direction is from low to high, the erasing action will inevitably cover the start area, and a power outage midway will brick the device. Skip writing and random address writing will still frequently erase surrounding sectors, making it very easy to accidentally erase the low-address start area; at the same time, it cannot adapt to CAN fragmented transmission, cannot resume interrupted transmission, and does not conform to the complete storage logic of firmware images. The unique necessity of the reverse writing of this invention: the writing start point is the highest address of the Flash, and writing is done step by step to the lower addresses; the entire update only occupies the upper application area, and never erases or touches the lowest low-address start area; the entire process does not require dual backup partitions or address lock-up protection, relying on the writing direction itself to naturally protect the start area, which is an inherent effect that other writing methods do not have.

[0155] The differences and security comparisons between the reverse writing method of this invention and the sequential writing method of existing technologies are shown in the appendix. Figure 3 The left side of the diagram shows the sequential write method, where data is written from low address to high address in the Flash memory. The low-address boot area is touched early in the update process, and a power outage during the update can easily damage it. The right side of the diagram shows the reverse write method of this invention, where data is written from high address to low address in the Flash memory. The low-address boot area remains untouched throughout the entire update process. Even if a power outage occurs, the Bootloader remains intact and usable, and the device can boot normally and continue updating. The diagram also includes a comparative textual explanation of the risk and security analyses.

[0156] (4) Resuming interrupted downloads

[0157] If a power outage or communication interruption occurs during the upgrade process, the FPGA will enter the Bootloader after power is restored:

[0158] Read the maximum completed segment number from the breakpoint record area of ​​the Flash memory;

[0159] Report breakpoint information via CAN bus (op code 0x05);

[0160] After receiving the breakpoint information, the host computer obtains the breakpoint location and continues sending subsequent fragments starting from the breakpoint fragment number + 1. This eliminates the need to retransmit the entire firmware from scratch, avoiding a large amount of repetitive data transmission, reducing CAN bus usage, and saving transmission time. It accurately continues the update progress, avoiding duplicate sending and writing of successfully uploaded fragments, thus improving remote update efficiency. It adapts to the unstable transmission environment of the CAN bus, which is prone to interruptions and packet loss, enhancing update fault tolerance. It maintains the original reverse-order fragment transmission sequence, ensuring the continuity of subsequent write processes and not disrupting the reverse-order update logic. It reduces the number of repeated Flash erase / write operations, extending memory lifespan and further reducing the risk of errors during transmission.

[0161] For a complete process and transmission efficiency comparison of the breakpoint resume function of this invention, please refer to the appendix. Figure 5 The top of the diagram shows the division between successfully written and untransmitted fragment states before the update interruption, as well as the currently completed fragment number recorded in the breakpoint record area of ​​the Flash memory; the middle of the diagram shows the recovery process after a power outage or communication interruption, where the FPGA re-powers on, reads the breakpoint record area, and reports the breakpoint information via the CAN bus; the bottom of the diagram shows the continuation process of the host computer transmitting the remaining fragments from the breakpoint position.

[0162] (5) Upgrade complete flag frame and overall verification

[0163] like Figure 4 As shown, after the host computer sends all the chips, it finally sends an upgrade completion flag frame (op code 0x04), carrying the overall CRC32 checksum. The FPGA receives this:

[0164] CRC32 verification is performed on all firmware in the Flash application area. During the upgrade handshake phase, the FPGA has returned the Flash start address, end address, and sector size to the host computer. Based on the Flash address partitioning rules: the lower addresses are fixed as the bootloader area, and excluding this protected area, all remaining higher address memory areas constitute the Flash application area. All firmware updates are written to this Flash application area. After all fragment writing is completed, the entire application area firmware data is verified to check for errors, omissions, or incompleteness in the reverse-order data. Combined with the previous single-fragment verification, a dual verification mechanism of fragment verification + overall global verification is formed, significantly improving update reliability. If the verification passes, the firmware is confirmed to be complete and usable, and the FPGA can safely jump to run the new firmware; if the verification fails, the update is considered abnormal, the status is reported, and a re-update is requested to prevent the incomplete firmware from starting. The entire process does not involve verification or modification of the low-address boot area, continuously ensuring boot area security and preventing device bricking.

[0165] The verification result is compared with the value sent by the host computer. During the upgrade handshake step, the upgrade start command frame sent by the host computer carries the overall firmware verification value. The host computer encapsulates the overall verification value into a CAN bus data frame and sends it to the bus. The FPGA's CAN interface receives the command message, performs message parsing and data unpacking, and then extracts and stores the overall verification value. After all firmware fragments are written to the Flash memory, the FPGA calls the local CRC32 calculation result and compares it with the pre-stored overall verification value sent by the host computer.

[0166] If the data matches, the update completion flag is set, the breakpoint record area is cleared, and the system jumps to the application. This confirms that the firmware image data written in reverse order is accurate, complete, and error-free, and that the entire update process is error-free. Setting the update completion flag marks the firmware upgrade as officially successful, preventing automatic resuming of updates upon subsequent power-ups. Clearing the breakpoint record area removes any remaining breakpoint fragment information from the previous update, preventing accidental triggering of resume uploads upon subsequent power-ups and ensuring a clean state. The system then safely jumps to run the newly written application firmware, and the device enters normal operating mode. This forms a complete safety loop, automatically clearing temporary states and solidifying the success flag after a successful update, ensuring stable device operation.

[0167] If there is a discrepancy, the Bootloader mode will be maintained, a failure status will be reported, and the system will wait for a re-update.

[0168] Firmware reverse fragmentation and reverse programming method: The host computer fragments, numbers, and sends the firmware starting from the end; the FPGA writes the firmware sequentially from the highest address to the lowest address. This solves the problem of traditional sequential programming easily damaging the low-address bootloader, causing the device to become "bricked"; it achieves anti-bricking under conditions without backup partitions, saving Flash resources.

[0169] The secure upgrade mechanism of sending the upgrade completion flag frame last: After all firmware fragment data transmission is completed, the upgrade completion flag frame is sent last; before the FPGA receives the upgrade completion flag frame, it retains the original boot logic. This solves the problem of firmware corruption and device failure due to abnormal interruption in traditional upgrades; it achieves final confirmation of upgrade integrity and natural safe regression, so that the device can still boot normally even if power is lost midway. Flash storage characteristics: It can only change from 1 to 0, not from 0 to 1; to write new data, the entire sector must be erased first. Erasure is a complete clearing of the entire sector, and it is not possible to erase the middle and retain the beginning and end. The root cause of the defects of traditional forward-order upgrades: Traditional upgrades write from the low address boot area to the high address, and the first step of the update is to erase and rewrite the underlying bootloader boot area. Once power is lost or communication is interrupted midway, the boot area has been erased and destroyed, and the new firmware has not been written. The device cannot find the boot code when powered on, and it becomes bricked and cannot be recovered. This invention uses high address to low address reverse order writing, and only the application area at the high address is erased and written throughout the process. The most critical low address boot area will not be touched, erased, or modified from beginning to end. Regardless of when the upgrade is interrupted, power is lost, or connection drops, the native bootloader remains intact, and the device can still start normally upon power-up without being damaged or locked. Combined with the breakpoint resume mechanism, updates can continue after an abnormal interruption, eliminating the need to re-flash the device and further avoiding the risk of damage from repeated writes.

[0170] A CAN bus-based fragmented acknowledgment and timeout retransmission protocol: Each fragment sent awaits an FPGA acknowledgment, and automatic retransmission occurs upon timeout; the FPGA requires only a single-chip buffer, eliminating the need for large-capacity RAM. This solves the problems of packet loss and unreliable transmission of the CAN bus in industrial interference environments; it is also compatible with resource-constrained embedded CAN devices, reducing node hardware overhead.

[0171] Precise breakpoint resumption based on fragment number and physical address: After each successful write to a fragment by the FPGA, the current fragment number is recorded in the non-volatile memory area; after a power failure and restart, the host computer reads the breakpoint and resumes transmission from the interrupted position. This solves the problem of needing to retransmit the entire data after an upgrade interruption in a weak network environment; it also significantly reduces the upgrade time on the low-bandwidth CAN bus and improves update efficiency.

[0172] A dual verification mechanism combining single-chip verification and overall firmware verification: Each chip carries a CRC16 checksum; after all chips are written, an overall firmware CRC32 check is performed. This dual guarantee ensures the firmware is correct after the update, making it suitable for high-reliability scenarios such as automotive and industrial FPGAs.

[0173] After the host computer performs reverse-order fragmentation of the firmware, it generates a CRC16 checksum for each independent fragment and encapsulates this checksum into the corresponding fragment data packet, which is then sent to the FPGA along with the fragment data. CRC16 fragment verification enables error detection of single-fragment data, identifying frame errors, lost frames, and interference distortion generated during CAN bus transmission. The FPGA verifies the received fragments in real time, immediately triggering retransmission if an anomaly occurs, preventing erroneous data from being written to Flash. Combined with subsequent global CRC32 verification, a dual verification system of fragmented CRC16 + global CRC32 is formed. This layered approach ensures data accuracy, guaranteeing both the error-free nature of individual fragment data and the integrity of the entire firmware, significantly improving update reliability.

[0174] Specific Example: An FPGA's external SPI Flash address range is 0x000000~0x07FFFF (512KB in total), where 0x000000~0x00FFFF is the low-address bootloader area, and 0x010000~0x07FFFF is the application area. The host computer divides the firmware (450KB in size) into 256-byte blocks, totaling 1800 blocks. Transmission begins from block 0 (corresponding to the end of the firmware, with the target address 0x07FFFF downwards). The FPGA receives the firmware via the CAN bus and writes it to the application area of ​​the Flash in reverse order, with target addresses sequentially 0x07FFFF, 0x07FEFF, ..., 0x010000. If a power failure occurs at block 1200 during the update process, after restarting, the FPGA reads the breakpoint record area and reports block number 1199. The host computer continues transmission from block 1200 without starting from the beginning. The low address boot area (0x000000~0x00FFFF) was not erased or written throughout the process, and the device could always boot normally.

[0175] Anomaly Handling Mechanism: In the absence of a backup partition, this invention ensures anomaly safety through a reverse order mechanism: If a power failure occurs during the update, the Bootloader will detect that the update is incomplete after restarting; since the critical low address area is not overwritten, the system can still start normally and enter update mode; after the host computer reads the breakpoint, it will continue to send the reverse order data from the current breakpoint; multiple update failures will not affect the basic boot capability of the device, avoiding "bricking".

[0176] At the start of the upgrade, the Bootloader initializes the breakpoint recording area and sets the status flag to "updating." This status is stored in the non-volatile breakpoint area of ​​Flash and is not lost when power is off. Only when the overall CRC check passes and the entire update is successful will the breakpoint recording area be cleared and the update completion flag be set. If there is a power outage or interruption during the process, and the process does not reach the final successful step, the update completion flag will never be set, and the breakpoint recording area will still retain the update progress and the "updating" status. After the device restarts, the Bootloader directly reads the breakpoint status bit and update completion flag bit in Flash: if it detects no successful completion flag and that the breakpoint area still contains update progress records, it can determine that the upgrade is incomplete and in an abnormal interruption state.

[0177] This embodiment demonstrates that, without partitioning a backup storage area or performing firmware backup, reliable remote firmware updates via the CAN bus can still be achieved through reverse-order updates, saving storage resources and reducing hardware costs. The core value of breakpoint resume transmission lies in the fact that successfully transmitted fragments do not need to be retransmitted. Therefore: the later the interruption → the more completed fragments → the fewer fragments remaining to be resumed → the greater the amount of transmission saved. In contrast, the retransmission from the beginning scheme requires retransmission of all firmware fragments regardless of when the interruption occurs. The quantitative comparison is shown in Table 4. The amount of transmission required for breakpoint resume transmission = the total number of fragments (1800) - the interruption position, the amount of transmission saved = the interruption position, and the time-saving ratio is the amount of transmission saved / the total number of fragments. It can be seen that the later the update, the more time is saved.

[0178] Table 4 Quantitative Comparison Table (taking a total of 1800 segments as an example)

[0179]

[0180] Example 3

[0181] An FPGA reverse firmware update system based on a CAN bus utilizes the FPGA reverse firmware update method based on a CAN bus as described in Embodiments 1 and 2. The hardware system of this embodiment includes: a remote update host computer, a CAN bus transceiver (including a CAN controller), and an FPGA node device with Flash memory. (See attached diagram.) Figure 2The remote update host computer runs upgrade management software to generate firmware fragments in reverse order, issue upgrade commands and firmware data via the CAN bus, handle responses and retransmissions, and manage breakpoint resume. The CAN bus transceiver's CAN controller completes the transmission and reception of CAN frames, supporting standard frames (11-bit ID) or extended frames (29-bit ID). Based on the CAN bus distributed communication architecture, it achieves stable and reliable remote firmware updates over long distances and across multiple nodes. The bus has strong anti-interference capabilities and is adaptable to complex electromagnetic environments in industrial settings. It is compatible with both standard and extended CAN frame formats, offering wide communication adaptability and flexible message identification, meeting diverse communication needs such as multi-device networking, command differentiation, and data transmission. The host computer integrates functions for firmware reverse order fragmentation, command issuance, data interaction, abnormal response retransmission, and breakpoint resume management, unifying and coordinating the entire upgrade process to achieve intelligent remote update control. The FPGA, combined with its built-in Flash memory, independently completes the entire process of bus data reception, parsing, sector-by-demand erasure, reverse writing, fragment verification, breakpoint storage, global verification, and program jump. This results in high hardware execution efficiency and excellent real-time upgrade performance. The entire hardware and software architecture is mutually compatible, fully inheriting the aforementioned reverse update method. Building upon advantages such as no modification to the low-address startup area, no bricking due to abnormal power loss, breakpoint resumption, and dual-verification protection, the method is implemented in hardware, and the solution can be deployed in engineering applications. The CAN transceiver and controller independently complete the transmission and reception of the underlying bus frames, separating the communication link from the FPGA's business logic. This results in a clear structure, high stability, and facilitates later maintenance and node expansion. Due to the limitation of the single-frame data length at the CAN bus physical layer, the host computer sends the complete fragmented data in frames according to the bus transmission rules. After receiving the data, the FPGA reassembles it, parses the information in each field, and executes the corresponding upgrade process.

[0182] The remote update host computer internally includes a firmware reversal and fragmentation module, a CAN driver module, an acknowledgment processing and retransmission module, a breakpoint management module, and an overall verification module. The CAN driver module is connected to the CAN bus transceiver. The firmware reversal and fragmentation module splits the original firmware image from tail to head in reverse order, generating firmware fragments with sequentially numbered segments. It also assigns a corresponding Flash target physical address to each segment, providing a data source for the high-address to low-address reverse update of this invention. The CAN driver module implements the CAN bus underlying message transmission and reception driver, encapsulating upgrade instructions, fragment data, address information, length information, and checksums according to the protocol; it is compatible with CAN standard frames and extended frames, completing bus data transmission and underlying communication adaptation. The acknowledgment processing and retransmission module receives acknowledgment messages returned by the FPGA node in real time, identifies the segment reception status and verification results; and automatically triggers retransmission for abnormal segments with verification anomalies or packet loss, ensuring reliable data transmission. The breakpoint management module receives breakpoint fragment information uploaded by the FPGA, parses the current update progress, and automatically resumes sending firmware data from the next fragment after the breakpoint, enabling breakpoint continuation after abnormal interruption and avoiding duplicate transmission of completed fragments. The overall verification module performs a global CRC32 operation on the complete original firmware, generates an overall firmware verification value, and sends it to the FPGA; this is used for overall readback verification and comparison at the FPGA end after the entire upgrade is completed to determine the integrity and validity of the firmware write.

[0183] The FPGA node device contains the following modules: CAN communication module, bootloader module, reverse addressing control module, Flash storage control module, verification module, and breakpoint management module. The CAN communication module is connected to the CAN bus transceiver. The CAN communication module, verification module, and breakpoint management module are all connected to the bootloader module. The bootloader module is connected to the reverse addressing control module. The reverse addressing control module is connected to the Flash storage control module. The Flash storage control module is connected to an external Flash memory.

[0184] CAN Communication Module: This module handles CAN frame transmission, reception, and parsing. The CAN communication module within the FPGA interfaces with the peripheral CAN controller and CAN transceiver, handling the reception, parsing, reassembly, and forwarding of bus messages. It receives CAN physical frames transmitted on the bus, identifying the frame ID and receiving the data payload. Following the bus framing transmission rules, it reassembles multiple fragmented CAN data frames into complete logical data segments. According to a preset byte offset protocol, it sequentially parses the opcode, segment number, target address, data length, firmware data, and CRC16 checksum fields within the data packet. It temporarily stores the parsed valid information and sends commands, addresses, and firmware data to the upper-level upgrade control module. Simultaneously, it receives internal FPGA response information, encapsulates it into a CAN response frame, and sends it to the host computer, achieving bidirectional communication.

[0185] Bootloader module: responsible for firmware update process control, verification, redirection and exception recovery.

[0186] Flash storage control module: External SPI interface Flash or on-chip Flash is used to store FPGA configuration firmware.

[0187] Reverse addressing control module: used to perform data reception and programming from high to low address.

[0188] Verification module: Supports single-chip CRC16 verification and overall CRC32 verification.

[0189] Breakpoint Management Module: Records the currently completed segment number in a fixed area of ​​Flash storage, i.e., the non-volatile storage area, which supports power-off recovery.

[0190] Flash memory: FPGA configuration file storage medium, divided into a fixed start area (low address segment) and an application area (high address segment), without a backup partition, and all update operations are completed directly in the application area.

[0191] An external Flash memory is connected via a Flash storage control module. The Flash memory is divided into a fixed boot area at low addresses and an application area at high addresses. Reverse writing proceeds from high addresses to low addresses, and the fixed boot area is not erased or written during the update process. Figure 2 Solid arrows indicate CAN bus communication links, while dashed boxes indicate module grouping relationships.

[0192] To distinguish between reverse-order update messages and regular service messages, a reverse-order update flag is set in the CAN frame ID. The single-chip data field structure definition is shown in Table 5.

[0193] Table 5 Single-chip data field structure definition table

[0194]

[0195] The message uses a standardized structured frame format with a fixed byte offset. The FPGA can parse the information obtained from this single-chip data field structure to fully extract all core information of the upgrade process: Operation code: Obtain the message instruction type, identify the working instruction, and define the current bus interaction process. Segment number: Obtain the unique number of the current firmware segment, match the reverse segmentation rule (segment 0 corresponds to the firmware tail), used for updating progress records and breakpoint location. Target address: Obtain the physical storage address of this segment to be written to Flash, clarify the data writing location, and adapt to the high-address to low-address reverse writing logic. Data length: Obtain the byte length of the effective firmware data of this segment, limiting the single-chip payload to ≤256 bytes, adapting to bus transmission and Flash writing specifications. Firmware data: Extract the original firmware content to be burned into Flash within this segment. CRC16 checksum: Obtain the CRC16-CCITT single-chip checksum unique to this segment, used for data integrity verification at the receiving end.

[0196] The above-mentioned fragment data domain structure instruction system is standardized, and the upgrade process is orderly and controllable; natively adapted reverse writing mechanism; fragment-level pre-error protection to avoid bad data writing from the source; provides underlying data support for breakpoint resume function; payload specification adapted to hardware, stable and compatible transmission; builds a two-layer full-link verification security system; isolates the start area from the bottom layer of the message to build a solid advantage against bricking.

[0197] This invention defines an upgrade communication data field format that includes an opcode, fragment number, target address, data length, firmware data, and a CRC16 checksum. Due to the limitation of the single-frame data length of the CAN bus physical layer, the host computer sends the complete logic data fragment in segments according to the bus transmission rules. After receiving the data, the FPGA reassembles it, parses the information in each field, and executes the corresponding upgrade process.

[0198] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for reversing firmware update in an FPGA based on a CAN bus, characterized in that, Includes the following steps: Step 1: The host computer sends an upgrade start command to the FPGA via the CAN bus, and the FPGA returns the parameters of the Flash memory; Step 2: The host computer reads the FPGA firmware file to be updated, and starts from the end of the FPGA firmware file to divide the data into segments according to a preset fixed length, and sequentially numbers them to form a reverse order segment queue from the end of the firmware to the beginning of the firmware. Step 3: The host computer sends firmware fragments sequentially through the CAN bus according to the order of the reverse fragment queue. After receiving each firmware fragment, the FPGA performs verification. If the verification is successful, it replies to the host computer with a verification success response frame. If the verification fails, it replies to the host computer with a verification failure response frame. If the verification fails or no response is received within the timeout period, the host computer retransmits the current firmware fragment. Step 4: The FPGA writes the verified firmware fragments sequentially from the high address to the low address of the Flash memory. Step 5: The FPGA records the fragment number of the successfully written firmware fragment in the non-volatile memory area; The process of triggering breakpoint resumption after abnormal interruption returns to step 3; Step 6: The host computer sends an upgrade completion flag frame, and the FPGA performs an overall verification.

2. The FPGA reverse firmware update method based on CAN bus according to claim 1, characterized in that, The upgrade start command carries the total firmware length and the overall firmware check value; the parameters of the Flash memory include the Flash start address, Flash end address and sector size; after receiving the upgrade start command, the FPGA automatically jumps into the bootloader program to clear and initialize the breakpoint record area in the non-volatile memory used to store breakpoint information. The bootloader calls the on-chip Flash driver interface to obtain the storage parameters corresponding to the Flash memory, and returns them to the host computer via the CAN bus. The FPGA firmware file contains all the logic configuration code, bootloader and application data required for FPGA operation; the FPGA reads the FPGA firmware from the Flash memory; the data of each firmware chip is further divided into multiple CAN data according to the effective data length of a single frame, and the effective data length of a single frame is the effective data payload length that a single CAN bus can carry; The firmware header is the starting position of the FPGA firmware file, which includes power-on boot information, bootloader startup code, and address base address information. The firmware tail is the end position of the FPGA firmware file, which contains the firmware backend application logic data.

3. The FPGA reverse firmware update method based on CAN bus according to claim 2, characterized in that, Each firmware segment contains a segment number, Flash target address, data content, and single-segment checksum. The response frame contains the segment number that has been successfully received, the receiving status, and the current Flash write progress information. The upgrade completion flag frame is a CAN command frame sent by the host computer, carrying a fixed identifier code, the total firmware length, and the overall check value.

4. The FPGA reverse firmware update method based on CAN bus according to claim 3, characterized in that, The fragment number is used to identify the order of firmware fragments in the reverse fragment queue. The Flash target address mark needs to be written to the corresponding physical address of the FPGA internal Flash. The data content is the original valid firmware data corresponding to the firmware fragment. The single-chip check code is the CRC16 check value generated by the single-chip data of the firmware fragment. The verification method is as follows: after the FPGA receives the data content of the firmware fragment, it recalculates the CRC16 check value and compares it with the single-chip check code carried in the fragment. If they match, the verification passes; otherwise, the data transmission is determined to be faulty.

5. The FPGA reverse firmware update method based on CAN bus according to any one of claims 1-4, characterized in that, Fixed address ranges are pre-divided in the on-chip Flash memory of the FPGA, and the lowest address segment of Flash is defined as the fixed start area, which is used to store the bootloader program. During the writing process, the host computer and the FPGA agree on updating the write address boundary by combining the obtained Flash start address and Flash end address. The fixed start area located in the lowest address segment of Flash memory is not erased or written.

6. The FPGA reverse firmware update method based on CAN bus according to claim 5, characterized in that, When an interruption occurs and the upgrade process is restarted, the FPGA reads the segment number recorded in the non-volatile memory area to obtain the breakpoint segment number, and reports the breakpoint information to the host computer. The host computer then continues to send subsequent firmware segments from the interruption position based on the breakpoint segment number. After receiving the upgrade completion flag frame, the FPGA performs verification on all firmware in the Flash memory. If the verification passes, it jumps to the application program to run, sets the completion flag, and clears the non-volatile memory area. Verification failed. Report failure status and wait for update.

7. The FPGA reverse firmware update method based on CAN bus according to claim 6, characterized in that, The method by which the FPGA writes the verified firmware fragments sequentially from the high address to the low address of the Flash memory is as follows: Determine if the Flash target address of the current segment is located in a new Flash sector; if so, perform Flash sector erasure. Write the data fragmented from the solid-state chip into the Flash application area corresponding to the Flash target address; After writing, immediately read back and compare with the original cached data. If they match, the write is successful; if they do not match, the write is considered abnormal, an error is marked, and retransmission is requested. Update the current fragment number to the breakpoint record area of ​​the Flash memory.

8. The FPGA reverse firmware update method based on CAN bus according to claim 7, characterized in that, The host computer reads the FPGA firmware binary file to be updated and constructs a reverse-order update package as follows: starting from the end of the FPGA firmware binary file, each pre-set fixed-length byte is divided into a firmware fragment, numbered sequentially from the end of the file to the beginning in ascending or descending order; the target address corresponding to the last firmware fragment = the highest Flash address - fragment data length + 1; the target addresses of subsequent firmware fragments decrease sequentially; the host computer sends the firmware fragments in order from the end of the file to the beginning of the file; after each firmware fragment is sent, a timeout timer is started: if an ACK response is received, the next firmware fragment is sent; if a NAK response is received or a timeout occurs, the current firmware fragment is retransmitted; the same fragment can be retransmitted a maximum of a pre-set fixed number of times, after which an upgrade failure is reported to the host computer; The FPGA sets the firmware update completion status bit preset in the non-volatile memory area to 1, thus solidifying the status indicator of this successful update. The host computer retransmits all CAN physical frames corresponding to the firmware fragment, and sets the reverse order update flag in the ID of the CAN physical frame; The bootloader reads the latest completed segment number from the breakpoint record area of ​​the Flash memory; reports the breakpoint information via the CAN bus; after receiving the breakpoint information, the host computer obtains the breakpoint location and continues to send subsequent firmware segments starting from the breakpoint segment number +1 or the breakpoint segment number -1. Perform CRC32 verification on all firmware in the Flash application area; compare the verification result with the overall verification value of the firmware sent by the host computer; if the comparison is inconsistent, maintain Bootloader mode, report the failure status, and wait for a new update.

9. An FPGA reverse firmware update system based on a CAN bus, utilizing the FPGA reverse firmware update method based on a CAN bus as described in any one of claims 1-8, characterized in that, It includes a remotely updated host computer, a CAN bus transceiver, and an FPGA node device with Flash memory. The host computer is connected to the FPGA node device via the CAN bus transceiver. The host computer is equipped with a firmware reversal and fragmentation module, a CAN driver module, an acknowledgment processing and retransmission module, a breakpoint management module I, and an overall verification module; the CAN driver module is connected to the CAN bus transceiver. The FPGA node device includes: a CAN communication module, a bootloader module, a reverse addressing control module, a Flash storage control module, a verification module, and a breakpoint management module II. The CAN communication module is connected to the CAN bus transceiver. The CAN communication module, the verification module, and the breakpoint management module II are all connected to the bootloader module. The bootloader module is connected to the reverse addressing control module. The reverse addressing control module is connected to the Flash storage control module. The Flash storage control module is connected to an external Flash memory.

10. The FPGA reverse firmware update system based on CAN bus according to claim 9, characterized in that, The firmware reversal fragmentation module splits the FPGA firmware file in reverse order from tail to head, generating firmware fragments with sequentially numbered segments, and assigns a corresponding Flash target address to each firmware fragment; the CAN driver module implements the CAN bus underlying message transmission and reception driver, and encapsulates the upgrade start command, fragment data, address information, length information and check code according to the protocol; the response processing and retransmission module receives the response messages returned by the FPGA node device in real time, identifies the fragment reception status and verification results, and automatically triggers retransmission for abnormal firmware fragments with verification errors or packet loss; the breakpoint management module receives the breakpoint fragment information uploaded by the FPGA node device, parses the current update progress, and automatically resumes sending firmware fragments from the next fragment after the breakpoint. The overall verification module performs a global CRC32 verification on the entire firmware, generates an overall firmware verification value, and sends it to the FPGA node. The CAN communication module completes CAN frame transmission, reception, and parsing; the bootloader module is responsible for firmware update process control, verification, jump, and exception recovery. The Flash storage control module is used to store FPGA configuration firmware; The reverse addressing control module is used to perform data reception and writing from high to low address. The verification module supports single-chip CRC16 verification and overall CRC32 verification; The breakpoint management module records the currently completed segment number in the non-volatile storage area of ​​the Flash memory; Flash memory is the storage medium for FPGA firmware files, and it is divided into a fixed boot area and an application area.

Images