Firmware upgrading method and device, storage medium and electronic device

Abstract

This application discloses a firmware upgrade method, apparatus, storage medium, and electronic device applied to a program memory, which includes a first partition and a second partition. The method includes: when a target upgrade instruction is received in the first partition and the target upgrade instruction is valid, writing a Bootloader upgrade package and / or an APP upgrade package to the second partition and obtaining an upgrade package flag; if the target upgrade instruction is an APP upgrade instruction and the upgrade package flag is a second preset value, controlling the program memory to restart to switch the currently running partition from the first partition to the second partition; if the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is a first preset value, controlling the program memory to restart, writing the Bootloader upgrade package stored in the second partition to the first partition, and controlling the program memory to restart to switch the currently running partition from the second partition to the first partition. The method of this application can improve the reliability of firmware upgrades.

Description

Technical Field

[0001] This application relates to the field of memory technology, and in particular to a firmware upgrade method, a computer-readable storage medium, an electronic device, and a firmware upgrade apparatus. Background Technology

[0002] Electronic Control Unit (ECU) reprogramming is a core step in ensuring vehicle performance upgrades and functional iterations. It must strictly adhere to multiple industry standards and specifications. In OTA (Over-The-Air) upgrade scenarios, it must also meet both the ISO 205 protocol upgrade process specifications and the ISO 15022 OTA (Over-The-Air) security process specifications. With increasingly stringent safety requirements for intelligent vehicles, the industry has explicitly discouraged the use of the default OTA update mode for vehicle safety-related ECUs. However, achieving efficient risk management while meeting stringent compliance requirements has become a common challenge across the industry. The reliability of current mainstream reprogramming solutions urgently needs improvement. Industry data shows that on average, one in three OTA updates fails, with an overall failure rate exceeding 1%, severely impacting user experience and vehicle operational safety. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in the related art. Therefore, the first objective of this application is to propose a firmware upgrade method that can mitigate upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0004] The second objective of this application is to provide a computer-readable storage medium.

[0005] The third objective of this application is to propose an electronic device.

[0006] The fourth objective of this application is to provide a firmware upgrade device.

[0007] To achieve the above objectives, a first aspect of this application proposes a firmware upgrade method applied to a program memory, the program memory including a first partition and a second partition. The method includes: when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, writing a Bootloader upgrade package and / or an APP upgrade package into the second partition, and obtaining an upgrade package flag bit, wherein the target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction; when the target upgrade instruction is the APP upgrade instruction and the upgrade package flag bit is a second preset value, controlling the program memory to restart to switch the currently running partition from the first partition to the second partition; when the target upgrade instruction is the Bootloader upgrade instruction and the upgrade package flag bit is a first preset value, controlling the program memory to restart, writing the Bootloader upgrade package stored in the second partition to the first partition, and controlling the program memory to restart to switch the currently running partition from the second partition to the first partition.

[0008] According to the firmware upgrade method of this application embodiment, when a target upgrade instruction is received in the first partition and the target upgrade instruction is a valid instruction, the Bootloader upgrade package and / or APP upgrade package are written to the second partition, and the upgrade package flag is obtained. The target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction. If the target upgrade instruction is an APP upgrade instruction and the upgrade package flag is a second preset value, the program memory is controlled to restart to switch the currently running partition from the first partition to the second partition. If the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is a first preset value, the program memory is controlled to restart, and the Bootloader upgrade package stored in the second partition is written to the first partition. The program memory is then controlled to restart again to switch the currently running partition from the second partition to the first partition. Therefore, this method can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0009] In addition, the firmware upgrade method according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, the method further includes: authenticating the target upgrade instruction based on a target authentication service, so as to determine the target upgrade instruction as a legitimate instruction after successful authentication.

[0010] According to one embodiment of this application, the method further includes: verifying the Bootloader upgrade package and / or the APP upgrade package based on a preset algorithm; after the verification is passed, setting the upgrade package flag bit based on atomic operations, wherein different upgrade packages correspond to different upgrade package flag bits.

[0011] According to one embodiment of this application, the method further includes: after verification, storing the target upgrade information of the Bootloader upgrade package and / or the APP upgrade package to a preset state partition, wherein the target upgrade information includes an upgrade version number, a flag bit, and an update time.

[0012] According to one embodiment of this application, the second partition includes a temporary storage area, and the method further includes: when the target upgrade instruction is a Bootloader upgrade instruction, writing the Bootloader upgrade package into the temporary storage area.

[0013] According to one embodiment of this application, the method further includes: after the program memory fails to restart, obtaining the number of restart failures; and if the number of failures reaches a preset failure threshold, triggering a recovery mode based on a hardware jumper to load and run the previous version of the Bootloader.

[0014] According to one embodiment of this application, the method further includes: in the event of verification failure, clearing the Bootloader upgrade package and / or the APP upgrade package in the second partition, and recording error information, wherein the error information includes a timestamp, an error code, and version information.

[0015] To achieve the above objectives, a second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the firmware upgrade method described above.

[0016] The computer-readable storage medium according to the embodiments of this application, by implementing the above-described firmware upgrade method during execution, can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0017] To achieve the above objectives, a third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the firmware upgrade method described above.

[0018] The electronic device according to the embodiments of this application can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety by performing the above-described firmware upgrade method.

[0019] To achieve the above objectives, a fourth aspect of this application provides a firmware upgrade apparatus. The apparatus includes: an application to a program memory, the program memory comprising a first partition and a second partition; the apparatus comprising: an upgrade module, configured to, when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, write a Bootloader upgrade package and / or an APP upgrade package to the second partition, and obtain an upgrade package flag bit, wherein the target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction; a control module, configured to, when the target upgrade instruction is the APP upgrade instruction and the upgrade package flag bit is a second preset value, control the program memory to restart, thereby switching the currently running partition from the first partition to the second partition; the control module is further configured to, when the target upgrade instruction is the Bootloader upgrade instruction and the upgrade package flag bit is a first preset value, control the program memory to restart, write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, thereby switching the currently running partition from the second partition to the first partition.

