RISC-V MCU system firmware upgrading method

Abstract

The invention provides an RISC-V MCU system firmware upgrading method, which comprises the following steps that: an equipment end starts an upgrading service program USP, and enters background silent upgrading or foreground inductive upgrading; after the backup area is determined, the device end determines to enter background silent upgrade or foreground inductive upgrade according to the type of the received upgrade command; the host end transmits the firmware data packet to the equipment end; after the firmware data is received at the equipment end, integrity and validity check is carried out on the firmware through the USP; the USP link of the equipment end is ended, and whether the equipment is restarted or not is judged; after the equipment end is restarted, traversing partitions in the partition table by starting a loading program BL, analyzing effective firmware from the partitions, and performing integrity and validity check; and if the checking is passed, executing the upgraded new firmware. The method has the advantages of data integrity and security, version management and backspacing mechanism, high efficiency, modularization, open source, low cost and the like at the same time, and a reliable and efficient solution is provided for firmware upgrade of the RISC-V MCU system.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware upgrade, and in particular to a RISC-V MCU system firmware upgrade method. Background Art

[0002] With the widespread adoption of the RISC-based microcontroller architecture in the MCU field, firmware upgrades for RISC-based systems are becoming increasingly important. Firmware is the core software of embedded systems, responsible for managing hardware resources, executing application logic, and providing user interfaces. Due to the complexity of software and the continuous evolution of device functionality, firmware upgrades can fix bugs, enhance functionality, optimize performance, or improve security.

[0003] However, any problems during the firmware upgrade process can lead to upgrade failure or even device bricking, so a reliable and secure upgrade mechanism must be carefully designed and implemented. Therefore, designing a firmware upgrade solution for RISC-V MCUs has important practical significance and application value. Summary of the Invention

[0004] In order to solve the problems existing in the prior art, the present invention provides a RISC-V MCU system firmware upgrade method, which has multiple advantages such as flexibility and user-friendliness, data integrity and security, version management and fallback mechanism, efficiency and modularity, open source and low cost, etc., providing a reliable and efficient solution for firmware upgrade of RISC-V MCU system.

[0005] The present invention achieves the above-mentioned purpose through the following technical solutions:

[0006] A RISC-V MCU system firmware upgrade method, comprising:

[0007] The host initiates an upgrade request, and the device responds with a confirmation based on its own operating status.

[0008] The device starts the upgrade service program USP and selects to enter the background silent upgrade or the foreground active upgrade according to the upgrade request mode of the host;

[0009] After the backup area is determined, the device determines whether to perform a silent background upgrade or a dynamic upgrade based on the type of upgrade command received.

[0010] The host transmits the firmware data packet to the device, where the firmware data packet contains a CRC reference value for verifying data integrity.

[0011] After receiving the firmware data on the device side, the integrity and validity of the firmware are checked through USP;

[0012] If the firmware passes the integrity and validity check, USP sets the update_flag in the firmware header of the current region to 1, indicating that the firmware in this region is the new upgraded firmware; at the same time, it sets the update_flag in the firmware header of another region to 0, indicating that the firmware in this region is the old version firmware;

[0013] The USP phase on the device side is completed, and it is determined whether to restart the device;

[0014] After the device is restarted, the bootloader BL traverses the partitions in the partition table, parses the valid firmware from the partition, and checks the firmware update flag update_flag in the firmware header. If a partition with update_flag set to 1 is detected, the BL marks the partition as active and performs integrity and validity checks.

[0015] If the check passes, BL maps the active partition to the virtual address space and jumps to the app address space to execute the upgraded new firmware;

[0016] If an error is detected when executing the updated firmware, BL will perform a version rollback process, that is, reactivate the backup partition storing the previous version as the active partition, remap it, and then jump to execution.

[0017] According to a RISC-V MCU system firmware upgrade method provided by the present invention, when determining the backup area, the USP determines the backup area or the active area by traversing and checking the update_flag of the header in the backup / active area, where the area with update_flag being 1 is the active area and the area with update_flag being 0 is the backup area.

