OTA upgrade method and electronic device

Abstract

The application discloses an OTA upgrading method and electronic equipment. The method comprises the following steps: when a waiting-receiving firmware flag is a first preset effective value, an authentication request frame is received; based on the authentication request frame and MCU unique serial number and IOT unique serial number, identity verification is performed on the IOT equipment, and an authentication response frame is returned to the IOT equipment; a version query frame is received, firmware metadata in the version query frame is verified, and a version reply frame is returned to the IOT equipment; firmware block data packets are received, each data packet in the firmware block data packets comprises a packet serial number, firmware data and a check value; the firmware data is sequentially written according to the packet serial number, and each data packet in each firmware block data packet is verified according to the check value; when each data packet in the firmware block data packets is verified and the overall firmware is verified, an OTA firmware upgrading operation is performed based on the firmware data. The application improves the safety and reliability of the OTA upgrading process, and reduces the cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of OTA upgrade, in particular to an OTA upgrade method and an electronic device. BACKGROUND

[0002] At present, the MCU-based intelligent terminal can update firmware remotely through an OTA (Over-The-Air) mode, so as to ensure function optimization and safety maintenance. However, the related OTA upgrade scheme generally has problems of low reliability and high cost: on the one hand, unstable communication link or insufficient verification mechanism can easily lead to firmware transmission error and device upgrade failure; on the other hand, in order to ensure upgrade safety, a large-capacity Flash with double-zone storage or multi-storage zones usually needs to be configured, thereby increasing hardware cost and system complexity. SUMMARY

[0003] An object of an embodiment of the present application is to provide an OTA upgrade method and an electronic device, so as to solve the technical problems of low reliability and high cost in the related art when performing OTA upgrade.

[0004] To solve the above technical problems, one technical scheme adopted by an embodiment of the present application is to provide an OTA upgrade method, applied to an MCU, wherein the MCU is connected with an IOT device, a storage space of the IOT device includes an APP receiving area of the MCU used for storing firmware information, and a storage space of the MCU includes a MCU storage information area, wherein the MCU storage information area stores a waiting-receiving-firmware flag, a unique serial number of the MCU, and a unique serial number of the IOT. The method comprises the following steps: when the waiting-receiving-firmware flag is a first preset valid value, receiving an authentication request frame sent by the IOT device; based on the authentication request frame and the unique serial number of the MCU and the unique serial number of the IOT, performing identity verification on the IOT device, and returning an authentication response frame to the IOT device, wherein the authentication response frame includes a verification result of identity matching of the IOT device; receiving a version query frame sent by the IOT device, verifying firmware metadata in the version query frame, and returning a version reply frame to the IOT device, wherein the version reply frame includes a verification result of passing the verification of the firmware metadata; receiving firmware block data packets sent by the IOT device, wherein each data packet in the firmware block data packets includes a packet serial number, firmware data, and a verification value; performing in-sequence writing on the firmware data according to the packet serial number, and verifying each data packet in each firmware block data packet according to the verification value; when each data packet in the firmware block data packets passes the verification, and the overall verification of the firmware passes, performing an OTA firmware upgrade operation based on the firmware data.

[0005] In some embodiments, the MCU further stores a check value of the current firmware and an IOT firmware backup request flag in the information area, and when the waiting-receive-firmware flag is not the first preset valid value, the method further comprises: judging whether the check value of the current firmware is a second preset valid value; if the check value of the current firmware is the second preset valid value, judging whether the IOT firmware backup request flag is a third preset valid value; and if the check value of the current firmware is not the second preset valid value, sending a firmware request to the IOT device, so that the IOT device sends an authentication request frame to the MCU after receiving the firmware request.

[0006] In some embodiments, when the IOT firmware backup request flag is not the third preset valid value, the method further comprises: jumping to the APP running area, running a main program and listening to an IOT instruction; based on the listened IOT instruction, detecting whether an MCU firmware receiving instruction initiated by the IOT device is received; and if the MCU firmware receiving instruction is received, setting the waiting-receive-firmware flag to the first preset valid value.

[0007] In some embodiments, the method further comprises: if the MCU firmware receiving instruction is not received, detecting whether a firmware backup request instruction requested by the IOT device is received; and if the firmware backup request instruction requested by the IOT device is received, setting the IOT firmware backup request flag to the third preset valid value.

[0008] In some embodiments, when the IOT firmware backup request flag is the third preset valid value, the method comprises: receiving a backup authentication request frame sent by the IOT device; based on the backup authentication request frame and the MCU unique serial number and the IOT unique serial number, performing identity verification on the IOT device, and returning a backup authentication response frame to the IOT device, the backup authentication response frame comprising a check result of identity matching of the IOT device; sending a backup version declaration frame to the IOT device, so that the IOT device checks the firmware metadata in the backup version declaration frame; when receiving a backup version confirmation frame returned by the IOT device, sending a firmware block data packet to the IOT device; wherein each data packet in the firmware block data packet comprises a packet serial number, firmware data and a check value, and the IOT device is used to write the firmware data to the APP receiving area of the MCU according to the packet serial number; the backup version confirmation frame is confirmation information returned by the IOT device when the firmware metadata check is passed.

[0009] In some embodiments, the method further comprises: sending an end instruction to the IOT device; the end instruction is used to make the IOT device calculate an overall check value of the firmware stored in the APP receiving area of the MCU, and compare the calculated overall check value with the check value in the backup version declaration frame, to detect whether the firmware backup is successful.

[0010] In some embodiments, the method further comprises setting a wait-receive firmware flag to an invalid value and recording new firmware information.

[0011] To solve the above technical problems, one of the technical solutions adopted by the embodiments of the present application is to provide an electronic device, comprising: a memory and a processor, the memory being connected to the processor, the processor being used to execute one or more computer programs stored in the memory, and the processor, when executing the one or more computer programs, causes the electronic device to implement an OTA upgrade method applied to an electronic device. The electronic device has the beneficial effects corresponding to the above-mentioned OTA upgrade method applied to an electronic device.

[0012] To solve the above technical problems, one of the technical solutions adopted by the embodiments of the present application is to provide a non-volatile computer readable storage medium, which stores computer executable instructions, when the computer executable instructions are executed by an electronic device, the electronic device executes the OTA upgrade method as described above.

[0013] To solve the above technical problems, one of the technical solutions adopted by the embodiments of the present application is to provide a computer program product, which comprises a computer program stored on a non-volatile computer readable storage medium, the computer program comprising program instructions, when the program instructions are executed by an electronic device, the electronic device executes the OTA upgrade method as described above.

