Updating method and device of battery control unit software, equipment and storage medium

Abstract

The invention discloses a battery control unit software updating method, device and equipment and a storage medium, and relates to the technical field of battery management systems.The battery control unit software updating method comprises the steps that an embedded multimedia card is initialized, and the embedded multimedia card comprises a first partition and a second partition; performing cyclic redundancy check on the first partition, and determining application firmware with a preset starting priority; performing cyclic redundancy check on the second partition to obtain a target check result; and when the target verification result is successful, covering the application program firmware with the preset starting priority by using OTA firmware to complete updating of the battery control unit software. According to the method and the device, the software can be effectively prevented from being mistakenly erased and written in the software running and updating process of the battery control unit, stable running of the system is ensured, meanwhile, the performance and the safety of equipment are improved, the fault risk in the updating process is reduced, and the reliability of the whole system is ensured.

Description

Technical Field

[0001] The present application relates to the technical field of battery management systems, and in particular to a method, device, equipment and storage medium for updating battery control unit software. Background Art

[0002] In modern battery management systems (BMS), the software update of the Battery Control Unit (BCU) is crucial. With the popularity of electric vehicles and energy storage systems, the demand for battery performance optimization and fault repair is increasing. Therefore, developing an efficient and secure BCU software update method that can ensure that potential errors are avoided during the software update process is the key to improving the reliability of battery management systems.

[0003] Current technical solutions usually rely on external storage media, such as QuadSerial Peripheral Interface Flash Memory (QSPI FLASH), to store the BCU software code. The address space of these storage media is divided into different areas, which are used to store bootloaders (BootLoader), application code (APP), and OTA (Over-the-Air) code and running data. This approach allows flexible code management in different storage areas, while loading the required applications through the BootLoader to ensure that the device can correctly access the required functions when it starts.

[0004] However, since the address space of the storage medium is continuous, incorrect address access may lead to accidental erasure of the bootloader or application code, which not only affects the device's bootability but may also cause the application's functionality to fail. Therefore, how to avoid software erroneous erasure during the operation and update of the battery control unit software has become an urgent problem to be solved.

[0005] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0006] The purpose of the present application is to provide a method, device, equipment and storage medium for updating battery control unit software, aiming to solve the technical problem of how to avoid software erroneous erasure during the operation and update of the battery control unit software.

[0007] To achieve the above objectives, the present application proposes a method for updating battery control unit software, the method comprising:

[0008] Initializing an embedded multimedia card, the embedded multimedia card comprising a first partition and a second partition;

[0009] Performing a cyclic redundancy check on the first partition to determine a preset boot priority application firmware;

[0010] Performing the cyclic redundancy check on the second partition to obtain a target check result;

[0011] When the target verification result is passed, the preset boot priority application firmware is overwritten with OTA firmware to complete the update of the battery control unit software.

[0012] In one embodiment, the step of performing a cyclic redundancy check on the first partition to determine the preset boot priority application firmware includes:

[0013] Sending a first partition switching instruction to the embedded multimedia card so that the embedded multimedia card switches partition to the first partition, where the first partition stores a first application firmware and a second application firmware;

[0014] Performing a cyclic redundancy check on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain a first validity and a first startup priority of the first application firmware and a second validity and a second startup priority of the second application firmware;

[0015] When the first boot priority is greater than the second boot priority, or when the first validity is valid and the second validity is invalid, marking the second application firmware as a preset boot priority application firmware;

[0016] When the first boot priority is less than or equal to the second boot priority, or when the first validity is invalid and the second validity is valid, the first application firmware is marked as the preset boot priority application firmware.

[0017] In one embodiment, when the target verification result is passed, the step of using the OTA firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software includes:

[0018] When the target verification result is passed, sending a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches the partition to the first partition;

[0019] The OTA firmware is used to overwrite the preset boot priority application firmware, and the first boot priority and the second boot priority are exchanged to complete the update of the battery control unit software.

[0020] In one embodiment, the step of performing the cyclic redundancy check on the second partition to obtain a target check result includes:

[0021] Sending a second partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches partition to the second partition, where the second partition stores OTA firmware;

[0022] Performing the cyclic redundancy check on the third file parameter information of the OTA firmware to obtain a first check result;

[0023] When the first verification result is failed, taking the first verification result as the target verification result;

[0024] When the first verification result is passed, loading the OTA firmware into the memory inside the single-chip microcomputer;

[0025] Performing the cyclic redundancy check on the OTA firmware in the memory to obtain a second check result;

[0026] The target verification result is obtained according to the second verification result.

[0027] In one embodiment, after the step of performing the cyclic redundancy check on the second partition to obtain a target check result, the method further includes:

[0028] When the target verification result is not passed, obtaining the upgraded firmware through the universal asynchronous receiver / transmitter upgrade task and the controller area network upgrade task;

[0029] The upgrade firmware is used to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

[0030] In one embodiment, when the target verification result is not passed, the step of obtaining the upgraded firmware through the universal asynchronous receiver and transmitter upgrade task and the controller area network upgrade task includes:

[0031] When the target verification result is not passed, sending a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches the partition to the first partition;

[0032] The upgraded firmware is obtained by completing the UART upgrade task or the CAN upgrade task.

[0033] In one embodiment, the step of using the upgrade firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software includes:

[0034] When the UART upgrade task or the CAN upgrade task is completed, using the upgrade firmware to overwrite the preset boot priority application firmware to obtain a third application firmware;

[0035] Get the count time of the communication timeout counter;

[0036] When the counting time is greater than a preset timeout time, performing the cyclic redundancy check on the third application firmware to obtain a third check result;

[0037] When the third verification result is passed, the third application firmware is started to complete the update of the battery control unit software.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a battery control unit software update device, the device comprising:

[0039] An initialization module, used for initializing an embedded multimedia card, wherein the embedded multimedia card includes a first partition and a second partition;

[0040] A first check module, configured to perform a cyclic redundancy check on the first partition to determine a preset startup priority application firmware;