[0018] According to a RISC-V MCU system firmware upgrade method provided by the present invention, the background silent upgrade is used to ensure that the process of the USP receiving firmware data does not affect the normal operation of the application app, specifically including:

[0019] The server splits the firmware data into multiple small data packets according to the predetermined protocol and sequence and sends them to the device. The device immediately stores or processes each small data packet after receiving it.

[0020] Among them, when the device receives a small data packet from the server, the Trap Delegation function of the interrupt mechanism in the RISC-V architecture is used to delegate the firmware receiving interrupt to a low-privilege mode (such as Supervisor mode), while the main application can still run at a higher privilege level (such as Machine mode) without interference.

[0021] This demonstrates that the present invention leverages the RISC-V architecture to design a lower-latency interrupt handling process. This allows for rapid response and processing of received data after a data reception interrupt is triggered, thereby reducing the impact of the interrupt on the main application. This is particularly important for scenarios like firmware data transmission, where interrupts are frequently triggered, as it prevents excessive interrupt service times from impacting the system's real-time performance.

[0022] According to a RISC-V MCU system firmware upgrade method provided by the present invention, the foreground-sensed upgrade allows the system to suspend the operation of the application during the upgrade process, specifically including:

[0023] When the USP receives the firmware data from the server, it immediately triggers the foreground upgrade process. At this time, the USP sends a command to the system to stop the currently running application.

[0024] After the application stops running, the system switches to the upgrade display interface. The server splits the firmware data into multiple large data packets and sends them to the device according to the preset protocol and sequence. The device suspends responding to other requests during the upgrade process.

[0025] Among them, the device side sets a global flag or status variable at the beginning of the upgrade to indicate that the current system is in the upgrade state; then, when processing the request, the device side first checks the value of the flag or status variable. If its value is upgrading, the device side refuses to process the request and returns a corresponding error prompt to the user.

[0026] According to a RISC-V MCU system firmware upgrade method provided by the present invention, during the transmission of a firmware data packet, the host side sends the firmware data packet and its own CRC reference value to the device side. After receiving the data packet, the device side performs a check based on the CRC reference value included in the data packet to determine whether an error occurred during the transmission of the data packet;

[0027] When an error is detected in a data packet, an error feedback signal is sent to the host to inform the host that the data packet transmission failed;

[0028] After receiving the error feedback from the device, the host resends the firmware data packet to the device. During the data retransmission process, the host ensures that the data packet and its CRC reference value remain unchanged to ensure that the device can correctly perform CRC check.

[0029] According to a RISC-V MCU system firmware upgrade method provided by the present invention, the integrity check of the firmware is performed through the USP, including:

[0030] The USP passes the received firmware data to the hardware CRC module, which performs CRC calculation on the data according to a predetermined generator polynomial and generates a CRC value. This value is used to compare with the CRC reference value in the firmware to verify the integrity and validity of the data.

[0031] USP compares the calculated CRC value with the CRC reference value in the firmware bin header. If the two match, it means that there was no error in the firmware data during transmission and it is complete and valid. If they do not match, it means that the firmware data may be damaged or tampered with, and USP will refuse to accept the firmware.

[0032] According to a RISC-V MCU system firmware upgrade method provided by the present invention, the validity of the firmware is checked through the USP, including:

[0033] Header validity check: During the firmware update process, USP recalculates the checksum of the received header data and compares it with the checksum stored in the header. If the two match, it means that there is no error in the header data during transmission and it is complete and valid. If they do not match, it means that the header data may be damaged or tampered with, and USP will refuse to accept the firmware or take other measures.

[0034] According to a RISC-V MCU system firmware upgrade method provided by the present invention, the validity of the firmware is checked through the USP, including:

[0035] Bin validity check: During the Bin validity check, a segment of instruction code is randomly extracted from the code area and the opcode is parsed out. Then, these opcodes are compared with the valid opcode values ​​defined in the RISC-V specification. If all the extracted opcodes are valid, it means that the bin's code area has no errors during transmission and is complete and valid. If an invalid opcode is found, it means that the bin's code area may be damaged or tampered with, and the USP will refuse to accept the firmware or take other measures.

