BMS (Battery Management System) double-partition collaborative flashing method and system and electronic equipment

Abstract

The invention discloses a BMS (Battery Management System) double-partition collaborative flashing method and system and electronic equipment. Relates to the field of program flashing. A BMS storage area is divided into a first bootstrap program area, two independent bootstrap program partitions and two independent application program partitions, an effective flag bit and a program version number are set for each partition, and state judgment of a partition type arbitration mechanism and a program flashing flag bit is combined, so that the application program is flashed and written, and the application program is flashed and written. A complete process from system starting, partition selection and flash control is constructed. According to the scheme, independent dual-backup management of the bootstrap program and the application program is realized, and when any flash fails or the program is abnormal, a runnable stable version is kept all the time; the technical problems of system paralysis, rollback mechanism deficiency, irreversible upgrading process and the like caused by flashing failure in a traditional single-partition or single-side dual-backup architecture are effectively solved, and the reliability, the safety and the fault-tolerant capability of BMS software updating are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of program flashing, and more particularly to a dual-partition collaborative flashing method, system, and electronic device for a BMS system. Background Technology

[0002] With the rapid development of new energy vehicle technology, the continuous optimization and reliable upgrade of the software functions of the Battery Management System (BMS), as the core control unit, have become critical requirements. In practical applications, the BMS often needs to achieve functional iteration, performance improvement, and defect repair through online flashing (OTA, or diagnostic flashing) to upgrade the vehicle's electronic system remotely via wireless communication methods such as 4G / 5G or Wi-Fi. However, the flashing process is susceptible to factors such as communication interruptions, power failures, or program errors, leading to upgrade failures or even system boot failures. Traditional single-partition flashing architectures lack redundancy backup mechanisms during the update process. Once the flashing is interrupted or the program malfunctions, the BMS will lose control, seriously affecting vehicle safety and user experience. Therefore, a software update solution with high fault tolerance and self-recovery capabilities is urgently needed to ensure the reliability of the flashing process.

[0003] While existing firmware update methods based on dual-partition architecture exist, they still have significant shortcomings at the system design level. On one hand, most solutions only perform dual backups of the application area, failing to divide the bootloader into an independent dual-partition structure, resulting in a single point of failure risk during bootloader upgrades. On the other hand, the system's logic for determining partition validity at startup is simplistic, lacking a multi-dimensional arbitration mechanism that combines version number, flag status, and external commands, making it difficult to handle complex and abnormal scenarios. Furthermore, state management during the flashing process is imprecise, and flag setting and response procedures are unclear, especially regarding flashing failures or verification failures, lacking clear rollback strategies and recovery paths. These issues collectively result in significant shortcomings in the security, flexibility, and maintainability of existing BMS flashing systems, making it difficult to meet the requirements of high-reliability application scenarios. Summary of the Invention

[0004] To address the technical problems of low reliability, poor fault tolerance, imperfect rollback mechanism, and imprecise partition management and status judgment logic in existing BMS systems during software flashing, this invention proposes a dual-partition collaborative flashing method for BMS systems. The BMS system's storage area includes a first bootloader area, a first bootloader partition, and a second bootloader partition, as well as a first application partition and a second application partition. Each bootloader partition and application partition is equipped with a valid flag bit indicating the validity of its program and a program version number. The dual-partition collaborative flashing method for BMS systems includes the following steps:

[0005] S1: After the BMS system starts up, it enters the first boot program area. Based on the valid flag bits and program version numbers of each boot program partition, the boot program partition types corresponding to the first and second boot program partitions are set respectively. The boot program partition types include runnable type and pre-flashable type. Jump to the runnable type boot program partition for execution.

[0006] S2: Based on the valid flag status of the first application partition and the second application partition and the program version number, set the application partition type corresponding to the first application partition and the second application partition respectively; the application partition type includes runnable type and pre-flashable type;

[0007] S3: Detect the status of the program write flag. If the program write flag is valid, proceed to the next step; if invalid, jump to the runnable application partition to execute the main control program.

[0008] S4: Enter program flashing mode: Receive the integrated upgrade file sent by the external system; determine whether the upgrade target is a bootloader upgrade or an application upgrade based on the type identification information of the integrated upgrade file; if it is a bootloader upgrade, write the program code corresponding to the bootloader partition that is currently the type to be flashed in the integrated upgrade file to that partition; if it is an application upgrade, write the program code corresponding to the application partition that is currently the type to be flashed in the integrated upgrade file to that partition.

[0009] Furthermore, the integration upgrade file includes first bootloader code and second bootloader code adapted to the first bootloader partition and the second bootloader partition, wherein the physical address in the first bootloader code points to the first bootloader partition, and the physical address in the second bootloader code points to the second bootloader partition; or the integration upgrade file includes first application code and second application code adapted to the first application partition and the second application partition, wherein the physical address in the first application code points to the first application partition, and the physical address in the second application code points to the second application partition.