[0020] According to the firmware upgrade apparatus of this application embodiment, the upgrade module is used to write the Bootloader upgrade package and / or APP upgrade package to the second partition and obtain the upgrade package flag bit when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, wherein the target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction; the control module is used to control the program memory to restart when the target upgrade instruction is an APP upgrade instruction and the upgrade package flag bit is a second preset value, so as to switch the currently running partition from the first partition to the second partition; the control module is also used to control the program memory to restart when the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag bit is a first preset value, and write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, so as to switch the currently running partition from the second partition to the first partition. Therefore, this apparatus can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] Figure 1 This is a flowchart of a firmware upgrade method according to an embodiment of this application.

[0023] Figure 2This is a flowchart illustrating a specific example of a firmware upgrade method according to this application.

[0024] Figure 3 This is a block diagram of an electronic device according to an embodiment of this application.

[0025] Figure 4 This is a block diagram of a firmware upgrade device according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0027] Currently, ECU flashing in the industry mainly adopts two major technical paths: traditional partitioning mode and A / B partitioning scheme. Although both modes are used in different scenarios, they both have significant technical defects and are difficult to adapt to the safety and efficiency requirements of intelligent vehicles.

[0028] Traditional partitioning is still widely used in older ECU devices, upgrading a single core area via a bootloader. The core flaw of this method lies in the rigidity of the upgrade logic: the current application partition must be erased before the new firmware is written. If an unexpected event such as a power outage or communication interruption occurs during this process, it can directly damage the ECU hardware. Furthermore, the ECU's functionality is completely disabled during the upgrade, severely impacting the stability of critical vehicle systems. Even if the ECU can revert to bootloader mode after a failed upgrade, it typically requires reflashing using specialized equipment, resulting in high maintenance costs and complex operations.

[0029] While the A / B partitioning scheme is a relatively advanced technology that achieves physical separation of "running and upgrading" based on Flash storage, it still fails to address core technical pain points: First, upgrade efficiency is low, with most schemes only supporting full-scale writing to new independent partitions, failing to achieve differentiated upgrades between the Bootloader and the App, resulting in a significant increase in upgrade time; second, the security mechanism has fatal vulnerabilities, with some schemes still using static key transmission methods; third, user experience and resource consumption issues are prominent, lacking effective prompts for partition switching and upgrade progress, and lacking atomic operation guarantee mechanisms, which easily leads to upgrade conflicts, while also requiring a 4MB fixed storage partition, resulting in resource waste.

[0030] In addition to the aforementioned mode-specific defects, existing ECU flashing technologies suffer from common deficiencies in core dimensions such as storage architecture, security authentication, upgrade strategies, and fault tolerance design, further hindering the effective implementation of the technology. At the technical implementation level, the storage architecture design is crude, often employing a single-partition or simple dual-partition structure. The Bootloader and App program storage are mutually bound, lacking independent isolation configuration, creating potential upgrade conflicts. Security authentication mechanisms are weak, generally relying on fixed keys or predictable random numbers for identity verification. Firmware integrity depends on a single verification mechanism, making it difficult to resist malicious tampering and cracking attacks. Upgrade strategies lack flexibility, lacking independent upgrade capabilities for the Bootloader and App, requiring a complete upgrade, and without priority control logic, the upgrade process significantly interferes with normal vehicle operation. Fault tolerance design is lacking; no specific protection mechanisms are designed for extreme scenarios such as partition write errors or sudden power outages, and no robust fault rollback path is established, easily leading to system "bricking" after an upgrade failure.

[0031] In addition, insufficient hardware compatibility is also a prominent issue. For example, the independent OTA feature of the ECU's Flash partition has not been fully explored and utilized, resulting in poor performance of the flashing program in terms of compatibility, stability, and universality. At the same time, the current solution has not been specifically optimized for typical faults such as partition write errors, which further reduces the reliability of upgrades and fails to meet the core requirements of smart cars for "safe, efficient, and reliable" ECU flashing technology.

[0032] To address this, this application proposes a firmware upgrade method that divides the program memory into two independent storage areas—a first partition (primary partition) and a second partition (backup partition)—through hardware-level address isolation. Each partition is equipped with a dedicated Bootloader and App storage block, enabling mutually exclusive access between the two partitions. An independent EEPROM status partition is also added to store upgrade flags, firmware metadata, and partition activation status. Chip hardware atomic instructions are used to execute flag write operations, preventing state chaos during the upgrade process at the hardware level. This completely avoids system risks, improves the reliability of firmware upgrades, and allows for rapid rollback to the active partition in extreme scenarios, completely eliminating the risk of system "bricking." Furthermore, it flexibly adapts to diverse scenarios, reducing system operation interference. It supports three upgrade modes: independent Bootloader, independent App, and a combination of both, eliminating the need for full upgrades or system reboots, meeting the "on-demand upgrade" requirements of automotive systems. It also enables precise upgrades for single ECUs or batch configuration of multiple ECUs, significantly reducing upgrade interference with system operation. In addition, two-way authentication and data packet verification can resist various malicious attacks, blocking illegal requests and improving the security of the program memory. It can reduce operation and maintenance costs, optimize operation and maintenance efficiency, adapt to multiple types of vehicle ECUs, and has strong compatibility and portability.

[0033] The firmware upgrade method, computer-readable storage medium, electronic device, and firmware upgrade apparatus proposed in this application are described below with reference to the accompanying drawings.

