Firmware upgrading method and device, computer equipment and storage medium

Abstract

The invention relates to a firmware upgrading method and device, computer equipment and a storage medium. The method comprises the steps that a corresponding virtual file interface is created for each microcontroller in a system; generating a differential patch based on the current firmware version and the target firmware; writing an upgrade preparation instruction into the control file to enable the microcontroller to be in an upgrade preparation state, and transmitting the differential patch to the microcontroller through the data channel file; writing a firmware reconfiguration command into the control file, triggering the microcontroller to reconfigure and generate target firmware in the inactive storage partition by combining the current firmware stored in the microcontroller and the differential patch; writing an atomic switching command into the control file, and triggering the microcontroller to execute atomic operation to modify the guide configuration; and reading the state file, and obtaining the upgrading state or rollback information of the microcontroller. According to the firmware upgrading method and device, the computer equipment and the storage medium, efficient, safe and reliable firmware differential upgrading can be achieved.

Description

Technical Field

[0001] This invention belongs to the field of firmware upgrade technology, and particularly relates to a firmware upgrade method, apparatus, computer equipment, and storage medium. Background Technology

[0002] Firmware upgrades are an indispensable part of the embedded system's lifecycle, used to fix defects, add functionality, or improve performance. Their technological evolution has gone through the following main stages: In the early stages, MCU firmware updates relied on physical contact, requiring the chip to be removed from the circuit board and programmed using a specialized programmer, or by connecting to an emulator via debugging interfaces such as JTAG / SWD. This method was costly and inefficient, suitable only for the R&D phase and unsuitable for field maintenance of deployed products.

[0003] In the mid-stage, to address the inconvenience of offline programming, a bootloader based on buses such as UART, I2C, SPI, and CAN was introduced. When the device powers on, the bootloader runs first, entering upgrade mode through preset trigger conditions (such as specific pin levels or specific communication commands). The host computer (such as a PC) sends the complete firmware binary file to the bootloader via a serial interface, which is responsible for erasing the old firmware and writing the new firmware. This method enables online upgrades, but it has the following problems: low transmission efficiency, typically requiring the transmission of the complete firmware image, which is extremely time-consuming for modern MCU firmware that can easily reach several megabytes via a low-speed bus (such as UART); and poor reliability, as the upgrade process is a destructive "erase-write" operation. If a power outage or communication interruption occurs during the writing process, the MCU may become "bricked" due to incomplete firmware, making it impossible to restart and extremely difficult to recover. Furthermore, the protocols are non-standard; different MCU manufacturers or developers implement different bootloader protocols, requiring the host computer software to be adapted for different devices. In complex systems managing multiple MCUs, the host computer application logic becomes exceptionally complex. Security is also lacking: firmware transmission is usually in plaintext, lacking authentication and data integrity verification, making it vulnerable to man-in-the-middle attacks and malicious firmware injection.

[0004] In recent times, to improve reliability, an A / B partitioning (or ping-pong upgrade) mechanism has been introduced. The MCU's Flash memory is divided into two independent firmware storage areas (A and B). When the system is running in area A, new firmware is downloaded to the idle area B. After downloading and verification, the boot flag is modified so that the system will boot from area B next time. This method avoids the risk of "bricking" during the upgrade process because even if the new firmware has problems, the system can still roll back to the old firmware in area A. However, the following shortcomings still exist: full upgrade packages are still commonly used, which puts a huge strain on network bandwidth or internal bus bandwidth, especially in billed traffic scenarios such as cellular networks, where costs are high; the upgrade interaction logic between the main control unit and the MCU is usually handled directly by the application layer software, which is tightly coupled with the underlying drivers and communication protocols. When there are multiple MCUs from different manufacturers using different communication buses in the system, the application software on the main control end needs to maintain multiple complex and parallel upgrade logics, resulting in poor scalability and maintainability. Most rollback mechanisms rely on external intervention (such as the main control sending rollback commands) or are based solely on simple boot count judgments, lacking effective monitoring of the functional "health" status of the new firmware. This may lead to the system "falsely" succeeding on a defective but bootable new firmware version, causing potential functional failures. Summary of the Invention

[0005] In view of this, the present invention provides a firmware upgrade method, apparatus, computer equipment and storage medium to solve the problems of low efficiency, insufficient reliability, poor security and tight coupling between the main control software and MCU hardware and weak scalability in MCU firmware upgrades in heterogeneous systems.