[0010] Further, the step of setting the boot partition type corresponding to the first boot partition and the second boot partition respectively based on the valid flag bit and program version number of each boot partition; specifically:

[0011] Read the valid flag bits corresponding to the first boot partition and the second boot partition;

[0012] If only the valid flag of the first boot partition is valid, then the first boot partition is set to the runnable type and the second boot partition is set to the pre-flash type.

[0013] If only the valid flag of the second boot partition is valid, then the second boot partition is set to the runnable type, and the first boot partition is set to the pre-flash type.

[0014] If both the first boot partition and the second boot partition have valid flags, then compare their program version numbers, set the boot partition with the higher version number as the runnable type, and set the boot partition with the lower version number as the pre-flash type.

[0015] Further, the step of setting the application partition types corresponding to the first application partition and the second application partition respectively based on the valid flag status of the first application partition and the application version number specifically involves:

[0016] Read the valid flag bits corresponding to the first application partition and the second application partition;

[0017] If only the first application partition is valid, then set the first application partition to the runnable type and the second application partition to the pre-flash type;

[0018] If only the second application partition is valid, then set the second application partition to the runnable type and the first application partition to the pre-flash type;

[0019] If both are valid, compare their program version numbers, set the application partition with the higher version number as the runnable type, and set the application partition with the lower version number as the ready-to-flash type.

[0020] Furthermore, the program write flag is set to valid based on a reprogramming request sent by an external system.

[0021] Furthermore, the step of writing the program code corresponding to the bootloader partition currently designated as the pre-flashable type from the integrated upgrade file into the partition also includes:

[0022] After the flashing process is complete, a verification is performed. If the verification passes, the valid flag of the bootloader partition is set to valid, its program version number is updated, and the BMS system is reset.

[0023] If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the program version of the bootloader partition whose current bootloader partition type is runnable;

[0024] The process of writing the program code corresponding to the application partition currently designated as the pre-flash type from the integrated upgrade file to the partition also includes:

[0025] After the flashing is completed, a verification is performed. If the verification passes, the valid flag of the application partition is set to valid, its program version number is updated, and the BMS system is reset.

[0026] If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the application version of the application partition whose current application partition type is runnable.

[0027] Furthermore, the verification specifically includes:

[0028] The verification specifically involves performing CRC or hash checks on the program code in the bootloader partition or application partition after the write operation is completed, in order to verify the integrity and correctness of the data.

[0029] Furthermore, if the valid flags of both the first boot partition and the second boot partition are valid, and a forced rollback command is received, then the boot partition with the lower program version number is set to the runnable type, and the boot partition with the higher program version number is set to the pre-flash type.

[0030] Furthermore, if the valid flags of both the first and second application partitions are valid and a forced rollback command is received, the application partition with the lower program version number is set to the runnable type, and the application partition with the higher program version number is set to the pre-flash type.

[0031] This invention also proposes a dual-partition collaborative flashing system for a BMS system. The storage area of ​​the BMS system includes a first bootloader area, a first bootloader partition, and a second bootloader partition, as well as a first application partition and a second application partition. Each bootloader partition and application partition is provided with a valid flag bit and a program version number to indicate the validity of its program. The dual-partition collaborative flashing system for the BMS system includes:

[0032] The bootloader execution module is used to enter the first bootloader area after the BMS system starts up, and set the bootloader partition types corresponding to the first bootloader partition and the second bootloader partition respectively according to the valid flag bits and program version numbers of each bootloader partition; the bootloader partition types include runnable type and pre-flashable type; jump to the runnable bootloader partition for execution;

[0033] The application partition type setting module is used to set the application partition type corresponding to the first application partition and the second application partition respectively according to the valid flag bit status and program version number of the first application partition and the second application partition; the application partition type includes runnable type and pre-flashable type.

[0034] The program flashing flag detection module is used to detect the status of the program flashing flag. If the program flashing flag is valid, proceed to the next step; if invalid, jump to the runnable application partition to execute the main control program.

[0035] The flashing module is used to enter the program flashing mode: it receives the integrated upgrade file sent by the external system; based on the type identification information of the integrated upgrade file, it determines whether the target of this upgrade is a bootloader upgrade or an application upgrade; if it is a bootloader upgrade, it writes the program code corresponding to the bootloader partition in the integrated upgrade file that is currently the type to be flashed into that partition; if it is an application upgrade, it writes the program code corresponding to the application partition in the integrated upgrade file that is currently the type to be flashed into that partition.

[0036] To address the aforementioned problems, another aspect of this invention provides an electronic device, including: a processor and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the aforementioned BMS system dual-partition collaborative flashing method.