[0036] According to a RISC-V MCU system firmware upgrade method provided by the present invention, during the data transmission process, after each data packet is sent, the device needs to perform a check and confirm whether it is successfully received.

[0037] According to a RISC-V MCU system firmware upgrade method provided by the present invention, BL is executed when the device is restarted, and the execution includes verifying the integrity and validity of the firmware of the active partition, establishing a mapping of the active partition to the virtual application area, and finally jumping to the application space to execute the firmware or operating system stored in the active partition;

[0038] The BL is used to maintain a partition table of the flash memory, which is used to store information about the flash physical area following the area where the BL is located. The partition table contains at least two entries, representing an active partition and a backup partition. The active partition is used to store the currently used firmware or operating system; the backup partition is used as a backup of the firmware or operating system.

[0039] It can be seen that compared with the prior art, the present invention has the following beneficial effects:

[0040] 1. This invention provides a set of hardware and software mechanisms that support location-independent firmware upgrades, enabling dual-host backup upgrades without system bricking due to upgrade failures. The low-power, low-cost RISC-V architecture of this invention also makes this method significantly advantageous in scenarios such as the Internet of Things and edge computing.

[0041] 2. This method supports two modes: background silent upgrade and foreground tangible upgrade. You can flexibly select the upgrade mode based on the host's upgrade request mode and the device's operating status. This does not affect the user experience (silent upgrade) and can provide clear upgrade feedback when necessary (tangible upgrade).

[0042] 3. The firmware data packet of this invention includes a CRC reference value, which is used to verify the integrity of the data during transmission, ensuring that the firmware is not damaged due to transmission errors during the upgrade process. After receiving the firmware data, the device also performs an integrity and validity check on the firmware through the USP, further enhancing the security of the firmware upgrade.

[0043] 4. This invention marks the new and old versions of firmware by setting the update_flag in the firmware header, allowing the device to automatically identify and load the latest valid firmware after a reboot. If an error is detected while executing the updated firmware, the BL performs a version rollback process, reactivating the backup partition storing the previous version as the active partition and remapping the partition before executing the new version, thus ensuring system stability and reliability.

[0044] 5. This invention achieves fast and efficient firmware loading and switching by using a bootloader (BL) to traverse partitions in the partition table, parse valid firmware from the partitions, and check the firmware update flag in the firmware header. The modular nature of the RISC-V architecture also makes this method more adaptable to different application requirements and hardware configurations.

[0045] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a flowchart of an embodiment of a RISC-V MCU system firmware upgrade method of the present invention.

[0047] Figure 2 This is a system schematic diagram of the RISC-V MCU architecture implemented in an embodiment of a RISC-V MCU system firmware upgrade method of the present invention.

[0048] Figure 3 This is a first principle schematic diagram of storage mapping in an embodiment of a RISC-V MCU system firmware upgrade method of the present invention.

[0049] Figure 4 This is a second principle diagram of storage mapping in an embodiment of a RISC-V MCU system firmware upgrade method of the present invention.

[0050] Figure 5 This is a firmware upgrade flow chart for starting an upgrade service program USP in an embodiment of a RISC-V MCU system firmware upgrade method of the present invention.

[0051] Figure 6 This is a firmware upgrade flow chart for a boot loader BL in an embodiment of a RISC-V MCU system firmware upgrade method of the present invention. DETAILED DESCRIPTION

[0052] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the described embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] The RISC-V MCU system firmware upgrade method of this embodiment is a firmware update process designed for RISC-V architecture microcontroller units (MCUs). This method ensures the security, stability, and effectiveness of the firmware during the upgrade process through a series of steps, thereby extending the service life of the RISC-V MCU and improving its performance and reliability.

[0054] See also Figures 1 to 6 The present embodiment involves a RISC-V MCU system firmware upgrade method, including:

[0055] In step S1, the host initiates an upgrade request, and the device responds with a confirmation start based on its own operating status.

[0056] In step S2, the device starts the upgrade service program USP and selects to enter the background silent upgrade or the foreground active upgrade according to the upgrade request mode of the host.

[0057] In step S3, after the backup area is determined, the device determines whether to enter a background silent upgrade or a foreground active upgrade based on the type of upgrade command received.

[0058] In step S4, the host transmits a firmware data packet to the device, wherein the firmware data packet carries a CRC reference value for verifying data integrity.

[0059] Step S5: After the device receives the firmware data, it performs integrity and validity checks on the firmware through the USP. If it fails, the information is fed back to the host.

[0060] In step S6, if the firmware passes the integrity and validity check, the USP sets the update_flag in the firmware header of the current area to 1, indicating that the firmware in this area is the new upgraded firmware; and sets the update_flag in the firmware header of another area to 0, indicating that the firmware in this area is the old version firmware.

[0061] In step S7, the USP phase on the device side is completed, and it is determined whether to restart the device. The device can be restarted immediately or at a suitable time later.

[0062] Step S8: After the device is restarted, the bootloader BL traverses the partitions in the partition table, parses the valid firmware from the partition, and checks the firmware update flag update_flag in the firmware header; if a partition with update_flag set to 1 is detected, then the partition has new firmware, and the BL marks the partition as an active partition and performs integrity and validity checks. The checking mechanism is the same as that in the USP.

[0063] In step S9, if the check passes, the BL maps the active partition to the virtual address space and jumps to the app address space to execute the upgraded new firmware.

[0064] In step S10, if an error is detected while executing the updated firmware, the BL will perform a version rollback process, reactivating the backup partition storing the previous version as the active partition, remapping it, and then jumping to execution. If the BL detects an error during the integrity and validity check of the updated firmware, resulting in the new upgraded firmware being unable to execute, the version rollback process will be performed, reactivating the backup partition storing the previous version as the active partition, remapping it, and then jumping to execution.

[0065] In this embodiment, when determining the backup area, the USP determines the backup area or the active area by traversing and checking the update_flag of the header in the backup / active area, wherein the area with update_flag being 1 is the active area, and the area with update_flag being 0 is the backup area.

[0066] There are two traversal methods in this embodiment. A simple method is that the actual addresses of the backup / active areas in the flash are fixed, so the USP only needs to locate the headers of the two areas at a fixed position; another flexible method is to add a linked list member in the bin header. The USP only needs to find the position of the first header, and subsequent headers can be traversed through the linked list. In specific solutions, you can choose to use it according to the application scenario.

[0067] In this embodiment, the background silent upgrade is used to ensure that the process of the USP receiving firmware data does not affect the normal operation of the application app, which specifically includes:

[0068] The server splits the firmware data into multiple small data packets (4 bytes is recommended in this embodiment) and sends them to the device according to a predetermined protocol and sequence. The device immediately stores or processes each small data packet after receiving it. When the device receives a small data packet from the server, the Trap Delegation function of the interrupt mechanism in the RISC-V architecture is used to delegate the firmware receive interrupt to a low-privilege mode (such as Supervisor mode), while the main application can still run at a higher privilege level (such as Machine mode) without interference.

[0069] This embodiment leverages the RISC-V architecture to design a lower-latency interrupt handling process. Once a data reception interrupt is triggered, it can quickly respond to and process received data, thereby reducing the impact of the interrupt on the main application. This is particularly important for scenarios like firmware data transmission where interrupts are frequently triggered, as it prevents excessive interrupt service times from impacting the real-time performance of the system.

[0070] In this embodiment, the foreground upgrade allows the system to suspend the running of the application during the upgrade process, specifically including:

[0071] When the USP receives the firmware data from the server, it immediately triggers the foreground upgrade process. At this time, the USP sends a command to the system to stop the currently running application.

[0072] After the application stops running, the system switches to the upgrade display interface. The server splits the firmware data into multiple large data packets and sends them to the device according to the preset protocol and sequence. The device suspends responding to other requests during the upgrade process.