[0006] To achieve the above objectives, in a first aspect, the technical solution of the present invention to solve the technical problem is to provide a firmware upgrade method, applied to a system including a main control processor and at least one microcontroller. The method is executed by the main control processor and includes: creating a corresponding virtual file interface for each microcontroller in the system, the virtual file interface including a control file, a status file, a data channel file, and a version information file; reading the version information file to obtain the current firmware version of the microcontroller to be upgraded, and generating a differential patch based on the current firmware version and the target firmware; writing an upgrade preparation instruction to the control file to put the microcontroller in an upgrade preparation state, and transmitting the differential patch to the microcontroller through the data channel file; writing a firmware reconstruction command to the control file to trigger the microcontroller to reconstruct and generate the target firmware in an inactive storage partition by combining the current firmware and the differential patch stored in its own storage; writing an atomic switch command to the control file to trigger the microcontroller to perform an atomic operation to modify the boot configuration and switch the boot partition to the inactive storage partition storing the target firmware; reading the status file to obtain the upgrade status or rollback information of the microcontroller, wherein the rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its boot program when the target firmware fails to be checked in a predetermined number of times.

[0007] In one specific embodiment, before transmitting the differential patch to the microcontroller via the data channel file, the process further includes establishing an information channel: the main control processor generates a random number and sends it to the microcontroller; the microcontroller uses a pre-shared key to calculate a message authentication code based on the random number and returns it to the main control processor; the main control processor uses the same pre-shared key and the random number to perform the same calculation and verifies the returned message authentication code. After successful verification, the secure communication channel is confirmed to have been successfully established.

[0008] In one specific embodiment, after writing the upgrade preparation instruction to the control file, the process further includes: the main control processor reading the status file to determine whether the microcontroller is in the upgrade preparation state.

[0009] In one specific embodiment, after generating a differential patch based on the current firmware version and the target firmware, the method further includes: digitally signing the target firmware, wherein the digital signature is generated by the main control processor using a private key to calculate the hash value of the target firmware, and is configured to be transmitted to the microcontroller together with the differential patch.

[0010] In one specific embodiment, after the microcontroller reconstructs and generates the target firmware in the inactive storage partition by combining the current firmware and differential patch stored in its own storage, it also performs integrity and authenticity verification on the target firmware, including: the microcontroller calculates the hash value of the target firmware and uses a preset public key to verify whether the digital signature from the main control processor is a valid signature of the hash value. If so, the target firmware is determined to have passed the verification, and the verification success status is reported by updating the status file.

[0011] In one specific embodiment, when the triggering microcontroller executes an atomic operation to modify the boot configuration, the boot configuration includes at least an identifier for indicating the boot partition and an upgrade attempt counter. The atomic operation changes the value of the identifier from pointing to the currently active storage partition to pointing to the inactive storage partition storing the target firmware, and at the same time sets the upgrade attempt counter from its non-upgrade state value to an initial value indicating the first upgrade attempt.

[0012] In one specific embodiment, the rollback signal generation process includes an iterative step triggered by a reset. In each iteration: when the microcontroller's bootloader starts, it reads the upgrade attempt counter and identifier stored in its non-volatile memory; if the upgrade attempt counter indicates that an upgrade attempt is in progress, the bootloader determines whether its count value exceeds the preset maximum allowed number of attempts; if it exceeds, the bootloader performs a rollback operation; if it does not exceed, the bootloader attempts to start the target firmware according to the identifier and starts a watchdog timer; if the target firmware fails to atomically clear the upgrade attempt counter before the watchdog timer expires, the bootloader triggers a reset to start the next iteration and increments the value of the upgrade attempt counter at the next startup.

[0013] Secondly, a firmware upgrade device is provided, comprising: an interface creation module for creating a corresponding virtual file interface for each microcontroller in the system, the virtual file interface including a control file, a status file, a data channel file, and a version information file; a patch generation module for reading the version information file, obtaining the current firmware version of the microcontroller to be upgraded, and generating a differential patch based on the current firmware version and the target firmware; a data transmission module for writing an upgrade preparation command to the control file, putting the microcontroller in an upgrade preparation state, and transmitting the differential patch to the microcontroller through the data channel file; a firmware reconstruction module for writing a firmware reconstruction command to the control file, triggering the microcontroller to combine its own stored current firmware and differential patch to reconstruct and generate the target firmware in an inactive storage partition; an atomic switching module for writing an atomic switching command to the control file, triggering the microcontroller to perform an atomic operation to modify the boot configuration and switch the boot partition to the inactive storage partition storing the target firmware; and a status reading module for reading the status file to obtain the upgrade status or rollback information of the microcontroller, wherein the rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its boot program when the target firmware fails to be checked in a predetermined number of times.