[0037] To address the aforementioned problems, in another aspect of this invention, a non-transitory machine-readable medium storing computer instructions is provided, the computer instructions being used to cause the computer to execute the aforementioned BMS system dual-partition collaborative writing method.

[0038] Compared with the prior art, the present invention has at least the following beneficial effects:

[0039] (1) This invention divides the BMS storage area into a first bootloader area, two independent bootloader partitions, and two independent application partitions, and sets a valid flag and program version number for each partition. Combined with the partition type arbitration mechanism and the status judgment of the program write flag, a complete process from system startup, partition selection, and write control is constructed. This scheme realizes independent dual backup management of the bootloader and the application. In the event of any write failure or program abnormality, a stable and runnable version is always retained. This effectively solves the technical problems of system paralysis due to write failure, lack of rollback mechanism, and irreversible upgrade process in traditional single-partition or single-sided dual backup architecture (i.e., only the application area adopts the dual-partition backup mechanism, while the bootloader still adopts the single-partition storage structure). It significantly improves the reliability, security, and fault tolerance of BMS software updates.

[0040] (2) This invention, after entering the first bootloader area during system startup, first checks the valid flag bits of each bootloader partition and arbitrates them in conjunction with the program version number, prioritizing the selection of partitions with higher versions and valid flag bits as runnable types, while the other partition serves as a pre-flash area, ensuring that the system always boots from a known and reliable bootloader. Based on this, the same validity judgment and version comparison logic is further performed on the application partitions, achieving collaborative management of the bootloader and applications. This mechanism avoids startup failures caused by flashing interruptions or flag bit errors, enhances the system's self-recovery capability under complex operating conditions, and is particularly suitable for frequent OTA upgrades or remote maintenance scenarios.

[0041] (3) This invention adopts an integrated upgrade file carrying dual-partition adaptation code, meaning the file simultaneously contains program code applicable to the first and second bootloader partitions (or the first and second application partitions), and each code segment has a pre-set corresponding physical address. After receiving the file, the BMS determines the upgrade target based on its type identification information and automatically selects the program code corresponding to that type in the file for writing based on the currently set "prepared flashing type". Since the selection of the target partition is determined autonomously by the internal state of the BMS (prepared flashing type), there is no need for the external system to dynamically specify the write address or partition number, avoiding the problem of writing the wrong partition due to communication configuration errors or human error. At the same time, the single-send, automatic matching mechanism simplifies the flashing process, reduces communication interaction, and improves flashing efficiency and automation.

[0042] (4) This invention introduces a verification mechanism (such as CRC check or hash check) after the program is written to verify the integrity of the program code written to the target partition. If the verification passes, the valid flag of the partition is set to valid, and its program version number is updated. Then, a system reset is triggered to activate the new version. If the verification fails, no flag is modified, and a system reset is directly triggered, allowing the BMS to resume running the original executable program version. This mechanism realizes closed-loop verification of the writing results, preventing invalid writing due to data corruption, communication interference, or storage abnormalities. It ensures that the system only switches the running version when the program is complete and reliable, greatly improving the reliability of software updates and system stability.

[0043] (5) For urgent downgrade needs, this invention supports forced rollback commands triggered externally or internally. When both the first and second application partitions are valid but have different version numbers, the partition with the lower program version number is actively selected as the runnable type, while the partition with the higher version number is converted into a pre-flash area. This function can be used to deal with scenarios where the new version of the program has serious defects or compatibility issues, achieving rapid and controllable version rollback and avoiding vehicle downtime or safety risks. At the same time, this mechanism complements the conventional "higher version priority" strategy, enhancing the flexibility and operability of the system in operation and maintenance management, and meeting the actual application needs of high-security-level vehicle electronic systems. Attached Figure Description

[0044] Figure 1 This is a flowchart of a dual-partition collaborative flashing method for a BMS system according to an embodiment of the present invention;

[0045] Figure 2 This is a module diagram of a dual-partition collaborative flashing system for a BMS system according to an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0047] The following are specific embodiments of the present invention, which are described in conjunction with the accompanying drawings. However, the present invention is not limited to these embodiments.

[0048] To address the technical problems of low reliability, poor fault tolerance, imperfect rollback mechanisms, and imprecise partition management and status judgment logic in existing BMS systems during software flashing, such as... Figure 1As shown, this invention proposes a dual-partition collaborative flashing method for a BMS system. The storage area of ​​the BMS system includes a first bootloader area (i.e., FBL boot area), a first bootloader partition, a second bootloader partition, a first application partition, and a second application partition. Each bootloader partition and application partition is provided with a valid flag bit and a program version number to indicate the validity of its program. The dual-partition collaborative flashing method for the BMS system includes the following steps:

[0049] S1: After the BMS system starts up, it enters the first boot program area. Based on the valid flag bits and program version numbers of each boot program partition, the boot program partition types corresponding to the first and second boot program partitions are set respectively. The boot program partition types include runnable type and pre-flashable type. Jump to the runnable type boot program partition for execution.

[0050] The boot partition type is set according to the valid flag bits and program version number of each boot partition, corresponding to the first boot partition and the second boot partition respectively; specifically:

[0051] Read the valid flag bits corresponding to the first boot partition and the second boot partition;

[0052] If only the valid flag of the first boot partition is valid, then the first boot partition is set to the runnable type and the second boot partition is set to the pre-flash type.

[0053] If only the valid flag of the second boot partition is valid, then the second boot partition is set to the runnable type, and the first boot partition is set to the pre-flash type.

[0054] If both the first boot partition and the second boot partition have valid flags, then compare their program version numbers, set the boot partition with the higher version number as the runnable type, and set the boot partition with the lower version number as the pre-flash type.

[0055] If the valid flags of the first bootloader partition and the second bootloader partition are both valid and the program version number is the same, then the preset priority bootloader partition is determined as the runnable type, and the other bootloader partition is determined as the pre-flashable type.

[0056] If the valid flags of both the first and second boot partitions are valid and a forced rollback command is received, then the boot partition with the lower program version number is set to the runnable type, and the boot partition with the higher program version number is set to the pre-flash type.

[0057] In this embodiment, after the BMS system powers on or resets, the boot code (i.e., the first bootloader area) located in the FBL_BASE stage is executed first. The main task of this stage is to select one of the two bootloader partitions as the currently running bootloader partition based on the valid flag status and program version number of the first and second bootloader partitions. After the system successfully enters the designated bootloader partition, it enters the bootloader stage. In this stage, the bootloader is responsible for initializing the application partitions: reading the valid flags and program version numbers of the first and second application partitions, and determining which application partition should be the "runnable type" for this boot, and the other as the "prepared to be flashed type," based on whether a forced rollback instruction has been received. The arbitration result directly affects the boot path of the subsequent main control program, ensuring the safe and stable operation of the system.

[0058] S2: Based on the valid flag status of the first application partition and the second application partition and the program version number, set the application partition type corresponding to the first application partition and the second application partition respectively; the application partition type includes runnable type and pre-flashable type;

[0059] The step of setting the application partition type corresponding to the first application partition and the second application partition respectively based on the valid flag status of the first application partition and the application version number is as follows:

[0060] Read the valid flag bits corresponding to the first application partition and the second application partition;

[0061] If only the first application partition is valid, then set the first application partition to the runnable type and the second application partition to the pre-flash type;

[0062] If only the second application partition is valid, then set the second application partition to the runnable type and the first application partition to the pre-flash type;

[0063] If both are valid, compare their program version numbers, set the application partition with the higher version number as the runnable type, and set the application partition with the lower version number as the ready-to-flash type.

[0064] If the valid flags of the first application partition and the second application partition are both valid and the program version numbers are the same, then the default priority running application partition will be determined as the runnable type, and the other application partition will be determined as the pre-flashable type.

[0065] If the valid flags of both the first and second application partitions are valid and a forced rollback command is received, then the application partition with the lower application version number is set to the runnable type, and the application partition with the higher application version number is set to the pre-flash type.

[0066] In embodiments of the present invention, the forced rollback command refers to a control command issued by an external system or triggered by the internal fault monitoring mechanism of the BMS system, used to proactively downgrade to a historically stable version. When the BMS system boots into the bootloader stage, it first arbitrates the partition type based on the valid flag bits of the first and second application partitions and the program version number. If both application partitions have valid flag bits and a forced rollback command is received, the application partition with the lower version number is set as the runnable type, and the application partition with the higher version number is set as the pre-flash type. Subsequently, the status of the program flashing flag bit is checked: if the flag bit is invalid, the system jumps to the currently set runnable type application partition (i.e., the lower version) to execute the main control program; if valid, it enters the program flashing mode. Through this mechanism, the BMS system can achieve version downgrading based on the forced rollback command during this boot process, ensuring rapid recovery to a stable operating state when the new version has serious defects, thus improving system security and maintainability.

[0067] In other words, for urgent downgrade needs, this invention supports a forced rollback command triggered externally or internally. When both the first and second application partitions are valid but have different version numbers, it proactively selects the partition with the lower application version number as the runnable type, while the higher version partition becomes the pre-flash area. This function can be used to address scenarios where new version programs have serious defects or compatibility issues, achieving rapid and controllable version rollback and avoiding vehicle downtime or security risks. Simultaneously, this mechanism complements the conventional "higher version priority" strategy, enhancing the system's flexibility and operability in operation and maintenance management, and meeting the practical application needs of high-security-level vehicle electronic systems.