[0073] Among them, the device side sets a global flag or status variable at the beginning of the upgrade to indicate that the current system is in the upgrade state; then, when processing the request, the device side first checks the value of the flag or status variable. If its value is upgrading, the device side refuses to process the request and returns a corresponding error prompt to the user.

[0074] It can be seen that in the foreground upgrade of this embodiment, after the USP receives the firmware data, it stops the running of the application app and enters the upgrade display interface. The firmware of the server is sent in a large package (1K is recommended in this embodiment), and the device side does not respond to other requests except the upgrade during the upgrade process. Because the app will stop running, the user will feel the upgrade process.

[0075] During the firmware data packet transmission process, the host sends the firmware data packet and its own CRC reference value to the device. After receiving the data packet, the device verifies it according to the CRC reference value included in the data packet to determine whether an error has occurred during the transmission of the data packet.

[0076] When an error is detected in a data packet, an error feedback signal is sent to the host to inform the host that the data packet transmission failed;

[0077] After receiving the error feedback from the device, the host resends the firmware data packet to the device. During the data retransmission process, the host ensures that the data packet and its CRC reference value remain unchanged to ensure that the device can correctly perform CRC check.

[0078] In this embodiment, the integrity check of the firmware is performed by USP, including:

[0079] The USP passes the received firmware data to the hardware CRC module, which performs CRC calculation on the data according to a predetermined generator polynomial and generates a CRC value. This value is used to compare with the CRC reference value in the firmware to verify the integrity and validity of the data.

[0080] USP compares the calculated CRC value with the CRC reference value in the firmware bin header. If the two match, it means that there was no error in the firmware data during transmission and it is complete and valid. If they do not match, it means that the firmware data may be damaged or tampered with, and USP will refuse to accept the firmware.

[0081] In this embodiment, the firmware is checked for validity by USP, including:

[0082] Header validity check: During the firmware update process, USP recalculates the checksum of the received header data and compares it with the checksum stored in the header. If the two match, it means that there is no error in the header data during transmission and it is complete and valid. If they do not match, it means that the header data may be damaged or tampered with, and USP will refuse to accept the firmware or take other measures.

[0083] Bin validity check: During the Bin validity check, a segment of instruction code is randomly extracted from the code area and the opcode is parsed out. Then, these opcodes are compared with the valid opcode values ​​defined in the RISC-V specification. If all the extracted opcodes are valid, it means that the bin's code area has no errors during transmission and is complete and valid. If an invalid opcode is found, it means that the bin's code area may be damaged or tampered with, and the USP will refuse to accept the firmware or take other measures.

[0084] During data transmission, each time a data packet is sent, the device needs to verify and confirm whether it is received successfully.

[0085] In this embodiment, the BL is executed when the device is restarted, and the execution includes verifying the integrity and validity of the firmware of the active partition, establishing a mapping between the active partition and the virtual application area, and finally jumping to the application space to execute the firmware or operating system stored in the active partition;

[0086] The BL is used to maintain a partition table of the flash memory, which is used to store information about the flash physical area following the area where the BL is located. The partition table contains at least two entries, representing an active partition and a backup partition. The active partition is used to store the currently used firmware or operating system; the backup partition is used as a backup of the firmware or operating system.

[0087] Specifically, the boot loader BL of this embodiment completes the firmware upgrade process together with the upgrade service program USP. The USP supports UART local upgrade or remote upgrade via UART+WIFI / BLE. The BL checks and verifies the upgraded firmware image and starts normally. The host tool can burn the firmware through the UART interface, such as for firmware mass production.

[0088] Among them, USP is responsible for monitoring upgrade events, receiving and writing new firmware, setting new firmware flags, etc.; USP supports local upgrade or remote upgrade. USP itself will write the firmware to flash and set the firmware header upgrade flag; USP supports two upgrade modes: silent background upgrade or foreground upgrade.

