Firmware upgrading method and device, electronic equipment and storage medium

Abstract

The invention provides a firmware upgrading method and device, electronic equipment and a storage medium, the method is applied to the field of software upgrading, and the method comprises the following steps: in response to a firmware upgrading request, obtaining an upgrading file of to-be-upgraded firmware and a partition flag bit of a current running program in a preset nonvolatile storage region, and based on a preset data transmission service, upgrading the to-be-upgraded firmware in the partition flag bit of the current running program in the nonvolatile storage region; analyzing the upgrading file to obtain a target write-in address, determining a logic partition where the target write-in address is located according to the partition flag bit, determining a logic partition to which the target write-in address belongs, and when the logic partition corresponding to the current running program and the logic partition to which the target write-in address belongs are different partitions, updating the upgrading file according to the target write-in address. And writing the upgrading file into the logic partition to which the target writing address belongs so as to upgrade the to-be-upgraded firmware. According to the method, on a microcontroller only supporting a single program storage area, logic double partitions are divided through software, and address filtering and redundancy flag bit management during operation are combined, so that a safe and reliable background firmware upgrading and automatic rollback mechanism without shutdown is realized.

Description

Technical Field

[0001] This application relates to the field of software upgrades, and more specifically, to firmware upgrade methods, apparatus, electronic devices, and storage media in the field of software upgrades. Background Technology

[0002] With the development of automotive intelligence, on-board electronic control units need to support over-the-air upgrades and fault rollback functions, which places higher demands on firmware upgrade and fault recovery capabilities (rollback).

[0003] In related technologies, high-end MCUs (Microcontroller Units) with physical dual-bank Flash are relied upon, where one bank runs the current program and the other bank downloads new firmware in the background, achieving seamless switching.

[0004] However, some manufacturers' low-end and mid-range MCUs typically only provide a single BankCodeFlash. Their program code, after compilation, contains instructions that depend on the starting address, such as absolute address jumps and fixed interrupt vector tables. This makes it impossible to dynamically relocate, resulting in difficulty in storing two executable versions at the same time. It also makes it difficult to achieve seamless background upgrades and software version rollbacks, which urgently need to be solved. Summary of the Invention

[0005] This application provides a firmware upgrade method, apparatus, electronic device, and storage medium. The method enables a safe and reliable background firmware upgrade and automatic rollback mechanism on a microcontroller that only supports a single program storage area. This is achieved by dividing the microcontroller into two logical partitions through software, combined with runtime address filtering and redundancy flag management.

[0006] In a first aspect, a firmware upgrade method is provided, comprising: in response to a firmware upgrade request, obtaining an upgrade file of the firmware to be upgraded and a partition flag of the currently running program in a preset non-volatile storage area; based on a preset data transmission service, parsing the upgrade file to obtain a target write address, and determining the logical partition corresponding to the currently running program according to the partition flag of the currently running program; determining the logical partition to which the target write address belongs, and if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, writing the upgrade file to the logical partition to which the target write address belongs, thereby upgrading the firmware to be upgraded.

[0007] The above technical solution enables a safe and reliable background firmware upgrade and automatic rollback mechanism that can be achieved without downtime on microcontrollers that only support a single program storage area. This can be achieved by dividing the microcontroller into two logical partitions through software, combined with runtime address filtering and redundancy flag management.

[0008] In conjunction with the first aspect, in some possible implementations, before obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the method further includes: dividing the code storage area into a first logical partition, a second logical partition, and a boot manager partition based on preset address boundaries; configuring a first linker script according to the starting address of the first logical partition, and compiling and linking the first source code of the running program corresponding to the first linker script to generate a first program image corresponding to the first logical partition; configuring a second linker script according to the starting address of the second logical partition, and compiling and linking the second source code of the running program corresponding to the second linker script to generate a second program image corresponding to the second logical partition; merging the first program image and the second program image based on the first address space of the first program image and the second address space of the second program image, and filling the boot manager partition with a target base value to obtain the upgrade file of the firmware to be upgraded.

[0009] Through the above technical solution, the generated upgrade file contains two complete, independent, and directly executable application copies, while maintaining a physical layout that is strictly aligned with the target MCU's storage architecture. This lays the foundation for achieving secure and seamless coexistence and switching between dual versions on a single-bank hardware platform.

[0010] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, after obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the method further includes: reading the partition flag in the preset non-volatile storage area, and using the partition flag to read the first logical partition and the second logical partition; determining whether the partition flag is invalid, or whether the first logical partition pointed to by the partition flag is invalid, or whether the second logical partition pointed to by the partition flag is invalid; if the partition flag is invalid, or the first logical partition pointed to by the partition flag is invalid, or the second logical partition pointed to by the partition flag is invalid, then verify the logical partition in the invalid state and / or repair the partition flag; otherwise, jump to the starting address of the currently running program.