[0034] Figure 1 This is a flowchart of a firmware upgrade method according to an embodiment of this application.

[0035] like Figure 1 As shown, the firmware upgrade method in this application embodiment may include the following steps: S1, when the target upgrade instruction is received in the first partition and the target upgrade instruction is a valid instruction, the Bootloader upgrade package and / or APP upgrade package are written to the second partition, and the upgrade package flag is obtained. The target upgrade instruction includes the Bootloader upgrade instruction and / or APP upgrade instruction.

[0036] S2, when the target upgrade command is an APP upgrade command and the upgrade package flag is set to the second preset value, control the program memory to restart, so as to switch the currently running partition from the first partition to the second partition. The second preset value can be determined according to the actual situation.

[0037] S3, when the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is set to the first preset value, control the program memory to restart, write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart again to switch the currently running partition from the second partition to the first partition. The first preset value can be determined according to the actual situation.

[0038] Specifically, in one embodiment of this application, the firmware upgrade method is applied to a program memory, which may include a first partition and a second partition. The program memory is a storage area for storing system firmware (including the bootloader and the application), and may be a non-volatile memory, such as PFlash memory. It stores the system's boot code (Bootloader) and main application (App), ensuring the system can start and run normally. The program memory is divided into two independent partitions: a first partition and a second partition. Each partition contains storage blocks for the bootloader and the application. For example, the PFlash can be divided into two independent storage areas—a first partition (primary partition) and a second partition (backup partition)—through hardware-level address isolation. Each area is configured with dedicated storage blocks for the bootloader and the application, achieving mutually exclusive access between the two areas. The memory controller divides the PFlash address space into two independent regions using address mapping technology. For example, the first partition has an address range of 0x00000000 to 0x007FFFFF (assuming 8MB), and the second partition has an address range of 0x00800000 to 0x00FFFFFF (assuming 8MB). The memory controller ensures that the system can only access one partition at any given time, thus achieving mutually exclusive access between the two partitions. The system can only read and execute code from one partition at any given time. For example, if the system is currently booting from partition A, then partition B will be in a standby state, and vice versa. Partition switching can be achieved through hardware instructions (such as Swap switching instructions). For example, the system can switch the currently active partition from partition A to partition B using specific instructions, and vice versa. Thus, through the dual-partition architecture, a redundancy mechanism for firmware upgrades is achieved, ensuring high system reliability and fault rollback capability during the upgrade process.

[0039] A target upgrade command refers to a command containing upgrade information, which may include a Bootloader upgrade command, an App upgrade command, or both. When the upgrade command is a Bootloader upgrade command, a corresponding Bootloader upgrade package can be obtained; when the upgrade command is an App upgrade command, a corresponding App upgrade package can be obtained; and when both Bootloader and App upgrade commands are used, both Bootloader and App upgrade packages can be obtained to upgrade the firmware. The Bootloader and App upgrade packages refer to binary files containing the new versions of the Bootloader and App, used to replace the currently running Bootloader and / or App to upgrade the system firmware. After receiving the target upgrade command in the first partition, its validity must be checked. Illegal upgrade commands are ignored to prevent malicious unauthorized operations. Only when the target upgrade command is received in the first partition and is valid can the Bootloader or App upgrade package, or both, be written to the second partition. For example, the legitimacy of upgrade commands can be verified through an authentication service, ensuring that only authorized upgrade commands can be executed, preventing unauthorized operations, and ensuring the integrity and tamper-proof nature of the upgrade commands. The upgrade package is written to the inactive partition (second partition), avoiding direct manipulation of the active partition (first partition), reducing the risk of write failures. Thus, the dual-partition architecture ensures high system reliability during the upgrade process.

[0040] After writing the Bootloader upgrade package and APP upgrade package to the second partition, it is also necessary to obtain the upgrade package flag. The upgrade package flag is a status flag used to indicate whether the current upgrade package is complete. By reading the upgrade package flag, the type of the current upgrade package and the completeness of the corresponding type of upgrade package can be determined, thereby executing the corresponding upgrade process.

[0041] If the target upgrade command is an APP upgrade command and the upgrade package flag is at the second preset value, the program memory can be restarted to switch the currently running partition from the first partition to the second partition. The second preset value can be determined based on the actual situation: parsing the target upgrade command to determine the command type is an APP upgrade command, checking the upgrade package flag to determine the type and integrity of the current upgrade package. If the target upgrade command is an APP upgrade command and the upgrade package flag is at the second preset value, the program memory can be restarted to switch the currently running partition from the first partition to the second partition. This partition switching mechanism achieves seamless APP upgrades, reduces interference with system operation, and ensures that the system can start normally and run the new APP after the upgrade. The upgrade package is written to the inactive partition (second partition) to avoid directly manipulating the active partition (first partition), reducing the risk of write failures.

[0042] If the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is at the first preset value, the program memory can be controlled to restart, and the Bootloader upgrade package stored in the second partition can be written to the first partition. This restart switches the currently running partition from the second partition to the first partition. The first preset value can be determined based on the actual situation. Specifically, the target upgrade instruction is parsed to determine if it is a Bootloader upgrade instruction. The upgrade package flag is checked to determine the type and integrity of the current upgrade package. If the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is at the first preset value, the program memory can be controlled to restart, switching the currently running partition from the first partition to the second partition. This partition switching mechanism ensures that the system can boot from the new Bootloader and that the system can start normally and run the new Bootloader after the upgrade. While currently running on the second partition, the Bootloader upgrade package stored in the second partition is written to the first partition, and the program memory is controlled to perform a second reboot to switch the currently running partition from the second partition to the first partition. This ensures that the new Bootloader is written to the main storage area (first partition) for use during subsequent startups, ensuring that the system ultimately runs on the new Bootloader.

