Upgrading system and upgrading method for integrating OTA function hardening to chip layer

Abstract

The invention discloses an upgrading system and an upgrading method for hardening and integrating an OTA function to a chip layer, and belongs to the field of software remote upgrading of intelligent household appliances. The upgrading system comprises a master control MCU, a communication connection unit and a cloud server. An OTA function module is integrated in a chip layer of the master control MCU in a hardening mode, and the OTA function module can achieve firmware integrity verification, dual-backup partition switching, breakpoint resume downloading and failure rollback protection. And the cloud server issues an upgrade package through a network, and the upgrade package is received by the communication connection unit and then transmitted to the OTA function module in the main control MCU for processing, so that software upgrade is realized. According to the method, complex OTA logic is sunk to the bottom layer of a chip, and standardized process processing is achieved through hardware and low-level firmware. The upper-layer application development is greatly simplified, and firmware updating can be completed only by calling an upgrading interface provided by a chip.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software remote upgrading of intelligent household appliances, and particularly relates to an upgrading system and an upgrading method for hardening and integrating OTA (Over-The-Air) functions to the chip layer, directly implementing hardware packaging of the OTA remote upgrading function at the chip layer, and realizing OTA upgrading of intelligent household appliances. BACKGROUND

[0002] With the popularity of the Internet of Things and intelligent household appliances, remote OTA upgrading has become an important means to keep device functions updated and security patches. However, the OTA upgrading function of most intelligent household appliances at present is mainly realized by upper-layer software, such as an application based on an embedded Linux system or a real-time operating system (RTOS). For resource-constrained devices or small household appliances controlled by a simple MCU, it is quite high in technical threshold and complexity to realize a complete and reliable OTA mechanism:

[0003] Firstly, it is complex and has a high error rate: in the traditional scheme, the device manufacturer needs to write OTA download, verification, and installation logic in the application or Bootloader. This involves the coordination of multiple modules such as network communication, storage management, and exception handling, and the process is complex and prone to errors. Once there is a problem in the upgrading process (such as power failure, verification failure, etc.), it is easy to cause the device to become "bricked" and unable to start. In fact, on simple devices such as single-chip microcomputers, if direct overwrite upgrading is used in a single partition, an error in the upgrading process will leave the device in an incomplete state, thus directly causing the device to malfunction.

[0004] Moreover, the cost of coordination and testing is high: OTA upgrading usually requires close cooperation between the main application and the communication module (Wi-Fi / Bluetooth, etc.) to ensure that the downloaded data is correctly written to the storage and the new firmware is started after reboot. For small and medium-sized household appliance manufacturers, due to the lack of support from operating systems, they need to develop and debug this entire process themselves, which is a huge cost. The hardware of Internet of Things devices is diverse, with different MCU architectures, storage layouts, and communication methods, and this fragmentation further increases the difficulty of implementation. Even if a general OTA scheme (such as an OTA cloud platform and Bootloader provided by a third party) is used, it still needs to be adapted and modified for different chips, increasing the technical burden.

[0005] Again, reliability and security challenges: the OTA process implemented by pure software requires high requirements for programmers, and many abnormal scenarios need to be considered (network interruption, power failure recovery, verification failure, upgrade package incompatibility, etc.). If not handled properly, the firmware may be damaged due to power interruption during full upgrade, or unknown code may be run due to unverified firmware integrity, endangering device safety. Therefore, to ensure the safety and reliability of the OTA process, a large number of protection mechanisms (such as digital signature verification, breakpoint resume, backup rollback) are required, which further increase the complexity of software implementation.

[0006] In summary, the existing OTA upgrade of smart home appliances has the problems of complex implementation, error-prone and non-universal. On the one hand, traditional OTA requires software to handle download, verification, storage switching and other steps, and a slight mistake may cause upgrade failure or even device damage. On the other hand, the platform differences of different devices make it difficult to standardize the OTA process, and fragmentation leads to separate development by small and medium-sized manufacturers, which is inefficient. In particular, in resource-constrained MCU systems, implementing reliable OTA faces objective limitations such as insufficient storage partition and limited running memory. Therefore, it is necessary to change the current situation of relying entirely on software implementation for OTA upgrade.

[0007] Based on the current OTA upgrade in the field of smart home appliances, which mainly relies on software implementation, not only the development threshold is high and the cycle is long, but also there are many uncertain factors in the upgrade process. This puts obvious pressure on small and medium-sized home appliance enterprises with limited technical strength and investment, and there is an urgent need for a more bottom-level and more universal and reliable OTA implementation method to reduce development difficulty and improve upgrade success rate. SUMMARY

[0008] The purpose of the present application is to overcome the shortcomings of the prior art, and to provide an upgrade system and method that harden and integrate OTA functions to the chip layer. By hardening the key processes of OTA at the bottom layer of the chip, the present application simplifies the implementation of remote upgrade of smart home appliances and improves their reliability. By integrating OTA function modules at the hardware level, this solution can complete the self-update of firmware without relying on complex upper-layer software, significantly reducing development and maintenance costs.