[0011] Through the above technical solutions, the above verification mechanism ensures that even in abnormal scenarios such as partition flag damage, upgrade interruption, or Flash bit flipping, the system still has the ability to self-diagnose, automatically repair, and boot safely, fundamentally avoiding the risk of bricking due to firmware upgrade failure, and significantly improving the reliability and functional safety of automotive or industrial embedded devices.

[0012] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the verification of the logical partition in an invalid state includes: if the first logical partition pointed to by the partition flag bit is invalid, then perform cyclic redundancy check on the first logical partition to obtain a first verification result of the first logical partition, and start the first logical partition when the first verification result meets the preset valid condition; if the second logical partition pointed to by the partition flag bit is invalid, then perform cyclic redundancy check on the second logical partition to obtain a second verification result of the second logical partition, and start the second logical partition when the second verification result meets the preset valid condition.

[0013] Through the above technical solutions, the above verification mechanism ensures that even in abnormal scenarios such as partition flag damage, upgrade interruption, or Flash bit flipping, the system still has the ability to self-diagnose, automatically repair, and boot safely, fundamentally avoiding the risk of bricking due to firmware upgrade failure, and significantly improving the reliability and functional safety of automotive or industrial embedded devices.

[0014] In combination with the first aspect and the above implementation methods, some possible implementation methods also include: determining whether a rollback instruction has been received; if the rollback instruction is received, switching the partition flag bit from the current flag bit to the target flag bit, and controlling the currently running program to run on the logical partition corresponding to the target flag bit upon restart.

[0015] The above technical solution enables instantaneous restoration to a verified and valid old firmware version by simply switching the partition flag bit through the rollback mechanism, without rewriting the Flash or external intervention. This achieves a highly reliable, low-overhead, and brick-proof security upgrade guarantee under the condition of limited single-bank storage resources.

[0016] In combination with the first aspect and the above implementation methods, in some possible implementation methods, after determining the logical partition to which the target write address belongs, the method further includes: if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition, then the upgrade file of the firmware to be upgraded is discarded.

[0017] By using the above technical solution and a runtime address filtering strategy, dual-bank behavior can be simulated on a single BankCodeFlash hardware, enabling seamless background upgrades by running one bank while upgrading the other. This effectively avoids the system instability risk caused by overwriting runtime code in related technologies.

[0018] Secondly, a firmware upgrade device is provided, the device comprising: The acquisition module is used to acquire the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area in response to the firmware upgrade request. The determination module is used to parse the upgrade file to obtain the target write address based on a preset data transmission service, and determine the logical partition corresponding to the currently running program according to the partition flag bit of the currently running program; The upgrade module is used to determine the logical partition to which the target write address belongs, and when the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, write the upgrade file to the logical partition to which the target write address belongs, so as to upgrade the firmware to be upgraded.

[0019] In conjunction with the second aspect, in some possible implementations, before obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the acquisition module further includes: The partitioning unit is used to divide the code storage area into a first logical partition, a second logical partition, and a boot manager partition based on preset address boundaries; The first generation unit is configured to configure a first linker script according to the starting address of the first logical partition, and to compile and link the first source code of the running program corresponding to the first linker script to generate a first program image corresponding to the first logical partition. The second generation unit is used to configure the second linker script according to the starting address of the second logical partition, and to compile and link the second source code of the running program corresponding to the second linker script to generate the second program image corresponding to the second logical partition. The merging unit is used to merge the first program image and the second program image based on the first address space of the first program image and the second address space of the second program image, and fill the boot manager partition with the target base value to obtain the upgrade file of the firmware to be upgraded.

[0020] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the acquisition module further includes: The reading unit is used to read the partition flag bit in the preset non-volatile storage area, and use the partition flag bit to read the first logical partition and the second logical partition; The judgment unit is used to determine whether the partition flag is invalid, or whether the first logical partition pointed to by the partition flag is invalid, or whether the second logical partition pointed to by the partition flag is invalid; The verification unit is used to verify the invalid logical partition and / or repair the partition flag if the partition flag is invalid, or the first logical partition pointed to by the partition flag is invalid, or the second logical partition pointed to by the partition flag is invalid; otherwise, it jumps to the starting address of the currently running program.

[0021] In combination with the second aspect and the above implementation methods, in some possible implementations, the verification unit includes: The first verification subunit is configured to perform cyclic redundancy check on the first logical partition if the first logical partition pointed to by the partition flag bit is invalid, obtain the first verification result of the first logical partition, and start the first logical partition when the first verification result meets the preset valid conditions. The second verification subunit is used to perform cyclic redundancy check on the second logical partition if the second logical partition pointed to by the partition flag bit is invalid, to obtain a second verification result of the second logical partition, and to start the second logical partition when the second verification result meets the preset valid condition.