[0043] It's important to note that the bootloader is the first program to run when the system starts, responsible for initializing the hardware and loading the main application (App). To ensure the system can boot normally after an upgrade, the new bootloader must be written to the primary storage area (first partition). By writing the new bootloader to the first partition, the system can use the new bootloader in subsequent boots. Using a dual-partition architecture, the system can write the new bootloader to the backup partition (second partition) during the upgrade process and synchronize it to the primary storage area (first partition) after successful verification. This mechanism ensures high reliability of the upgrade process; even if the upgrade fails, the system can roll back to the old version of the bootloader. App upgrades typically do not affect the system's boot capabilities, so the new App can be written directly to the backup partition, and a seamless upgrade can be achieved through a partition switching mechanism.

[0044] Additionally, when the target upgrade commands are both an APP upgrade command and a Bootloader upgrade command, the above two steps can be combined simultaneously, and a third preset value can be defined, which can be determined according to the situation. For example, if the target upgrade commands are both an APP upgrade command and a Bootloader upgrade command, and the upgrade package flag is set to the third preset value, the program memory can be controlled to restart to switch the currently running partition from the first partition to the second partition, thus completing the APP upgrade. In the second partition, the Bootloader upgrade package stored in the second partition also needs to be written to the first partition, and the program memory needs to be controlled to restart a second time to switch the currently running partition from the second partition to the first partition, ensuring that the new Bootloader is written to the main storage area (first partition) for use during subsequent startup, ensuring that the system ultimately runs on the new Bootloader.

[0045] Therefore, by using a dual-partition architecture and partition switching mechanism, the system's high reliability is ensured during the upgrade process. Even if the upgrade fails, the system can be rolled back to the old version. Through the partition switching mechanism, a seamless upgrade is achieved, reducing interference with system operation. This helps to avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0046] According to one embodiment of this application, the firmware upgrade method further includes: authenticating the target upgrade command based on the target authentication service, so as to determine the target upgrade command as a legitimate command after successful authentication.

[0047] Specifically, after receiving the target upgrade command, a target authentication service is required to authenticate the command to confirm its legitimacy. For example, the target authentication service might be UDS 27. UDS (Unified Diagnostic Services) is a standardized automotive diagnostic communication protocol used for firmware upgrades and diagnostics of automotive electronic control units (ECUs). UDS 27 is the security authentication component of the UDS protocol. Two-way authentication via UDS 27 ensures the legitimacy and security of the upgrade command, preventing unauthorized firmware updates.

[0048] The system receives a target upgrade command containing Bootloader or App upgrade information. The host computer (upgrade tool) sends a UDS 27 07 command to request a seed. Upon receiving the request, the ECU (target device) generates a random seed (e.g., using a CRC 32 algorithm) and sends it back to the host computer. This random seed increases the complexity and security of authentication, ensuring each authentication process is unique and preventing replay attacks. The host computer uses the received seed and a pre-shared key to generate a key using a specific algorithm (e.g., HMAC, Hash-based Message Authentication Code). The ECU also uses the same seed and pre-shared key to generate the same key, ensuring that the host computer and ECU generate identical keys. This provides a foundation for subsequent authentication, and encryption algorithms ensure key security. The host computer then sends the generated key to the ECU via a UDS 27 08 command, providing a key that the ECU can verify, thus confirming the host computer's identity. After receiving the key, the ECU verifies whether it matches the key it generated. If the ECU responds with an authentication success message, the host computer begins sending upgrade data, verifying the key to ensure the legitimacy and security of the upgrade command. If the keys match, the ECU responds with an authentication success message, and the system continues with subsequent upgrade operations. If the keys do not match, the ECU responds with an authentication failure message, the system refuses to perform the upgrade operation, and an error log is recorded.

[0049] Therefore, through the above steps, upon receiving the target upgrade command, the system performs two-way authentication via the UDS 27 service to ensure the legitimacy and security of the upgrade command. This authentication mechanism, through steps such as random seed and key generation and key verification, ensures that only authorized upgrade operations can be executed, thereby improving the system's security and reliability. This design is particularly suitable for embedded systems with extremely high security requirements, such as automotive electronic control units.

[0050] According to one embodiment of this application, the firmware upgrade method further includes: verifying the Bootloader upgrade package and / or APP upgrade package based on a preset algorithm; after the verification is passed, setting the upgrade package flag bit based on atomic operations, wherein different upgrade packages correspond to different upgrade package flag bits.

[0051] Specifically, before writing the upgrade package to the second partition, it is necessary to verify the integrity of the Bootloader upgrade package and / or APP upgrade package, or the Bootloader upgrade package and APP, based on a preset algorithm. For example, a preset algorithm refers to a predefined verification algorithm used to verify the integrity and correctness of the upgrade package. This may include HMAC (Hash-based Message Authentication Code) or CRC (Cyclic Redundancy Check), ensuring that the upgrade package has not been tampered with or corrupted during transmission and writing. For instance, upon receiving a Bootloader upgrade package or APP upgrade package, a preset algorithm (such as HMAC) is used to verify the upgrade package and generate a verification value. If the verification value matches, the verification passes, and subsequent operations continue. If the verification value does not match, the verification fails, the system records an error log, and terminates the upgrade operation to prevent upgrade failure due to data corruption or tampering.

[0052] After successful verification, upgrade package flags can be set based on atomic operations. Different upgrade packages correspond to different upgrade package flags. An atomic operation is an uninterruptible operation that ensures the uniqueness and consistency of operations in a multi-threaded or multi-tasking environment. Setting flags through atomic operations prevents state chaos caused by concurrent operations. The corresponding flag is selected based on the type of upgrade package. For example, for a Bootloader upgrade, set the flag SoftUpdateFlag=4; for an App upgrade, set the flag App_update_pending=3; for simultaneous Bootloader and App upgrades, set the flag App_update_pending=5. Hardware-level atomic operations (such as LDREX / STREX instructions) are used to write the flags to the state partition, and the upgrade package's metadata (such as version number, flags, update time, etc.) is synchronized to the state partition.