[0041] A second verification module, used for performing the cyclic redundancy check on the second partition to obtain a target verification result;

[0042] The update module is used to use OTA firmware to overwrite the preset startup priority application firmware when the target verification result is passed, so as to complete the update of the battery control unit software.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a battery control unit software update device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the battery control unit software update method as described above.

[0044] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the battery control unit software update method as described above are implemented.

[0045] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the battery control unit software update method as described above.

[0046] One or more technical solutions proposed in this application have at least the following technical effects:

[0047] Initialize an embedded multimedia card, the embedded multimedia card includes a first partition and a second partition; perform a cyclic redundancy check on the first partition to determine the preset boot priority application firmware; perform the cyclic redundancy check on the second partition to obtain a target check result; when the target check result is passed, use the OTA firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software. First, initialize the embedded multimedia card to ensure that its first partition and second partition can work normally. The first partition is used to store the application firmware with the preset boot priority, and the second partition is used to store the OTA firmware and related data, laying a solid foundation for subsequent operations. Then, the system performs a cyclic redundancy check on the first partition to verify the integrity of the preset boot priority application firmware to ensure that it is not damaged and can start and run normally. This process effectively prevents system failures caused by firmware damage. When the first partition check result passes, the system further performs the same cyclic redundancy check on the second partition to obtain the target check result, ensure the validity of the OTA firmware, and avoid performance degradation and safety hazards caused by firmware problems. If the target check result is displayed as "passed", the system will use the verified OTA firmware to overwrite the preset boot priority application firmware in the first partition to complete the update of the battery control unit software. Through this series of operations, software erasure errors can be effectively avoided during the operation and update of the battery control unit software, ensuring stable system operation. At the same time, it improves the performance and safety of the equipment, reduces the risk of failure during the update process, and ensures the reliability of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0050] Figure 1A flowchart of a method for updating the battery control unit software according to an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of the partitions of an embedded multimedia card provided in Embodiment 1 of the method for updating the software of a battery control unit of the present application;

[0052] Figure 3 A flowchart diagram of a second embodiment of a method for updating the battery control unit software of the present application;

[0053] Figure 4 A schematic diagram of a simplified flow chart of a method for updating the battery control unit software provided in the second embodiment of the present application;

[0054] Figure 5 A schematic diagram of the module structure of a device for updating software of a battery control unit according to an embodiment of the present application;

[0055] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the battery control unit software update method in the embodiment of the present application.

[0056] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0057] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0058] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0059] With the widespread use of electric vehicles and energy storage systems, software updates for battery control units (BCUs) in battery management systems (BMSs) have become particularly important. In order to improve the reliability of the system, it is necessary to develop an update method that is both efficient and secure to avoid update errors. Currently, BCU software is usually stored on external storage media such as QSPI FLASH, which manages BootLoader, APP code, and OTA code through different partitions. Although this design provides flexible code management, the continuous address space may lead to erroneous address access, which in turn may accidentally erase critical code, affecting device startup and application functionality.

[0060] The main solution of the embodiment of the present application is: first initialize the embedded multimedia card (EMMC), then the system performs a CRC check on the application firmware to ensure the integrity of the firmware and prevent system failure. If the check passes, the system performs a CRC check on the OTA firmware and related data to confirm the validity of the OTA firmware. If the check passes, the system will use the OTA firmware to update the application firmware and complete the battery control unit (BCU) software update.

[0061] It should be noted that the execution subject of the embodiment of the present application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a battery management system, etc. The following takes the battery management system as an example to illustrate this embodiment and the following embodiments.

[0062] Based on this, the present application embodiment provides a method for updating the battery control unit software, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the method for updating the battery control unit software of the present application.

[0063] In this embodiment, the method for updating the battery control unit software includes steps S10 to S40:

[0064] Step S10, initializing an embedded multimedia card, wherein the embedded multimedia card includes a first partition and a second partition;

[0065] It should be noted that the Embedded Multi Media Card (EMMC) is an integrated non-volatile memory widely used in mobile devices and embedded systems. In this embodiment, EMMC is used to store different components of the battery control unit (BCU) software. There are 4 independent partitions inside the EMMC chip, namely boot area partition 1, boot area partition 2, RPMB area partition, and user data area. The 4 partitions use independent address spaces. When accessing different partitions, it is necessary to send a partition switching command to the EMMC controller. In this embodiment, the BootLoader code is placed in the boot area partition 1, the APP code is placed in the boot area partition 2 partition, and the OTA code and running data are placed in the user data area. Since in different partitions, the data of other partitions cannot be accessed by changing the access address, the BootLoader code and the APP code are very safe, and the probability of being accidentally accessed and erased is very low, which enables effective management between different operations and storage requirements.

[0066] Please refer to Figure 2 , Figure 2The embedded multimedia card partition diagram provided in the first embodiment of the update method of the battery control unit software of the present application shows in detail the internal partition structure of the embedded multimedia card (EMMC), in which each partition has its specific function and starting address. As can be seen from the figure, Boot Area Partition1 and Boot Area Partition2 both start from address 0x00000000. These two partitions are used to store BootLoader code and APP code, respectively, which are the basis for system startup and operation. Following closely is the RPMB Area Partition. Although its size is not shown in the figure, it is usually used to store encrypted data to ensure data security. The User Data Area is located in the extended user data area of ​​EMMC, and the starting address is also 0x00000000. Its size is variable and is the total size of the EMMC card minus 1. This area is used to store OTA code and operation data. The figure also mentions "Size as multiple of WPG", which means that the size of each partition is an integer multiple of the size of the erase page group (Write Page Group), which is a requirement in the EMMC design to ensure consistency and reliability when data is erased. In addition, the "Start Address" and "Size" columns in the figure refer to the starting address and size of each partition. The entire partition diagram clearly describes how the EMMC card enhances data security through independent partitions, especially when performing software updates and data storage, effectively avoiding interference between different types of data and potential data corruption risks.