[0022] In conjunction with the second aspect and the above-described implementation methods, in some possible implementations, the aforementioned firmware upgrade device further includes: The judgment module is used to determine whether a rollback command has been received; The control module is configured to, upon receiving the rollback instruction, switch the partition flag from the current flag to the target flag, and, upon restarting, control the currently running program to run on the logical partition corresponding to the target flag.

[0023] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after determining the logical partition to which the target write address belongs, the upgrade module further includes: The data discarding unit is used to discard the upgrade file of the firmware to be upgraded if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition.

[0024] Thirdly, an electronic device is provided, including the firmware upgrade method described in the above embodiments.

[0025] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0026] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0027] Figure 1 A flowchart illustrating the firmware upgrade method provided in this application embodiment; Figure 2 This is a schematic diagram of logical partitioning according to an embodiment of this application; Figure 3 This is a flowchart illustrating the overall implementation of background upgrade and rollback for a dual-bank application using a single-bank MCU according to one embodiment of this application. Figure 4 A block diagram of the firmware upgrade device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0028] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0030] With the development of automotive intelligence, the vehicle electronic control unit needs to support over-the-air upgrades and fault rollback functions, which puts forward higher requirements for firmware upgrades and fault recovery capabilities (rollback). Among the related technologies, high-end MCUs with physical dual-bank Flash are relied upon. One bank runs the current program, while the other bank downloads new firmware in the background to achieve seamless switching. The code generated after the compilation of such MCU programs contains absolute addresses or references that depend on fixed addresses. This type of code can only run normally after being loaded into a specific address in memory and cannot be moved to other addresses for execution at will. Since the program storage of such MCUs does not have physical partitioning function, it is difficult to achieve background seamless upgrades and software version rollback. Therefore, the related technologies have the following disadvantages: (1) upgrade interruption leads to loss of function; (2) it is not possible to have two different versions of the program that can run at the same time, and rollback is not supported; (3) a long downtime is required for program upgrade, resulting in a poor user experience.

[0031] Therefore, based on the aforementioned problems, this application urgently needs a software-level dual-bank upgrade and rollback solution that does not rely on hardware dual-bank and is applicable to single-bank MCUs. For example, such as Figure 1 As shown, the method includes: In step S101, in response to the firmware upgrade request, the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area are obtained.

[0032] Optionally, in one embodiment of this application, before obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the method further includes: dividing the code storage area into a first logical partition, a second logical partition, and a boot manager partition based on preset address boundaries; configuring a first linker script according to the starting address of the first logical partition, and compiling and linking the first source code of the running program corresponding to the first linker script to generate a first program image corresponding to the first logical partition; configuring a second linker script according to the starting address of the second logical partition, and compiling and linking the second source code of the running program corresponding to the second linker script to generate a second program image corresponding to the second logical partition; merging the first program image and the second program image based on the first address space of the first program image and the second address space of the second program image, and filling the boot manager partition with a target base value to obtain the upgrade file of the firmware to be upgraded.

[0033] The preset address boundaries can be set by those skilled in the art according to the requirements of firmware upgrades, and are not specifically limited here.

[0034] Specifically, such as Figure 2As shown, based on the physical layout of the MCU's code storage area CodeFlash and the alignment requirements of the erase blocks, this application needs to pre-set preset address boundaries to divide the entire code storage area into three functionally distinct sub-areas: the boot manager partition (BM), the first logical partition (APP1), and the second logical partition (APP2). The boot manager partition is located at the starting address of CodeFlash (e.g., 0x00000000-0x00003FFF) and is used for program guidance after the MCU is powered on. It also stores the boot code and determines which area's application will be executed. After removing the area occupied by BM, the remaining storage area is divided into two equal-sized logical partitions according to the block size, which serve as the deployment areas for the first logical partition APP1 (e.g., 0x00004000-0x0003FFFF) and the second logical partition APP2 (e.g., 0x00040000-0x0007FFFF), respectively.

[0035] Furthermore, for the same set of application source code (i.e., software logic with completely identical functions), firstly, two independent linker scripts are configured, namely the first linker script and the second linker script. The first linker script uses the starting address of the first logical partition (e.g., 0x00004000) as the program base address and relocates the interrupt vector table, code segment, read-only data segment, and initialization data segment. The second linker script uses the starting address of the second logical partition (e.g., 0x00040000) as the program base address and performs the same relocation operation.

[0036] Secondly, using the standard compilation toolchain, the source code under the two linking configurations (i.e., the first source code and the second source code, which are the same) is compiled and linked to generate two executable program images with different address offsets but the same function: the first program image APP1_Hex corresponding to the first logical partition and the second program image APP2_Hex corresponding to the second logical partition.

[0037] Finally, APP1_Hex and APP2_Hex are merged according to their respective address spaces to form a unified upgrade file HexSum that covers the entire CodeFlash address range. At the same time, for areas not occupied by the program image (especially the boot manager partition and the gap between the two images), the target base value is filled according to the erase state characteristics of the Flash memory, that is, the hexadecimal value 0xFF is filled to ensure that the programming tool will not mistakenly program undefined areas as 0x00 during writing, thereby avoiding damage to the default state of Flash or causing verification errors.