[0009] The purpose of the present application is achieved by the following technical solutions:

[0010] An upgrade system that hardens and integrates OTA functions to the chip layer, applied in the field of smart home appliances, comprising a master MCU (Microcontroller Unit), a communication connection unit and a cloud server;

[0011] The OTA function module is hardened and integrated in the chip layer of the master MCU, and the OTA function module is an OTA function module capable of implementing firmware integrity verification, dual backup partition switching, breakpoint resume download and failure rollback protection.

[0012] The master MCU is connected with the communication connection unit through SPI / UART interface.

[0013] The communication connection unit is connected with the cloud server network, and the communication connection unit realizes data communication with the cloud server.

[0014] The cloud server transmits an upgrade package through the network, and the communication connection unit receives the upgrade package and transmits the upgrade package to the OTA function module in the master MCU for processing, so as to realize software upgrade.

[0015] Preferably, the master MCU is the master MCU of a smart home appliance; the master MCU adopts a dual-partition architecture, so as to realize the dual-backup partition switching function of the OTA function module.

[0016] Preferably, the dual-backup partition includes a running partition and an upgrade standby partition; the OTA function module is arranged in a firmware storage area (such as ROM / Flash) in the upgrade standby partition of the master MCU.

[0017] Preferably, the OTA function module includes a download agent and a verification module in the internal ROM (Read-Only Memory) of the master MCU; the download agent and the verification module pre-embed an OTA upgrade agent program in the on-chip ROM area of the master MCU, or divide a read-only Bootloader area in the Flash, and preferentially run at power-on. The download agent and the verification module are started when receiving an upgrade trigger signal, and undertake the tasks of handshake and initialization, firmware download (i.e. data reception) and integrity verification.

[0018] The handshake and initialization specifically include: handshake with the external communication connection unit through UART, SPI and other buses, and confirm entering the OTA mode; suspend the execution of the main application (or actively jump into the Bootloader by the application), so as to free up resources for the upgrade process; set necessary buffer and flag bits, for example, point the download target address to the starting address of the Flash standby partition.

[0019] The firmware download, in particular, is that the OTA function module receives the firmware data packet from the communication connection unit in batches according to the established protocol using the breakpoint resume mechanism. For example, a fixed size data block (such as 256 bytes) is written into the Flash block by block; after receiving a block of data, it is immediately written into the Flash standby area at a specific offset, and the check code (such as CRC) of the data block is calculated; the download agent and the check module maintain a download progress pointer and a check cumulative value; when the communication is interrupted or an abnormality occurs, the download agent and the check module will record the current completed byte offset, and request to continue transmission from the offset next time the connection is resumed (i.e. breakpoint resume). Such a mechanism ensures that even if the network is unstable, the upgrade can be completed eventually without the need to repeat the entire file download.

[0020] The integrity check, in particular, is that after all the firmware data is received, the OTA function module agent performs overall check on the new firmware in the standby area. The integrity check is one of the following two ways: the first way is to calculate the hash value or digital signature of the whole package, and compare it with the check code provided by the cloud; or the second way is to perform CRC check on each block of transmission and verify the cumulative result at the end. Only when the check result matches and the new firmware is complete and correct, the OTA function module agent will perform the subsequent switching operation; if the check fails, it is decided whether to request to download again or to give up the upgrade and report an error. In a secure situation, the chip can also integrate an encryption engine to verify the digital signature of the firmware, preventing tampering with the upgrade package from a hardware attack.

[0021] Preferably, the communication connection unit is preferably a Wi-Fi module.

[0022] Preferably, the cloud server is at least one of the cloud servers of AWS, Aliyun, Tiaoma Intelligence, Huawei Cloud or Tencent Cloud.

[0023] Preferably, the upgrade system in which the OTA function is hardened into the chip layer further comprises a display driving unit, a sensor unit and a peripheral unit; the display driving unit, the sensor unit and the peripheral unit are connected with the master control MCU respectively; the display driving unit realizes the driving of the display hardware, and the sensor unit transmits the received sensing signal to the master control MCU.

[0024] Preferably, the sensor unit comprises at least one of a temperature sensor, a photoelectric detector, a PM2.5 detector, a humidity detector and a gas detector.

[0025] Preferably, the external unit is at least one of an ADC acquisition unit, a PWM output unit, an I / O control unit and a TK application unit.

[0026] An upgrade method that hard-integrates OTA functionality to the chip layer, based on the aforementioned upgrade system, includes the following steps:

[0027] S01. The communication connection unit receives an upgrade notification or firmware package from the cloud server and notifies the main control MCU to enter upgrade mode. The OTA function module on the main control MCU requests the communication connection unit to transmit firmware data in blocks through the command interface.

