Method for zigbee firmware and matter firmware switching based on OTA upgrade

Abstract

The application belongs to the technical field of Internet of Things, and specifically discloses a method for switching zigbee firmware and matter firmware based on OTA upgrading. The application modifies the bootloader based on mcuboot, so that the bootloader has the ability to simultaneously adapt to the startup of zigbee firmware and matter firmware. By identifying different firmware types, the corresponding startup environment and process are dynamically selected to ensure the stability and adaptability of firmware startup. The application generates corresponding OTA firmware for zigbee firmware and matter firmware, and realizes flexible switching between different firmware through OTA updating and upgrading, so that the firmware switching is more convenient and efficient. The application not only realizes flexible switching between zigbee firmware and matter firmware, but also improves the reuse capability of the system, so that the Internet of Things device can normally work in different environments.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, and relates to Zigbee firmware and Matter firmware, specifically to a method for switching between Zigbee firmware and Matter firmware based on OTA upgrades. Background Technology

[0002] Zigbee is a low-power, highly interoperable wireless communication technology suitable for smart home and IoT applications, boasting advantages such as long lifespan and high security. Matters is an initiative aimed at unifying interconnectivity standards for smart home devices, emphasizing interoperability, simplified development and deployment, security, and privacy protection. Both aim to provide users with a more integrated, secure, and reliable smart home experience, and together they drive the development and widespread adoption of smart home technology.

[0003] Zigbee and Matter are both excellent protocols for smart homes. Currently, most smart home products on the market only support one of them: Zigbee devices connect to a Zigbee gateway, and Matter devices connect to a Matter gateway. If a user changes their gateway, the firmware protocol of the original devices will become incompatible with the new gateway, rendering the original home devices unusable, causing inconvenience and waste. Summary of the Invention

[0004] Based on the aforementioned technical status and problems, the purpose of this invention is to provide a method for flexibly switching between Zigbee firmware and Matter firmware via OTA upgrade, so that the device can adapt to different environments and ensure that the firmware can work normally in different environments.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows.

[0006] The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade proposed in this invention includes the following steps: Step 1: Obtain device information. Obtain the device information of the device to be upgraded via Zigbee or Matter protocol, including at least the device's firmware type, firmware version, and related attribute information. Step 2: Prepare the OTA upgrade package and add a firmware identifier at the appropriate location in the firmware. Then, add the firmware information table to the header and footer of the MCUboot firmware to generate the basic firmware for Zigbee or Matter, which is used for firmware security and integrity verification during bootloader startup. Finally, add the OTA header, which is the information description part of the firmware request during OTA, to convert the Matter firmware into OTA firmware that can be used in the Zigbee environment, or to convert the Zigbee firmware into OTA firmware that can be used in the Matter environment. Step 3: Push the OTA upgrade package; Step 4: Device upgrade, bootloader starts, checks if firmware exists in the partition table, verifies the bootloader information for existing firmware, then reads the firmware type, and performs corresponding initialization according to the firmware type, providing different boot environments for matter firmware and zigbee firmware respectively, and performs device upgrade. Step 5: Reboot the device and start the new firmware.

[0007] To further explain, the firmware identifier in step 2 is added to the firmware header. The firmware identifier can identify the Zigbee firmware and the Matter firmware, and also includes the firmware version and firmware magic number information.

[0008] To further explain, the basic firmware of Zigbee and Matter generated in step 2 uses the same firmware partition table to ensure that the firmware can run normally.

[0009] To further explain, in step 2, the OTA header of the Zigbee firmware is generated by adding an OTA header script, which generates the corresponding format based on the input firmware type and firmware version parameter information, and then adds it to the header of the generated base firmware.

[0010] To further clarify, the parameters input to the Zigbee firmware OTA header script in step 2 must be consistent with the firmware parameters of the running Zigbee firmware; otherwise, the generated OTA firmware cannot be properly recognized by Zigbee OTA. The firmware parameters include the firmware type and the firmware magic number.

[0011] To further explain, in step 2, the OTA firmware of the matter firmware is generated by calling the matter OTA tool. The firmware parameters passed into the OTA tool need to be consistent with the parameters of the running matter firmware; otherwise, the generated OTA firmware cannot be properly recognized by matter OTA. The firmware parameters include the pid parameter and the vid parameter.