[0038] As a result, the generated upgrade file contains two complete, independent, and directly executable copies of the application, while maintaining a physical layout that is strictly aligned with the target MCU's storage architecture. This lays the foundation for a secure and seamless coexistence and switching between the two versions on a single-bank hardware platform.

[0039] Furthermore, during system operation, when an externally initiated firmware upgrade request is received, such as receiving a 0x34 request download service conforming to the UDS (Unified Diagnostic Services) protocol via the vehicle diagnostic bus CAN (Controller Area Network), the currently executing program will initiate the upgrade process. This process first includes obtaining two key pieces of information: the upgrade file of the firmware to be upgraded and the partition flag bit BankFlag of the currently running program in the preset non-volatile storage area.

[0040] The upgrade file is a complete firmware image package pre-built during the development phase (i.e., the HexSum file mentioned above). Its contents cover the entire CodeFlash address space and include all data from the boot manager partition BM, the first logical partition APP1, and the second logical partition APP2. The upgrade file is sent to the MCU in blocks by the host computer or OTA (Over-the-Air) server through a preset data transmission service (such as the UDS0x36 service). After receiving the upgrade instruction, the currently running program begins to receive and cache the data stream of the upgrade file to prepare for subsequent parsing and writing.

[0041] The partition flag is used to indicate which logical partition the currently running program should run. Its value is usually 0x00 (indicating that APP1 is activated) or 0x01 (indicating that APP2 is activated). This partition flag is not stored in volatile RAM (Random Access Memory), but is stored in a non-volatile memory area inside the MCU, such as DataFlash or backup registers, and a redundant storage strategy is adopted (such as storing one copy at two different addresses) to improve reliability.

[0042] It should be noted that if the data block length of the 0x36 service is too long, writing it all at once will block and consume too much program execution time. Therefore, it is necessary to set the block length reasonably or divide it into multiple sub-blocks and write it multiple times.

[0043] Therefore, by synchronously acquiring complete upgrade image data and current running status identifiers, the necessary input is provided for realizing a seamless upgrade mechanism of "writing to the opposite partition during runtime and protecting the self-partition" on a single-bank hardware platform.

[0044] In step S102, based on the preset data transmission service, the upgrade file is parsed to obtain the target write address, and the logical partition corresponding to the currently running program is determined according to the partition flag bit of the currently running program.

[0045] Specifically, during the firmware upgrade process, the currently running program receives upgrade files from the host computer or OTA server via a diagnostic communication protocol.

[0046] Specifically, such as Figure 3 As shown, the host computer first notifies the MCU of the total length of the firmware data to be transmitted and the target starting address by requesting a download service, such as the 0x34 service. Then, it sends the upgrade data in the upgrade file frame by frame in a block manner through the preset data transmission service, namely the 0x36 service. After receiving each frame of 0x36 data, the currently running program parses it according to the protocol format of the data transmission service and extracts the target write address corresponding to the data block. The target write address is the physical address originally defined in the upgrade file HexSum and is directly mapped to the linear address space of CodeFlash, such as 0x00004100 or 0x00050000. This target write address determines the final storage location of the data block in Flash.

[0047] At the same time, the application reads the partition flag BankFlag from a preset non-volatile storage area. This partition flag BankFlag is set by the boot manager BM at system startup and remains unchanged during normal operation.

[0048] The partition flag BankFlag can take the values ​​0x00 and 0x01. 0x00 indicates that the currently active and running program is the first logical partition APP1, and 0x01 indicates that the currently active and running program is the second logical partition APP2. By comparing the value of the partition flag BankFlag with the preset address boundary, the currently running program can determine the identity of the logical partition it is currently residing in. For example, if BankFlag=0x00, the currently running program is located in the first logical partition APP1, and if BankFlag=0x01, the currently running program is located in the second logical partition APP2.

[0049] In step S103, the logical partition to which the target write address belongs is determined. If the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, the upgrade file is written to the logical partition to which the target write address belongs in order to upgrade the firmware to be upgraded.

[0050] Optionally, in one embodiment of this application, after determining the logical partition to which the target write address belongs, the method further includes: if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition, then the upgrade file of the firmware to be upgraded is discarded.

[0051] Specifically, after completing the resolution of the target write address of the upgrade file and the identification of the currently running program, the system further executes the address ownership judgment and write control logic of the currently running program.