[0014] Thirdly, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, characterized in that the processor implements the firmware upgrade method when executing the computer program.

[0015] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being executed by a processor as a firmware upgrade method.

[0016] Compared with the prior art, the firmware upgrade method, apparatus, computer equipment, and storage medium provided by the present invention have the following beneficial effects: By completely isolating the application layer from specific microcontroller models and communication buses through a virtual file interface, any type of microcontroller can be managed with simple file read and write operations. This greatly reduces the development and maintenance complexity of the main control application. When adding a new microcontroller, only a kernel driver and MCU firmware conforming to this framework need to be developed for it, without any modification to the main control application layer code. At the same time, it supports concurrent upgrades of multiple MCUs by simply opening multiple device files, providing a unified and standardized MCU management paradigm that facilitates automated testing, deployment, and operation and maintenance.

[0017] Differential upgrades transmit only 5%-20% of the full packet, significantly shortening upgrade time, saving bandwidth (especially expensive wireless network traffic), and reducing the RAM required for data processing within the MCU.

[0018] By using A / B partitioning and atomic switching, the upgrade process ensures that the running system is not affected, and the switching action is completed instantly, minimizing service interruption time. Based on multiple safeguards such as attempt counters, watchdog timers, and application check-ins, it can not only prevent bricking caused by startup failure, but also detect false liveness states that can start but cannot work properly, achieving true system self-healing.

[0019] By using identity authentication and encrypted transmission, the risk of firmware being eavesdropped on, tampered with, or injected with malicious firmware is eliminated, ensuring the security of the entire system. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the steps of a firmware upgrade method provided in the first embodiment of the present invention. Figure 2 This is a schematic diagram of a virtual file interface module in a firmware upgrade method; Figure 3 This is a schematic diagram of the logic for determining whether to perform a rollback operation in a firmware upgrade method. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] It should be noted that all directional indications in the embodiments of this application are only used to explain the relative positional relationship and movement of each component in a specific posture. If the specific posture changes, the directional indications will also change accordingly.

[0023] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. When the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0024] like Figures 1 to 2 As shown, the first embodiment of this application provides a firmware upgrade method, applied to a system including a main control processor and at least one microcontroller. The method is executed by the main control processor and includes the following steps: S100 creates a corresponding virtual file interface for each microcontroller in the system. The virtual file interface includes a control file, a status file, a data channel file, and a version information file. Specifically, the control file is used to send high-level upgrade-related commands to the microcontroller, such as preparing for upgrade, triggering switchover startup, and aborting upgrade; the status file is used to query the current upgrade status of the MCU, such as idle, upgrading in progress, verification successful, and rollback occurring; the data channel file is used to transmit data such as differential upgrade patches; and the version information file is used to read information such as the currently running firmware version, bootloader version, and hardware version of the microcontroller.

[0025] In this embodiment, the system includes a high-performance main control processor running the Linux operating system, such as the NXP.MX series, TI AM series, etc., and one or more microcontrollers (MCUs) connected via buses such as SPI, UART, I2C or CAN, such as STM32, Infineon Aurix, Renesas RH85, etc.

[0026] By implementing a character device driver for each MCU in the Linux kernel, and utilizing the Linux miscdevice or sysfs framework, a unique virtual device node is created for each MCU in the / dev / or / sys / class / directory, such as / dev / mcu0, / dev / mcu1, etc., thus achieving hardware decoupling.

[0027] Each microcontroller is not a single file node, but a directory containing functionally defined virtual files (attribute files), mapping complex upgrade state machines and data flows to simple file read / write operations, for example: / dev / mcu0 / control (write-only): This is the control file used to send high-level commands to the microcontroller. The application layer initiates operations via `echo "COMMAND"> / dev / mcu0 / control`.

[0028] prepare_upgrade: Notifies the microcontroller to prepare to enter upgrade mode, locks application functions, and returns the current version information.