[0014] In the embodiments of the present application, on the one hand, a controllable "wait-receive firmware flag" is set in the MCU to trigger the OTA upgrade process, and a bidirectional identity verification mechanism is introduced between the MCU and the IOT device to ensure that only authorized IOT devices can participate in the upgrade; in combination with firmware metadata verification, block data transmission and multi-level CRC verification (including data packet level and overall level verification), the situation of upgrade failure caused by communication abnormalities, data errors or firmware incompatibility is effectively reduced, thereby significantly improving the security and reliability of the OTA upgrade process. On the other hand, by multiplexing the storage space of the IOT device as the cache and transit area of the MCU firmware, block reception and relay transmission of the firmware are realized, without the need for additional configuration of a dedicated upgrade control module or independent storage chip, thereby simplifying system design, reducing material investment and maintenance overhead, and effectively reducing the overall implementation cost. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor under the premise of these drawings.

[0016] Figure 1 is a structural block diagram of an OTA upgrade system provided by an embodiment of the present application;

[0017] Figure 2 is a structural schematic diagram of an OTA upgrade system provided by an embodiment of the present application;

[0018] Figure 3 is a flowchart of an OTA upgrade method provided by an embodiment of the present application;

[0019] Figure 4 is a flowchart of an OTA upgrade method provided by another embodiment of the present application;

[0020] Figure 5 is a structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solutions and advantages of the present application more clear, the following will further describe the present application in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0022] It should be noted that, if there is no conflict, each feature in the embodiments of the present application can be combined with each other, and all within the scope of protection of the present application. In addition, although the functional modules are divided in the device schematic diagram, and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in different order than the module division in the device or the order in the flowchart. Furthermore, the "first", "second", "third" and the like used in the present application do not limit the data and execution order, and only distinguish the same items or similar items with basically the same function and effect.

[0023] It should be noted that, in each of the following embodiments, there is no certain order between the following steps, and those skilled in the art can understand that, according to the description of the embodiments of the present application, the execution order of the following steps in different embodiments can be different, that is, they can be executed in parallel, or exchanged, etc.

[0024] MCU firmware refers to a software program burned in the internal non-volatile memory (usually Flash) of an MCU (Microcontroller Unit) for implementing specific functions. For example, the MCU firmware in a power storage device is used to manage the charge and discharge logic of the battery, monitor the battery status (such as voltage, current, temperature), and implement protection functions (such as overvoltage, overcurrent, and overheat protection); the MCU firmware in an inverter is used to control DC-AC conversion and generate stable sinusoidal AC output. Among them, Bootloader is the first program to run after the system is powered on or reset, used for system initialization, firmware verification, version management, and firmware upgrade control (such as OTA upgrade logic). Application is the main program that implements the specific business functions of the device, which is started and run by Bootloader.

[0025] OTA (Over-The-Air) is a mechanism for remotely updating MCU firmware through a wireless communication network. This technology enables devices to download, verify, and write firmware versions without physical contact (such as using a connection programmer), thereby achieving remote maintenance and function upgrades. MCU firmware can be remotely upgraded through the OTA mechanism, i.e., without manual contact with the device (such as inserting a programmer or disassembling and burning), but through wireless or network communication, the device automatically downloads and updates the entire process of the MCU internal firmware, which can be referred to as OTA upgrade.

[0026] In the application design of MCU, two architecture schemes can be used to meet the needs of OTA upgrade: single application program (single APP) architecture and multi-application program (such as dual APP) architecture. These two architecture schemes are different underlying firmware architecture schemes provided for the purpose of OTA upgrade.

[0027] Single application program architecture refers to that the Flash of the MCU is only divided into one application program area, and all business logic and function codes are concentrated in this area. When performing OTA upgrade, the new firmware is downloaded to the device memory through a communication interface (such as UART, CAN, Wi-Fi, etc.), and is replaced with the original firmware using an overwriting burning method. If the upgrade process is suddenly interrupted by power failure or communication interruption, the MCU firmware will be damaged and the system will directly malfunction.

[0028] The multi-application architecture refers to that the Flash of the MCU is divided into two or more independent application areas, and each application area can independently store a complete application firmware image. When performing OTA upgrade, the currently running firmware (such as AppA) continues to work, the new firmware downloaded by OTA is written into the standby partition (such as App B), the Bootloader verifies the legality of the new firmware, and switches to start App B at the next restart. If the upgrade fails, it can be rolled back to APP A. The OTA upgrade process of this multi-application architecture is safe and reliable, but the occupied Flash capacity is larger, the Bootloader logic is more complex, and the hardware cost increases.

[0029] As can be known, whether it is a single-application architecture or a multi-application architecture, the new firmware is written into the Flash (non-volatile memory) of the MCU. That is, the essence of the current OTA upgrade is: download new firmware from the outside (cloud / gateway / module) -> MCU writes firmware data into internal Flash through Bootloader -> restart running new firmware.

[0030] However, the OTA upgrade process based on the single-application architecture may be interrupted (power off, offline) in the middle, and the firmware data in the Flash will be damaged; and the OTA upgrade process based on the multi-application architecture leads to an increase in implementation complexity and hardware cost. Therefore, the design of OTA upgrade needs to balance between system reliability and cost control.

[0031] In view of this, the embodiments of the present application provide an OTA upgrade system and an OTA upgrade method, which aims to realize remote and intelligent firmware upgrade through the cooperation of the cloud server, the mobile APP, the IOT device and the MCU. The cloud server stores and manages the latest MCU firmware, the mobile APP provides a user-friendly upgrade interface and communicates with the IOT device to send upgrade instructions. The IOT device is used to receive, store and manage firmware, and monitor the device state to ensure the stability and reliability during the firmware upgrade process. The MCU serves as the core control unit, performs control tasks, and interacts with the IOT device through a specific interface to complete the download, verification and update of the firmware.

[0032] The embodiment of the application adopts a single application architecture based on an MCU, and combines part of a Flash storage of an IOT device as a backup area of the MCU, so as to effectively control the cost while ensuring the reliability of the system. The greatest advantage of the single application architecture is simple and efficient firmware storage management, but there is a risk of interruption in the firmware update process, and the system is vulnerable to the risk of firmware damage leading to unavailability. To make up for this deficiency, the scheme of the embodiment utilizes the additional storage resources of the IOT device to divide part of the Flash space as a backup area of the MCU, and downloads and stores the new firmware to the backup area during OTA upgrade. In this way, even if an abnormality occurs in the upgrade process (such as power failure or communication interruption), the system can still roll back to the original firmware, avoiding the risk of firmware damage under the single application architecture.

[0033] Therefore, the scheme of the embodiment of the application not only improves the upgrade reliability of the system, but also effectively reduces the hardware cost, providing a sustainable solution for long-term operation and maintenance of the device.

[0034] Please refer to Figure 1 , Figure 1 is a structural block diagram of an OTA upgrade system provided by the embodiment of the application. The OTA upgrade system 100 includes a cloud server 10, a mobile phone APP 20, an IOT device 30, and an MCU 40.