[0053] Therefore, through the above steps, after receiving the upgrade package, the system verifies the upgrade package using a preset algorithm (such as HMAC) to ensure the integrity and correctness of the data. After successful verification, the system uses atomic operations to set the upgrade package flag and synchronizes the metadata to the state partition. This design ensures the security and reliability of the upgrade process, preventing state chaos caused by data corruption or concurrent operations.

[0054] According to one embodiment of this application, the firmware upgrade method further includes: after verification, storing the target upgrade information of the Bootloader upgrade package and / or APP upgrade package to a preset state partition, wherein the target upgrade information includes an upgrade version number, a flag bit, and an update time.

[0055] Specifically, after successful verification, the target upgrade information of the Bootloader upgrade package or APP upgrade package can be stored in a preset state partition, or the target upgrade information of both the Bootloader upgrade package and the APP upgrade package can be stored in the preset state partition simultaneously. The preset state partition is a storage area independent of the first and second partitions, specifically used to store information related to the system state. This information includes, but is not limited to, the upgrade version number, flag bits, and update time. The upgrade version number represents the version information of the upgrade package, used to identify the specific version of the upgrade package. The flag bit is a checksum calculated using a preset algorithm (such as HMAC), used to verify the integrity and correctness of the upgrade package. The update time records the specific time the upgrade package was generated or updated, used to track the timeliness of the upgrade package. In other words, the preset state partition can record key information generated during the upgrade process, such as the upgrade version number, checksum, and update time. Furthermore, the storage of state information is achieved through hardware-level atomic operations, ensuring the uniqueness and consistency of the state information writes, preventing state chaos caused by concurrent operations, and recording key information during the upgrade process, providing a basis for subsequent troubleshooting.

[0056] Therefore, through the above steps, after receiving the upgrade package, the system verifies the package using a preset algorithm to ensure the integrity and correctness of the data. After successful verification, the system stores the target upgrade information in a preset state partition and uses atomic operations to ensure the uniqueness and consistency of the state information writes. This design ensures the security and reliability of the upgrade process, preventing state chaos caused by data corruption or concurrent operations. The preset state partition is an independent storage area that records key information during the upgrade process, providing a basis for subsequent troubleshooting.

[0057] According to one embodiment of this application, the second partition includes a temporary storage area, and the firmware upgrade method further includes: writing the Bootloader upgrade package into the temporary storage area when the target upgrade instruction is a Bootloader upgrade instruction.

[0058] Specifically, the second partition includes a temporary storage area, which is an independent storage region specifically used to temporarily store critical data that needs to be written during the Bootloader upgrade process, such as upgrade packages and drivers. It is a storage area independent of the main storage area (such as partitions A and B) to reduce the risks associated with directly manipulating the main storage area. That is, when the target upgrade instruction is a Bootloader upgrade instruction, the Bootloader upgrade package can be written to the temporary storage area. For example, storing critical data temporarily in the temporary storage area avoids direct manipulation of the main storage area, reducing the risk of write failures (such as power outages or verification failures). If a power outage occurs during the write process, the data in the temporary storage area will not affect the normal operation of the main storage area. After the program memory restarts, it will detect that the data in the temporary storage area is invalid, thus avoiding the use of corrupted data for booting. The address range can be planned as 0x70000000-0x7000FFFF, with a capacity of 64KB, supporting a maximum single write size (such as 32KB), improving data write efficiency.

[0059] For example, upon receiving a target upgrade command, the system verifies the command's legitimacy through an authentication service. It then checks the upgrade package flag to confirm that the current upgrade package is a Bootloader upgrade package and is complete. If this is confirmed, the Bootloader upgrade package can be written to a temporary storage area (address range 0x70000000 to 0x7000FFFF).

[0060] Therefore, by temporarily storing critical data in a temporary storage area, direct operation of the main storage area is avoided, reducing the risk of write failures. If a power outage occurs during the writing process of the Bootloader upgrade package, the data in the temporary storage area will not affect the normal operation of the main storage area, ensuring the stability of the program memory.

[0061] According to one embodiment of this application, the firmware upgrade method further includes: after a program memory reboot failure, obtaining the number of reboot failures; and if the number of failures reaches a preset failure count threshold, triggering a recovery mode based on a hardware jumper to load and run the previous version of the Bootloader. The preset failure count threshold can be determined according to actual circumstances.

[0062] Specifically, after a program memory reboot fails, the number of reboot failures can be obtained. A reboot failure means that the program memory failed to successfully enter the expected running state during a reboot attempt. This could be due to a failure to boot after the bootloader or the corresponding app upgrade package has been written, resulting in the program memory potentially failing to boot normally, or failing to enter normal operating mode after booting. The number of reboot failures refers to the number of consecutive reboot attempts that failed. By recording the number of reboot failures, the system can determine whether it needs to enter recovery mode.

[0063] The system assesses the relationship between the number of failed reboots and a preset failure threshold. If the number of failed reboots reaches the preset threshold, a hardware jumper-triggered recovery mode is triggered to load and run the previous version of the bootloader. The preset failure threshold is a pre-defined value used to determine how many consecutive reboot failures the system must undergo before entering recovery mode, preventing the system from attempting reboots indefinitely and ensuring it reaches a safe state. Hardware jumper-triggered recovery mode is a method that uses a hardware mechanism (such as a change in the level of a specific pin) to trigger the system into recovery mode. After the preset number of consecutive reboot failures, the hardware jumper triggers recovery mode, loading and running the previous version of the bootloader to ensure the system can recover to a stable state. It should be noted that the previous version of the bootloader refers to the older version used before the current bootloader, typically stored in a spare partition. This ensures that when the current bootloader fails to start, the previous version is loaded to guarantee a normal system startup.