[0089] Among them, BL is executed when the device is restarted. BL is responsible for completing the firmware integrity and validity check of the active partition, mapping the active partition to the virtual app area, jumping app execution, and other functions. BL maintains the flash partition table, which stores the flash physical area information after the area where BL is located. The partition table of this embodiment consists of two entries, representing the active partition and the inactive partition (backup partition) respectively. The entry contains the following information: the starting physical address addr of the partition; the size of the partition size; whether the partition is active.

[0090] like Figure 3 and Figure 4 As shown, the storage mapping of this embodiment includes:

[0091] a. Flash physical space can be remapped to app virtual space

[0092] b. The APP is divided into a read-only area for storing firmware and a read-write area for user data space.

[0093] c. The firmware format is an image file format consisting of a header and a bin file containing additional information. It is an image format recognizable by BL. The header space is fixed at 64 bytes and mainly contains information such as the header checksum, firmware version number, bin size, bin execution address, upgrade flag, CRC32 check bit, etc.

[0094] Specifically, the upgrade communication protocol of this embodiment includes:

[0095] Physical layer:

[0096] Physical signal pins, using UART communication, require two main signal pins:

[0097] 1.TXD (Transmit Data): The data sending pin of the transmitter, responsible for outputting data to the transmission line.

[0098] 2.RXD (Receive Data): The data receiving pin at the receiving end is responsible for receiving data from the transmission line.

[0099] UART frame structure. In UART, data is transmitted in the form of frames. Each frame consists of several parts: Start Bit + Data Bits + Parity Bit + Stop Bit.

[0100] Baud rate, the default baud rate of the physical layer is 115200, and handshake negotiation is supported to negotiate a higher or lower baud rate

[0101] Protocol layer:

[0102] Start firmware upgrade command: issued by the host upgrade tool to notify the device to enter firmware upgrade mode. The host can request the device to perform a background silent upgrade or a foreground upgrade.

[0103] Firmware package distribution: Split the firmware file into multiple small packages (if it is a background silent upgrade, the data size is fixed at 4 bytes) and send them one by one via UART.

[0104] Data verification: In order to ensure the integrity of data during transmission, CRC verification is usually required.

[0105] Packet confirmation mechanism: After each data packet is sent, the device needs to verify and confirm whether it is successfully received.

[0106] Retransmission mechanism: If the receiver finds that the data packet is wrong, it asks the sender to resend the data packet.

[0107] End firmware upgrade command: After all firmware is transferred, send the end command to notify the device to write the new firmware.

[0108] In this embodiment, the firmware upgrade protocol packet format includes the following fields:

[0109] Header: Indicates the beginning of the protocol packet and is marked with a fixed byte 0xFE.

[0110] Command type: Identifies whether the packet is an upgrade command, data packet, or confirmation packet, etc.

[0111] Data length: The length of the data in this data packet, in bytes.

[0112] Data packet number: used to identify the order of data packets when they are transmitted in packets.

[0113] Data content: actual firmware data or control commands.

[0114] Check value: used to check whether the data is transmitted correctly (CRC).

[0115] Tail: Marks the end of the data packet and is marked with a fixed byte 0xEF.

[0116] In this embodiment, the command type description includes:

[0117] 0x53: Upgrade start command, used to notify the device to enter upgrade mode. No parameters.

[0118] 0x45: Upgrade end command, used to end the upgrade process and notify the device to start verifying or writing firmware.

[0119] 0x11: Communication rate negotiation command. After handshaking at the default communication rate, a higher or lower rate can be negotiated based on the characteristics of both parties.

[0120] 0x22: Data transfer command, the actual transmission of each firmware data packet.

[0121] 0x33: Confirmation command. The receiver confirms receipt of a packet. The sender continues to send the next packet after receiving it.

[0122] 0x44: Background silent upgrade command.

[0123] 0x55: The front desk receives an upgrade command.