[0028] S02. The communication connection unit sends the firmware data in fragments to the main control MCU block by block through the SPI / UART interface. The main control MCU receives the data and writes it to the spare partition of its own Flash, and at the same time returns a receipt confirmation. If the transmission is interrupted, both parties coordinate to resume the transmission from the breakpoint according to the completed data offset until the firmware is completely received.

[0029] S03. The main control MCU verifies the firmware and notifies the communication connection unit of the upgrade result. If the upgrade result fails, it attempts to recover or re-download. If the upgrade result is successful, it restarts and switches to the new firmware to complete the OTA upgrade.

[0030] Preferably, in step S03, the OTA upgrade process is as follows: the initial state is idle; upon receiving an upgrade command, it enters the download in progress state; after downloading and verification, it enters the switch-start state, guiding the new firmware to run upon the next reset; if verification fails or an abnormality occurs during the upgrade process, it enters the rollback state to ensure that the old firmware is still loaded upon restart; after the new firmware runs for the first time, it is marked as stable after self-testing, at which point the OTA upgrade process ends and returns to the idle state. The typical state transitions of the chip-built OTA function module (i.e., the OTA engine) in this invention include idle waiting, download in progress, verification, switch-start, and rollback states, as well as the transition conditions between each state. The OTA upgrade process in this invention embodies the fault tolerance mechanism and execution path of the hardware-encapsulated OTA upgrade process.

[0031] The core idea of ​​this invention is to encapsulate key OTA upgrade functional modules (including firmware integrity verification, dual backup partition switching, breakpoint resume download, and failure rollback protection) within the chip through hardware logic or firmware microcode, achieving a "one-and-done" low-level integration. In other words, the chip natively provides the basic operations required for the upgrade, while hardware handles most of the tedious and error-prone process control. Upper-layer applications only need to issue upgrade commands and provide the new firmware data source. In this invention, the OTA process is considered a crucial control flow related to the normal operation of the device; having it managed by a chip-level module significantly reduces the impact of human error and abnormal situations.

[0032] Compared with the prior art, the technical solution of the present invention has the following advantages:

[0033] 1. In this invention, the OTA function is hard-integrated into the chip layer, enabling the chip to have a built-in OTA engine. The OTA upgrade engine code or dedicated logic circuitry is pre-loaded in the firmware storage area (such as ROM / Flash) of the smart home appliance's main control MCU chip. This OTA engine is responsible for executing each step of the OTA upgrade process, such as receiving upgrade commands, downloading new firmware via the communication interface, verifying firmware integrity, managing dual-partition storage, and switching boot versions. The OTA engine can be firmware code written into the MCU's internal ROM or implemented as on-chip logic units (such as state machines or coprocessors) to ensure reliable operation independent of the application program.

[0034] 2. This invention employs a dual-backup partition and rollback mechanism. The chip storage architecture is designed in a dual-partition (dual-bank) mode, comprising a running partition and an upgrade backup partition. Under normal circumstances, the device boots from the running partition and executes the current firmware. When a new firmware upgrade is available, the OTA engine downloads and stores it in the backup partition. After successful verification, the boot flag is switched to the backup partition, and the device runs from the new firmware after a reboot. If the new firmware malfunctions, it automatically rolls back to the old version partition to ensure that the device always has a usable firmware to run. This A / B dual-partition redundancy design ensures the atomicity of the upgrade process—either a completely successful switch or a return to the state before the upgrade, greatly reducing the risk of the device becoming unusable due to upgrade failure.

[0035] 3. This invention employs breakpoint resumption and integrity verification. The OTA engine has breakpoint resumption capabilities, enabling it to resume unfinished download progress after network interruptions or device restarts. The engine records the written data offset or fragment sequence number to resume downloading from the point of interruption after reconnection, avoiding repeated transmission of the entire upgrade package, improving efficiency and reducing communication traffic. Simultaneously, the engine performs rigorous integrity verification on the downloaded firmware data (e.g., calculating CRC checksums or digital signature verification). Only complete firmware that passes verification is triggered for startup, ensuring that device operation is not damaged or compromised due to transmission errors or tampering.

[0036] 4. This invention features hardware-level fault tolerance protection. By hardware-enabling critical OTA steps, it achieves more robust fault tolerance at the chip level. The upgrade installation phase is executed by an independent bootloader or hardware state machine, which can automatically take measures to isolate faults and roll back the old version when an anomaly is detected (such as verification failure or power-off recovery), ensuring that even if the installation fails, it does not affect the normal operation of the device. Essentially, the hardware provides an "insurance mechanism" for the OTA process, protecting the device from entering an uncertain state in extreme cases.

[0037] Through the above solution, this invention sinks the complex OTA logic down to the chip level, implementing a standardized process using hardware and low-level firmware. On the one hand, upper-layer application development is greatly simplified, requiring only the use of the chip's upgrade interface to complete firmware updates; on the other hand, since the upgrade process is uniformly implemented and verified by the chip manufacturer, its reliability and security are more guaranteed, eliminating the need for device manufacturers to reinvent the wheel. In summary, this invention aims to provide a universal, low-barrier-to-entry path for OTA upgrades in smart home appliances, enabling more small and medium-sized manufacturers to easily empower their products with remote upgrade capabilities, while reducing after-sales risks caused by upgrade failures. Attached Figure Description