[0035] The mobile phone APP 20 is in communication connection with the cloud server 10 through a network to obtain firmware information (such as firmware version, package size, update content, etc.) of the device. The mobile phone APP 20 is also in communication connection with the IOT device 30, such as through wireless protocols like Bluetooth, Wi-Fi, Bluetooth Mesh, Zigbee, etc. to communicate with the IOT device 30. The mobile phone APP 20 can send an “upgrade” instruction to the IOT device 30 to inform the device to perform firmware download and update operations, and can also obtain the upgrade status of the IOT device 30 (such as progress, success or failure, etc.). The IOT device 30 and the MCU 40 are in data interaction through a specific communication interface (such as SPI, UART, I2C, etc.), for example, the IOT device 30 is used to receive the firmware package and transmit it to the storage area of the MCU 40. After receiving the firmware package, the MCU 40 performs firmware writing, verification, upgrade, and startup through the Bootloader. The IOT device 30 can also be in communication connection with the cloud server 10, such as through HTTP, MQTT, WebSocket, etc. to perform bidirectional communication with the cloud server 10, and can upload the version information of the current MCU firmware to the cloud server 10; the cloud server 10 can feed back firmware update information to the IOT device 30 according to the state of the device; and the IOT device 30 can also download a new firmware package according to the instruction issued by the cloud server 10.

[0036] In this embodiment, the cloud server 10 is the core of the entire OTA upgrade system 100, which is used to manage and store firmware-related resources and information (such as version number, update content, file size, etc.). When the IOT device 30 requests for upgrade, the cloud server 10 provides the corresponding firmware package. The cloud server 10 can manage the firmware version information of each IOT device 30, ensuring that each IOT device 30 obtains the appropriate latest firmware. The cloud server 10 can be deployed on a data center or a cloud platform and communicates with other devices through the Internet.

[0037] The mobile phone APP 20 is an interface for users to interact with the IOT device 30, providing simple and intuitive upgrade control and progress monitoring. The mobile phone APP 20 converts the user's operation instructions into control signals executable by the IOT device 30 through wireless communication. The mobile phone APP 20 provides a user interface, which is a visual interface for firmware upgrade, showing the current firmware version of the IOT device 30, available firmware updates, upgrade progress and status, etc. The mobile phone APP 20 can also request and obtain the firmware version information, package size, update content, etc. of the IOT device 30 from the cloud server 10. When the user issues operation instructions such as "check for updates" or "upgrade immediately" through the user interface, the mobile phone APP 20 converts these instructions into a format that the system can understand and sends them to the IOT device 30 through wireless communication. In addition, the mobile phone APP 20 can synchronize the firmware upgrade progress, success or failure feedback information in real time through communication with the IOT device 30.

[0038] The IOT device 30 is mainly used to manage firmware download, storage and upgrade, etc. In this embodiment, the IOT device 30 is configured with a large-capacity Flash memory for storing MCU firmware. When the upgrade instruction is issued, the IOT device 30 receives and caches the new firmware package. In addition, the IOT device 30 can also integrate a state monitoring module inside, which can monitor the working state of the MCU and the system in real time, ensuring the stable operation of the system during firmware upgrade, and feeding back the device state to the cloud server 10 or the mobile phone APP 20. The IOT device 30 downloads the firmware package according to the instruction of the cloud server 10, and transmits the firmware to the MCU 40 through the communication interface (such as serial port UART, CAN bus) with the MCU 40 for upgrade.

[0039] MCU 40 is the core control unit of the entire system, responsible for performing the main control tasks of the device. In the energy storage system, MCU 40 is used for tasks such as battery management, energy scheduling, temperature monitoring, etc., which directly affects the normal operation of the device. In the OTA upgrade process, MCU 40 receives the firmware package transmitted from IOT device 30, writes the firmware data into the Flash memory using Bootloader, and completes the upgrade operation. In addition, the Bootloader inside MCU 40 monitors the status of the firmware to ensure that checksum and legality verification are completed during the firmware upgrade process. If the new firmware is successfully written, MCU 40 will start the new firmware; if it fails, it can roll back to the old version. Among them, MCU 40 and IOT device 30 exchange data through a communication interface (such as SPI, UART, I2C).

[0040] In the present OTA upgrade system 100, IOT device 30 refers to a hardware module with communication and storage functions, which is equipped with a network communication module (such as Wi-Fi, 4G / 5G, Bluetooth, etc.) and a larger Flash memory, and interacts with MCU 40 through a communication interface (such as UART or CAN). IOT device 30 and MCU 40 can belong to the same hardware device. For example, in the energy storage system, the battery is managed and controlled through MCU 40, and communicates with the external system (such as a cloud server or a mobile application) through IOT device 30 (such as 4G, 5G or Wi-Fi) to upload battery status data, perform remote monitoring and firmware upgrade. In such a system, IOT device 30 and MCU 40 are integrated on the same hardware platform, and together complete the functions of battery management, communication and upgrade.

[0041] In Figure 1 In the OTA upgrade system 100 shown, only the cloud server 10 is connected to a mobile APP 20 and an IOT device 30, which is connected to an MCU 40. It should be understood that IOT device 30 can also be in communication connection with cloud server 10. At the same time, the system supports communication and cooperation between multiple IOT devices 30 and multiple MCUs 40, so that the system can be flexibly expanded to adapt to large-scale devices and complex network environments. The communication relationship between multiple IOT devices 30 and multiple MCUs 40 can be one-to-one, one-to-many, or many-to-many configuration.

[0042] The working principle of the OTA upgrade system 100 is that the user initiates an upgrade request through the mobile phone APP 20, the mobile phone APP 20 communicates with the cloud server 10 to confirm whether there is a new firmware version that adapts to the current IOT device 30. If a usable firmware update is detected, the mobile phone APP 20 will display the relevant information to the user, and after the user confirms, the mobile phone APP 20 sends an upgrade instruction to the IOT device 30. The upgrade instruction is a control command generated by the mobile phone APP 20 after the user confirms the upgrade operation and sent to the IOT device 30, which is used to trigger the firmware update process of the device. After the IOT device 30 receives the upgrade instruction, it parses the content of the upgrade instruction and obtains the adapted latest firmware package from the cloud server 10, and stores it in its own Flash. Subsequently, the IOT device 30 transmits the firmware data to the MCU 40 through the communication interface such as serial port (UART) or CAN bus, and the MCU 40 uses Bootloader to perform firmware writing and system restart, thereby completing the upgrade process. In this process, the IOT device 30 is not only used for firmware transmission and storage, but also can monitor the upgrade status in real time and feed back the progress to the mobile phone APP 20 or the cloud server 10, ensuring the traceability and safety of the upgrade process. In addition, the IOT device 30 can directly communicate with the cloud server 10 in both directions, ensuring the synchronization of firmware package acquisition and device status, thereby realizing distributed and flexible firmware management and upgrade. Through effective hardware cooperation and communication mechanism, the system ensures the efficiency, reliability and scalability of OTA upgrade.