[0052] Specifically, the currently running program determines which logical partition the parsed target write address falls into based on preset address boundaries (e.g., the first logical partition APP1 covers 0x00004000-0x0003FFFF, and the second logical partition APP2 covers 0x00040000-0x0007FFFF). Simultaneously, the system has determined the logical partition where the currently running program resides by reading the partition flag bit BankFlag in the non-volatile memory area. Then, the system compares whether the logical partition to which the target write address belongs is consistent with the logical partition where the currently running program resides: if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are consistent... If the logical partitions of the target write address are different (for example, the logical partition corresponding to the currently running program is APP1, while the logical partition to which the target write address belongs is APP2), then the data block is determined to be legitimate upgrade content belonging to the logical partition to which the target write address belongs. At this time, the system calls the Flash driver residing in RAM to safely write the upgrade data to the location specified by the target write address in CodeFlash. The Flash driver has been copied from ROM to RAM before running to ensure that it will not cause execution exceptions due to overwriting its own code during the erase / write process. Moreover, all write operations are completed in interrupt-masked or low-priority tasks to balance real-time performance and security.

[0053] It should be noted that, through the above process, when each frame of 0x36 upgrade data is received, the process is repeated to achieve block-by-block, selective updating of the opposite logical partition. As all data blocks belonging to the opposite partition are completely written, the partition is updated to the new version of firmware. After the entire upgrade process is completed and passes integrity verification (such as CRC or digital signature verification), the system switches the partition flag BankFlag to point to the newly written logical partition. On the next system restart, the boot manager partition BM will load and execute the new version program, thereby completing the firmware upgrade.

[0054] Furthermore, if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition (for example, the logical partition corresponding to the currently running program is APP1, and the logical partition to which the target write address belongs is also the APP1 area), then it is determined that the data block intends to overwrite the program code being executed. In order to prevent the runtime code from being corrupted and causing the system to crash, the data block, i.e. the upgrade file of the firmware to be upgraded, is immediately discarded and no write operation is performed. Therefore, by utilizing runtime address filtering strategies, dual-bank behavior can be simulated on a single BankCodeFlash hardware, enabling seamless background upgrades by running one and upgrading the other, effectively avoiding the system instability risks caused by overwriting runtime code in related technologies.

[0055] Optionally, in one embodiment of this application, after obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the method further includes: reading the partition flag in the preset non-volatile storage area, and using the partition flag to read the first logical partition and the second logical partition; determining whether the partition flag is invalid, or whether the first logical partition pointed to by the partition flag is invalid, or whether the second logical partition pointed to by the partition flag is invalid; if the partition flag is invalid, or the first logical partition pointed to by the partition flag is invalid, or the second logical partition pointed to by the partition flag is invalid, then verifying the logical partition in the invalid state and / or repairing the partition flag; otherwise, jumping to the starting address of the currently running program.

[0056] Optionally, in one embodiment of this application, verifying a logical partition in an invalid state includes: if the first logical partition pointed to by the partition flag is invalid, performing a cyclic redundancy check on the first logical partition to obtain a first verification result of the first logical partition, and starting the first logical partition when the first verification result meets a preset valid condition; if the second logical partition pointed to by the partition flag is invalid, performing a cyclic redundancy check on the second logical partition to obtain a second verification result of the second logical partition, and starting the second logical partition when the second verification result meets a preset valid condition.

[0057] Specifically, after the system is powered on or reset, the boot manager partition BM first executes the pre-boot integrity and status verification process. The core of this process is to read and verify the partition flag bit BankFlag to determine which application partition should be loaded for execution.

[0058] Specifically, the BM reads the partition flag from the non-volatile memory area preset inside the MCU. To improve reliability, the partition flag adopts a redundant storage strategy, that is, the same BankFlag value (e.g., 0x00 indicates APP1 is activated, and 0x01 indicates APP2 is activated) is written to two different physical addresses (e.g., 0x400000 and 0x400001 of DataFlash). The BM determines whether the partition flag is valid by comparing the consistency of these two copies. If the two are consistent and the value is valid (only 0x00 or 0x01), the partition flag is considered valid; otherwise, it is considered invalid (e.g., the copies are inconsistent, the value is 0xFF (erased state), or an illegal value such as 0x55). Then, BM uses the value of the partition flag to access or verify the contents of the corresponding first or second logical partition. If BankFlag=0x00, BM attempts to load and verify the first logical partition APP1. If BankFlag=0x01, BM attempts to load and verify the second logical partition APP2. Subsequently, BM performs multi-level validity checks, mainly including: the partition flag is invalid (such as inconsistent redundant copies or illegal values) and the partition flag is valid, but the contents of the logical partition it points to are invalid (such as CRC check failure of APP1, signature verification failure, or illegal start command). If any of the above conditions are met, BM starts the dual-partition full verification and self-recovery mechanism.