[0067] The first partition refers to the area where the application firmware is stored, namely "boot area partition 2". In this embodiment, this partition is used to store the main application code (APP) and supports the storage of two copies of the APP code. This design ensures that in the event of a software update or failure, the system can still recover from another copy of the APP code, thereby enhancing the stability and reliability of the system. The second partition refers to the "user data area", which is used to store OTA (Over-the-Air) firmware updates and runtime data. OTA firmware allows the system to be remotely upgraded, repaired or enhanced in a timely manner, while the runtime data is used to save necessary status information during program execution. This partition structure ensures that the OTA code and runtime data will not conflict with the APP code during software updates, thereby improving the security and integrity of the data.

[0068] It is understandable that the embedded multimedia card (EMMC) is first initialized through system instructions to establish communication with the storage medium and ensure that its various partitions are in an available state. This initialization process includes identifying the four partitions inside the EMMC (boot area partition1, boot area partition2, RPMB area partition and userdata area), and the address space of each partition is set by the EMMC factory. During specific operations, the system runs the BootLoader code and loads the APP code from the boot area partition2 partition to the RAM inside the MCU. The APP code runs in the MCU's RAM. The boot area partition2 partition is not accessed during APP operation. The userdata area partition is accessed by default during APP operation, and when OTA updates are required, the update files in the user data area are directly operated, thereby improving the efficiency and security of data reading and writing, and reducing the potential risks caused by erroneous access. This series of operations provides a solid foundation for the stable operation and flexible function updates of the BCU.

[0069] Step S20, performing a cyclic redundancy check on the first partition to determine a preset startup priority application firmware;

[0070] It should be noted that cyclic redundancy check (CRC) is an algorithm used to detect errors that may occur during data transmission or storage. It generates a check code by performing specific mathematical operations on data blocks and calculates the check code again when reading data to verify the integrity and accuracy of the data.

[0071] The system will perform CRC calculation on the application firmware (APP code) stored in the first partition, and generate a fixed-length checksum to represent the data content of the firmware. Then, the system compares the checksum with the pre-calculated CRC value stored in the firmware information to determine whether the firmware is damaged or modified during the storage process. In this way, the system can verify the integrity and validity of the application firmware at startup, thereby ensuring that only firmware with undamaged data can be loaded and executed. The preset boot priority application firmware refers to the firmware with a lower boot priority among the two APP codes stored in boot area partition 2. In this solution, each APP code has a boot priority, and the system will select the APP code to be started first according to the set rules at startup. If the application firmware with a low boot priority is verified to be valid after CRC verification, the system will use it as a backup to ensure that the system can still operate normally when the high-priority application firmware is unavailable or has problems. This redundant design increases the reliability and fault tolerance of the system and ensures that the function can be quickly restored in the event of a failure.

[0072] It is understandable that the system first performs a cyclic redundancy check (CRC) on the application firmware in the first partition to ensure the integrity and accuracy of the data. Specifically, the system generates a checksum by calculating the firmware data and compares it with the preset CRC value stored in the firmware information to verify whether the firmware has not been damaged during the storage process. If the CRC check passes, the system will identify the application firmware with a preset boot priority, that is, the firmware with a lower boot priority. The purpose of this process is to ensure that when the high-priority application firmware is unavailable or fails, the low-boot priority application firmware can be safely and reliably used as a backup, thereby improving the stability and fault tolerance of the system and ensuring smooth startup and operation under various circumstances.

[0073] Step S30, performing the cyclic redundancy check on the second partition to obtain a target check result;

[0074] It should be noted that the target verification result refers to the verification result generated by calculating the cyclic redundancy check (CRC) on the data in the second partition (i.e., OTA firmware or running data) and the corresponding file parameter information, including pass and fail. This result is used to verify whether the data stored in the second partition maintains integrity and consistency during transmission or storage, and to verify relevant file information, such as validity, boot priority, etc. Specifically, the system compares the calculated verification result with the pre-stored verification value to confirm whether the OTA firmware and running data are not damaged when accessed. If the verification results are consistent, it means that the data is valid and can be safely used for subsequent operations; if they are inconsistent, it means that the data may be erroneous or damaged, and appropriate measures need to be taken to deal with it.

[0075] It is understandable that the system performs a cyclic redundancy check (CRC) on the data in the second partition (including OTA firmware and running data) and the corresponding file parameter information to ensure the integrity and reliability of the data. Specifically, the system first reads the data stored in the second partition and applies a predetermined CRC algorithm for verification. After the verification is completed, the system compares the generated verification result with the previously stored preset value to determine the validity of the data. There are two states for the target verification result: if the verification result shows "pass", it means that there is no error in the data during storage and transmission, and it can be safely used for subsequent operations; if the verification result is "failed", it means that the data may be damaged or interfered with, and the system needs to take measures, such as re-downloading the OTA firmware or performing other troubleshooting, to ensure the stability and normal operation of the system.

[0076] As an example, the steps of performing the cyclic redundancy check on the second partition to obtain a target verification result include: sending a second partition switching instruction to the embedded multimedia card to switch the partition of the embedded multimedia card to the second partition, where the second partition stores the OTA firmware; performing the cyclic redundancy check on the third file parameter information of the OTA firmware to obtain a first verification result; when the first verification result is failed, using the first verification result as the target verification result; when the first verification result is passed, loading the OTA firmware into the memory inside the microcontroller; performing the cyclic redundancy check on the OTA firmware in the memory to obtain a second verification result; and obtaining the target verification result based on the second verification result.