[0038] Fig. 1 This is a schematic diagram of the hardware-encapsulated OTA function architecture in the smart home appliance control chip of the embodiment.

[0039] Fig. 2 This is a timing flowchart of the MCU and Wi-Fi module working together to perform OTA upgrades in this embodiment.

[0040] Fig. 3 This is a schematic diagram of the OTA upgrade process state machine in the embodiment. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

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

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

[0044] Currently, OTA upgrades in the smart home appliance field mainly rely on software implementation, which suffers from high development barriers, long development cycles, and numerous uncertainties during the upgrade process. To address these technical problems, this invention proposes an upgrade system and method that hard-integrates OTA functionality to the chip layer.

[0045] The purpose of this invention is to address the shortcomings of the existing technology by providing an upgrade system and method that hard-integrates OTA (Over-The-Air) functionality into the chip layer. This invention integrates the key functions of the OTA upgrade process into the internal structure of a smart home appliance control chip (such as a Wi-Fi communication module chip or a main control MCU / SoC), enabling the OTA upgrade process to be completed at the chip hardware level. This technology belongs to the fields of embedded system firmware updates and IoT device management, aiming to improve the reliability and ease of remote upgrades for smart home appliances.

[0046] Example 1

[0047] like Fig. 1 As shown, an upgrade system that integrates OTA functionality into a chip is applied in the field of smart home appliances, including a main control MCU, a communication connection unit, and a cloud server;

[0048] The main control MCU has an OTA function module hard-integrated within its chip layer. The OTA function module is capable of firmware integrity verification, dual backup partition switching, breakpoint resume download, and failure rollback protection.

[0049] The main control MCU and the communication connection unit interact and connect via an SPI / UART interface;

[0050] The communication connection unit is connected to the cloud server network, enabling the communication connection unit to perform data communication with the cloud server;

[0051] The cloud server sends an upgrade package over the network, which is received by the communication connection unit and then transmitted to the OTA function module inside the main control MCU for processing, thereby realizing the software upgrade.

[0052] The main control MCU is the main control MCU of the smart home appliance; the main control MCU adopts a dual-partition architecture to realize the dual backup partition switching function of the OTA function module.

[0053] The communication connection unit is a Wi-Fi module.

[0054] The cloud server is at least one of the cloud servers from AWS, Alibaba Cloud, Tuya Smart, Huawei Cloud, or Tencent Cloud.

[0055] The upgrade system that integrates OTA functionality into the chip further includes a display driver unit, a sensor unit, and a peripheral unit; the display driver unit, sensor unit, and peripheral unit are respectively connected to the main control MCU; the display driver unit drives the display hardware, and the sensor unit transmits the received sensing signals to the main control MCU.

[0056] The sensor unit includes at least one of a temperature sensor, a photodetector, a PM2.5 detector, a humidity detector, and a gas detector.

[0057] The external unit is at least one of an ADC acquisition unit, a PWM output unit, an I / O control unit, and a TK application unit; the sensor unit and the external unit are selected and configured according to the needs of different smart home appliances.

[0058] like Fig. 2 As shown, an upgrade method that hard-integrates OTA functionality into a chip, based on the aforementioned upgrade system, includes the following steps:

[0059] S01. The communication connection unit receives an upgrade notification or firmware package from the cloud server and notifies the main control MCU to enter upgrade mode. The OTA function module on the main control MCU requests the communication connection unit to transmit firmware data in blocks through the command interface.

[0060] S02. The communication connection unit sends the firmware data in fragments to the main control MCU block by block through the SPI / UART interface. The main control MCU receives the data and writes it to the spare partition of its own Flash, and at the same time returns a receipt confirmation. If the transmission is interrupted, both parties coordinate to resume the transmission from the breakpoint according to the completed data offset until the firmware is completely received.

[0061] S03. The main control MCU verifies the firmware and notifies the communication connection unit of the upgrade result (success / failure). If the upgrade result is failure, it attempts to restore or re-download. If the upgrade result is success, it restarts and switches to the new firmware to complete the OTA upgrade.

[0062] like Fig. 3As shown, in step S03, the OTA upgrade process is as follows: the initial state is idle; upon receiving an upgrade command, it enters the download in progress state; after downloading and verification, it enters the switch-start state, guiding the new firmware to run upon the next reset; if verification fails or an abnormality occurs during the upgrade process, it enters the rollback state to ensure that the old firmware is still loaded upon restart; after the new firmware runs for the first time, it is marked as stable after self-testing, at which point the OTA upgrade process ends and returns to the idle state. The typical state transitions of the chip-built OTA function module (i.e., the OTA engine) in this invention include idle waiting, download in progress, verification, switch-start, and rollback states, as well as the transition conditions between each state. The OTA upgrade process in this invention embodies the fault tolerance mechanism and execution path of the hardware-encapsulated OTA upgrade process.