[0059] First, if the first logical partition pointed to by the partition flag is invalid, a cyclic redundancy check is performed on the first logical partition. This involves reading the CRC32 value pre-stored in the header of the first logical partition image, recalculating the CRC for valid program data segments (excluding the CRC field itself), and comparing the calculated value with the pre-stored value. If they match, the digital signature is further verified to ensure that the firmware has not been tampered with, and the first verification result is obtained. Based on the first verification result, a decision is made: if only one partition is valid, that partition is selected for booting, and the partition flag is repaired (i.e., the correct value is written back to the two redundant locations in the DataFlash). Optionally, if both partitions are valid, the newer version is selected for booting based on the version information embedded in the image, and the BankFlag is updated synchronously; if both partitions are invalid, safe mode is entered (e.g., waiting for diagnostic flashing or illuminating the fault indicator); if the partition flag is valid and the logical partition it points to passes all validity checks, the BM jumps directly to the application start address of that partition (usually the start address of the interrupt vector table, such as 0x00004000 or 0x00040000), transfers control to the currently running program, and the system starts normally.

[0060] Therefore, the above verification mechanism ensures that even in abnormal scenarios such as partition flag damage, upgrade interruption, or Flash bit flipping, the system still has the ability to self-diagnose, automatically repair, and boot safely, fundamentally avoiding the risk of bricking due to firmware upgrade failure, and significantly improving the reliability and functional safety of automotive or industrial embedded devices.

[0061] Optionally, in one embodiment of this application, the method further includes: determining whether a rollback instruction has been received; if a rollback instruction has been received, switching the partition flag from the current flag to the target flag, and controlling the currently running program to run on the logical partition corresponding to the target flag upon restart.

[0062] Specifically, after the firmware upgrade is completed and the system switches to the new version, it continuously monitors whether a rollback command is received. This command is usually sent by the host computer through a diagnostic communication bus (such as a CAN bus) and conforms to the diagnostic protocol specification. The triggering scenarios for the rollback command can include: abnormal operation of the new firmware version, failure of function verification, and user-initiated request to restore to the previous stable version.

[0063] Furthermore, after the currently running program (e.g., a new version running on the second logical partition APP2) detects a valid rollback command, it first verifies the legality of the rollback command (e.g., through secure access authentication and message integrity verification). Once confirmed to be correct, it performs rollback preparation operations, mainly including: (1) Determine the current partition flag state: The currently running program reads the current partition flag BankFlag in the preset non-volatile storage area (such as DataFlash). Assuming the current BankFlag = 0x01, it means that the system is currently activating the second logical partition APP2; (2) Calculate the target flag: According to the binary design of logical partitions (only APP1 and APP2 are valid states), the target flag is the inverse of the current flag. For example, if the current partition flag is 0x01 (APP2), then the target flag is 0x00 (APP1), and if the current partition flag is 0x00 (APP1), then the target flag is 0x01 (APP2); (3) Update the partition flag: The currently running program calls The underlying non-volatile storage driver updates the two redundant copies of BankFlag (such as the two backup addresses in DataFlash) to the target flag value at the same time to ensure atomicity and reliability of the write. This operation does not involve any CodeFlash erasure or program modification, but only changes the "pointer" of the boot process; (4) Trigger system restart. After the rollback instruction is completed, the application can actively trigger MCU soft reset or wait for external reset signal; (5) Execute target partition after restart. After the system restarts, the boot manager BM first reads the updated partition flag (now 0x00) and determines that the first logical partition APP1 should be loaded. BM performs integrity verification on APP1 (such as CRC32 (Cyclic Redundancy Check) and / or digital signature verification). After confirming that it is valid, it jumps to the starting address of APP1 (such as 0x00004000) to execute, thereby completing the rollback.

[0064] It should be noted that the rollback process does not require re-downloading or rewriting the firmware, as the old version of the program is still completely preserved in its corresponding logical partition. The entire rollback operation is achieved by switching only one flag bit, featuring instantaneous effectiveness, high reliability, and low resource overhead. At the same time, to prevent malicious or accidental rollbacks, the system can introduce enhanced mechanisms such as rollback count limits, rollback version validity checks (ensuring that the target partition has not been overwritten or damaged), and rollback logging, further improving the system's robustness and traceability. To better meet network security requirements and prevent code area tampering, the FlashDrive that Codeflash uses for erasing and writing operations should run independently in the RAM area, be zeroed after reset, and undergo a test of the maximum RAM usage space to prevent FlashDrive from being tampered with during runtime.

[0065] Therefore, by simply switching the partition flag bit through the rollback mechanism, it is possible to instantly restore to the verified and valid old firmware version without rewriting the Flash or external intervention. This achieves a highly reliable, low-overhead, and brick-proof security upgrade guarantee under the condition of limited single-bank storage resources.

[0066] In the embodiments of this application, based on the above specific discussion, this application uses a low-cost MCU to implement complex background seamless upgrade and software rollback functions, reducing the amount of software engineering, reducing the workload of software code management and download testing, increasing the stability of the upgrade function, and ensuring the integrity of the function through the rollback mechanism when the software upgrade fails, thereby bringing a better user experience through seamless background upgrade.