[0064] This allows the system to detect reboot failures and record the number of consecutive reboot failures, providing a basis for subsequent recovery operations. By setting a preset failure threshold, the system can determine when to enter recovery mode, avoiding premature or delayed entry. Hardware jumpers trigger recovery mode, ensuring it is unaffected by software failures and improving system reliability. The hardware jumpers provide rapid response, ensuring the program memory quickly enters recovery mode after multiple reboot failures, reducing system downtime. Furthermore, by loading an older version of the bootloader, the system ensures a stable recovery, improving availability and user experience. Through these steps, the system effectively handles reboot failures after program memory failures, ensuring system stability and availability.

[0065] According to one embodiment of this application, the firmware upgrade method further includes: in the event of verification failure, clearing the Bootloader upgrade package and / or APP upgrade package in the second partition, and recording error information, wherein the error information includes a timestamp, error code, and version information.

[0066] Specifically, in the event of a verification failure, the Bootloader upgrade package, APP upgrade package, or both can be cleared from the second partition, and error information can be recorded. This error information includes the timestamp, error code, and version information of the corresponding upgrade package. Verification failure occurs when the calculated checksum during integrity verification of the upgrade package differs from the expected value, indicating that the data may have been tampered with or corrupted during transmission or writing. Error information refers to the failure-related information recorded during the upgrade process, including the timestamp, error code, and version information. This provides detailed information for troubleshooting and subsequent analysis, helping developers or maintenance personnel quickly locate the problem. The timestamp records the specific time the error occurred, helping to determine the exact point in time and facilitating problem tracking. The error code is a predefined code used to identify the specific error type; for example, ERR_CHECKSUM_FAILED indicates verification failure, allowing for quick identification of the error type and enabling system or maintenance personnel to take appropriate measures. Version information refers to the version number of the upgrade package, identifying the specific version of the upgrade package and helping to determine the version of the failed upgrade package, facilitating subsequent analysis and repair.

[0067] In the case of a Bootloader upgrade command, if the verification of the Bootloader upgrade package written to the second partition fails due to a discrepancy between the verification value and the expected value, the Bootloader upgrade package in the second partition can be cleared. This clearing operation ensures that the second partition is restored to its initial state before the upgrade package was written, preventing the corrupted upgrade package from affecting subsequent operations of the program memory and ensuring that the program memory can recover to a stable state after the corrupted data is cleared. Error information, including timestamps, error codes, and version information, is recorded in a separate storage area (such as a status partition or error log partition). This provides detailed information for troubleshooting and subsequent analysis, helping developers or maintenance personnel quickly locate the problem.

[0068] When an app upgrade command is in effect, during the verification of the app upgrade package written to the second partition, if the verification value is found to be inconsistent with the expected value, the verification is deemed to have failed. The app upgrade package in the second partition can be cleared. This clearing operation ensures that the second partition is restored to its initial state before the upgrade package was written, preventing the corrupted upgrade package from affecting subsequent operations of the program storage and ensuring that the program storage can recover to a stable state after the corrupted data is cleared. Error information, including timestamps, error codes, and version information, is recorded in a separate storage area (such as a status partition or error log partition). This provides detailed information for troubleshooting and subsequent analysis, helping developers or maintenance personnel quickly locate the problem.

[0069] When using Bootloader and App upgrade commands, if the verification value of the App upgrade package and Bootloader upgrade package written to the second partition is found to be inconsistent with the expected value, the verification is deemed to have failed. The App upgrade package and Bootloader upgrade package in the second partition can be cleared. This clearing operation ensures that the second partition is restored to its initial state before the upgrade packages were written, preventing corrupted upgrade packages from affecting subsequent operations of the program memory and ensuring that the program memory can recover to a stable state after the corrupted data is cleared. Error information, including timestamps, error codes, and version information, is recorded in a separate storage area (such as a status partition or error log partition), providing detailed information for troubleshooting and subsequent analysis, helping developers or maintenance personnel quickly locate problems.

[0070] In addition, after verification fails, not only will the corrupted upgrade package be deleted, but the system can also automatically roll back to the old version of the bootloader and app to ensure that the program storage can boot normally. Furthermore, after verification fails and error information is logged, maintenance personnel can be notified via network or other communication methods that a verification failure has occurred.

[0071] Therefore, in the event of an upgrade package verification failure, the corrupted upgrade package can be effectively removed, and detailed error information can be recorded. This provides detailed information for troubleshooting and subsequent analysis, helping developers or maintenance personnel to quickly locate the problem. Furthermore, the timestamp and version information ensure the traceability of the error, facilitating subsequent repairs and improvements.

[0072] In addition, in one embodiment of this application, a pre-programming process is required before flashing the upgrade package. This process is an important stage in the firmware upgrade method, preparing for subsequent firmware flashing operations and ensuring that the target ECU (Electronic Control Unit) is in a stable state suitable for flashing. First, a UDS 10 83 command can be issued using functional addressing mode to bring the corresponding ECU cluster into an extended session, opening a channel for subsequent diagnostic operations. Then, switching to physical addressing mode, a 31 01 F0 02 command is issued to verify the pre-programming conditions such as ECU power supply voltage, current operating status, and available storage space, ensuring that the basic requirements for flashing are met. That is, through condition checks, the hardware and software status of the target ECU is ensured to meet the basic requirements for flashing, avoiding flashing failures due to hardware or software problems, ensuring that the system is in a stable and ready state before flashing, and reducing potential unexpected events during the flashing process. In addition, the function addressing sends commands 85 82 to disable the DTC (Diagnostic Trouble Code) setting function to avoid false fault reports during the flashing process, and commands 28 83 01 to stop communication processes unrelated to diagnosis, thus freeing up bus bandwidth. In other words, disabling the DTC setting function prevents interruptions or incorrect judgments caused by false fault reports during the flashing process, stops communication processes unrelated to diagnosis, frees up bus bandwidth, and ensures the efficiency and stability of the flashing operation. By reading hardware and software version information, it ensures that the new firmware is compatible with the hardware and software versions of the target ECU, avoiding flashing failures due to version incompatibility. This ensures that the system can correctly identify the version information of the target ECU before flashing, thereby selecting the appropriate firmware for upgrade.