[0029] transfer_patch: Indicates that subsequent data written to the data file will be differential patches.

[0030] The verify_patch command enables the microcontroller to verify received patches and merge them with the old firmware to generate the target firmware.

[0031] switch_boot: Commands the microcontroller to perform an atomic switch, and the next boot will be from the target firmware.

[0032] abort_upgrade: interrupts the upgrade process at any time.

[0033] query_status: Triggers a status update.

[0034] / dev / mcu0 / status (read-only): This is the status file used to query the current status of the microcontroller. The application layer reads it via `cat / dev / mcu0 / status`.

[0035] Possible status indicators include: idle,ready_for_upgrade,transferring,verifying,verification_ok,verification_failed,ready_to_switch,booting_new,running_new_ok,rollback_occurred,error_xxx, etc.

[0036] / dev / mcu0 / data (write-only): Data channel file used to transfer data to the microcontroller, mainly differential upgrade patches. The application layer writes patch data blocks to this file using the standard write() system call.

[0037] / dev / mcu0 / version (read-only): Version information file, which can read the currently running firmware version, bootloader version, hardware version, etc. on the microcontroller.

[0038] S200 reads the version information file, obtains the current firmware version of the microcontroller to be upgraded, and generates a differential patch based on the current firmware version and the target firmware. Specifically, when an upgrade is required, the main control processor first obtains the current firmware version of the microcontroller by reading the version information file, and then obtains the target firmware for the upgrade version. Next, it calls differential algorithms, such as bsdiff and xdelta, to generate a differential patch.

[0039] The difference algorithm can be expressed as:

[0040] F old It is a binary image of the old firmware, F new It is a binary image of the target firmware. It is the generated differential patch file.

[0041] Understandably, a block matching algorithm optimized for embedded systems can also be invoked to generate differential patches.

[0042] S300 writes upgrade preparation instructions to the control file, puts the microcontroller in upgrade preparation state, and transmits the differential patch to the microcontroller through the data channel file; Specifically, after the differential patch is created, an upgrade preparation instruction is written to the control file. The application layer writes the differential patch to the data channel file. The kernel driver segments, encrypts, and packages the data, and sends it to the microcontroller via the underlying bus. Upon receiving the data, the microcontroller stores the patch data in a dedicated RAM buffer or a temporary area in Flash.

[0043] S400 writes a firmware refactoring command to the control file, triggering the microcontroller to combine the current firmware and differential patch stored in its own storage to refactor and generate the target firmware in the inactive storage partition. Specifically, after the microcontroller receives the differential patch, the main processor writes a firmware reconstruction command through the control file. The microprocessor reads the current firmware version from the partition where the currently running firmware is located, such as partition A, and, in conjunction with the received differential patch, gradually reconstructs the target firmware in an inactive area, such as partition B. For example:

[0044] The refactoring process utilizes the microcontroller's Flash read / write capabilities, simultaneously reading from area A, performing calculations, and writing to area B to optimize memory usage.

[0045] After completing the target firmware reconstruction, the microcontroller updates its status, either by updating the status file, which can be done through polling by the kernel driver or by the microcontroller reporting proactively. For example, the microcontroller updates the status file and reports verification_ok to the main controller processor.

[0046] S500 writes an atomic switching command to the control file, triggering the microcontroller to perform an atomic operation to modify the boot configuration and switch the boot partition to the inactive storage partition storing the target firmware; Specifically, after the reconstruction is completed, the main control processor can write an atomic switching command to the control file at an appropriate time, such as when the vehicle is stationary or the production line is stopped. After receiving this command, the microcontroller performs an atomic operation to modify the boot configuration, which is usually stored in a separate, very small Flash sector or eFuse with ECC verification.

[0047] S600 reads the status file to obtain the microcontroller's upgrade status or rollback information. The rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its bootloader when the target firmware fails to sign in a predetermined number of times. Specifically, when the microcontroller atomically switches to the partition corresponding to the target firmware and boots, if the target firmware fails to complete initialization and confirm that it has entered a stable and usable working state within the specified time, it is considered a check-in failure, and the boot attempt is judged as a failure. When such failed attempts accumulate to a predetermined number, the bootloader will automatically perform a rollback operation, restore to the original firmware version, and update the state file with this rollback event. If the target firmware completes initialization and confirms that it has entered a stable and usable working state within the predetermined number of attempts and the specified time, the boot attempt is considered successful, and the boot success event is updated with the state file.