[0067] In summary, the firmware upgrade method according to the embodiments of this application, in response to a firmware upgrade request, obtains the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in a preset non-volatile storage area. Based on a preset data transmission service, the upgrade file is parsed to obtain the target write address, and the logical partition is determined according to the partition flag. If the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, the upgrade file is written to the logical partition to which the target write address belongs, thereby upgrading the firmware to be upgraded. This method, on microcontrollers that only support a single program storage area, achieves a safe and reliable background firmware upgrade and automatic rollback mechanism without system downtime by software-dividing into two logical partitions, combined with runtime address filtering and redundant flag management.

[0068] Figure 4 This is a schematic diagram of the structure of a firmware upgrade device provided in an embodiment of this application.

[0069] For example, such as Figure 4 As shown, the device may include: an acquisition module 100, a determination module 200, and an upgrade module 300.

[0070] The acquisition module 100 is used to acquire the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area in response to the firmware upgrade request. The determination module 200 is used to parse the upgrade file to obtain the target write address based on the preset data transmission service, and determine the logical partition corresponding to the currently running program according to the partition flag bit of the currently running program. The upgrade module 300 is used to determine the logical partition to which the target write address belongs, and if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, the upgrade file is written to the logical partition to which the target write address belongs in order to upgrade the firmware to be upgraded.

[0071] Optionally, in one embodiment of this application, before obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the acquisition module 100 further includes: The partitioning unit is used to divide the code storage area into a first logical partition, a second logical partition, and a boot manager partition based on preset address boundaries; The first generation unit is used to configure the first linker script according to the starting address of the first logical partition, and to compile and link the first source code of the running program corresponding to the first linker script to generate the first program image corresponding to the first logical partition. The second generation unit is used to configure the second linker script according to the starting address of the second logical partition, and to compile and link the second source code of the running program corresponding to the second linker script to generate the second program image corresponding to the second logical partition. The merging unit is used to merge the first program image and the second program image based on the first address space of the first program image and the second address space of the second program image, and fill the boot manager partition with the target base value to obtain the upgrade file of the firmware to be upgraded.

[0072] Optionally, in one embodiment of this application, after obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the acquisition module 100 further includes: The read unit is used to read the partition flag bits in the preset non-volatile memory area, and to read the first logical partition and the second logical partition using the partition flag bits; The judgment unit is used to determine whether the partition flag is invalid, or whether the first logical partition pointed to by the partition flag is invalid, or whether the second logical partition pointed to by the partition flag is invalid; The verification unit is used to verify the invalid logical partition and / or repair the partition flag if the partition flag is invalid, or the first logical partition pointed to by the partition flag is invalid, or the second logical partition pointed to by the partition flag is invalid; otherwise, it jumps to the starting address of the currently running program.

[0073] Optionally, in one embodiment of this application, the verification unit includes: The first verification subunit is used to perform cyclic redundancy check on the first logical partition if the first logical partition pointed to by the partition flag bit is invalid, to obtain the first verification result of the first logical partition, and to start the first logical partition when the first verification result meets the preset valid conditions. The second verification subunit is used to perform cyclic redundancy check on the second logical partition if the partition flag bit points to an invalid second logical partition, to obtain the second verification result of the second logical partition, and to start the second logical partition when the second verification result meets the preset valid conditions.

[0074] Optionally, in one embodiment of this application, the firmware upgrade device 10 described above further includes: The judgment module is used to determine whether a rollback command has been received; The control module is used to switch the partition flag from the current flag to the target flag if a rollback command is received, and to control the currently running program to run on the logical partition corresponding to the target flag when restarting.

[0075] Optionally, in one embodiment of this application, after determining the logical partition to which the target write address belongs, the upgrade module 300 further includes: The data discarding unit is used to discard the upgrade file of the firmware to be upgraded if the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition.

[0076] In summary, the firmware upgrade apparatus according to the embodiments of this application, in response to a firmware upgrade request, obtains the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in a preset non-volatile storage area. Based on a preset data transmission service, it parses the upgrade file to obtain the target write address, determines the logical partition it belongs to based on the partition flag, and determines the logical partition to which the target write address belongs. If the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, the upgrade file is written to the logical partition to which the target write address belongs to upgrade the firmware to be upgraded. This method, on a microcontroller that only supports a single program storage area, achieves a safe and reliable background firmware upgrade and automatic rollback mechanism without downtime by dividing the system into two logical partitions through software, combined with runtime address filtering and redundant flag management.

[0077] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0078] It should be understood that the methods described above can be applied to... Figure 5 In the electronic device with the structure shown.

[0079] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform the firmware upgrade method provided in embodiments of this application.

[0080] Furthermore, the device also includes a communication interface 503 for communication between the memory 501 and the processor 502.

[0081] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0082] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0083] It should be understood that the apparatus provided in this embodiment is used to execute the firmware upgrade method described above, and therefore can achieve the same effect as the implementation method described above.