[0012] To further explain, the initialization of the matter firmware startup environment in step 4 specifically includes interrupt configuration and peripheral initialization.

[0013] To further explain, the initialization of the Zigbee firmware boot environment in step 4 includes two boot methods: one is that the bootloader initializes the interrupt priority, and the Zigbee firmware does not need to initialize the interrupt priority again; the other is that the bootloader does not initialize the interrupt priority, but actively initializes the interrupt priority before executing normal functions after the firmware starts.

[0014] The beneficial effects of this invention are as follows: Based on MCUBoot, this invention modifies the bootloader to enable simultaneous booting of Zigbee and Matter firmware. By identifying different firmware types, it dynamically selects the appropriate boot environment and process, ensuring the stability and compatibility of firmware booting. It generates corresponding OTA firmware for both Zigbee and Matter firmware, enabling flexible switching between different firmware through OTA updates, making firmware switching more convenient and efficient. This invention not only achieves flexible switching between Zigbee and Matter firmware but also improves the system's reusability, allowing IoT devices to operate normally in different environments. Attached Figure Description

[0015] Figure 1 This is a schematic diagram illustrating the switching between Zigbee firmware and Matter firmware disclosed in this invention.

[0016] Figure 2 This is a flowchart illustrating the Zigbee firmware and Matter firmware switching method disclosed in this invention.

[0017] Figure 3 This is the original format for Zigbee firmware and Matter firmware.

[0018] Figure 4 This diagram illustrates the steps involved in generating bootloader-based OTA upgrade firmware for this invention.

[0019] Figure 5 This is a schematic diagram of the bootloader firmware startup process disclosed in this invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the preferred embodiments described herein are for illustrative purposes only and are not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0021] This invention discloses a method for flexibly switching between Zigbee firmware and Matter firmware via OTA upgrade, enabling the device to adapt to different environments and ensuring that the firmware can function normally under various conditions. (Refer to...) Figure 1 This invention modifies the bootloader based on MCUboot, enabling it to simultaneously adapt to Zigbee firmware and Matter firmware boot. By identifying different firmware types, it dynamically selects the corresponding Zigbee or Matter boot environment and process, and then switches the Zigbee firmware or Matter firmware to the firmware adapted to the Matter or Zigbee environment through OTA upgrade, so that the device can boot normally with the new firmware.

[0022] like Figure 2 As shown, the method for switching between Zigbee firmware and Matter firmware based on OTA upgrade disclosed in this invention specifically includes the following steps: S1: Obtain device information. Obtain device information of the device to be upgraded via Zigbee or Matter protocol, including at least the device's firmware type, firmware version, and related attribute information; S2: Prepare the OTA upgrade package. Add a firmware identifier to the appropriate location in the firmware of the device to be upgraded, and add the firmware information table to the header and footer of the MCUboot firmware respectively, generating the basic firmware for Zigbee or Matter, which is used for firmware security and integrity verification during bootloader startup; then continue to add the OTA header, which is the information description part of the firmware requested during OTA, and finally convert the Matter firmware into OTA firmware that can be used in the Zigbee environment, or convert the Zigbee firmware into OTA firmware that can be used in the Matter environment; S3: Push the OTA upgrade package. Push the OTA firmware generated in step S2 above to the device to be upgraded via the gateway; S4: Bootloader starts, device upgrade. First, it checks if new firmware (i.e., OTA firmware pushed in S3) exists in the partition table. If new firmware exists, it verifies the bootloader information, then reads the firmware type and performs corresponding initialization according to the firmware type, providing different boot environments for matter firmware and zigbee firmware respectively, and performs device OTA upgrade; S5: Start Firmware. Reboot the device and start the new firmware.