[0124] In practical applications, the method provided in this embodiment first confirms the model and current firmware version of the RISC-V MCU, downloads the latest firmware upgrade package from a reliable source, and receives the firmware upgrade data sent by the host through a specific communication protocol (such as UART, SPI, etc.). After the upgrade is complete, the firmware upgrade data is written to the storage area of ​​the RISC-V MCU, and the relevant register configuration and status information are updated as needed. After the firmware upgrade is complete, the necessary verification and testing work is performed, and the RISC-V MCU is restarted to make the new firmware take effect.

[0125] In summary, the present invention provides a set of hardware and software mechanisms that support location-independent firmware upgrades, enabling dual-host backup upgrades without system bricking due to upgrade failures. Furthermore, the present invention's low-power, low-cost RISC-V architecture also makes this method significantly advantageous in scenarios such as the Internet of Things and edge computing.

[0126] Furthermore, this method supports two modes: silent background upgrade and visible foreground upgrade. It can be flexibly selected according to the upgrade request mode of the host side and the operating status of the device side. It does not affect the user experience (silent upgrade) and can provide clear upgrade feedback when necessary (visible upgrade).

[0127] Furthermore, the firmware data packet of the present invention includes a CRC reference value, which is used to verify the integrity of the data during transmission, ensuring that the firmware is not damaged due to transmission errors during the upgrade process. After receiving the firmware data, the device also performs an integrity and validity check on the firmware through the USP, further enhancing the security of the firmware upgrade.

[0128] Furthermore, the present invention sets the update_flag in the firmware header to mark the old and new versions of the firmware, allowing the device to automatically identify and load the latest valid firmware after a reboot. If an error is detected while executing the updated firmware, the BL performs a version rollback process, reactivating the backup partition storing the previous version as the active partition and remapping the partition before executing the new version, thus ensuring system stability and reliability.

[0129] Furthermore, the present invention achieves fast and efficient firmware loading and switching by using a bootloader (BL) to traverse partitions in the partition table, parse valid firmware from the partitions, and check the firmware update flag in the firmware header. The modular nature of the RISC-V architecture also makes this method more adaptable to different application requirements and hardware configurations.

[0130] The above embodiments are only preferred embodiments of the present invention and cannot be used to limit the scope of protection of the present invention. Any non-substantial changes and replacements made by technicians in this field on the basis of the present invention fall within the scope of protection required by the present invention.

Claims

1. A RISC-V MCU system firmware upgrade method, characterized in that: include: The host initiates an upgrade request, and the device replies to confirm the start based on its own operating status; The device starts the upgrade service program USP and selects to enter the background silent upgrade or the foreground active upgrade according to the upgrade request mode of the host; After the backup area is determined, the device determines whether to enter the background silent upgrade or the foreground active upgrade according to the type of upgrade command received; The host transmits the firmware data packet to the device, where the firmware data packet carries a CRC reference value for verifying data integrity; After receiving the firmware data on the device side, the firmware is checked for integrity and validity through USP; If the firmware passes the integrity and validity check, USP sets the update_flag in the firmware header of the current region to 1, indicating that the firmware in this region is the new upgraded firmware; at the same time, it sets the update_flag in the firmware header of another region to 0, indicating that the firmware in this region is the old version firmware; The USP phase on the device side is completed, and it is determined whether to restart the device; After the device is restarted, the bootloader BL traverses the partitions in the partition table, parses the valid firmware from the partition, and checks the firmware update flag update_flag in the firmware header; If a partition with update_flag set to 1 is detected, BL marks the partition as an active partition and performs integrity and validity checks; If the check passes, BL maps the active partition to the virtual address space and jumps to the app address space to execute the upgraded new firmware; If an error is detected when executing the updated firmware, BL will perform the version rollback process, that is, reactivate the backup partition storing the previous version as the active partition, and jump to execution after remapping.

2. The method according to claim 1, characterized in that: When determining the backup area, USP determines the backup area or active area by traversing and checking the update_flag of the header in the backup / active area. The area with update_flag of 1 is the active area, and the area with update_flag of 0 is the backup area.