[0077] The second switch partition instruction refers to a command sent by the system to the embedded multimedia card (EMMC) to switch its current access partition to the second partition. This instruction ensures that the system can access the OTA firmware stored in the partition for subsequent verification and loading operations. OTA firmware refers to firmware updated through Over-the-Air (OTA) technology and stored in the second partition. It usually contains improvements or fixes to system functions, allowing devices to download and install new firmware versions over the network without physical connection. The third file parameter information refers to metadata related to the OTA firmware, which usually includes information such as the firmware version number, file size, checksum, validity, and boot priority. This information is used to perform a cyclic redundancy check on the OTA firmware to ensure the integrity and consistency of the firmware during the loading process. The first verification result refers to the result obtained after performing a cyclic redundancy check on the OTA firmware in the second partition. The result has two states: "pass" or "fail". If the result is "fail", it means that the OTA firmware is damaged; if the result is "pass", it means that the firmware is complete and can continue to be loaded. A single-chip microcomputer refers to a microcontroller used in embedded systems. It integrates a processor, memory, and input and output interfaces. The single-chip microcomputer is responsible for executing programs stored inside it, including loading and running OTA firmware. Memory refers to the storage space inside the single-chip microcomputer for storing programs and data. In this step, the memory is used to temporarily store the loaded OTA firmware for further verification and execution. The second verification result refers to the result obtained after the OTA firmware is loaded into the internal memory of the single-chip microcomputer and a cyclic redundancy check is performed on it again. Similar to the first verification result, the second verification result also has a "pass" or "fail" status, which is used to confirm whether the OTA firmware stored in the memory is intact. Based on this result, the system determines the final target verification result.

[0078] The system first sends a second partition switching instruction to the embedded multimedia card (EMMC) to switch it to the second partition where the OTA firmware is stored. Subsequently, the system performs a cyclic redundancy check (CRC) on the third file parameter information of the OTA firmware, which includes the validity of the firmware, the boot priority and other metadata to ensure that the firmware is not damaged during storage and transmission. Based on the calculated first verification result, the system determines whether the firmware is valid: if the first verification result is "failed", it is used as the target verification result, indicating that there is a problem with the OTA firmware; if the first verification result is "passed", the system continues to load the OTA firmware into the memory inside the microcontroller. Then, the system performs a cyclic redundancy check on the OTA firmware in the memory again to obtain the second verification result. Finally, the target verification result is confirmed based on the second verification result to ensure that the OTA firmware loaded into the memory is complete and valid to ensure subsequent normal operation.

[0079] As an example, after performing the cyclic redundancy check on the second partition and obtaining the target check result, it also includes: when the target check result is failed, obtaining the upgrade firmware through the universal asynchronous receiver and transmitter upgrade task and the controller local area network upgrade task; using the upgrade firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

[0080] The Universal Asynchronous Receiver / Transmitter (UART) upgrade task refers to the process of firmware upgrade through the UART interface, which is a commonly used serial communication protocol for data transmission between devices. In this task, the system uses the UART interface to receive new upgrade firmware, usually by connecting to a computer or other device for data transmission. The advantage of the UART upgrade task is its simplicity and wide compatibility, making the firmware update process more flexible. The Controller Area Network (CAN) upgrade task refers to the process of firmware upgrade through the CAN protocol. CAN is a serial communication protocol used in vehicles and industrial automation systems, with strong anti-interference ability and good real-time performance. In this task, the system uses the CAN network to receive new upgrade firmware. Upgrading through CAN can support fast communication between multiple devices and is suitable for firmware updates in complex environments. Upgrade firmware refers to a new version of firmware provided to a device, which contains functional improvements, bug fixes, or security enhancements. It is a file used to replace the original preset boot priority application firmware. During the firmware upgrade process, the system will load the new upgrade firmware into the device to ensure that it can take advantage of the latest features and optimizations, thereby improving the performance and stability of the system.

[0081] After completing the cyclic redundancy check on the second partition, if the target check result is "failed", the system will start the firmware upgrade procedure. First, the system will receive the new upgrade firmware through two communication interfaces, the Universal Asynchronous Receiver / Transmitter (UART) and the Controller Area Network (CAN). UART is used for serial data transmission with external devices (such as computers), while CAN is used to quickly and securely transmit data in a local area network, which is particularly suitable for complex vehicles or industrial environments. The new upgrade firmware received contains the latest features and fixes, and is designed to replace the existing preset boot priority application firmware. The system will then overwrite the original firmware with the upgrade firmware to ensure that the battery control unit software is updated to improve its performance and stability and resolve previous problems. This process ensures that when a problem is found in the OTA firmware, the system can restore functionality through an effective upgrade method to ensure the normal operation of the device.

[0082] As an example, when the target verification result is failed, the steps of obtaining upgraded firmware through the universal asynchronous receiver and transmitter upgrade task and the controller local area network upgrade task include: when the target verification result is failed, sending a first partition switching instruction to the embedded multimedia card to switch the partition to the first partition; and obtaining the upgraded firmware by completing the universal asynchronous receiver and transmitter upgrade task or the controller local area network upgrade task.

[0083] The first partition switching instruction refers to a command sent by the system to the embedded multimedia card (EMMC) to switch the current access partition to the first partition. The first partition usually stores APP code or other important firmware and data, and can provide necessary support for the subsequent firmware upgrade process.

[0084] When the target verification result is "failed", the system will first send the first switching partition instruction to the embedded multimedia card (EMMC). The purpose of the instruction is to switch the current access partition of the EMMC to the first partition. In this partition, APP code or other key firmware is usually stored, which is crucial for subsequent firmware upgrades. After switching to the first partition, the system will receive the new upgrade firmware through either of two communication methods-universal asynchronous receiver-transmitter (UART) or controller area network (CAN). The UART connection is used for serial data transmission with external devices (such as computers), while CAN is suitable for fast and reliable data transmission in local area networks. Through one of these two methods, the system will download the latest upgrade firmware, which contains necessary functional improvements and bug fixes. This step ensures that when a problem with the OTA firmware is detected, the system can quickly switch to a safe partition and successfully obtain the new firmware, thereby effectively updating the battery control unit software and resuming normal operation.

[0085] Step S40: When the target verification result is passed, the upgrade firmware is used to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

[0086] It is understood that when the target verification result is "passed", the system will immediately apply the new upgrade firmware to the battery control unit to overwrite the low boot priority part of the original preset boot priority application firmware. This process first ensures the integrity and validity of the new firmware to avoid potential damage or errors affecting the normal operation of the device. The system will write the upgrade firmware to the designated storage area, especially the application firmware for low boot priority, to replace the old version of the firmware and ensure that the battery control unit can run the latest program. This update process not only includes copying the new firmware to the appropriate storage location, but also performs necessary checks and verifications to ensure that the startup and operation of the new firmware meet the design requirements. After the update is completed, the system usually restarts the battery control unit to load the new firmware to make it effective and optimize performance. Through this process, the device can obtain the latest features and fixes in a timely manner, improve the stability and security of the system, and ensure the efficient operation of the battery control unit.