[0048] In one embodiment, after generating a differential patch based on the current firmware version and the target firmware, the method further includes: The target firmware is digitally signed, wherein the digital signature is generated by the main control processor using a private key to calculate the hash value of the target firmware, and is configured to be transmitted to the microcontroller along with the differential patch.

[0049] Specifically, after generating the differential patch, the main control unit will also modify the target firmware F. new Perform digital signature, generate signature Where H is the hash function, such as SHA-256, and K... priv It is the private key. Signature S and differential patch The data is transmitted to the microcontroller either together or separately.

[0050] In one embodiment, before transferring the differential patch to the microcontroller via a data channel file, an information channel is established, specifically: The main processor generates random numbers and sends them to the microcontroller; The microcontroller uses a pre-shared key to calculate a message authentication code based on random numbers and returns it to the main controller processor; The main control processor uses the same pre-shared key and random number to perform the same calculations and verifies the returned message authentication code. Once the verification is successful, the secure communication channel is confirmed to have been established.

[0051] Specifically, after writing the upgrade preparation instructions to the control file, the kernel driver and the microcontroller firmware will perform a lightweight handshake protocol to establish a secure session, such as using a challenge-response mechanism with a pre-shared key (PSK).

[0052] All subsequent data packets transmitted via the data channel will be encrypted and authenticated using a session key (such as AES-128-GCM mode) to ensure data confidentiality and integrity and prevent eavesdropping and tampering.

[0053] In one embodiment, after writing the upgrade preparation instruction to the control file, the method further includes: The main control processor reads the status file to determine whether the microcontroller is in upgrade preparation state.

[0054] Specifically, when the microcontroller receives the upgrade preparation instruction sent by the main controller through the control file, it does not immediately complete all operations. Instead, it performs a series of actions such as locking the current application and preparing the receive buffer. After processing, it actively updates its state to the state file through the kernel driver. The main controller must read the state flags in the state file and confirm that the microcontroller is in the upgrade preparation state before it can begin transmitting the differential patch. Otherwise, if the microcontroller is not ready to receive data, it may lead to data loss, buffer overflow, or communication disorder, resulting in upgrade failure.

[0055] In this embodiment, after writing the upgrade preparation instruction, the main control processor can read the status file by polling.

[0056] It should be noted that other methods, such as interrupt callback mechanisms, message queues / signals, and fixed delay waiting, can also be used as the basis for determining whether a microcontroller is in an upgrade-ready state.

[0057] In one embodiment, after the microcontroller reconstructs the target firmware from the inactive storage partition by combining the current firmware stored in its own memory with the differential patch, it also performs integrity and authenticity verification on the target firmware, including: The microcontroller calculates the hash value of the target firmware and uses a preset public key to verify whether the digital signature from the main controller is a valid signature of the hash value. If so, the target firmware is determined to have passed the verification, and the verification success status is reported by updating the status file.

[0058] Specifically, after the reconstruction is complete, the microcontroller calculates the newly generated firmware. hash value Then, using the public key K preset in the microcontroller's secure storage area, such as OTP or protected Flash,... pub The signature S sent by the master controller is decrypted and verified.

[0059] The verification conditions are:

[0060] The target firmware is considered complete and legitimate only when the hash value matches and the signature verification passes. After successful verification, the microcontroller updates the status file, either through kernel polling or by actively reporting the status.

[0061] In one embodiment, before writing the atomic switching command to the control file, the method further includes reading the status file to determine whether the integrity and authenticity verification of the target firmware has been successfully completed.

[0062] In this embodiment, after verifying the integrity and authenticity of the target firmware, the microcontroller updates the status flag corresponding to the status file to verification_ok. After the main control processor confirms that the microcontroller's status flag is verification_ok, it sends an atomic switching command at an appropriate time.

[0063] In one embodiment, when the microcontroller is triggered to perform an atomic operation to modify the boot configuration, the boot configuration includes at least an identifier for indicating the boot partition and an upgrade attempt counter. The atomic operation changes the value of the identifier from pointing to the currently active storage partition to pointing to the inactive storage partition storing the target firmware, and at the same time sets the upgrade attempt counter from its non-upgrade state value to an initial value indicating the first upgrade attempt.