[0068] S3: Detect the status of the program flashing flag. If the program flashing flag is valid, proceed to the next step; if the program flashing flag is invalid, jump to the runnable application partition to execute the main control program.

[0069] The program write flag is set to active based on a reprogramming request sent by an external system.

[0070] In this embodiment, the program flashing flag is used to indicate whether the BMS system needs to enter program flashing mode. During normal operation or startup, this flag is invalid by default, and the system will skip the flashing process and directly execute the main control program. When an external system (such as a host computer, diagnostic device, or OTA platform) initiates a software upgrade request, it will send a reprogramming command to the BMS through the communication interface. After receiving the request, the BMS will set the program flashing flag to valid. This flag is usually stored at a specific address in non-volatile memory (such as Flash or EEPROM) to ensure that it remains in its state after system reset or power failure restart. Through this mechanism, the BMS system can automatically enter FBL mode and perform flashing operations on the next startup without continuous intervention from external systems, improving the reliability and automation of the upgrade process. After the flashing is completed, regardless of success or failure, the BMS system will clear the flag to prevent repeated entry into program flashing mode.

[0071] Flash memory is a non-volatile semiconductor memory capable of retaining data for extended periods after power loss. It is widely used in embedded systems to store program code and large amounts of configuration information. Its characteristics include large storage capacity and high read speed. However, due to the limited erase / write cycle life of Flash memory (typically 10,000 to 100,000 cycles), wear leveling and write frequency control must be considered during the design phase. In this invention, the program write / erase flag can be stored in a specific reserved sector of the Flash memory, ensuring it remains valid even after system reset or power failure.

[0072] EEPROM (Electrically Erasable Programmable Read-Only Memory) is a type of non-volatile memory that persistently retains data after power loss. Compared to Flash memory, EEPROM supports byte-by-byte erasure and writing, eliminating the need for complete block erasure. Therefore, it is more suitable for storing frequently modified small amounts of data, such as system status flags, calibration parameters, or fault records. In a BMS (Battery Management System), EEPROM is commonly used to store information requiring high durability and flexible updates, such as run counts, lifecycle data, and program write / erase flags. Its write / erase cycle life is typically over one million cycles, offering high reliability. In this invention, the program write / erase flag can be optionally stored in the EEPROM to support frequent setting and clearing during multiple upgrade operations, improving system stability and durability.

[0073] S4: Enter program flashing mode: Receive the integrated upgrade file sent by the external system; determine whether the upgrade target is a bootloader upgrade or an application upgrade based on the type identification information of the integrated upgrade file; if it is a bootloader upgrade, write the program code corresponding to the bootloader partition that is currently the type to be flashed in the integrated upgrade file to that partition; if it is an application upgrade, write the program code corresponding to the application partition that is currently the type to be flashed in the integrated upgrade file to that partition.

[0074] The integration upgrade file includes first bootloader code and second bootloader code adapted to the first bootloader partition and the second bootloader partition, wherein the physical address in the first bootloader code points to the first bootloader partition, and the physical address in the second bootloader code points to the second bootloader partition; or the integration upgrade file includes first application code and second application code adapted to the first application partition and the second application partition, wherein the physical address in the first application code points to the first application partition, and the physical address in the second application code points to the second application partition.

[0075] This invention employs an integrated upgrade file carrying dual-partition adaptation code. The file simultaneously contains program code applicable to both the first and second bootloader partitions (or first and second application partitions), with each code segment pre-configured with its corresponding physical address. Upon receiving this file, the BMS determines the upgrade target based on its type identifier information and automatically selects the corresponding program code from the file based on the currently set "prepared flashing type." Since the target partition selection is determined autonomously by the BMS's internal state (prepared flashing type), there is no need for an external system to dynamically specify the write address or partition number, avoiding the problem of writing programs to the wrong partition due to communication configuration errors or human error. Furthermore, the single-send, automatic matching mechanism simplifies the flashing process, reduces communication interactions, and improves flashing efficiency and automation.

[0076] The process of writing the program code corresponding to the bootloader partition currently designated as a pre-flashable type from the integrated upgrade file to that partition also includes:

[0077] After the flashing process is complete, a verification is performed. If the verification passes, the valid flag of the bootloader partition is set to valid, its program version number is updated, and the BMS system is reset.

[0078] If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the program version of the bootloader partition whose current bootloader partition type is runnable;

[0079] The process of writing the program code corresponding to the application partition currently designated as the pre-flash type from the integrated upgrade file to the partition also includes:

[0080] After the flashing is completed, a verification is performed. If the verification passes, the valid flag of the application partition is set to valid, its program version number is updated, and the BMS system is reset.

[0081] If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the application version of the application partition whose current application partition type is runnable.