[0073] Furthermore, after the firmware upgrade is complete, the system can be restored to its normal operating state. For example, the function addressing command UDS 10 83 is issued to re-enter the extended session, the command UDS 28 80 03 is issued to resume the communication process, the DTC (Diagnostic Trouble Code) setting function is enabled via the UDS 8581 command, and finally the command UDS 10 81 is issued to roll back to the default session. This restores the communication process with the ECU, ensuring the system can interact normally with the ECU; re-enables the DTC setting function, ensuring the system can report fault information correctly; and rolls back to the default session, ensuring the system returns to its stable state before the upgrade. Moreover, if temporary fault information exists during the upgrade process, the physical addressing command UDS 14 FF FF FF can be issued to clear the temporary DTCs generated during the flashing process and the temporary fault information generated during the upgrade, ensuring that there is no residual fault information on the ECU and that the system can operate normally after the upgrade, avoiding false alarms or anomalies caused by residual fault information.

[0074] The following is combined with Figure 2The method described in this application is used to describe the method.

[0075] As a specific example, the firmware upgrade method of this application may include the following steps: S101, when the target upgrade instruction is received in the first partition, the target upgrade instruction is authenticated based on the target authentication service, so as to determine that the target upgrade instruction is a valid instruction after successful authentication. The target upgrade instruction includes the Bootloader upgrade instruction and / or the APP upgrade instruction.

[0076] S102, write the Bootloader upgrade package and / or APP upgrade package to the second partition.

[0077] S103, Verify the Bootloader upgrade package and / or APP upgrade package based on a preset algorithm.

[0078] S104. Determine if the verification passes. If yes, proceed to step S105; otherwise, proceed to step S110.

[0079] S105, set the upgrade package flag bit based on atomic operation, and store the target upgrade information of the Bootloader upgrade package and / or APP upgrade package to the preset state partition. The target upgrade information includes the upgrade version number, flag bit and update time. Different upgrade packages correspond to different upgrade package flag bits.

[0080] S106, if the target upgrade instruction is an APP upgrade instruction and the upgrade package flag is a second preset value, control the program memory to restart so as to switch the currently running partition from the first partition to the second partition.

[0081] S107, If the program memory fails to restart, obtain the number of times the restart failed.

[0082] S108. Determine whether the number of failures has reached the preset failure threshold. If yes, proceed to step S109; otherwise, proceed to step S107.

[0083] S109, based on hardware jumper-triggered recovery mode, runs by loading the previous version of the bootloader.

[0084] S110, clear the Bootloader upgrade package and / or APP upgrade package in the second partition, and record error information, including timestamp, error code, and version information.

[0085] S111, when the target upgrade instruction is the Bootloader upgrade instruction and the upgrade package flag is the first preset value, control the program memory to restart, write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, so as to switch the currently running partition from the second partition to the first partition, and proceed to step S107.

[0086] In summary, according to the firmware upgrade method of this application embodiment, when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, the Bootloader upgrade package and / or APP upgrade package are written to the second partition, and the upgrade package flag is obtained. The target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction. If the target upgrade instruction is an APP upgrade instruction and the upgrade package flag is a second preset value, the program memory is controlled to restart to switch the currently running partition from the first partition to the second partition. If the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag is a first preset value, the program memory is controlled to restart, and the Bootloader upgrade package stored in the second partition is written to the first partition. The program memory is then controlled to restart again to switch the currently running partition from the second partition to the first partition. Therefore, this method can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0087] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0088] The computer-readable storage medium of this application embodiment stores a program that, when executed by a processor, implements the firmware upgrade method described above.

[0089] The computer-readable storage medium according to the embodiments of this application can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety by executing the above-described firmware upgrade method.

[0090] Corresponding to the above embodiments, this application also proposes an electronic device.

[0091] like Figure 3 As shown, the electronic device 200 of this application embodiment may include: a memory 210, a processor 220, and a program stored on the memory 210 and executable on the processor 220. When the processor 220 executes the program, it implements the above-described firmware upgrade method.

[0092] The electronic device according to the embodiments of this application can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety by performing the above-described firmware upgrade method.

[0093] Corresponding to the above embodiments, this application also proposes a firmware upgrade device.

[0094] like Figure 4 As shown, the firmware upgrade device 100 of this application embodiment includes an upgrade module 110 and a control module 120.

[0095] The upgrade module 110 is configured to, when the first partition receives a target upgrade instruction and the target upgrade instruction is valid, write the Bootloader upgrade package and / or APP upgrade package to the second partition and obtain the upgrade package flag bit, wherein the target upgrade instruction includes the Bootloader upgrade instruction and / or APP upgrade instruction. The control module 120 is configured to, when the target upgrade instruction is an APP upgrade instruction and the upgrade package flag bit is a second preset value, control the program memory to restart, thereby switching the currently running partition from the first partition to the second partition. The control module 120 is also configured to, when the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag bit is a first preset value, control the program memory to restart, write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, thereby switching the currently running partition from the second partition to the first partition.

[0096] According to one embodiment of this application, upgrade module 110: authenticates the target upgrade command based on the target authentication service, so as to determine the target upgrade command as a legitimate command after successful authentication.