[0063] The following is combined with Figs. 1 to 3 This document provides a detailed description of the specific implementation methods and systems of the present invention. The present invention can be implemented using in-chip firmware code, hardware logic units, or a combination of both. In a preferred embodiment, the Bootloader / ROM code within the main control MCU chip integrates an OTA upgrade proxy function, while the communication connection unit (such as a Wi-Fi network module) is responsible for interacting with the cloud server to obtain upgrade data. Both work together to complete the upgrade through a predetermined protocol and hardware interface. Specific implementation methods include, but are not limited to, the following aspects:

[0064] 1. The OTA function module includes a download agent and verification module in the internal ROM of the main control MCU: the OTA upgrade agent program is pre-flashed in the on-chip ROM area of ​​the main control MCU (or a read-only bootloader area is partitioned in Flash, which runs first upon power-up); this download agent and verification module starts when it receives an upgrade trigger signal and performs the following tasks:

[0065] 1.1 Handshake and Initialization: The system hands over with the external communication module via buses such as UART and SPI to confirm entry into OTA mode; it pauses the execution of the main application (or the application actively jumps to the Bootloader) to free up resources for the upgrade process. Necessary buffers and flags are set, for example, the download target address is set to the starting address of the Flash backup partition.

[0066] 1.2 Firmware Download (Data Reception): The OTA agent receives firmware data packets in batches from the communication module according to a predetermined protocol. For example, it writes data blocks of fixed size (e.g., 256 bytes) to Flash one block at a time. Upon receiving each data block, it immediately writes it to a specific offset in the Flash spare area and calculates a checksum (e.g., CRC) for that data block. The agent module maintains a download progress pointer and a cumulative checksum value. When communication is interrupted or an error occurs, the agent records the currently completed byte offset and requests to continue transmission from that offset upon reconnection (resume interrupted download). This mechanism ensures that even with network instability, the upgrade can be completed eventually without needing to download the entire file again.

[0067] 1.3 Integrity Verification: After all firmware data has been received, the OTA agent performs a comprehensive verification of the new firmware in the backup area. One method is to calculate the hash value or digital signature of the entire packet and compare it with the checksum provided by the cloud; alternatively, CRC verification is performed during each transmission, and the accumulated result is verified at the end. Only when the verification result matches and the new firmware is complete and error-free will the agent proceed with the subsequent switching operation; if the verification fails, it will decide whether to re-request the download or abandon the upgrade and report the error, depending on the situation. For security purposes, the chip can also integrate an encryption engine to verify the firmware's digital signature, preventing hardware-based attacks that could tamper with the upgrade package.

[0068] 2. Cooperative OTA command protocol between the main control MCU and the communication connection unit (Wi-Fi communication module): In order to realize the above handshake and segmented transmission, a simple and efficient command protocol is established between the MCU Bootloader and the communication connection unit.

[0069] For example, the following instructions and processes can be designed:

[0070] 2.1 Upgrade Request and Response: When the communication connection unit detects new firmware on the cloud server (via MQTT notification or periodic query), it sends an "OTA Upgrade Request" command to the main control MCU, including the new firmware version number, file size, checksum, and other information. The main control MCU verifies the version number; if it decides to perform the upgrade, it replies "Confirm entry into OTA mode." Subsequently, the main control MCU resets some states and prepares to receive data.

[0071] 2.2 Data Block Transfer: The module sends a "Data Block Transfer" command, including the block number and data payload. Upon receiving this command, the MCU writes to the Flash memory and returns either a "Receive Confirmation" or a "Retransmission Request" (if the block verification fails or other errors occur). Both parties transfer the complete file in sequence. If the MCU needs to pause the transfer (e.g., due to Flash writing time or a full buffer), it can send a "Suspend" command to instruct the module to wait.

[0072] 2.3 Resume Transmission Support: If communication is interrupted or the MCU restarts, after the connection is re-established, the MCU can send a "resume request" along with the sequence number or byte offset of the last successfully received block. The module then continues sending subsequent data from that breakpoint until completion. Note: To support this feature, the upgrade package can predefine the total number of blocks or include overall file offset information in each block.

[0073] 2.4 Completion and Verification: After the module sends the last piece of data, it sends a "Transmission Complete" command. Upon receiving this command, the MCU performs an integrity check. If successful, it replies with "Upgrade Package OK" and notifies the module that the connection can be disconnected; otherwise, it replies with "Upgrade Package Error," and the module can choose to retransmit the entire package or declare failure. The MCU will then decide whether to switch the boot area based on the verification result.

[0074] The collaborative OTA command protocol between the main control MCU and the communication connection unit can be either proprietary to either party or refer to existing IoT OTA standards. The key is simplicity, reliability, and reduced resource consumption. For example, many existing solutions use the XMODEM / YMODEM protocol to transmit firmware via serial port; this invention is compatible with similar approaches but has been customized and optimized to support breakpoint resumption and automatic retries.