[0087] As an example, the steps of using the upgrade firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software include: when the universal asynchronous receiver and transmitter upgrade task or the controller local area network upgrade task is completed, using the upgrade firmware to overwrite the preset boot priority application firmware to obtain a third application firmware; obtaining the counting time of the communication timeout counter; when the counting time is greater than the preset timeout time, performing the cyclic redundancy check on the third application firmware to obtain a third check result; when the third check result is passed, starting the third application firmware to complete the update of the battery control unit software.

[0088] The third application firmware refers to the new firmware generated after the upgrade firmware is used to overwrite the original low boot priority application firmware. The firmware contains updated functions and fixes, which can replace the old firmware to improve the performance and stability of the battery control unit. The communication timeout counter is a timer that monitors the data transmission status between the device and the communication interface (such as UART or CAN). When the system downloads or upgrades the firmware through these interfaces, the communication timeout counter will start timing to detect whether the data transmission is successfully completed within the predetermined time. The counting time refers to the length of time recorded by the communication timeout counter, which indicates the time elapsed from the start of data transmission to the current moment. The preset timeout time refers to the maximum allowed time limit set by the system when performing data transmission. For example, it is set to 60 seconds. If no feedback information is given during this period of time, the system will consider that a timeout has occurred and take corresponding measures, such as retrying or reporting an error or considering that the overwriting has been completed. The third verification result refers to the verification result obtained after performing a cyclic redundancy check on the overwritten third application firmware, indicating whether the firmware is complete and not damaged. If the verification result is passed, it means that the firmware is valid and can be safely started; if the verification result is failed, it means that there may be problems with the firmware and error handling or retry operations are required.

[0089] After completing the upgrade task of the Universal Asynchronous Receiver / Transmitter (UART) or Controller Area Network (CAN), the system will immediately use the downloaded upgrade firmware to overwrite the original low boot priority application firmware to generate a new third application firmware. Next, the system will start the communication timeout counter to record the time from the start of the upgrade task to the present, ensuring that the progress can be monitored in time during the data transmission process. If the counting time exceeds the preset timeout time (for example, 60 seconds), the system will consider that the upgrade firmware has been overwritten and will perform a cyclic redundancy check on the third application firmware to confirm the integrity of the firmware and generate a third verification result. If the verification result is displayed as "passed", it means that the new firmware is not damaged and can be safely started. The system will then load and start the third application firmware to complete the update of the battery control unit software and ensure that the device runs the latest functions and fixes. This series of steps ensures the efficiency and reliability of the firmware update process.

[0090] This embodiment provides a method for updating the software of a battery control unit, which initializes an embedded multimedia card, the embedded multimedia card including a first partition and a second partition; performs a cyclic redundancy check on the first partition to determine the preset boot priority application firmware; performs the cyclic redundancy check on the second partition to obtain a target check result; when the target check result is passed, the preset boot priority application firmware is overwritten with the OTA firmware to complete the update of the battery control unit software. First, the embedded multimedia card is initialized to ensure that its first partition and second partition can work normally. The first partition is used to store the application firmware with the preset boot priority, and the second partition is used to store the OTA firmware and related data, laying a solid foundation for subsequent operations. Then, the system performs a cyclic redundancy check on the first partition to verify the integrity of the preset boot priority application firmware to ensure that it is not damaged and can start and run normally. This process effectively prevents system failures caused by firmware damage. When the first partition check result passes, the system further performs the same cyclic redundancy check on the second partition to obtain the target check result, ensure the validity of the OTA firmware, and avoid performance degradation and safety hazards caused by firmware problems. If the target verification result is displayed as "passed", the system will use the verified OTA firmware to overwrite the preset boot priority application firmware in the first partition to complete the update of the battery control unit software. Through this series of operations, it is possible to effectively avoid software error erasure during the operation and update of the battery control unit software, ensure the stable operation of the system, improve the performance and safety of the equipment, reduce the risk of failure during the update process, and ensure the reliability of the overall system.

[0091] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 3 , Figure 3 This is a flow chart of a second embodiment of a method for updating the battery control unit software of the present application. Step S20 of the method for updating the battery control unit software includes steps S21 to S24:

[0092] Step S21, sending a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches partition to the first partition, where the first partition stores a first application firmware and a second application firmware;

[0093] It should be noted that the first partition switching instruction refers to a control signal or command sent to the embedded multimedia card (EMMC) to instruct the EMMC to switch to the specified first partition. This instruction ensures that the system can access and operate the data and firmware stored in the partition, thereby providing support for subsequent application loading and operation. The first application firmware refers to an application code stored in the first partition, which has a higher startup priority. It is usually the firmware that is loaded and run first when the battery control unit is started. The normal operation of this firmware is essential to the basic functions and performance of the system. The second application firmware refers to another application code that is also stored in the first partition, but its startup priority is lower than that of the first application firmware. This firmware usually exists as a backup or redundancy solution to ensure that when the first application firmware fails or fails, it can be switched and the normal operation of the system is guaranteed.

[0094] It is understandable that in this step, the system sends a first partition switching instruction to the embedded multimedia card (EMMC) in order to switch the working partition of the EMMC to the first partition. Two application firmwares are stored in this first partition: the first application firmware and the second application firmware. First, the process of sending instructions involves the controller communicating with the EMMC through a specific protocol to ensure that the instructions can be correctly received and executed. After switching to the first partition, the system can access the application firmware stored in the partition, and then decide which firmware should be loaded and executed. The first application firmware usually has a higher startup priority, which means that when the system starts, the firmware will be loaded and run first; and the second application firmware exists as a backup to deal with possible failures of the first application firmware. This process ensures that the system can flexibly respond to various situations during operation, thereby improving the stability and reliability of the battery control unit.