[0064] Specifically, the modifications to the boot partition identifier and the upgrade attempt counter are an inseparable whole; they either take effect simultaneously or remain completely unchanged, thus absolutely avoiding the system falling into an intermediate state of inconsistent boot targets. Setting the upgrade attempt counter to its initial value of "1" signifies formally entering the "first upgrade attempt" phase, establishing a clear starting point for subsequent automatic rollback criteria based on this counter. Once this atomic operation is completed, the microcontroller automatically triggers a hardware reset to enter the boot process determined by the new configuration.

[0065] like Figure 3 As shown, in one embodiment, the rollback signal generation process includes an iterative step triggered by a reset, in each iteration: When the microcontroller bootloader starts, it reads the upgrade attempt counter and identifier stored in its non-volatile memory. If the upgrade attempt counter indicates that an upgrade attempt is in progress, the bootloader determines whether the count value exceeds the preset maximum allowed number of attempts; If the timeout is exceeded, the bootloader performs a rollback operation; if the timeout is not exceeded, the bootloader attempts to boot the target firmware based on the identifier and starts a watchdog timer. If the target firmware fails to atomically clear the upgrade attempt counter before the watchdog timer expires, the bootloader triggers a reset to start the next iteration and increments the upgrade attempt counter value on the next startup.

[0066] Specifically, the rollback information generation process is completed through an automated loop triggered by a system reset. This loop begins when the microcontroller's bootloader reads the upgrade attempt counter and boot partition identifier stored in a protected non-volatile area (such as a separate Flash sector) at each startup. If the counter indicates the system is in the middle of an upgrade attempt (i.e., its value is non-zero), the bootloader first checks if the count has exceeded the preset maximum allowed number of attempts (e.g., 3). If it has, the bootloader immediately performs a rollback operation, rewriting the boot partition identifier to point to a known, healthy original firmware partition, resetting the counter to zero, and updating the status file to indicate that a rollback has occurred. If the count has not exceeded the limit, the bootloader attempts to boot the target firmware based on the identifier and simultaneously starts a separate hardware watchdog timer. The target firmware must complete all critical initializations before this timer expires and execute a core atomic operation to reset the aforementioned upgrade attempt counter to zero, serving as the sole proof of its successful "check-in" and entry into a stable working state. If the target firmware fails to complete the atomic zeroing operation in time due to a fault, deadlock, or initialization delay, the watchdog timer will time out and force a system-level hardware reset. This reset signifies the failure of this boot attempt. After the system restarts, the bootloader will increment the upgrade attempt counter at the beginning of a new loop to accumulate the number of failures, and repeat the entire process of reading, judging, and attempting until the target firmware successfully checks in or the accumulated failures exceed the limit, triggering an automatic rollback.

[0067] Thus, with multiple safeguards based on the attempt counter, watchdog timer, and application check-in, it can not only prevent bricking caused by startup failure, but also detect false liveness states where the system can start but cannot work properly, achieving true system self-healing and improving reliability.

[0068] The second embodiment of this application provides a firmware upgrade device, which includes: The interface creation module is used to create a corresponding virtual file interface for each microcontroller in the system. The virtual file interface includes a control file, a status file, a data channel file, and a version information file. The patch generation module is used to read the version information file, obtain the current firmware version of the microcontroller to be upgraded, and generate a differential patch based on the current firmware version and the target firmware. The data transmission module is used to write upgrade preparation instructions to the control file, put the microcontroller in upgrade preparation state, and transmit the differential patch to the microcontroller through the data channel file. The firmware refactoring module is used to write firmware refactoring commands to the control file, triggering the microcontroller to combine the current firmware and differential patches stored in its own storage to refactor and generate the target firmware in the inactive storage partition. The atomic switching module is used to write atomic switching commands to the control file, triggering the microcontroller to perform atomic operations to modify the boot configuration and switch the boot partition to the inactive storage partition storing the target firmware; The status reading module is used to read the status file and obtain the upgrade status or rollback information of the microcontroller. The rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its bootloader when the target firmware fails to check in a predetermined number of times.

[0069] Each module in the aforementioned firmware upgrade device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0070] In this embodiment, the main control processor is an NXP.MX8MPlus running a Linux 5.10 operating system based on the Yocto project. Two microcontrollers are used, specifically two STM32H753XI chips. This model of MCU integrates 2MB of dual-bank Flash memory, supporting simultaneous read and write operations to different memory banks, providing a hardware foundation for A / B partition upgrades. The two MCUs are connected to the main control processor via different buses. MCU0 is connected via a high-speed SPI bus (50MHz clock frequency); MCU1 is connected via a UART asynchronous serial bus (3Mbps baud rate).