[0043] In order to ensure the safety of the above OTA upgrade process and the credibility of the communication between devices, the OTA upgrade system 100 also strictly plans the identity management and data storage structure of the device in the design stage. In the device factory stage, the host computer tool is used to fix the two-way identity certificate to the non-volatile storage area of the corresponding device during production programming, so as to realize the identity authentication and pairing verification mechanism in the subsequent upgrade process. Specifically, the MCU 40 writes its own unique serial number (SN_MCU) and the unique serial number (SN_IOT) of the IOT device 30 paired with it in its storage information area, while the IOT device 30 writes its own unique serial number (SN_IOT) and the unique serial number (SN_MCU) of the MCU 40 paired with it in its own storage information area. In this way, the two-way identity binding between the MCU 40 and the IOT device 30 is realized, so that in the system running and OTA upgrade process, any party can perform legality check according to the serial number, effectively preventing illegal devices from accessing, and ensuring the uniqueness and security of communication.

[0044] In the system structure design, the Flash storage space of the MCU 40 is divided into three main parts of BOOT program area, MCU storage information area and APP running area according to functions. Among them, the BOOT program area is used to store the boot program, has the characteristics of non-erasable, and is the basic area of system startup.

[0045] The MCU storage information area is used to save the identity information of itself and the paired IOT device 30, and record the key state parameters related to firmware upgrade. The area specifically includes the unique serial number of the MCU 40, the unique serial number of the bound IOT device 30, the waiting to receive firmware flag, the IOT request firmware backup flag, the version number of the APP firmware, the firmware size and the check value (such as CRC32) of the current firmware in the APP running area. Among them, the waiting to receive firmware flag is set to a preset valid value (such as 55) when the MCU 40 allows the IOT device 30 to transmit the firmware, and the IOT request firmware backup flag is set to another preset valid value (such as 66) when the MCU 40 allows to transmit the firmware backup to the IOT device 30. These flags and firmware information together constitute the core basis of MCU firmware management and upgrade control.

[0046] The APP running area stores the business logic code of the MCU 40, which is the running area of the core function of the MCU 40. In the OTA upgrade process, the new firmware program will be written to this area after passing the verification, realizing the system function update.

[0047] Similar to the MCU 40, the Flash of the IOT device 30 is also divided into multiple areas according to functions to ensure the stability of system running and the orderliness of data management. It includes: BOOT program area, IOT storage information area, its own APP running area, its own APP receiving area and MCU APP receiving area.

[0048] The BOOT program area is used to store the boot program, and this area is not erasable, ensuring that the IOT system can be safely started in any case. The IOT storage information area records the unique serial number of itself and the serial number of the paired MCU 40, and saves multiple key state information, including the MCU backup area flag, the version number of the backup firmware, the CRC32 check value, and the firmware size, etc. Through these information, the IOT device 30 can quickly judge the validity of the backup firmware when performing OTA upgrade or rollback operation. The self-APP running area is used to store the core business logic code of the IOT device 30, which is the main program area for normal operation of the device. The self-APP receiving area is used to temporarily store the downloaded firmware file during the OTA upgrade process, and then copy it to the self-APP running area after the integrity check is correct. The MCU's APP receiving area is used to receive and store the MCU firmware, which can be used as a temporary buffer area for the MCU firmware, and can also serve as a firmware backup storage area when necessary, providing support for fault-tolerant update and version rollback of the MCU 40.

[0049] Through the above factory identity certificate solidification mechanism and the fine partition design of the MCU 40 and the IOT device 30 Flash, the OTA upgrade system 100 can ensure security and reliability at each stage of the device life cycle. From factory identity authentication, firmware transmission to storage verification, the OTA upgrade system 100 realizes an end-to-end trusted communication mechanism. When power failure, abnormal interruption or firmware check failure occurs, the IOT device 30 can perform rollback or retransmission according to the state information in its Flash, thereby avoiding system failure caused by firmware damage. The design of this architecture not only improves the security and recoverability of the upgrade process, but also provides flexible expansion capability for remote upgrade management of large-scale devices.

[0050] In some embodiments, as Figure 2As shown, the mobile phone APP 20 runs on the mobile terminal device, and the IOT device 30 and the MCU 40 belong to the hardware components of the energy storage system. In this application scenario, the cloud server 10 is in communication connection with the mobile terminal device and the energy storage system respectively, and the mobile terminal device is in communication connection with the energy storage system. Among them, the cloud server 10 stores and manages the MCU firmware version information, and when a new version is detected to be available, it can initiate an upgrade through the mobile terminal device or directly notify the energy storage system; the mobile terminal device serves as a user interaction portal, runs the mobile phone APP 20, is used to display the current firmware version, receive the user's upgrade instruction, and establish a connection with the cloud server 10 and the energy storage system through wireless communication (such as Wi-Fi, Bluetooth or mobile network); the IOT device 30 inside the energy storage system is used to communicate with the cloud server 10, download and cache the latest firmware package, and then transmit the firmware data to the MCU 40 through a serial port (UART) or a CAN bus; the MCU 40 completes the writing, verification and system restart of the firmware according to the Bootloader program, thereby completing the OTA upgrade. During the whole process, the IOT device 30 also feeds back the upgrade status information to the mobile terminal device and the cloud server in real time, realizing remote, reliable and visualized firmware upgrade management of the energy storage system.

[0051] Please refer to Figure 3 , Figure 3 is a flowchart of an OTA upgrade method provided by the embodiment of the present application. The OTA upgrade method can be applied to the OTA upgrade system described above.

[0052] S1: The MCU is powered on.

[0053] S2: The program in the BOOT program area starts running.

[0054] S3: Information in the MCU storage information area is read, and the information includes a waiting-to-receive firmware flag, a verification value of the currently running firmware and an IOT-requested firmware backup flag.

[0055] S4: It is judged whether the waiting-to-receive estimation flag is a first preset valid value.

[0056] The first preset valid value is used to represent the state of "MCU allowing IOT to transmit firmware", that is, it indicates that the MCU is currently in a state of being able to receive firmware, and in a specific implementation, it can be set to a hexadecimal number 0x55 (or a decimal number 55).

[0057] If the waiting-to-receive estimation flag is the first preset valid value, the following step S5 is executed; if the waiting-to-receive estimation flag is not the first preset valid value, the following step S6 is executed.

[0058] S5: The process of IOT transmitting firmware to MCU is executed.

[0059] S6: judging whether the check value of the current running firmware is the second preset valid value.

[0060] The second preset valid value is used to check the integrity of the current running area firmware. Specifically, it can refer to the "CRC32 check value of APP firmware" saved in the MCU storage information area. The MCU calculates the CRC32 value (denoted as Crc cal ) of the current APP running area firmware, and compares it with the reference CRC32 value (i.e. the APP firmware CRC32 written last time, also known as the second preset valid value) recorded in the storage information area; if they are consistent, it is considered that the APP firmware is valid, otherwise it is considered that the firmware is damaged and requests the IOT to resend the firmware.

[0061] If the check value of the current running firmware is not the second preset valid value, step S7 is executed; if the check value of the current running firmware is the second preset valid value, step S8 is executed.

[0062] S7: requesting the IOT to send the firmware.

[0063] S8: judging whether the IOT request firmware backup flag is the third preset valid value.