[0075] 3. Dual-Partition Storage Architecture and Boot Switching of the Main Control MCU Chip: This invention employs a dual-partition design in the chip's non-volatile storage (internal Flash or external Flash mapping). One partition serves as the active (running) partition, storing the currently running firmware; the other serves as the upgrade (backup) partition, used to store downloaded new firmware. The two partitions are typically of equal capacity, both sufficient to hold the complete firmware image. In specific implementations, the following strategies can be employed:

[0076] 3.1 Fixed Dual-Party Scheme: The Flash memory is divided into two equal parts, either contiguous or separate in address. One part is designated as partition A (running), and the other as partition B (backup). Upon MCU power-on reset, the bootloader determines which partition image to boot from based on the previous upgrade status. For example, a flag at a fixed address in the Flash memory indicates the currently valid partition number, or a hardware register / fuse bit records the current version. During normal operation, the flag points to partition A; after an OTA upgrade is completed, the bootloader updates the flag to point to partition B, and the next reboot boots the new program from partition B.

[0077] 3.2 Partition Switching and Rollback: The bootloader must be able to decide whether to maintain the switch based on the running status of the new firmware. The typical process is as follows: When the bootloader detects new firmware in the spare partition and the verification passes, it attempts to start the new firmware (temporarily marking the status as "under testing"). After the new firmware runs, it needs to perform a self-check under certain conditions (e.g., running several critical tasks or confirming a heartbeat with the cloud). Then, the application calls the confirmation interface provided by the chip to mark itself as "normal," and the OTA process is considered successfully completed. If the new firmware crashes, freezes, or fails to issue confirmation within a limited time, the bootloader determines that the upgrade failed upon the next reset, automatically restores the flag to the old Partition A firmware, and initiates a rollback. This ensures that if the upgraded software has fatal problems, the device can revert to running the previous stable version, meeting safety and reliability requirements.

[0078] 3.3 Factory Image and Error Protection: In the specific implementation, a read-only factory emergency image can also be set. When both partitions A and B are detected as corrupted and unbootable, the bootloader will load the factory image to ensure that the device can at least enter a network standby state, and then repair it via OTA. This further improves the system's self-healing capability. However, considering the limited chip resources, the factory image solution should be selected according to the situation.

[0079] The dual-partition architecture design of this invention is implemented on the chip hardware, eliminating the need for porting OTA code each time and ensuring atomicity of execution through hardware. Practice has shown that the dual-partition scheme significantly reduces the risk of device failure due to power outages during upgrades, forming a crucial foundation for reliable OTA.

[0080] 4. Resume interrupted downloads and exception handling mechanisms: In hardware-encapsulated OTA solutions, resume interrupted downloads and exception handling are integrated as basic functional modules.

[0081] 4.1 Download Resume: As mentioned earlier, the OTA engine records the download progress. When the network is interrupted, the chip can save the length of data already downloaded in non-volatile memory (such as a specific area in Flash or the MCU backup register). Even if the device unexpectedly restarts or loses power, the progress can be read after recovery, and then a request can be made to download only the remaining portion via the communication protocol. This mechanism avoids repeated transmissions, saves time, and reduces wear caused by repeated Flash erasures. Furthermore, since the engine is embedded in the chip, its state saving and recovery are more reliable and do not rely on application layer processing.

[0082] 4.2 Safe Boot After Power Loss / Abnormality: If the device loses power during download, upon power-up, the Bootloader first checks if the previous OTA update was incomplete. If an incomplete image is found in the backup partition (e.g., due to length record failure or verification failure), it will by default boot from the original running partition, and can notify the cloud to re-initiate the OTA update or wait for the device to become idle to automatically resume the download. Under no circumstances will the hardware logic guarantee that an incomplete new image will be booted, thus avoiding the device becoming unusable in a "partial upgrade" state.

[0083] 4.3 Error Isolation and Rollback: In addition to the aforementioned rollback mechanism, this invention also includes fault-tolerant processing for the installation phase. For example, when formally overwriting the backup area image onto the running area (some schemes require a copy operation) or switching flags, if the process is interrupted (e.g., a sudden power outage), the Bootloader will detect this interruption on the next boot, stop the switching process, and retain the old system running. Furthermore, if a functional abnormality is detected after the new firmware boots (captured by watchdog reset, etc.) and the running flag is not updated, the Bootloader will directly restore the old firmware. All of this is automatically completed by the underlying firmware without user intervention, thereby ensuring that the device can still function normally in the event of an upgrade failure to the greatest extent possible.

[0084] 5. Integration with existing chip architectures: The solution of this invention can be widely applied to current mainstream low-cost MCU or SoC platforms, and can be flexibly mapped to implement corresponding functions on different architectures.