[0084] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing program code, etc.

[0085] The processing module may be a processor 502 or a controller, which may implement or execute various exemplary logic blocks, modules, and circuits as disclosed herein. The processor 502 may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory 501.

[0086] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor 502 and a memory 501. The memory 501 is used to store instructions. When the processor calls and executes the instructions, the chip can execute the firmware upgrade method provided in the above embodiments.

[0087] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned method steps to implement a firmware upgrade method provided in the above embodiment.

[0088] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a firmware upgrade method provided in the above embodiment.

[0089] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0090] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0091] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A firmware upgrade method, characterized in that, The method includes: In response to a firmware upgrade request, obtain the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area; Based on the preset data transmission service, the upgrade file is parsed to obtain the target write address, and the logical partition corresponding to the currently running program is determined according to the partition flag bit of the currently running program; The logical partition to which the target write address belongs is determined. If the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, the upgrade file is written to the logical partition to which the target write address belongs in order to upgrade the firmware to be upgraded.

2. The method according to claim 1, characterized in that, Before obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the following steps are also included: Based on preset address boundaries, the code storage area is divided into a first logical partition, a second logical partition, and a boot manager partition; Configure a first linker script according to the starting address of the first logical partition, and compile and link the first source code of the running program corresponding to the first linker script to generate the first program image corresponding to the first logical partition. Configure the second linker script according to the starting address of the second logical partition, and compile and link the second source code of the running program corresponding to the second linker script to generate the second program image corresponding to the second logical partition; Based on the first address space of the first program image and the second address space of the second program image, the first program image and the second program image are merged, and the target hexadecimal value is filled into the boot manager partition to obtain the upgrade file of the firmware to be upgraded.

3. The method according to claim 1, characterized in that, After obtaining the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the following is also included: Read the partition flag bit in the preset non-volatile storage area, and use the partition flag bit to read the first logical partition and the second logical partition; Determine whether the partition flag is invalid, or whether the first logical partition pointed to by the partition flag is invalid, or whether the second logical partition pointed to by the partition flag is invalid; If the partition flag is invalid, or the first logical partition pointed to by the partition flag is invalid, or the second logical partition pointed to by the partition flag is invalid, then the invalid logical partition is checked and / or the partition flag is repaired; otherwise, the program jumps to the starting address of the currently running program.

4. The method according to claim 3, characterized in that, The logical partitions whose verification is invalid include: If the first logical partition pointed to by the partition flag is invalid, then a cyclic redundancy check is performed on the first logical partition to obtain the first verification result of the first logical partition, and the first logical partition is started when the first verification result meets the preset valid conditions. If the second logical partition pointed to by the partition flag is invalid, a cyclic redundancy check is performed on the second logical partition to obtain a second verification result of the second logical partition, and the second logical partition is started when the second verification result meets the preset valid condition.

5. The method according to claim 1, characterized in that, Also includes: Determine if a rollback command has been received; If the rollback instruction is received, the partition flag is switched from the current flag to the target flag, and upon restart, the currently running program is controlled to run on the logical partition corresponding to the target flag.

6. The method according to claim 1, characterized in that, After determining the logical partition to which the target write address belongs, the process also includes: If the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are the same partition, then the upgrade file of the firmware to be upgraded is discarded.

7. A firmware upgrade device, characterized in that, The device includes: The acquisition module is used to acquire the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area in response to the firmware upgrade request. The determination module is used to parse the upgrade file to obtain the target write address based on a preset data transmission service, and determine the logical partition corresponding to the currently running program according to the partition flag bit of the currently running program; The upgrade module is used to determine the logical partition to which the target write address belongs, and when the logical partition corresponding to the currently running program and the logical partition to which the target write address belongs are different partitions, write the upgrade file to the logical partition to which the target write address belongs, so as to upgrade the firmware to be upgraded.

8. The apparatus according to claim 7, characterized in that, Before acquiring the upgrade file of the firmware to be upgraded and the partition flag of the currently running program in the preset non-volatile storage area, the acquisition module further includes: The partitioning unit is used to divide the code storage area into a first logical partition, a second logical partition, and a boot manager partition based on preset address boundaries; The first generation unit is configured to configure a first linker script according to the starting address of the first logical partition, and to compile and link the first source code of the running program corresponding to the first linker script to generate a first program image corresponding to the first logical partition. The second generation unit is used to configure the second linker script according to the starting address of the second logical partition, and to compile and link the second source code of the running program corresponding to the second linker script to generate the second program image corresponding to the second logical partition. The merging unit is used to merge the first program image and the second program image based on the first address space of the first program image and the second address space of the second program image, and fill the boot manager partition with the target base value to obtain the upgrade file of the firmware to be upgraded.

9. An electronic device, characterized in that, The electronic device includes: a firmware upgrade method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 6.

Images