[0023] When preparing OTA upgrade packages, different firmware require different firmware identifiers. Because different chips have different requirements for .bin files, the location for adding the firmware identifier needs to be adjusted adaptively according to the chip type. As a specific implementation, this embodiment is based on the Telink 9218 series chip, so the corresponding firmware identifier is added to the header position of the firmware, where it can be modified but will not affect the overall firmware operation. For example... Figure 3 and Figure 4 As shown, a firmware identifier is added to the header of the firmware body to form the original firmware. Specifically, the Zigbee original firmware includes two parts: the Zigbee firmware identifier header and the Zigbee firmware body. The Matter original firmware includes two parts: the Matter firmware identifier header and the Matter firmware body. The firmware identifier is used to identify the firmware type, i.e., Zigbee firmware or Matter firmware, and also includes firmware version and firmware magic number information.

[0024] For raw firmware with added firmware identifiers, in order to be correctly recognized by MCUBoot, it must meet MCUBoot's basic firmware format requirements, which include the MCUBoot header and MCUBoot tail. These two parts contain information tables generated during firmware compilation, which are directly encrypted by the tools provided by the bootloader during firmware generation, and the corresponding decryption keys are stored in the bootloader. The bootloader directly verifies the firmware during startup, identifying its integrity and whether it has been tampered with, thereby verifying its legitimacy. The Matter SDK for the 9218 chip used in this solution can directly generate basic firmware that meets MCUBoot requirements. However, for raw Zigbee firmware, the MCUBoot header needs to be added to the beginning of the firmware by modifying the linker script to generate basic firmware that MCUBoot can correctly recognize. The partition table of this basic firmware must be consistent with the partition table of the Matter firmware to ensure normal MCUBoot operation. The default size of the MCUBoot header is 0x200, mainly used for MCUBoot signing. After verifying the validity of the firmware, the bootloader reads the firmware type information from the firmware identifier and dynamically selects the appropriate Zigbee or Matter boot environment and process based on the different firmware types.

[0025] To meet the OTA requirements of the firmware, an OTA header script needs to be generated. This script generates the corresponding format based on the input firmware type and version parameters, and then adds it to the header of the already generated base firmware that meets MCUBoot requirements. During OTA, the firmware information description is first requested from the gateway. Zigbee specifies the format for the OTA firmware information description as "ZigBee OTA header," and Matter specifies the format as "Matter OTA header." After receiving the description information, its validity needs to be verified before normal OTA can proceed. Zigbee OTA firmware generation requires confirmation of the firmware type, firmware version, and other accompanying information. To ensure proper recognition during the OTA upgrade process, when calling the script to generate the OTA firmware, the firmware type and version information running on the device to be upgraded are used. Based on this information, an information table that can be recognized by the device to be upgraded is generated, and this information is then added to the beginning of the original bin file. This converts the Matter firmware into OTA firmware that Zigbee can use. Similarly, when it is necessary to convert Zigbee firmware into OTA firmware that Matter can use, the script src / app / ota_image_tool.py in the Matter source code directory can be used to directly generate an upgrade firmware that Matter can recognize. Matter needs to determine the PID and VID when recognizing the upgrade firmware. The parameters passed when converting Zigbee firmware into OTA firmware that Matter can use must be parameters that the running Matter firmware can recognize. If the parameters are incorrect, it will cause the OTA to fail.

[0026] Figure 5 This is a schematic diagram of the bootloader firmware startup process disclosed in this invention, as shown below. Figure 5As shown, when the device to be upgraded is powered on, MCUBoot, or bootloader, automatically starts. First, it checks if the new firmware exists in the partition table. Then, it verifies the firmware's legitimacy by combining the information tables in the MCUBoot header and tail sections of the firmware. Since the firmware needs to be signed and encrypted using tools provided by the bootloader after compilation, the key for decrypting the information tables is stored in the bootloader. Only after successful decryption can the bootloader properly identify the firmware's integrity and whether it has been tampered with. After completing the firmware legitimacy verification, the bootloader reads the firmware type from the firmware identifier and performs corresponding initialization based on the firmware type, providing different boot environments for Matter and Zigbee firmware respectively. For Matter firmware, initialization only requires clearing the usage of all peripherals and using the default interrupt configuration of MCUBoot to start the Matter firmware normally. For Zigbee firmware, initialization is divided into two startup methods. One is that the bootloader initializes the interrupt priority in advance and adjusts the interrupt priority through the plic part, so the Zigbee firmware does not need to initialize the interrupt priority again. The other is that the bootloader does not initialize the interrupt priority during the startup process. Instead, the compiled Zigbee firmware determines whether the priority in the plic is set after startup and before executing normal functions. If it is not set, it actively initializes the interrupt priority and then starts the Zigbee firmware normally.