[0097] According to one embodiment of this application, the upgrade module 110 is further configured to: verify the Bootloader upgrade package and / or APP upgrade package based on a preset algorithm; and after the verification is passed, set the upgrade package flag bit based on atomic operations, wherein different upgrade packages correspond to different upgrade package flag bits.

[0098] According to one embodiment of this application, the upgrade module 110 is further configured to: after verification, store the target upgrade information of the Bootloader upgrade package and / or APP upgrade package in a preset state partition, wherein the target upgrade information includes the upgrade version number, a flag bit, and an update time.

[0099] According to one embodiment of this application, the second partition includes a temporary storage area, and the upgrade module 110 is further configured to: write the Bootloader upgrade package into the temporary storage area when the target upgrade instruction is a Bootloader upgrade instruction.

[0100] According to one embodiment of this application, the control module 120 is further configured to: obtain the number of restart failures after the program memory restart fails; and, if the number of failures reaches a preset failure threshold, trigger a recovery mode based on a hardware jumper to load and run the previous version of the Bootloader.

[0101] According to one embodiment of this application, the control module 120 is further configured to: in the event of a verification failure, clear the Bootloader upgrade package and / or APP upgrade package in the second partition and record error information, wherein the error information includes a timestamp, an error code, and version information.

[0102] It should be noted that for details not disclosed in the firmware upgrade device of this application embodiment, please refer to the details disclosed in the firmware upgrade method of this application embodiment, which will not be repeated here.

[0103] According to the firmware upgrade apparatus of this application embodiment, the upgrade module is used to write the Bootloader upgrade package and / or APP upgrade package to the second partition and obtain the upgrade package flag bit when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, wherein the target upgrade instruction includes a Bootloader upgrade instruction and / or an APP upgrade instruction; the control module is used to control the program memory to restart when the target upgrade instruction is an APP upgrade instruction and the upgrade package flag bit is a second preset value, so as to switch the currently running partition from the first partition to the second partition; the control module is also used to control the program memory to restart when the target upgrade instruction is a Bootloader upgrade instruction and the upgrade package flag bit is a first preset value, and write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, so as to switch the currently running partition from the second partition to the first partition. Therefore, this apparatus can avoid upgrade risks, improve the reliability of firmware upgrades, and enhance user experience and vehicle safety.

[0104] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0105] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0108] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0109] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A firmware upgrade method, characterized in that, Applied to a program memory, the program memory including a first partition and a second partition, the method includes: When the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction, the Bootloader upgrade package and / or APP upgrade package are written to the second partition, and the upgrade package flag is obtained. The target upgrade instruction includes the Bootloader upgrade instruction and / or APP upgrade instruction. When the target upgrade instruction is the APP upgrade instruction and the upgrade package flag is a second preset value, the program memory is controlled to restart so as to switch the currently running partition from the first partition to the second partition; When the target upgrade instruction is the Bootloader upgrade instruction and the upgrade package flag is a first preset value, the program memory is controlled to restart, and the Bootloader upgrade package stored in the second partition is written to the first partition. The program memory is then controlled to restart, so as to switch the currently running partition from the second partition to the first partition.

2. The firmware upgrade method according to claim 1, characterized in that, The method further includes: The target upgrade command is authenticated based on the target authentication service, so that the target upgrade command is determined to be a legitimate command after successful authentication.

3. The firmware upgrade method according to claim 2, characterized in that, The method further includes: The Bootloader upgrade package and / or the APP upgrade package are verified based on a preset algorithm; After the verification is successful, the upgrade package flag is set based on atomic operations, wherein different upgrade packages correspond to different upgrade package flags.

4. The firmware upgrade method according to claim 3, characterized in that, The method further includes: After verification, the target upgrade information of the Bootloader upgrade package and / or the APP upgrade package is stored in a preset state partition, wherein the target upgrade information includes the upgrade version number, a flag bit, and the update time.

5. The firmware upgrade method according to claim 1, characterized in that, The second partition includes a temporary storage area, and the method further includes: If the target upgrade instruction is a Bootloader upgrade instruction, the Bootloader upgrade package is written to the temporary storage area.

6. The firmware upgrade method according to claim 1, characterized in that, The method further includes: After the program memory fails to restart, obtain the number of restart failures; If the number of failures reaches a preset failure threshold, a recovery mode is triggered based on a hardware jumper to load and run the previous version of the Bootloader.

7. The firmware upgrade method according to claim 3, characterized in that, The method further includes: In the event of a verification failure, the Bootloader upgrade package and / or the APP upgrade package in the second partition are cleared, and error information is recorded, including a timestamp, error code, and version information.

8. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor, implements the firmware upgrade method according to any one of claims 1-7.

9. An electronic device, characterized in that, include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the firmware upgrade method according to any one of claims 1-7.

10. A firmware upgrade device, characterized in that, Applied to a program memory, the program memory including a first partition and a second partition, the device includes: The upgrade module is used to write the Bootloader upgrade package and / or APP upgrade package to the second partition and obtain the upgrade package flag bit when the first partition receives a target upgrade instruction and the target upgrade instruction is a valid instruction. The target upgrade instruction includes the Bootloader upgrade instruction and / or APP upgrade instruction. The control module is used to control the program memory to restart when the target upgrade instruction is the APP upgrade instruction and the upgrade package flag is a second preset value, so as to switch the currently running partition from the first partition to the second partition; The control module is further configured to, when the target upgrade instruction is the Bootloader upgrade instruction and the upgrade package flag is a first preset value, control the program memory to restart, write the Bootloader upgrade package stored in the second partition to the first partition, and control the program memory to restart, so as to switch the currently running partition from the second partition to the first partition.

Images