[0071] The core of the host Linux system is a kernel driver called mcu_updater.ko. This driver creates a device node for each physical MCU and establishes four attribute files (control, status, data, and version) for each device in sysfs, thus providing a unified virtual file operation interface to the upper layers. Internally, the driver maps read and write operations on these files to specific communication with the underlying SPI or UART bus, and its configuration information is obtained through the device tree, thereby achieving the driver's versatility. A C++ daemon process called mcu_manager_daemon runs in user space. It is responsible for monitoring the firmware repository, generating differential patches, and driving the MCU's upgrade state machine completely by sequentially reading and writing the aforementioned virtual files, including the entire process of preparation, transmission, verification, and switching.

[0072] On the MCU side, the STM32H753 chip's software is divided into two parts: the bootloader and the main application. The bootloader resides in a protected memory area and is responsible for implementing boot configuration management, attempt counter checks, and decisive rollback logic. The main application includes communication drivers, an upgrade agent state machine, a firmware reconstruction module, and a security module. The upgrade agent responds to master control commands, and after receiving a differential patch, reconstructs the new firmware in the inactive memory area and verifies it using the chip's hardware encryption engine. After the target firmware boots, it must call the check-in function for confirmation before the watchdog timeout; otherwise, the bootloader's automatic rollback mechanism will be triggered.

[0073] In case of abnormal situations, the system incorporates a frame protocol with serial numbers and verification codes, as well as a timeout retransmission mechanism at the communication layer. During the upgrade process, if the MCU fails to apply a patch or verify a signature, it will report the specific error through the status interface, causing the main control to halt the process. If the firmware switch fails to boot, the MCU Bootloader will automatically roll back to the old version and report the rollback event through the status, allowing the main control application to retry or report to the cloud.

[0074] The third embodiment of this application provides a computer device, which includes a memory and at least one processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0075] The fourth embodiment of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0076] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (Read-Only Memory). Memory includes ROM, magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in this application may include at least one of relational databases and non-relational databases. Non-relational databases may include distributed databases based on blockchain, etc., and are not limited thereto. The processors involved in the various embodiments provided in this application may be general-purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these. The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered to be within the scope of this specification.

[0077] Compared with existing technologies, the firmware upgrade method, apparatus, computer equipment, and storage medium provided by this invention completely isolate the application layer from specific microcontroller models and communication buses through a virtual file interface. This allows for the management of any type of microcontroller with only simple file read and write operations, greatly reducing the complexity of development and maintenance of the main control application. When adding a new microcontroller, only a kernel driver and MCU-side firmware conforming to this framework need to be developed for it, without any modification to the main control application layer code. At the same time, it supports concurrent upgrades of multiple MCUs by simply opening multiple device files, providing a unified and standard MCU management paradigm that facilitates automated testing, deployment, and maintenance.

[0078] Differential upgrades transmit only 5%-20% of the full packet, significantly shortening upgrade time, saving bandwidth (especially expensive wireless network traffic), and reducing the RAM required for data processing within the MCU.

[0079] By using A / B partitioning and atomic switching, the upgrade process ensures that the running system is not affected, and the switching action is completed instantly, minimizing service interruption time. Based on multiple safeguards such as attempt counters, watchdog timers, and application check-ins, it can not only prevent bricking caused by startup failure, but also detect false liveness states that can start but cannot work properly, achieving true system self-healing.

[0080] By using identity authentication and encrypted transmission, the risk of firmware being eavesdropped on, tampered with, or injected with malicious firmware is eliminated, ensuring the security of the entire system.