[0095] Step S22, performing a cyclic redundancy check on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain a first validity and a first boot priority of the first application firmware and a second validity and a second boot priority of the second application firmware;

[0096] It should be noted that the first validity refers to whether the firmware is complete, correct and can run normally after performing a cyclic redundancy check (CRC) on the file parameter information of the first application firmware. If the check passes, it means that the firmware is valid, indicating that its data has not been damaged or tampered with. The first boot priority refers to the priority loading level of the first application firmware when the system starts. Generally, the firmware with a higher boot priority will be loaded and run by the system first. The boot priority of the first application firmware determines whether it will be executed preferentially compared to other firmware. The second validity is similar to the first validity, which refers to judging the integrity and operability of the firmware after checking the file parameter information of the second application firmware. If the check passes, it indicates that the firmware can also be used normally. The second boot priority refers to the priority of the second application firmware when the system starts, which is usually lower than the first application firmware. When the first application firmware cannot work properly, the system will switch to the second application firmware with a lower boot priority to ensure that the system can continue to run.

[0097] It is understandable that first, the file parameter information of the first application firmware and the second application firmware is read from EMMC, and a cyclic redundancy check (CRC) is performed on the parameter information of the two firmwares. This verification process is used to detect the data integrity of each firmware to confirm whether there is a data error. By verifying the first application firmware, the system can determine whether it is valid (i.e., the first validity), and at the same time, according to the preset configuration (file information) of the firmware, determine the startup priority (i.e., the first startup priority) of the firmware. Then, the file parameter information of the second application firmware is verified in the same way to determine its validity (i.e., the second validity) and startup priority (i.e., the second startup priority). The purpose of this step is to ensure that the system can select the most suitable firmware for loading according to the verification results and the startup priority, thereby avoiding startup errors caused by firmware damage or priority confusion, and ensuring the stable operation of the battery control unit software.

[0098] Step S23, when the first boot priority is greater than the second boot priority, or when the first validity is valid and the second validity is invalid, marking the second application firmware as a preset boot priority application firmware;

[0099] It is understandable that the system first checks the startup priority and validity of the first application firmware and the second application firmware. If it is found that the first startup priority is greater than the second startup priority, it means that the first application firmware has a higher running priority, and the system will mark the second application firmware as the preset startup priority application firmware to provide backup support for it in the subsequent startup process. At the same time, the system will also consider another situation, that is, when the first application firmware is invalid and the second application firmware is valid, the system will also mark the second application firmware as the preset startup priority application firmware. The advantage of this is that even if the first firmware does not work properly for some reason, the system still retains the second firmware as a backup option, thereby ensuring that the battery control unit can quickly switch to the valid firmware when an abnormality occurs, ensuring the reliability and stability of the system.

[0100] Step S24: when the first boot priority is less than or equal to the second boot priority, or when the first validity is invalid and the second validity is valid, marking the first application firmware as the preset boot priority application firmware.

[0101] It is understandable that when it is found that the first boot priority is less than or equal to the second boot priority, it means that the running importance of the first application firmware is lower than or equal to the second application firmware. Therefore, the system marks the first application firmware as the preset boot priority application firmware. In addition, if the validity of the first application firmware is judged to be invalid, and the validity of the second application firmware is valid, this will also cause the first application firmware to be marked as the preset boot priority application firmware. Such processing logic ensures that the system can always select a valid and appropriately prioritized application firmware to start, thereby improving the reliability of the battery control unit and avoiding system failures caused by invalid firmware or improper priority. This marking mechanism provides a clear basis for subsequent firmware updates and recovery, and helps to quickly switch to valid applications when an abnormality occurs, thereby ensuring the normal operation of the system.

[0102] As an example, when the target verification result is passed, the OTA firmware is used to overwrite the preset boot priority application firmware, and the step of completing the update of the battery control unit software includes: when the target verification result is passed, a first partition switching instruction is sent to the embedded multimedia card to switch the partition of the embedded multimedia card to the first partition; the OTA firmware is used to overwrite the preset boot priority application firmware, and the first boot priority and the second boot priority are exchanged to complete the update of the battery control unit software.

[0103] In this step, the system first confirms that the target verification result is passed, which means that the integrity and validity of the OTA firmware are verified and meet the update requirements. Next, the system sends a first partition switching instruction to the embedded multimedia card to switch to the first partition storing the preset boot priority application firmware. This switch ensures that the system can access and update the currently running firmware. Subsequently, the system applies the OTA firmware to overwrite the existing preset boot priority application firmware to complete the update process of the battery control unit software. While updating, the system also swaps the first boot priority with the second boot priority. The significance of this operation is to promote the new firmware to the main boot program to ensure that it is executed first in subsequent operations. This method not only ensures the timely update and replacement of the software, but also optimizes the operating performance of the battery control unit by adjusting the boot priority, thereby improving the reliability and efficiency of the entire system.

[0104] This embodiment sends a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches the partition to the first partition, where the first application firmware and the second application firmware are stored; a cyclic redundancy check is performed on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain the first validity and the first boot priority of the first application firmware and the second validity and the second boot priority of the second application firmware; when the first boot priority is greater than the second boot priority, or when the first validity is valid and the second validity is invalid, the second application firmware is marked as the preset boot priority application firmware; when the first boot priority is less than or equal to the second boot priority, or when the first validity is invalid and the second validity is valid, the first application firmware is marked as the preset boot priority application firmware. First, the system sends a first partition switching instruction to the embedded multimedia card, so that it switches to the first partition, where the first application firmware and the second application firmware are stored, ensuring that the system can access the stored application firmware for subsequent verification and update. Next, a cyclic redundancy check is performed on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain their validity and boot priority. The purpose of this check step is to verify the integrity and reliability of the firmware to ensure that no errors occur when the software is running. This not only enhances the stability of the system, but also provides data support for the selection of firmware. After the validity and priority judgments are made, if the first boot priority is greater than the second boot priority, or the first validity is valid and the second validity is invalid, the system will mark the second application firmware as the preset boot priority application firmware. This decision ensures that more reliable or newer firmware versions are given priority when the firmware is updated and the system is started, enhancing the security of software operation. On the contrary, if the first boot priority is less than or equal to the second boot priority, or the first validity is invalid and the second validity is valid, the system will mark the first application firmware as the preset boot priority application firmware. This mechanism provides flexibility to adapt to different firmware states, so as to ensure that the system can quickly switch to the valid backup firmware when the firmware fails or fails, and further ensure the stable operation and reliable update of the battery control unit software. This dynamic firmware management mechanism greatly improves the reliability and adaptability of the system, ensuring that the system will not crash or perform poorly due to firmware problems during the battery management process.