[0082] This invention, upon entering the first bootloader area during system startup, first checks the validity flags of each bootloader partition and arbitrates them based on the program version number, prioritizing partitions with higher versions and valid flags as runnable types. The remaining partition is designated as a pre-flash area, ensuring the system always boots from a known, reliable bootloader. Building upon this, the same validity checks and version comparison logic are further applied to application partitions, achieving collaborative management of the bootloader and applications. This mechanism avoids startup failures caused by flashing interruptions or flag misalignment, enhancing the system's self-recovery capability under complex conditions, and is particularly suitable for scenarios involving frequent OTA upgrades or remote maintenance.

[0083] The verification specifically involves:

[0084] The verification specifically involves performing CRC or hash checks on the program code in the bootloader partition or application partition after the write operation is completed, in order to verify the integrity and correctness of the data.

[0085] This invention introduces a verification mechanism (such as CRC check or hash check) after the program is written to verify the integrity of the program code written to the target partition. If the verification passes, the valid flag of the partition is set to valid, its program version number is updated, and then a system reset is triggered to activate the new version. If the verification fails, no flag is modified, and a system reset is directly triggered, allowing the BMS to resume running the original executable program version. This mechanism achieves closed-loop verification of the write result, preventing invalid writes caused by data corruption, communication interference, or storage anomalies. It ensures that the system only switches the running version when the program is complete and reliable, greatly improving the reliability of software updates and system stability.

[0086] It's important to note that current advanced flashing methods typically employ a dual-zone backup structure. The Flash memory is divided into two equally sized application storage areas (Zone A and Zone B), both used to store application code. However, only one zone's program is marked as valid at any given time, identified by a validity flag. During system startup, the BootLoader uses the flag to determine which zone's application is valid and jumps to that zone for execution. During software updates, the new version is written to the currently invalid partition (e.g., if running A, it upgrades B), then the original valid partition is erased and the flag state is switched, achieving version switching. While this method avoids duplicate data copying, it still presents significant management complexity: it requires explicit control over whether the system is currently in "running A and upgrading B" or "running B and upgrading A" mode; external flashing devices need to dynamically sense the running partition status and accurately specify the target flashing partition, increasing the burden on communication protocols and control logic.

[0087] The essence of the above solution is "single-sided operation, opposite-sided upgrade," and its core pain point lies in the fact that the correct execution of the flashing operation highly depends on the accurate perception and proactive intervention of the external system regarding the current operating status. That is, before initiating an upgrade, the external system must clearly know whether the BMS is currently running an application in partition A or partition B in order to send the new version of the program to the corresponding non-running partition (e.g., flashing B if A is running). This mechanism requires strict state synchronization between the BMS and the host computer, increasing the complexity of the communication protocol. If anomalies such as delayed status reporting, misordered instructions, or network interruptions occur, the external system may write the program to the running partition, leading to code corruption or system malfunction. This risk is particularly pronounced in remote OTA upgrade scenarios. Furthermore, because partitions A and B have different physical addresses, the two programs need to be compiled and generated separately, further increasing the complexity of software release and version management.

[0088] This invention effectively solves the aforementioned upgrade management challenges through a novel collaborative flashing architecture. Specifically, the invention designs both the bootloader and the application program as independent dual-physical partition structures and introduces a dynamic arbitration mechanism for "runnable type" and "prepared flashing type." During the flashing process, the external system does not need to concern itself with which partition is currently running; instead, it distributes the integrated upgrade file containing adaptation code for both partitions at once. The bootloader within the BMS system sets the type of the application partition based on the valid flag status and program version number, thereby identifying the application partition currently in the "prepared flashing type" and selecting the corresponding program code from the integrated upgrade file for writing. Since the selection of the target partition is decided autonomously by the BMS and is entirely based on the local state arbitration result, the external system does not need to dynamically determine the running status or specify the flashing target, completely eliminating the dependence of the flashing operation on external management logic, significantly simplifying the upgrade process, and improving the automation and reliability of the flashing process.

[0089] This invention divides the BMS storage area into a first bootloader area, two independent bootloader partitions, and two independent application partitions. Each partition is assigned a valid flag and a program version number. Combined with a partition type arbitration mechanism and the status judgment of the program write flag, a complete process from system startup, partition selection, and write control is constructed. This solution achieves independent dual-backup management of the bootloader and applications. In the event of any write failure or program anomaly, a stable, working version is always retained. This effectively solves the technical problems of system paralysis due to write failure, lack of rollback mechanism, and irreversible upgrade process in traditional single-partition or single-sided dual-backup architectures (i.e., only the application area uses a dual-partition backup mechanism, while the bootloader still uses a single-partition storage structure). It significantly improves the reliability, security, and fault tolerance of BMS software updates.