[0085] 5.1 ESP32 and other Wi-Fi SoC platforms: The ESP32 series chips integrate a main processor and a Wi-Fi wireless unit, and support partition table management and OTA upgrades. This invention can extend the hardware logic based on its existing secondary bootloader, enabling OTA-related checks and rollback flag updates to be automatically completed by the bootloader. Simultaneously, utilizing its dual-core architecture, one core handles OTA downloads and writes to Flash, while the other core maintains basic functions without interruption, thus ensuring uninterrupted device service during online upgrades (this can be optionally implemented when resources permit).

[0086] 5.2 Low-cost modules such as BK7231 and BL602: These SoCs are commonly used in Wi-Fi modules for small home appliances, containing embedded MCUs and wireless transceivers. A unified OTA engine protocol can be pre-configured in their on-chip firmware, allowing them to both upgrade their own firmware as independent units and provide OTA assistance to external host MCUs via UART. The mechanism of this invention enables such modules to become universal "OTA upgrade units." When small and medium-sized manufacturers use these chips, they only need to call AT commands or APIs to trigger reliable OTA, without needing to delve into the underlying details.

[0087] 5.3 Open Architecture (e.g., RISC-V) Platform: In open-source SoC designs based on the RISC-V core, the modules in this solution (downloader, verifier, partition switching FSM, etc.) can be implemented as internal SoC IP using a hardware description language. On the one hand, these modules can be ported and reused as reusable IP cores in different chip designs; on the other hand, due to the customizability of the open-source architecture, manufacturers can adjust the size and functionality of the OTA modules according to their own application requirements (such as whether to add encryption verification, boot wait time, etc.). This helps to form a unified OTA hardware standard in the IoT field and accelerates ecosystem building.

[0088] It should be noted that this invention does not limit the specific implementation to relying entirely on hardware circuitry; in practical applications, a combination of hardware and firmware can be used. For example, a complete OTA function module (OTA engine) can also be implemented by a read-only bootloader program inside the MCU. Although it is essentially software, it is transparent to application developers, essentially providing "firmware-level hardware functionality" to the chip. Importantly, regardless of the internal implementation details, the device appears to have a built-in universal OTA capability: supporting secure downloads, coexistence of new and old versions, and automatic recovery from failures. This is precisely the technical effect that this invention aims to achieve.

[0089] Compared with the prior art, the technical solution of the present invention has the following advantages:

[0090] This invention moves the key processes of OTA remote upgrades from the software layer to the chip hardware layer, achieving a significant improvement in the upgrade method for smart home appliances. Specific innovations include:

[0091] 1. This invention employs hardware-encapsulated OTA (Over-The-Air) process: It is the first to propose a solution that integrates the complete OTA upgrade mechanism (download, verification, switching, and rollback) into the main control MCU chip of smart home appliances, elevating OTA from an application software function to a low-level built-in capability of the chip. Compared to pure software implementation, hardware encapsulation offers advantages such as strong determinism and rapid response, significantly reducing the interference and uncertainty of the upgrade process on the system.

[0092] 2. The upgrade method of this invention offers improved reliability and versatility: Through hardware-level safeguards such as dual backup partitions, breakpoint resume, and power-loss protection, this invention makes the remote upgrade process safer and more reliable, significantly reducing the likelihood of device unavailability due to upgrade failures. Since chip manufacturers have fully verified the OTA function module during the design phase, terminal products from various manufacturers can directly utilize this reliable function, improving the consistency and success rate of OTA implementation across the industry.

[0093] 3. The software upgrade method of this invention lowers the development threshold and cost: Small and medium-sized home appliance manufacturers do not need to build professional teams to develop complex OTA software; they only need to call the standard interfaces or commands provided by the chip to realize the remote upgrade function of their products. This reduces R&D investment and cycle time, and also reduces testing and certification costs. Especially in scenarios that require safety certification (such as the IEC 60730 safety standard), using the upgrade module built into the chip makes it easier to meet the requirements, eliminating repetitive software verification work.

[0094] 4. Modular and Reusable Design of the Software Upgrade System of the Invention: This invention provides a portable OTA function module design suitable for MCUs and SoCs of different architectures, especially compatible with the currently popular RISC-V open-source chip platform. The OTA function module can be used as an IP core for chip design reuse, or as a Bootloader library for upgrading existing chips, greatly improving the adoption rate of OTA functionality in the Internet of Things (IoT) field. This standardized and modular approach is expected to become the basic configuration for future smart terminal firmware upgrades.

[0095] In summary, this invention successfully overcomes the bottlenecks of difficult and risky remote upgrades for smart home appliances in existing technologies by hard-integrating OTA upgrade functionality at the chip level. It provides the industry with a highly reliable, low-cost, and easily deployable new OTA upgrade solution, possessing broad application prospects and significant practical value. Manufacturers utilizing this solution will be able to more easily maintain continuous software updates for their devices, enhancing user experience and product competitiveness.