[0105] For example, in order to help understand the implementation process of the battery control unit software update method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 4 , Figure 4 A brief flowchart of a method for updating the battery control unit software is provided, specifically:

[0106] The figure shows the process of BCU software update in the battery management system, including the process of firmware IAP update through UART or CAN communication interface. First, the system creates UART and CAN upgrade tasks and initializes the communication timeout counter. Then, the system loads the low-priority APP firmware and checks the validity of the OTA firmware. If the OTA firmware is valid, the system loads the OTA firmware into the RAM of the microcontroller and performs a CRC check. After the check passes, the system saves the OTA firmware to the low-priority APP firmware area and swaps the startup priority of the APP firmware. Then, the system starts the APP firmware. If the communication times out during the upgrade process, the system will execute the UART or CAN upgrade communication task and recheck the validity of the firmware after the timeout. If the firmware is invalid, the system will initialize the UART and CAN communication interfaces and wait for the In-Application Programming (IAP) upgrade command. If the IAP upgrade command is not received after the timeout counter expires, the system will run the APP startup code; if the APP code is successfully started, the APP code will be run, otherwise the BootLoader code will continue to run. The entire process can effectively avoid software erasure errors during the operation and update of the battery control unit software, ensuring the security and reliability of BCU software updates.

[0107] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the updating method of the battery control unit software of the present application. More simple transformations based on this technical concept are all within the protection scope of the present application.

[0108] This application also provides a battery control unit software update device, please refer to Figure 5 , the updating device of the battery control unit software comprises:

[0109] An initialization module 10, used to initialize an embedded multimedia card, wherein the embedded multimedia card includes a first partition and a second partition;

[0110] A first check module 20, configured to perform a cyclic redundancy check on the first partition to determine a preset startup priority application firmware;

[0111] A second verification module 30, configured to perform the cyclic redundancy check on the second partition to obtain a target verification result;

[0112] The update module 40 is used to use OTA firmware to overwrite the preset startup priority application firmware to complete the update of the battery control unit software when the target verification result is passed.

[0113] In one embodiment, the first verification module 20 is also used to send a first partition switching instruction to the embedded multimedia card so that the embedded multimedia card switches the partition to the first partition, where the first partition stores a first application firmware and a second application firmware; perform a cyclic redundancy check on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain the first validity and first boot priority of the first application firmware and the second validity and second boot priority of the second application firmware; when the first boot priority is greater than the second boot priority, or when the first validity is valid and the second validity is invalid, mark the second application firmware as the preset boot priority application firmware; when the first boot priority is less than or equal to the second boot priority, or when the first validity is invalid and the second validity is valid, mark the first application firmware as the preset boot priority application firmware.

[0114] In one embodiment, the update module 40 is also used to send a first partition switching instruction to the embedded multimedia card when the target verification result is passed, so that the embedded multimedia card switches the partition to the first partition; use the OTA firmware to overwrite the preset boot priority application firmware, and exchange the first boot priority and the second boot priority to complete the update of the battery control unit software.

[0115] In one embodiment, the second verification module 30 is also used to send a second partition switching instruction to the embedded multimedia card so that the embedded multimedia card switches the partition to the second partition, where the OTA firmware is stored; perform the cyclic redundancy check on the third file parameter information of the OTA firmware to obtain a first verification result; when the first verification result is not passed, use the first verification result as the target verification result; when the first verification result is passed, load the OTA firmware into the memory inside the single-chip microcomputer; perform the cyclic redundancy check on the OTA firmware in the memory to obtain a second verification result; and obtain the target verification result based on the second verification result.

[0116] In one embodiment, the update module 40 is also used to obtain upgrade firmware through a universal asynchronous receiver / transmitter upgrade task and a controller area network upgrade task when the target verification result fails; and use the upgrade firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

[0117] In one embodiment, the update module 40 is also used to send a first partition switching instruction to the embedded multimedia card when the target verification result fails, so that the embedded multimedia card switches the partition to the first partition; and obtain the upgraded firmware by completing the universal asynchronous receiver and transmitter upgrade task or the controller local area network upgrade task.

[0118] In one embodiment, the update module 40 is also used to, when the universal asynchronous receiver and transmitter upgrade task or the controller local area network upgrade task is completed, use the upgrade firmware to overwrite the preset startup priority application firmware to obtain a third application firmware; obtain the counting time of the communication timeout counter; when the counting time is greater than the preset timeout time, perform the cyclic redundancy check on the third application firmware to obtain a third check result; when the third check result is passed, start the third application firmware to complete the update of the battery control unit software.

[0119] The battery control unit software update device provided by the present application adopts the battery control unit software update method in the above embodiment, which can solve the technical problem of how to avoid software error erasure during the operation and update of the battery control unit software. Compared with the prior art, the beneficial effects of the battery control unit software update device provided by the present application are the same as the beneficial effects of the battery control unit software update method provided by the above embodiment, and the other technical features in the battery control unit software update device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0120] The present application provides a battery control unit software update device, the battery control unit software update device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the battery control unit software update method in the above-mentioned embodiment one.