[0090] To address the technical problems of low reliability, poor fault tolerance, imperfect rollback mechanisms, and imprecise partition management and status judgment logic in existing BMS systems during software flashing, such as... Figure 2 As shown, this embodiment of the invention also proposes a dual-partition BMS system bootloader and application collaborative flashing system. The BMS system storage area includes a first bootloader area, a first bootloader partition, and a second bootloader partition, as well as a first application partition and a second application partition. Each bootloader partition and application partition is provided with a valid flag bit and a program version number to indicate the validity of its program. The BMS software flashing system includes:

[0091] The bootloader execution module is used to enter the first bootloader area after the BMS system starts up, and set the bootloader partition types corresponding to the first bootloader partition and the second bootloader partition respectively according to the valid flag bits and program version numbers of each bootloader partition; the bootloader partition types include runnable type and pre-flashable type; jump to the runnable bootloader partition for execution;

[0092] The application partition type setting module is used to set the application partition type corresponding to the first application partition and the second application partition respectively according to the valid flag bit status and program version number of the first application partition and the second application partition; the application partition type includes runnable type and pre-flashable type.

[0093] The program flashing flag detection module is used to detect the status of the program flashing flag. If the program flashing flag is valid, proceed to the next step; if invalid, jump to the runnable application partition to execute the main control program.

[0094] The flashing module is used to enter the program flashing mode: it receives the integrated upgrade file sent by the external system; based on the type identification information of the integrated upgrade file, it determines whether the target of this upgrade is a bootloader upgrade or an application upgrade; if it is a bootloader upgrade, it writes the program code corresponding to the bootloader partition in the integrated upgrade file that is currently the type to be flashed into that partition; if it is an application upgrade, it writes the program code corresponding to the application partition in the integrated upgrade file that is currently the type to be flashed into that partition.

[0095] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method of this invention.

[0096] The present invention also provides a non-transitory machine-readable medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform the method of the present invention.

[0097] This invention also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform the method of this invention.

[0098] refer to Figure 3The present invention will now describe a structural block diagram of an electronic device that can serve as a server or client in embodiments of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0099] like Figure 3 As shown, the electronic device includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the electronic device. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0100] Multiple components in the electronic device are connected to I / O interface 405, including: input unit 406, output unit 407, storage unit 408, and communication unit 409. Input unit 406 can be any type of device capable of inputting information into the electronic device. Input unit 406 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 408 may include, but is not limited to, disks and optical discs. Communication unit 409 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0101] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the methods and processes described above. For example, in some embodiments, the method embodiments of the present invention can be implemented as a computer program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 402 and / or communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0102] Computer programs for implementing the methods of embodiments of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0103] In the context of embodiments of the present invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable signal medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0104] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

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

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

[0107] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

Claims

1. A BMS system double-partition cooperative flashing method, characterized in that, The storage area of the BMS system comprises a first boot program area, first and second boot program partitions, and first and second application program partitions; each boot program partition and application program partition is provided with a valid flag bit and a program version number for indicating the validity of the program thereof; the BMS system dual-partition cooperative flashing method comprises the following steps: S1: after the BMS system is started, the first boot program area is entered, and the first and second boot program partitions are set to correspond to the boot program partition types according to the valid flag bits and the program version numbers of the boot program partitions; The boot program partition types comprise a runnable type and a preparatory flashing type; Jump to the boot program partition of the runnable type for execution; S2: the first and second application program partitions are set to correspond to the application program partition types according to the valid flag bit states and the program version numbers of the first and second application program partitions; the application program partition types comprise a runnable type and a preparatory flashing type; S3: the state of the program flashing flag bit is detected, if the program flashing flag bit is valid, the next step is entered; If invalid, jump to the application program partition of the runnable type for execution of the main control program; S4: enter the program flashing mode: receive the integrated upgrade file sent by the external system; determine whether the upgrade target of this time is a boot program upgrade or an application program upgrade according to the type identification information of the integrated upgrade file; If it is a boot program upgrade, write the program code corresponding to the boot program partition currently in the preparatory flashing type in the integrated upgrade file into the partition; if it is an application program upgrade, write the program code corresponding to the application program partition currently in the preparatory flashing type in the integrated upgrade file into the partition.

2. The method of claim 1, wherein the BMS system dual-zone cooperative flashing method is characterized in that, The integrated upgrade file comprises first and second boot program codes adapted to the first and second boot program partitions, wherein the physical address in the first boot program code points to the first boot program partition, and the physical address in the second boot program code points to the second boot program partition; or the integrated upgrade file comprises first and second application program codes adapted to the first and second application program partitions, wherein the physical address in the first application program code points to the first application program partition, and the physical address in the second application program code points to the second application program partition.