[0081] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A firmware upgrade method, characterized in that, Applied to a system including a main control processor and at least one microcontroller, the method is executed by the main control processor and includes: In the system, a corresponding virtual file interface is created for each microcontroller. The virtual file interface includes a control file, a status file, a data channel file, and a version information file. Read the version information file to obtain the current firmware version of the microcontroller to be upgraded, and generate a differential patch based on the current firmware version and the target firmware; Write upgrade preparation instructions to the control file to put the microcontroller into upgrade preparation state, and transfer the differential patch to the microcontroller through the data channel file; Write a firmware refactoring command to the control file, triggering the microcontroller to combine the current firmware and differential patch stored in its own storage to refactor and generate the target firmware in the inactive storage partition; Write an atomic switch command to the control file to trigger the microcontroller to perform an atomic operation to modify the boot configuration and switch the boot partition to the inactive storage partition that stores the target firmware; Read the status file to obtain the microcontroller's upgrade status or rollback information. The rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its bootloader when the target firmware fails to check in a predetermined number of times.

2. The firmware upgrade method as described in claim 1, characterized in that, Before transferring the differential patch to the microcontroller via the data channel file, the process also includes establishing an information channel: The main processor generates random numbers and sends them to the microcontroller; The microcontroller uses a pre-shared key to calculate a message authentication code based on random numbers and returns it to the main controller processor; The main control processor uses the same pre-shared key and random number to perform the same calculations and verifies the returned message authentication code. Once the verification is successful, the secure communication channel is confirmed to have been established.

3. The firmware upgrade method as described in claim 1, characterized in that, After writing the upgrade preparation instruction to the control file, the process also includes: The main control processor reads the status file to determine whether the microcontroller is in upgrade preparation state.

4. The firmware upgrade method as described in claim 1, characterized in that, After generating a differential patch based on the current firmware version and the target firmware, the process also includes: The target firmware is digitally signed, wherein the digital signature is generated by the main control processor using a private key to calculate the hash value of the target firmware, and is configured to be transmitted to the microcontroller along with the differential patch.

5. A firmware upgrade method as described in claim 1, characterized in that, The microcontroller, combining its stored current firmware and differential patches, reconstructs the target firmware from the inactive storage partition and then performs integrity and authenticity verification on the target firmware, including: The microcontroller calculates the hash value of the target firmware and uses a preset public key to verify whether the digital signature from the main controller is a valid signature of the hash value. If so, the target firmware is determined to have passed the verification, and the verification success status is reported by updating the status file.

6. The firmware upgrade method as described in claim 1, characterized in that: When the triggering microcontroller executes an atomic operation to modify the boot configuration, the boot configuration includes at least an identifier for indicating the boot partition and an upgrade attempt counter. The atomic operation changes the value of the identifier from pointing to the currently active storage partition to pointing to the inactive storage partition storing the target firmware, and at the same time sets the upgrade attempt counter from its non-upgrade state value to an initial value indicating the first upgrade attempt.

7. A firmware upgrade method as described in claim 6, characterized in that, The rollback signal generation process includes iterative steps triggered by a reset, in each iteration: When the microcontroller bootloader starts, it reads the upgrade attempt counter and identifier stored in its non-volatile memory. If the upgrade attempt counter indicates that an upgrade attempt is in progress, the bootloader determines whether the count value exceeds the preset maximum allowed number of attempts; If the timeout is exceeded, the bootloader performs a rollback operation; if the timeout is not exceeded, the bootloader attempts to boot the target firmware based on the identifier and starts a watchdog timer. If the target firmware fails to atomically clear the upgrade attempt counter before the watchdog timer expires, the bootloader triggers a reset to start the next iteration and increments the upgrade attempt counter value on the next startup.

8. A firmware upgrade device, characterized in that: The interface creation module is used to create a corresponding virtual file interface for each microcontroller in the system. The virtual file interface includes a control file, a status file, a data channel file, and a version information file. The patch generation module is used to read the version information file, obtain the current firmware version of the microcontroller to be upgraded, and generate a differential patch based on the current firmware version and the target firmware. The data transmission module is used to write upgrade preparation instructions to the control file, put the microcontroller in upgrade preparation state, and transmit the differential patch to the microcontroller through the data channel file. The firmware refactoring module is used to write firmware refactoring commands to the control file, triggering the microcontroller to combine the current firmware and differential patches stored in its own storage to refactor and generate the target firmware in the inactive storage partition. The atomic switching module is used to write atomic switching commands to the control file, triggering the microcontroller to perform atomic operations to modify the boot configuration and switch the boot partition to the inactive storage partition storing the target firmware; The status reading module is used to read the status file and obtain the upgrade status or rollback information of the microcontroller. The rollback information is generated by the microcontroller automatically performing a rollback operation under the control of its bootloader when the target firmware fails to check in a predetermined number of times.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images