[0027] In summary, the method for switching between Zigbee and Matter firmware based on OTA upgrades disclosed in this invention modifies the bootloader based on MCUBoot, enabling it to simultaneously adapt to booting with both Zigbee and Matter firmware. By identifying different firmware types, it dynamically selects the appropriate boot environment and process, ensuring the stability and compatibility of firmware booting. It generates corresponding OTA firmware for both Zigbee and Matter firmware, enabling flexible switching between different firmware through OTA updates, making firmware switching more convenient and efficient. This invention not only achieves flexible switching between Zigbee and Matter firmware but also improves the system's reusability, allowing IoT devices to operate normally in different environments.

[0028] The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application, and all such modifications or substitutions should be covered within the scope of the claims of this application.

Claims

1. A method for switching between Zigbee firmware and Matter firmware based on OTA upgrades, characterized in that, Includes the following steps: Step 1: Obtain device information. Obtain the device information of the device to be upgraded via Zigbee or Matter protocol, including at least the device's firmware type and firmware version information. Step 2: Prepare the OTA upgrade package and add a firmware identifier at the appropriate location in the firmware. Then, add the firmware information table to the header and footer of the MCUboot firmware to generate the base firmware for Zigbee or Matter, used for firmware security and integrity verification during bootloader startup. Finally, add the OTA header, which is the information description part requested by the OTA client. Specifically, for converting Matter firmware to OTA firmware usable in a Zigbee environment, add an OTA header script, pass in the firmware type and firmware version parameters consistent with the Zigbee firmware currently running on the device, generate the corresponding Zigbee OTA header, and then add it to the header of the generated base firmware. For converting Zigbee firmware to OTA firmware usable in a Matter environment, call the Matter OTA tool, pass in the PID and VID parameters consistent with the running Matter firmware, generate the corresponding Matter OTA header, and then add it to the header of the generated base firmware. Through the above two OTA header generation methods, Matter firmware can be converted to OTA firmware usable in a Zigbee environment, or Zigbee firmware can be converted to OTA firmware usable in a Matter environment. Step 3: Push the OTA upgrade package; Step 4: Device upgrade, bootloader starts, checks if firmware exists in the partition table, verifies the bootloader information for existing firmware, then reads the firmware type, and performs corresponding initialization according to the firmware type, providing different boot environments for matter firmware and zigbee firmware respectively, and performs device upgrade. Step 5: Reboot the device and start the new firmware.

2. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, The firmware identifier in step 2 is added to the firmware header. The firmware identifier can identify Zigbee firmware and Matter firmware, and also includes firmware version and firmware magic number information.

3. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, The basic firmware for Zigbee and Matter generated in step 2 uses the same firmware partition table to ensure that the firmware can run normally.

4. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, In step 2, the OTA header of the Zigbee firmware is generated by adding an OTA header script. Based on the input firmware type and firmware version parameters, the corresponding format is generated and then added to the header of the generated base firmware. The parameters input to the OTA header script must be consistent with the firmware parameters of the running Zigbee firmware; otherwise, the generated OTA firmware cannot be properly recognized by Zigbee OTA.

5. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, In step 2, the OTA firmware of the Matter firmware is generated by calling the Matter OTA tool. The firmware parameters passed into the OTA tool need to be consistent with the parameters of the running Matter firmware; otherwise, the generated OTA firmware cannot be properly recognized by Matter OTA. The firmware parameters include the pid parameter and the vid parameter.

6. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, Step 4, the initialization of the matter firmware boot environment, specifically includes interrupt configuration and peripheral initialization.

7. The method for switching between Zigbee firmware and Matter firmware based on OTA upgrade according to claim 1, characterized in that, The initialization of the Zigbee firmware boot environment in step 4 includes two boot methods: one is that the bootloader initializes the interrupt priority, and the Zigbee firmware does not need to initialize the interrupt priority again; the other is that the bootloader does not initialize the interrupt priority, but actively initializes the interrupt priority before executing normal functions after the firmware starts.

Images