3. The method of claim 1, wherein, The first and second boot program partitions are set to correspond to the boot program partition types according to the valid flag bits and the program version numbers of the boot program partitions; Specifically: read the valid flag bits corresponding to the first and second boot program partitions; If only the valid flag bit of the first boot program partition is valid, set the first boot program partition to the runnable type and the second boot program partition to the preparatory flashing type; If only the valid flag bit of the second boot program partition is valid, set the second boot program partition to the runnable type and the first boot program partition to the preparatory flashing type; If the valid flag bits of the first boot program partition and the second boot program partition are both valid, the program version numbers of the two are compared, the boot program partition with the higher version number is set as the runnable type, and the boot program partition with the lower version number is set as the preparation writing type.

4. The method of claim 1, wherein, The application program partition types corresponding to the first application program partition and the second application program partition are set according to the valid flag bit states and the program version numbers of the first application program partition and the second application program partition, and specifically: The valid flag bits corresponding to the first application program partition and the second application program partition are read; If only the first application program partition is valid, the first application program partition is set as the runnable type, and the second application program partition is set as the preparation writing type; If only the second application program partition is valid, the second application program partition is set as the runnable type, and the first application program partition is set as the preparation writing type; If both are valid, the program version numbers of the two are compared, the application program partition with the higher version number is set as the runnable type, and the application program partition with the lower version number is set as the preparation writing type.

5. The method of claim 1, wherein, The program writing flag bit is set as valid based on a reprogramming request sent by an external system.

6. The method of claim 1, wherein, The program code corresponding to the current boot program partition of the preparation writing type in the integrated upgrade file is written into the partition, and then the method further includes: After the writing is completed, verification is performed, if the verification passes, the valid flag bit of the boot program partition is set as valid, the program version number is updated, and the BMS system is reset; If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the program version of the boot program partition of the current boot program partition type as the runnable type; The program code corresponding to the current application program partition of the preparation writing type in the integrated upgrade file is written into the partition, and then the method further includes: After the writing is completed, verification is performed, if the verification passes, the valid flag bit of the application program partition is set as valid, the program version number is updated, and the BMS system is reset; If the verification fails, a rollback operation is triggered: the BMS system is reset to continue running the program version of the application program partition of the current application program partition type as the runnable type.

7. The method of claim 6, wherein the BMS system dual-zone cooperative flashing method is characterized by, The verification specifically includes: The verification specifically includes: CRC verification or hash verification is performed on the program code in the boot program partition or the application program partition after the writing is completed, to verify the data integrity and correctness.

8. The method of claim 3, wherein the BMS system dual-zone cooperative flashing method is characterized by, If the valid flag bits of the first boot program partition and the second boot program partition are both valid, and a forced rollback instruction is received, the boot program partition with the lower program version number is set as the runnable type, and the boot program partition with the higher program version number is set as the preparation writing type.

9. The method of claim 4, wherein, If the valid flag bits of the first application program partition and the second application program partition are both valid, and a forced rollback instruction is received, the application program partition with the lower program version number is set as the runnable type, and the application program partition with the higher program version number is set as the preparation writing type.

10. A BMS system double-partition cooperative flashing system characterized in that, The storage area of the BMS system comprises a first boot program area, first and second boot program partitions, and first and second application program partitions; each boot program partition and application program partition is provided with a valid flag bit and a program version number for indicating the validity of the program thereof; the BMS system dual-partition cooperative flashing system comprises: a boot program execution module for, after the BMS system is started, entering the first boot program area, setting the first and second boot program partition types corresponding to the first and second boot program partitions respectively according to the valid flag bits and the program version numbers of the boot program partitions; the boot program partition types comprise a runnable type and a preparatory flashing type; and jumping to the executable boot program partition for execution; an application program partition type setting module for setting the first and second application program partition types corresponding to the first and second application program partitions respectively according to the valid flag bit states and the program version numbers of the first and second application program partitions; the application program partition types comprise a runnable type and a preparatory flashing type; a program flashing flag bit detection module for detecting the state of the program flashing flag bit; if the program flashing flag bit is valid, the next step is entered; if the program flashing flag bit is invalid, the executable application program partition is jumped to for execution of the main control program; a flashing module for entering a program flashing mode: receiving an integrated upgrade file sent by an external system; determining whether the target of this upgrade is a boot program upgrade or an application program upgrade according to the type identification information of the integrated upgrade file; if it is a boot program upgrade, writing the program code corresponding to the boot program partition currently in the preparatory flashing type in the integrated upgrade file into the partition; if it is an application program upgrade, writing the program code corresponding to the application program partition currently in the preparatory flashing type in the integrated upgrade file into the partition.

11. An electronic device comprising: A processor and a memory storing a program, characterized in that the program comprises instructions which, when executed by the processor, cause the processor to perform a BMS system dual-partition cooperative flashing method according to any one of claims 1 to 9.

Images