[0121] Reference below Figure 6, which shows a schematic diagram of the structure of a battery control unit software update device suitable for implementing the embodiment of the present application. The battery control unit software update device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The battery control unit software update device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0122] like Figure 6 As shown, the update device of the battery control unit software may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the update device of the battery control unit software are also stored. The processing device 1001, the ROM 1002 and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the update device of the battery control unit software to communicate wirelessly or wired with other devices to exchange data. Although the figure shows an update device of the battery control unit software with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0123] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program firmware for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0124] The battery control unit software update device provided by the present application adopts the battery control unit software update method in the above embodiment, which can solve the technical problem of how to avoid software error erasure during the operation and update of the battery control unit software. Compared with the prior art, the beneficial effects of the battery control unit software update device provided by the present application are the same as the beneficial effects of the battery control unit software update method provided in the above embodiment, and the other technical features in the battery control unit software update device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0125] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0126] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0127] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the method for updating the battery control unit software in the above-mentioned embodiment.

[0128] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program firmware contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0129] The computer-readable storage medium may be included in the battery control unit software update device; or may exist independently without being assembled into the battery control unit software update device.

[0130] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the update device of the battery control unit software, the update device of the battery control unit software: initializes the embedded multimedia card, and the embedded multimedia card includes a first partition and a second partition; performs a cyclic redundancy check on the first partition to determine the preset boot priority application firmware; performs the cyclic redundancy check on the second partition to obtain a target verification result; when the target verification result is passed, uses OTA firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

[0131] Computer program firmware for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program firmware may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0132] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of firmware, and the module, program segment or a part of firmware contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0133] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0134] The readable storage medium provided in the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned method for updating the battery control unit software, and can solve the technical problem of how to avoid software error erasure during the operation and update of the battery control unit software. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the present application are the same as the beneficial effects of the method for updating the battery control unit software provided in the above-mentioned embodiment, and will not be repeated here.

[0135] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned battery control unit software update method when executed by a processor.

[0136] The computer program product provided by the present application can solve the technical problem of how to avoid software erroneous erasure during the operation and update of the battery control unit software. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the battery control unit software update method provided in the above embodiment, which will not be repeated here.

[0137] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for updating battery control unit software, characterized in that: The method comprises: Initializing an embedded multimedia card, the embedded multimedia card comprising a first partition and a second partition; Performing a cyclic redundancy check on the first partition to determine a preset boot priority application firmware; Performing the cyclic redundancy check on the second partition to obtain a target check result; When the target verification result is passed, the preset boot priority application firmware is overwritten with OTA firmware to complete the update of the battery control unit software.

2. The method according to claim 1, characterized in that The step of performing a cyclic redundancy check on the first partition to determine the preset startup priority application firmware includes: Sending a first partition switching instruction to the embedded multimedia card so that the embedded multimedia card switches partition to the first partition, where the first partition stores a first application firmware and a second application firmware; Performing a cyclic redundancy check on the first file parameter information of the first application firmware and the second file parameter information of the second application firmware to obtain a first validity and a first startup priority of the first application firmware and a second validity and a second startup priority of the second application firmware; When the first boot priority is greater than the second boot priority, or when the first validity is valid and the second validity is invalid, marking the second application firmware as a preset boot priority application firmware; When the first boot priority is less than or equal to the second boot priority, or when the first validity is invalid and the second validity is valid, the first application firmware is marked as the preset boot priority application firmware.

3. The method according to claim 2, characterized in that When the target verification result is passed, the step of using the OTA firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software includes: When the target verification result is passed, sending a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches the partition to the first partition; The OTA firmware is used to overwrite the preset boot priority application firmware, and the first boot priority and the second boot priority are exchanged to complete the update of the battery control unit software.

4. The method according to claim 1, characterized in that The step of performing the cyclic redundancy check on the second partition to obtain a target check result comprises: Sending a second partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches partition to the second partition, where the second partition stores OTA firmware; Performing the cyclic redundancy check on the third file parameter information of the OTA firmware to obtain a first check result; When the first verification result is failed, taking the first verification result as the target verification result; When the first verification result is passed, loading the OTA firmware into the memory inside the single-chip microcomputer; Performing the cyclic redundancy check on the OTA firmware in the memory to obtain a second check result; The target verification result is obtained according to the second verification result.

5. The method according to claim 1, characterized in that After the step of performing the cyclic redundancy check on the second partition to obtain a target check result, the method further includes: When the target verification result is not passed, obtaining the upgraded firmware through the universal asynchronous receiver / transmitter upgrade task and the controller area network upgrade task; The upgrade firmware is used to overwrite the preset boot priority application firmware to complete the update of the battery control unit software.

6. The method according to claim 5, characterized in that When the target verification result is not passed, the step of obtaining the upgraded firmware through the universal asynchronous receiver / transmitter upgrade task and the controller area network upgrade task comprises: When the target verification result is not passed, sending a first partition switching instruction to the embedded multimedia card, so that the embedded multimedia card switches the partition to the first partition; The upgraded firmware is obtained by completing the UART upgrade task or the CAN upgrade task.

7. The method according to claim 5, characterized in that The step of using the upgrade firmware to overwrite the preset boot priority application firmware to complete the update of the battery control unit software includes: When the UART upgrade task or the CAN upgrade task is completed, using the upgrade firmware to overwrite the preset boot priority application firmware to obtain a third application firmware; Get the count time of the communication timeout counter; When the counting time is greater than a preset timeout time, performing the cyclic redundancy check on the third application firmware to obtain a third check result; When the third verification result is passed, the third application firmware is started to complete the update of the battery control unit software.

8. A battery control unit software update device, characterized in that: The device comprises: An initialization module, used for initializing an embedded multimedia card, wherein the embedded multimedia card includes a first partition and a second partition; A first check module, configured to perform a cyclic redundancy check on the first partition to determine a preset startup priority application firmware; A second verification module, used for performing the cyclic redundancy check on the second partition to obtain a target verification result; The update module is used to use OTA firmware to overwrite the preset startup priority application firmware to complete the update of the battery control unit software when the target verification result is passed.

9. A battery control unit software update device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for updating the battery control unit software according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the method for updating the battery control unit software as described in any one of claims 1 to 7 are implemented.

Images