[0064] The third preset valid value is used to indicate the firmware backup request state between the MCU and the IOT. When the IOT requests to obtain firmware backup from the MCU, the "IOT request firmware backup flag" in the MCU storage information area is set to the third preset valid value to represent that the request is in a valid state. In a specific embodiment, the third preset valid value can be the decimal value 66, indicating that the MCU allows or is executing the firmware backup transmission operation to the IOT.

[0065] If the IOT request firmware backup flag is the third preset valid value, step S9 is executed; if the IOT request firmware backup flag is not the third preset valid value, step S10 is executed.

[0066] In the embodiments of the present application, three types of preset valid values are defined, which are the first preset valid value, the second preset valid value and the third preset valid value. Based on the definition and cooperation of the three types of preset valid values, the system establishes a controllable and traceable upgrade and backup state channel between the MCU and the IOT device, making the OTA upgrade process more reliable and secure.

[0067] The first preset valid value is used to identify a state in which the MCU allows the IOT to transmit firmware thereto. When the MCU is in a standby state in which the firmware can be received, a "waiting for firmware reception flag" in a storage information area of the MCU is set to the first preset valid value (such as a decimal value 55). At this time, the IOT device can transmit a firmware data packet to the MCU through a communication interface (such as a UART or a CAN bus) to perform an upgrade write.

[0068] The second preset valid value is used to represent an integrity reference value of the firmware in the current APP running area. The value corresponds to an APP firmware CRC32 check value stored in the storage information area of the MCU. When the MCU is started or performs a self-check, the firmware in the current APP running area is read and a CRC32 value thereof is calculated. If the calculated value is consistent with the second preset valid value, it is indicated that the firmware is complete and valid. If the calculated value is inconsistent with the second preset valid value, it is indicated that the firmware is damaged, and the MCU will request the IOT to send the firmware for repair or recovery.

[0069] The third preset valid value is used to identify a state in which the IOT requests the MCU to transmit firmware backup thereto. When the IOT device needs to backup the firmware of the MCU, it sets an "IOT request firmware backup flag" in the storage information area of the MCU to the third preset valid value (such as a decimal value 66) through a control communication signal. At this time, the MCU starts a firmware uplink process, uploads the firmware in the APP running area thereof to an "MCU APP receiving area" of the IOT device, and realizes remote backup and version synchronization of the firmware.

[0070] S9: A process of transmitting the firmware from the MCU to the IOT is performed.

[0071] S10: Jumping to the APP running area, running a main program, and listening to an IOT instruction. The listening to the IOT instruction means that the MCU continuously listens to a communication message from the IOT device when the main program is running, and is used to determine whether to enter a firmware upgrade mode.

[0072] S11: Based on the listened IOT instruction, it is determined whether a MCU firmware reception instruction initiated by the IOT is received. The MCU firmware reception instruction is one of the above-mentioned IOT instructions, and is an instruction for triggering the MCU to enter a firmware reception (OTA upgrade) process. The MCU firmware reception instruction can include an identification field (such as a command code 0x01 or "OTA_START") for informing the MCU to prepare to receive new firmware.

[0073] If the MCU firmware reception instruction initiated by the IOT is received, step S12 is performed; if the MCU firmware reception instruction initiated by the IOT is not received, step S13 is performed.

[0074] S12: The MCU control system stops charging and discharging, sets the waiting-receiving-firmware flag to a first preset valid value, and jumps to step S2.

[0075] S13: It is judged whether the IOT-requested firmware backup request instruction is received.

[0076] The firmware backup request instruction is an instruction sent by the IOT device to the MCU for requesting the MCU to provide the current running firmware for backup. When the MCU receives the firmware backup request instruction, the current task running is stopped, the IOT-requested firmware backup flag is set to a third preset valid value, and the Boot area is jumped to prepare for transmitting the firmware.

[0077] If the IOT-requested firmware backup request instruction is received, step S14 is executed; if the IOT-requested firmware backup request instruction is not received, step S10 is executed.

[0078] S14: The MCU control system stops charging and discharging, sets the IOT-requested firmware backup flag to the third preset valid value, and jumps to step S2.

[0079] In the embodiment, the OTA process is a periodic listening and triggering mechanism. After the MCU completes firmware receiving upgrade or firmware uploading backup, the corresponding triggering flag is cleared and the system returns to the main program running state. When no new upgrade or backup request is detected, the system remains in the APP running area to continuously listen, thereby realizing a stable and cyclic OTA task management mechanism.

[0080] Step S5 is triggered when the “waiting-receiving-firmware flag” in the MCU storage information area is the first preset valid value, indicating that the MCU allows the IOT to transmit firmware thereto. Before the IOT transmits firmware to the MCU, a firmware transmission request phase is further included. The firmware transmission request phase includes: when the IOT device detects that the MCU firmware version stored in the Flash thereof is higher than the current running version of the MCU, the IOT device can actively send a firmware OTA request to the MCU; or, when the MCU receives an update instruction through a remote management platform (such as a mobile phone APP), the MCU can also actively initiate a firmware transmission request to the IOT. After the MCU receives the OTA request of the IOT (or after the MCU initiates the firmware transmission request), the MCU completes state verification without error, sets the “waiting-receiving-firmware flag” in the MCU storage information area to the first preset valid value (such as 55), indicating that the MCU has entered a receivable firmware state. At this time, after the IOT detects that the “waiting-receiving-firmware flag” of the MCU is the first preset valid value, the IOT starts transmitting firmware data to the MCU through a communication interface (such as UART, CAN bus), and the Bootloader module of the MCU is responsible for receiving, verifying and writing to the APP running area.

[0081] S5: executing the process of IOT transmitting firmware to MCU, specifically including:

[0082] S51: MCU receives the authentication request frame sent by IOT, and based on the authentication request frame and the unique serial number of MCU and the unique serial number of IOT bound thereto stored by itself, performs identity verification to determine that the IOT currently establishing connection is matched, and returns an authentication response frame to the IOT. The authentication response frame includes the verification result of identity matching of IOT.

[0083] Specifically, MCU receives the authentication request frame (i.e. message 1) sent by IOT, and the specific content of the message 1 includes IOT_SN (i.e. the unique serial number of IOT device, used to identify the specific device initiating authentication), MCU_SN (i.e. the unique serial number of target MCU, used to verify the target identity of communication), transmission direction (the field of current communication direction, such as 0x01, which represents IOT→MCU), and message CRC32 (32-bit cyclic redundancy code for integrity check of the whole frame data, used to detect errors in the transmission process). MCU performs identity verification based on the received message data, the unique serial number (SN_MCU) of itself in the storage information area and the unique serial number (SN_IOT) of IOT bound thereto, and executes the following verification logic: calculating and comparing the message CRC32, if the verification fails, discarding the message. If the IOT_SN in the message 1 does not match the pre-stored SN_IOT, the exception code can be set to 0x01 (indicating that the IOT identity does not match). If the MCU_SN in the message 1 does not match the pre-stored SN_MCU, the exception code is set to 0x02 (indicating that the MCU identity does not match).