3. The method according to claim 1, characterized in that: The background silent upgrade is used to ensure that the process of USP receiving firmware data does not affect the normal operation of the application app, specifically including: The server splits the firmware data into multiple small data packets and sends them to the device according to the predetermined protocol and sequence. The device immediately stores or processes each small data packet after receiving it. Among them, when the device receives a small data packet from the server, the firmware receives the interrupt and is delegated to a low-privilege mode using the TrapDelegation function of the interrupt mechanism in the RISC-V architecture, while the main application can still run at a higher privilege level without interference.

4. The method according to claim 1, characterized in that: The foreground upgrade allows the system to suspend the running of the application during the upgrade process, including: When USP receives the firmware data from the server, it immediately triggers the foreground upgrade process. At this time, USP sends a command to the system to stop the currently running application. After the application stops running, the system switches to the upgrade display interface. The server splits the firmware data into multiple large data packets and sends them to the device according to the preset protocol and sequence. The device suspends responding to other requests during the upgrade process. Among them, the device side sets a global flag or status variable at the beginning of the upgrade to indicate that the current system is in the upgrade state; then, when processing the request, the device side first checks the value of the flag or status variable. If its value is upgrading, the device side refuses to process the request and returns a corresponding error prompt to the user.

5. The method according to claim 1, characterized in that: During the transmission of the firmware data packet, the host sends the firmware data packet and its own CRC reference value to the device. After receiving the data packet, the device verifies it according to the CRC reference value attached to the data packet to determine whether an error occurs during the transmission of the data packet. When an error is detected in a data packet, an error feedback signal is sent to the host to inform the host that the data packet transmission failed; After receiving the error feedback from the device, the host resends the firmware data packet to the device; during the data retransmission process, the host ensures that the data packet and its CRC reference value remain unchanged to ensure that the device can correctly perform CRC check.

6. The method according to claim 1, characterized in that: The firmware is checked for integrity by USP, including: The USP passes the received firmware data to the hardware CRC module, which performs CRC calculation on the data according to the predetermined generator polynomial and generates a CRC value, which is used to compare with the CRC reference value built into the firmware to verify the integrity and validity of the data; USP compares the calculated CRC value with the CRC reference value in the firmware bin header. If the two match, it means that there is no error in the firmware data transmission process and it is complete and valid. If they do not match, it means that the firmware data may be damaged or tampered with, and USP will refuse to receive the firmware.

7. The method according to any one of claims 1 to 6, characterized in that: The firmware is checked for validity by USP, including: Header validity check: During the firmware update process, USP recalculates the checksum of the received header data and compares it with the checksum stored in the header; if the two match, it means that there is no error in the header data during transmission and it is complete and valid; if they do not match, it means that the header data may be damaged or tampered with, and USP will refuse to receive the firmware or take other measures.

8. The method according to claim 7, characterized in that: The firmware is checked for validity by USP, including: Bin validity check: During the Bin validity check, a segment of instruction in the code area is randomly extracted and the opcode is parsed out. Then, these opcodes are compared with the valid opcode values ​​defined in the RISC-V specification. If all the extracted opcodes are valid, it means that there is no error in the code area of ​​the bin during the transmission process and it is complete and valid. If an invalid opcode is found, it means that the code area of ​​the bin may be damaged or tampered with, and USP will refuse to receive the firmware or take other measures.

9. The method according to any one of claims 1 to 6, characterized in that: During data transmission, each time a data packet is sent, the device needs to verify and confirm whether it is successfully received.

10. The method according to any one of claims 1 to 6, characterized in that: BL is executed when the device is restarted. The execution includes verifying the integrity and validity of the firmware of the active partition, establishing a mapping from the active partition to the virtual application area, and finally jumping to the application space to execute the firmware or operating system stored in the active partition; The BL is used to maintain a partition table of the flash memory, and the partition table is used to store the flash physical area information after the area where the BL is located; wherein the partition table contains at least two entries, representing an active partition and a backup partition respectively, the active partition is used to store the firmware or operating system currently in use; the backup partition is used as a backup of the firmware or operating system.

Images