[0096] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An upgrade system that hard-integrates OTA functionality to the chip layer, characterized in that: Includes the main control MCU, communication connection unit, and cloud server; The main control MCU has an OTA function module hard-integrated within its chip layer. The OTA function module is capable of firmware integrity verification, dual backup partition switching, breakpoint resume download, and failure rollback protection. The main control MCU and the communication connection unit interact and connect via an SPI / UART interface; The communication connection unit is connected to the cloud server network, enabling the communication connection unit to perform data communication with the cloud server; The cloud server sends an upgrade package over the network, which is received by the communication connection unit and then transmitted to the OTA function module inside the main control MCU for processing, thereby realizing the software upgrade.

2. The upgrade system that hard-integrates OTA functionality to the chip layer according to claim 1, characterized in that: The main control MCU is the main control MCU of the smart home appliance; the main control MCU adopts a dual-partition architecture to realize the dual backup partition switching function of the OTA function module.

3. The upgrade system that hard-integrates OTA functionality to the chip layer according to claim 1, characterized in that: The OTA function module includes a download agent and verification module in the internal ROM of the main control MCU. The download agent and verification module pre-embeds the OTA upgrade agent program in the on-chip ROM area of ​​the main control MCU or divides a read-only Bootloader area in Flash, and runs first when powered on. The download agent and verification module starts when it receives an upgrade trigger signal and undertakes the tasks of handshake and initialization, firmware download and integrity verification.

4. The upgrade system for hard-integrating OTA functionality to the chip layer according to claim 3, characterized in that: The handshake and initialization process specifically involves: handshaking with an external communication connection unit via UART or SPI bus to confirm entry into OTA mode; pausing the execution of the main application to free up resources for the upgrade process; setting the necessary buffers and flags; and pointing the download target address to the starting address of the Flash spare partition.

5. The upgrade system for hard-integrating OTA functionality to the chip layer according to claim 3, characterized in that: The firmware download specifically involves the OTA function module receiving firmware data packets in batches from the communication connection unit using a breakpoint resume method according to a predetermined protocol.

6. The upgrade system that hard-integrates OTA functionality to the chip layer according to claim 3, characterized in that: The integrity verification specifically involves the following steps: After all firmware data has been received, the OTA function module agent performs a comprehensive verification of the new firmware in the backup area. The integrity verification is performed in one of the following two ways: The first way is to calculate the hash value or digital signature of the entire packet and compare it with the verification code provided by the cloud; or the second way is to perform CRC verification during each transmission and verify the accumulated result at the end. The OTA function module agent will only perform subsequent switching operations when the verification result matches and the new firmware is complete and error-free. If the verification fails, decide whether to request the download again or abandon the upgrade and report the error, depending on the situation.

7. The upgrade system that hard-integrates OTA functionality to the chip layer according to claim 1, characterized in that: The communication connection unit is a Wi-Fi module; The cloud server is at least one of the cloud servers from AWS, Alibaba Cloud, Tuya Smart, Huawei Cloud, or Tencent Cloud.

8. The upgrade system that hard-integrates OTA functionality to the chip layer according to claim 1, characterized in that: It also includes a display driver unit, a sensor unit, and a peripheral unit; the display driver unit, sensor unit, and peripheral unit are respectively connected to the main control MCU; the display driver unit drives the display hardware, and the sensor unit transmits the received sensing signals to the main control MCU; The sensor unit includes at least one of a temperature sensor, a photoelectric detector, a PM2.5 detector, a humidity detector, and a gas detector; The external unit is at least one of the following: ADC acquisition unit, PWM output unit, I / O control unit, and TK application unit.

9. An upgrade method for hard-integrating OTA functionality into the chip layer, characterized in that: The upgrade system based on any one of claims 1-8 includes the following steps: S01. The communication connection unit receives an upgrade notification or firmware package from the cloud server and notifies the main control MCU to enter upgrade mode. The OTA function module on the main control MCU requests the communication connection unit to transmit firmware data in blocks through the command interface. S02. The communication connection unit sends the firmware data in fragments to the main control MCU block by block through the SPI / UART interface. The main control MCU receives the data and writes it to the spare partition of its own Flash, and at the same time returns a receipt confirmation. If the transmission is interrupted, both parties coordinate to resume the transmission from the breakpoint according to the completed data offset until the firmware is completely received. S03. The main control MCU verifies the firmware and notifies the communication connection unit of the upgrade result. If the upgrade result fails, it attempts to recover or re-download. If the upgrade result is successful, it restarts and switches to the new firmware to complete the OTA upgrade.

10. The upgrade method for hard-integrating OTA functionality to the chip layer according to claim 9, characterized in that: In step S03, the OTA upgrade process is as follows: the initial state is idle, and when an upgrade command is received, it enters the download in progress state; Once the download is complete and verification is successful, the system enters the switching startup state and will boot the new firmware upon the next reset. If verification fails or an error occurs during the upgrade process, the system enters the rollback state to ensure that the old firmware is still loaded upon restart. After the new firmware runs for the first time, it is marked as stable after a self-test, at which point the OTA upgrade process ends and returns to the idle state.

Images