[0084] If all the above verifications pass, the exception code can be set to 0x00, indicating that the identity verification is successful. Subsequently, MCU will construct an authentication response frame (i.e. message 2), and the specific content of the message 2 includes IOT_SN, MCU_SN, transmission direction, exception code and message CRC32, and sends it to IOT for feedback of the identity verification result.

[0085] This step ensures that only the matched IOT and MCU can establish a firmware transmission connection, providing a secure premise for subsequent firmware data transmission.

[0086] S52: MCU receives the version query frame (i.e. message 3) sent by IOT, verifies the firmware metadata in the version query frame, and returns a version reply frame to the IOT, which includes the verification result of passing the verification of firmware metadata.

[0087] The firmware metadata refers to data information used for describing basic attributes and integrity features of the firmware before formal transmission or upgrade of the firmware. The firmware metadata includes firmware version number, firmware size, CRC check value of the whole firmware, and the like, and does not include actual firmware code data. Specifically, the MCU receives a version query frame (message 3) sent by the IOT. The message 3 includes a firmware version number (Version_receive), a firmware CRC32 (CRC32_Firmware), a firmware size (Size_Firmware), and a message CRC32. The MCU first performs integrity check on the message CRC32. If the check fails, the version query frame is discarded. Then, it is checked whether the firmware size exceeds the maximum capacity of the APP running area of the MCU. If the size exceeds the maximum capacity, an exception code is set to 0x03 and fed back to the IOT.

[0088] If the above checks all pass, the MCU records the firmware version number, the firmware CRC32, and the firmware size in the message, and prepares for subsequent packet reception. Meanwhile, it also performs version legality check to determine whether the first four bits (hardware material number) of the Version_receive are consistent with the current hardware material number of the MCU. If the first four bits are consistent with the current hardware material number of the MCU, it means that the firmware is compatible with the hardware and can be upgraded. For example, the current version of the MCU is 1234.001, in which 1234 is the hardware material number, and the four digits do not change in the process of version iteration. The 001 is the software iteration number, which can be iteratively upgraded with the hardware.

[0089] After the check passes, the MCU constructs and sends a version reply frame (message 4) including IOT_SN, MCU_SN, exception code (0 for passing the check), and message CRC32, and feeds back the firmware information check result to the IOT, so as to provide legality confirmation for the formal firmware transmission stage.

[0090] S53: The MCU receives firmware block data packets sent by the IOT. Each data packet includes a packet sequence number, firmware data, and a check value.

[0091] The MCU processes the received block data packets as follows: when the packet sequence number is 1, the MCU erases the whole APP running area and writes the data in the packet to the starting position of the APP running area; when the packet sequence number is greater than 1, the MCU directly writes the data in the packet to the corresponding position without erasing again. In addition, the MCU also checks the received data packet. Specifically, CRC check can be performed. If the check is successful, an ACK (acknowledgement information) is replied, and the next data packet is continuously received. If the check fails, a NAK (retransmission request) is replied to request the IOT to retransmit the data packet. If the number of retransmissions of a single packet exceeds the preset maximum number of times, the MCU replies an exit upgrade instruction to terminate the OTA upgrade process, so as to ensure system safety and data reliability.

[0092] When the IOT receives the ACK instruction, the next firmware data packet is sent; when the IOT receives the NAK instruction, the current firmware data packet is re-sent; and when the IOT receives the exit upgrade instruction, the transmission is terminated.

[0093] This step ensures that each piece of chunk data is subjected to integrity verification and confirmation before being written into the APP running area of the MCU, thereby realizing the reliability of firmware transmission, chunk retransmission and abnormal safety exit mechanism.

[0094] S54: When receiving the firmware transmission completion instruction, the overall verification value of the received firmware is calculated, and the calculated overall verification value of the received firmware is compared with the CRC32 verification value stored in the MCU storage information area to detect whether they are consistent.

[0095] If consistent, it indicates that the firmware is correct and complete, and the following step S55 is executed. If inconsistent, it indicates that the verification fails, and the IOT needs to re-initiate the firmware upgrade process.

[0096] S55: The MCU sets the "waiting for received firmware flag" in the storage information area to an invalid value, and records the upgrade state and new firmware information this time.

[0097] The "waiting for received firmware flag" in the storage information area of the MCU is set to an invalid value, indicating that the MCU has completed firmware reception and no longer allows the IOT to transmit firmware to it.

[0098] Recording the upgrade state and new firmware information this time includes recording the new firmware version number, recording the overall CRC32 verification value of the new firmware, and recording the size of the new firmware.

[0099] This step ensures that the firmware state and version information are recorded persistently after the MCU completes the upgrade, providing a correct version reference for subsequent operation, and preventing repeated or incorrect firmware transmission.

[0100] The above step S7 is to request the IOT to send the firmware. If the MCU receives the transmission firmware instruction initiated by the IOT, step S5 can be executed, specifically, the above steps S51 to S55 are executed.

[0101] The above step S9 is the process of transmitting the firmware from the MCU to the IOT, which is triggered when the "IOT request firmware backup flag" in the MCU storage information area is the third preset valid value, indicating that the IOT device needs to obtain the current MCU firmware information. It is the entrance condition for the MCU to actively provide firmware backup to the IOT. The trigger condition is that the IOT detects that the MCU backup area flag in its storage information area is in an invalid state, indicating that the APP receiving area of the MCU of the IOT does not have a valid firmware backup. At this time, the IOT sends a MCU firmware request instruction to the MCU, which specifically includes:

[0102] S91: receiving the backup authentication request frame (i.e. message 5) sent by the IOT, and based on the backup authentication request frame and the MCU unique serial number and the unique serial number of the IOT bound thereto stored by itself, performing identity verification to determine that the IOT currently establishing the connection is matched, and returning a backup authentication response frame (i.e. message 6) to the IOT. The backup authentication response frame includes the verification result of the identity matching of the IOT.

[0103] This step is similar to the above step S51, and for details, reference can be made to step S51.

[0104] S92: sending a backup version declaration frame (i.e. message 7) to the IOT, the backup version declaration frame including firmware metadata, the firmware metadata including a firmware version number, a firmware CRC32, a firmware size and a message CRC32.

[0105] Before the formal transmission of the firmware, the MCU sends firmware metadata to the IOT, which is used to indicate the basic attributes and integrity information of the firmware to be transmitted. Through this step, the IOT can preliminarily verify the legality, version compatibility and data integrity of the firmware before receiving the actual firmware data, thereby avoiding receiving an incorrect version or incompatible firmware, and ensuring the effectiveness of subsequent block transmission and the safety of the system.

[0106] S93: when receiving the backup version confirmation frame (i.e. message 8) returned by the IOT, sending a firmware block data packet to the IOT, each data packet in the firmware block data packet including a packet serial number, firmware data and a verification value; the backup version confirmation frame is the confirmation information returned by the IOT when the firmware metadata verification is passed.

[0107] Among them, the MCU can send data packets in blocks of 1024 bytes. Among them, the IOT processes the received firmware block data packet as follows: when the packet serial number is 1, the IOT erases the entire APP receiving area of the MCU, and writes the data of the packet into the starting position of the APP receiving area of the MCU; when the packet serial number is greater than 1, the IOT directly writes the data of the packet into the corresponding position. In addition, the IOT also checks the received data packet, which can be specifically checked by CRC. If the check is successful, an ACK (confirmation information) is returned to the MCU, and the next data packet is continued to be received; if the check fails, a NAK (retransmission request) is returned to the MCU to request the MCU to retransmit the data packet. Among them, if the number of single packet retransmissions exceeds the preset maximum number of times, the IOT terminates the OTA upgrade process according to the exit upgrade instruction sent by the MCU, so as to ensure the system safety and data reliability.

[0108] S94: send an end instruction to the IOT. The end instruction is used to make the IOT calculate the overall CRC32 of the firmware stored in the APP receiving area of the MCU, and compare the calculated overall CRC32 with the CRC32 in the backup version declaration frame to detect whether the firmware backup is successful.

[0109] If the two CRC32s are consistent, it means that the firmware backup is successful, otherwise the firmware backup is unsuccessful. If the firmware backup is successful, the IOT needs to perform the following operations: set the "MCU backup area flag" in the storage information area to be valid, indicating that there is a complete and valid firmware backup in the "APP receiving area of the MCU"; write the backup MCU firmware version number (Version_receive) and CRC32 value (CRC32_Firmware) into the flag area for subsequent system query or verification; wait for the MCU to clear the "IOT request firmware backup flag", ensure that the backup process is completely terminated, and ensure that the system state is synchronized. This operation ensures that the IOT end backup firmware integrity is traceable, and provides a reliable basis for subsequent possible MCU firmware recovery or re-upgrade.

[0110] It should be noted that the above MCU can be specifically the MCU 40 in the above system embodiment, and the above IOT can be specifically the IOT device 30 in the above system embodiment.

[0111] The OTA upgrade method provided by the embodiment of the application triggers the OTA upgrade process by setting a controllable "waiting for receiving firmware flag" in the MCU, and introduces a bidirectional identity verification mechanism between the MCU and the IOT device to ensure that only authorized IOT devices can participate in the upgrade; in combination with firmware metadata verification, block data transmission, and multi-level CRC verification (including data packet level and overall level verification), the OTA upgrade process is significantly improved in safety and reliability. At the same time, by reusing the storage space of the IOT device as the cache and transit area of the MCU firmware, block receiving and relay transmission of the firmware are realized, without the need for additional configuration of a dedicated upgrade control module or an independent storage chip, thereby simplifying system design, reducing material investment and maintenance costs, and effectively reducing the overall implementation cost.

[0112] Please refer to Figure 4 , Figure 4 is a flowchart of an OTA upgrade method provided by another embodiment of the application. The method can be applied to the MCU in the above system embodiment, and the method includes but is not limited to the following steps:

[0113] S21: when the waiting for receiving firmware flag is a first preset valid value, receive the authentication request frame sent by the IOT device;

[0114] S22: identity check the IOT device based on the authentication request frame and the MCU unique serial number and the IOT unique serial number, and return an authentication response frame to the IOT device, the authentication response frame including a check result of identity matching of the IOT device;

[0115] S23: receive a version query frame sent by the IOT device, check the firmware metadata in the version query frame, and return a version reply frame to the IOT device, the version reply frame including a check result of passing the check of the firmware metadata;

[0116] S24: receive a firmware block data packet sent by the IOT device, each data packet in the firmware block data packet including a packet serial number, firmware data, and a check value;

[0117] S25: write the firmware data in sequence according to the packet serial number, and check each data packet in each firmware block data packet according to the check value;

[0118] S26: when each data packet in the firmware block data packet passes the check and the overall check of the firmware passes, perform an OTA firmware upgrade operation based on the firmware data.

[0119] In some embodiments, the method further includes setting a waiting-receiving-firmware flag to an invalid value, and recording new firmware information.

[0120] In some embodiments, the MCU further stores an IOT-requested-firmware-backup flag in the information area, and the method includes: when the IOT-requested-firmware-backup flag is a third preset valid value, receiving a backup authentication request frame sent by the IOT device; identity checking the IOT device based on the backup authentication request frame and the MCU unique serial number and the IOT unique serial number, and returning a backup authentication response frame to the IOT device, the backup authentication response frame including a check result of identity matching of the IOT device; sending a backup version declaration frame to the IOT device, so that the IOT device checks the firmware metadata in the backup version declaration frame; when receiving a backup version confirmation frame returned by the IOT device, sending a firmware block data packet to the IOT device; each data packet in the firmware block data packet includes a packet serial number, firmware data, and a check value, and the IOT device is used to write the firmware data to the APP receiving area of the MCU according to the packet serial number; the backup version confirmation frame is confirmation information returned by the IOT device when the check of the firmware metadata passes.

[0121] In some embodiments, the method further includes sending an end instruction to the IOT device; the end instruction is used to make the IOT device calculate an overall check value of the firmware stored in the APP receiving area of the MCU, and compare the calculated overall check value with the check value in the backup version declaration frame, to detect whether the firmware backup is successful.

[0122] In some embodiments, the MCU further stores a check value of the current firmware in the information area, and when the flag for waiting for receiving firmware is not the first preset valid value, the method further comprises: judging whether the check value of the current firmware is a second preset valid value; if the check value of the current firmware is the second preset valid value, judging whether the IOT firmware backup request flag is a third preset valid value; and if the check value of the current firmware is not the second preset valid value, sending a firmware request to the IOT device, so that the IOT device sends an authentication request frame to the MCU after receiving the firmware request.

[0123] In some embodiments, when the IOT firmware backup request flag is not the third preset valid value, the method further comprises: jumping to the APP running area, running the main program and listening to the IOT instruction; based on the listened IOT instruction, detecting whether the MCU firmware receiving instruction initiated by the IOT device is received; and if the MCU firmware receiving instruction is received, setting the flag for waiting for receiving firmware to the first preset valid value.

[0124] In some embodiments, the method further comprises: if the MCU firmware receiving instruction is not received, detecting whether the firmware backup request instruction requested by the IOT device is received; and if the firmware backup request instruction requested by the IOT device is received, setting the IOT firmware backup request flag to the third preset valid value.

[0125] It should be noted that the OTA upgrade method provided in the embodiment has the corresponding functional modules and beneficial effects of the above-mentioned system embodiments and method embodiments. Technical details not described in detail in the embodiment can be referred to the above-mentioned OTA upgrade method applied to the MCU provided in the application embodiments.

[0126] Please refer to Figure 5 , Figure 5 is a structural schematic diagram of an electronic device provided in the embodiment. The electronic device 50 comprises one or more processors 51 and a memory 52. The memory 52 is connected to the one or more processors 51, for example, connected to the processor 51 through a bus.

[0127] The processor 51 is configured to support the electronic device 50 to perform the corresponding functions in the methods in the above method embodiments. The processor 51 can be a central processing unit (CPU), a network processor (NP), a hardware chip or any combination thereof. The hardware chip can be an application specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0128] The memory 52 is configured to store program codes and the like. The memory 52 can include a volatile memory (VM), such as a random access memory (RAM); the memory can also include a non-volatile memory (NVM), such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); and the memory 52 can further include a combination of the above-mentioned memories.

[0129] The memory 52 can be configured to store non-volatile software programs, non-volatile computer-executable programs and modules, such as program instructions / modules corresponding to the OTA upgrade method in the embodiments of the present application. The processor 51 performs various functional applications of the OTA upgrade method by running the non-volatile software programs, instructions and modules stored in the memory 52, i.e., implements the OTA upgrade method provided by the above method embodiments.

[0130] The memory 52 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and application programs required by at least one function. The one or more modules are stored in the memory 52 and, when executed by the one or more processors 51, perform the OTA upgrade method in any of the above method embodiments, e.g., perform the method steps described in the above method embodiments and implement the functions of the modules described in the above system embodiments.

[0131] The electronic device 50 of the embodiments of the present application can be specifically an MCU (microcontroller unit), and can also be a BMS (battery management system) control unit, a PCS (power conversion system) control module, an EMS (energy management system) communication module, a collection control board, an inverter control unit, or other energy storage device control modules with embedded firmware update functions.

[0132] The embodiments of the present application provide a non-volatile computer readable storage medium, which stores computer executable instructions, and the computer executable instructions are executed by one or more processors, for example, one processor 51 in the electronic device 50, so that the one or more processors 51 can execute the OTA upgrade method in any of the above method embodiments, for example, execute the method steps described in the above method embodiments, and realize the functions of the modules described in the above system embodiments. Figure 5 The embodiments of the present application provide a non-volatile computer readable storage medium, which stores computer executable instructions, and the computer executable instructions are executed by one or more processors, for example, one processor 51 in the electronic device 50, so that the one or more processors 51 can execute the OTA upgrade method in any of the above method embodiments, for example, execute the method steps described in the above method embodiments, and realize the functions of the modules described in the above system embodiments.

[0133] The embodiments of the present application provide a computer program product, which includes a computer program stored on a non-volatile computer readable storage medium, and the computer program includes program instructions, when the program instructions are executed by the electronic device, the electronic device can execute the OTA upgrade method in any of the above method embodiments, for example, execute the method steps described in the above method embodiments, and realize the functions of the modules described in the above system embodiments.

[0134] Those skilled in the art can understand that all or part of the processes in the above method embodiments can be completed by a computer program instructing related hardware, and the program can be stored in a computer readable storage medium, and when the program is executed, the program can include the processes of the above method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0135] The above disclosure is only the preferred embodiments of the present application, and of course cannot limit the scope of the rights of the present application, so the equivalent changes made according to the claims of the present application are still within the scope of the present application.

Claims

1. An OTA upgrade method, applied to an MCU, characterized in that, The MCU is connected to the IoT device. The storage space of the IoT device includes an APP receiving area for storing firmware information of the MCU. The storage space of the MCU includes an MCU storage information area, which stores a firmware waiting flag, a unique serial number of the MCU, and a unique serial number of the IoT device. The method includes: When the waiting firmware flag is a first preset valid value, the authentication request frame sent by the IoT device is received; Based on the authentication request frame, the unique serial number of the MCU, and the unique serial number of the IoT, the identity of the IoT device is verified, and an authentication response frame is returned to the IoT device. The authentication response frame includes the verification result of the identity matching of the IoT device. The system receives a version query frame sent by the IoT device, verifies the firmware metadata in the version query frame, and returns a version response frame to the IoT device, the version response frame including the verification result that the firmware metadata verification passed; Receive firmware block data packets sent by the IoT device, wherein each data packet in the firmware block data packet includes a packet sequence number, firmware data and a check value; The firmware data is written sequentially according to the packet sequence number, and each data packet in each firmware block data packet is verified according to the check value. When each data packet in the firmware block data packet passes verification and the overall firmware passes verification, an OTA firmware upgrade operation is performed based on the firmware data.

2. The method according to claim 1, characterized in that, The MCU storage information area also stores the current firmware checksum and the IoT request firmware backup flag. When the waiting firmware reception flag is not a first preset valid value, the method further includes: Determine whether the verification value of the current firmware is a preset second valid value; If the current firmware verification value is the second preset valid value, then determine whether the IOT request firmware backup flag is the third preset valid value; If the current firmware verification value is not the second preset valid value, a firmware request is sent to the IoT device so that the IoT device sends the authentication request frame to the MCU after receiving the firmware request.

3. The method according to claim 2, characterized in that, When the IoT request firmware backup flag is not the third preset valid value, the method further includes: Jump to the APP running area, run the main program and listen for IoT instructions; Based on the monitored IoT instructions, detect whether an MCU firmware receive instruction initiated by the IoT device has been received; If the MCU firmware receive instruction is received, the waiting firmware flag is set to the first preset valid value.

4. The method according to claim 3, characterized in that, The method further includes: If the MCU firmware receive instruction is not received, then check whether the firmware backup request instruction requested by the IoT device has been received. If a firmware backup request instruction is received from the IoT device, the IoT request firmware backup flag is set to the third preset valid value.

5. The method according to claim 2, characterized in that, When the IoT request firmware backup flag is the third preset valid value, the method includes: Receive the backup authentication request frame sent by the IoT device; Based on the backup authentication request frame and the unique serial number of the MCU and the unique serial number of the IoT, the identity of the IoT device is verified, and a backup authentication response frame is returned to the IoT device. The backup authentication response frame includes the verification result of the identity matching of the IoT device. Send a backup version declaration frame to the IoT device so that the IoT device can verify the firmware metadata in the backup version declaration frame; When a backup version confirmation frame is received from the IoT device, a firmware block data packet is sent to the IoT device. Each data packet in the firmware block data packet includes a packet sequence number, firmware data, and a checksum. The IoT device is used to write the firmware data to the APP receiving area of ​​the MCU according to the packet sequence number. The backup version confirmation frame is a confirmation message returned by the IoT device when the firmware metadata verification is successful.

6. The method according to claim 5, characterized in that, The method further includes: Send a termination command to the IoT device; the termination command is used to enable the IoT device to calculate the overall verification value of the firmware stored in the APP receiving area of ​​the MCU, and compare the calculated overall verification value with the verification value in the backup version declaration frame to detect whether the firmware backup was successful.

7. The method according to claim 1, characterized in that, The method further includes: Set the waiting firmware flag to an invalid value and record the new firmware information.

8. An electronic device, characterized in that, include: A memory and a processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, the processor, when executing the one or more computer programs, causing the electronic device to implement the OTA upgrade method as described in any one of claims 1-7.

9. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the OTA upgrade method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions that, when executed by an electronic device, cause the electronic device to perform the OTA upgrade method according to any one of claims 1-7.

Images