Communication protocol dynamic switching method and device, equipment and storage medium

Abstract

The application relates to the technical field of Internet of Things, and in particular to a communication protocol dynamic switching method and device, equipment and a storage medium, two types of Flash memory partitions are divided, internal Flash contains a boot loader, protocol firmware and a public data partition, external Flash contains an OTA upgrade, a blank reservation and a switching flag partition; after a protocol switching instruction is received, a current firmware writes user configuration data into the public data partition, writes check information in the switching flag partition, executes system reset, the boot loader reads the switching flag partition and checks target firmware, if the check is passed, the target firmware is started to complete initialization, and two types of communication protocol switching are realized. The application does not need additional hardware, reduces cost, avoids device idling, and helps smooth transition of Internet of Things device protocols.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, device, and storage medium for dynamic switching of communication protocols. Background Technology

[0002] With the rapid development of smart home and Internet of Things (IoT) technologies, the ZigBee protocol, as a classic low-power wireless communication protocol, has built a broad application foundation and a mature market ecosystem in the field of smart sensors; while the Matter protocol, as a new generation of unified IoT interconnection standard, is gradually becoming the mainstream direction of industry development.

[0003] Currently, most existing IoT devices on the market are built on the ZigBee protocol, covering various types of terminal devices such as door magnetic sensors, environmental sensors, and light sensors. When users migrate to the Matter ecosystem, they face many technical and application-level obstacles. Specifically, existing ZigBee devices and Matter devices use different protocol stacks and firmware architectures, and users cannot freely switch protocols on a single device. This results in the need to purchase new devices adapted to the Matter protocol during the protocol transition phase, leading to idle resources and wasted investment in the original ZigBee devices. Although some manufacturers have launched dual-mode devices that support both ZigBee and Matter, these devices require two independent RF chips or high-performance processor units, significantly increasing hardware manufacturing costs and making it difficult to achieve large-scale adoption in cost-sensitive, low-cost sensor-based IoT devices. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides a method, apparatus, device, and storage medium for dynamic switching of communication protocols, which solves problems such as excessively long switching time, insufficient reliability, and loss of user data in existing technologies, enabling low-cost IoT sensor devices to switch quickly, securely, and seamlessly between ZigBee and Matter protocols.

[0005] The first aspect of this application provides a method for dynamically switching communication protocols, applied to Internet of Things (IoT) devices with built-in internal Flash memory and external Flash memory, the method comprising: The internal Flash memory is divided into a bootloader partition, a protocol firmware partition, and a common data partition, and the external Flash memory is divided into an OTA upgrade partition, a blank reserved area, and a switching flag partition; the protocol firmware partition includes at least a first protocol firmware partition and a second protocol firmware partition, and the OTA upgrade partition includes at least a first OTA upgrade partition and a second OTA upgrade partition. When a protocol switching command is received from the user during normal operation, the current protocol firmware is controlled to write the user configuration data into the public data partition and write integrity verification information into the switching flag partition; the current protocol firmware is the protocol firmware that the IoT device runs under normal operation. Perform a system reset and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information; When the integrity verification result is determined to be successful, the target protocol firmware is controlled to start and complete initialization, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

[0006] In an optional implementation, controlling the bootloader partition to read the switching flag partition and performing integrity verification on the target protocol firmware partition based on the integrity verification information includes: Read the switching flag bit in the switching flag partition, and determine whether there is a valid switching request based on the switching flag bit; When a valid handover request is determined, the verification value of the target protocol firmware is calculated based on the integrity verification information, and the verification value is compared with a preset verification value. When the verification value is consistent with the preset verification value, the verification result is determined to be successful. The bootloader partition is configured to start as the target protocol firmware partition. The switching flag bit in the switching flag partition is cleared. The program code in the target protocol firmware partition is then jumped to and executed. When the verification value is inconsistent with the preset verification value, the verification result is determined to be a verification failure. The current protocol firmware is maintained unchanged, the switching flag bit in the switching flag partition is cleared, and the process jumps back to the current protocol firmware partition to continue running.

[0007] In an optional implementation, the method further includes: Determine whether the target protocol firmware has completed initialization within a preset time period; When it is determined that the target protocol firmware has not completed initialization within the preset time period, a system reset is performed; Once the system reset is complete, the bootloader partition is controlled to read the failure counter of the target protocol firmware and increment the failure counter. Determine whether the accumulated failure counter value is less than a preset anomaly detection threshold; If the failure counter value is less than the anomaly determination threshold, the bootloader partition is controlled to retry starting the target protocol firmware partition.

[0008] In an optional implementation, the method further includes: If the failure counter value is greater than or equal to the anomaly determination threshold, it is determined that the target protocol firmware has an operational anomaly, and the switching flag bit in the switching flag partition is cleared; Roll back the firmware boot link to the current protocol firmware partition before the handover operation was performed; Load and start the current protocol firmware partition, restore to the first communication protocol before the switch, and output a preset status prompt signal to inform the user that the protocol switch operation has failed.

[0009] In an optional implementation, after the target protocol firmware is started and initialized, the method further includes: Read the user configuration data from the public data partition; The user configuration data is parsed and then restored to the runtime data structure of the target protocol firmware. Perform integrity verification on the restored user configuration data and compare the real-time verification results with the pre-stored valid verification benchmarks; When the real-time data verification result meets the valid verification benchmark, the second communication protocol is loaded and the system enters normal working state through the second communication protocol. When the real-time data verification result does not meet the valid verification benchmark, the user configuration data is discarded, and the target protocol firmware is started by loading the preset default configuration.

[0010] In an optional implementation, after the current protocol firmware writes user configuration data to the public data partition and writes integrity verification information to the switching flag partition, the method further includes: The user configuration data and integrity verification information are identified as the original data to be retained, and the original data to be retained is temporarily stored in a preset temporary storage location; The original data to be retained is compared bit by bit with the data already written obtained from the switching flag partition; If the retained original data matches the written data completely, it is determined that the retained original data was successfully written. If any data in the retained original data and the written data are inconsistent, it is determined that the retained original data was written abnormally, and the written data in the switching flag partition is cleared.

[0011] In an optional implementation, the method further includes: When the user configuration data is stored in the public data partition, the user configuration data is also synchronously stored in the private data partition corresponding to the current protocol firmware. Monitor user data change events in the current protocol firmware, and when a change in the user configuration data is detected, synchronously write the changed user configuration data to the public data partition; Within the public data partition, a corresponding version identifier is maintained for the user configuration data, and the freshness of the user configuration data is determined based on the version identifier. The latest user configuration data is selected according to the freshness.

[0012] A second aspect of this application provides a communication protocol dynamic switching device, applied to an Internet of Things (IoT) device with built-in internal Flash memory and external Flash memory, the device comprising: The storage partitioning module is used to divide the internal Flash memory into a bootloader partition, a protocol firmware partition, and a common data partition, and to divide the external Flash memory into an OTA upgrade partition, a blank reserved area, and a switching flag partition; the protocol firmware partition includes at least a first protocol firmware partition and a second protocol firmware partition, and the OTA upgrade partition includes at least a first OTA upgrade partition and a second OTA upgrade partition. The instruction processing module is used to control the current protocol firmware to write user configuration data into the public data partition and write integrity verification information into the switching flag partition when a protocol switching instruction input by the user is received during normal operation; the current protocol firmware is the protocol firmware running on the IoT device during normal operation. The reset verification module is used to perform system reset and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information. The switching startup module is used to control the target protocol firmware to start and complete initialization when the integrity verification result is determined to be successful, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

[0013] A third aspect of this application provides an Internet of Things (IoT) device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the dynamic switching method for the communication protocol.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described dynamic switching method for communication protocols.

[0015] In summary, the communication protocol dynamic switching method, apparatus, device, and storage medium provided in this application have at least one of the following beneficial effects: 1. The internal Flash memory is divided into a bootloader partition, a protocol firmware partition, and a common data partition. The protocol firmware partition contains at least the first protocol firmware (corresponding to the ZigBee protocol) and the second protocol firmware (corresponding to the Matter protocol). At the same time, the external Flash memory is divided into an OTA upgrade partition, a blank reserved area, and a switching flag partition. The OTA upgrade partition contains at least the OTA upgrade partitions corresponding to the two types of protocol firmware. This enables the coexistence of two types of protocol firmware on the same device and provides a hardware storage foundation for a single device to carry multiple protocol firmware. 2. Under normal operating conditions, when a user protocol switching command is received, the current protocol firmware will write the user configuration data to the common data partition to ensure the continuity of the user configuration after the switch. At the same time, it will write integrity verification information to the switching flag partition. Subsequently, the system will be reset, and the bootloader partition will read the verification information from the switching flag partition to perform integrity verification on the target protocol firmware. After the verification is successful, the target protocol firmware will be started and initialized, and finally the switch from the first communication protocol (ZigBee) to the second communication protocol (Matter) will be realized. The protocol migration can be completed without replacing the device. 3. IoT devices with built-in internal Flash and external Flash do not require two independent RF chips or high-performance processor units. Dual-mode protocol compatibility and switching can be achieved simply by partitioning the existing Flash memory, rationally storing the protocol firmware, and designing the switching process. No additional hardware investment is required. Through software-level storage partitioning design and protocol switching process optimization, the manufacturing cost of dual-mode protocol devices is reduced, enabling large-scale popularization in low-cost IoT devices. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a method for dynamically switching communication protocols according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the region division of an internal Flash address space according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the region division of an external Flash address space according to an embodiment of this application; Figure 4This is a schematic diagram illustrating the collaborative relationship between internal Flash and external Flash, as shown in an embodiment of this application. Figure 5 This is a timing diagram illustrating a method for dynamically switching communication protocols according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating a Bootloader decision-making process according to an embodiment of this application; Figure 7 This is a flowchart illustrating an automatic rollback operation according to an embodiment of this application; Figure 8 This is a flowchart illustrating a real-time data synchronization mechanism according to an embodiment of this application; Figure 9 This is a framework diagram of a communication protocol dynamic switching system shown in an embodiment of this application; Figure 10 This is a functional block diagram of a communication protocol dynamic switching device shown in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an Internet of Things (IoT) device shown in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0019] Furthermore, existing protocol switching technologies mostly rely on Over-the-Air (OTA) technology to remotely flash complete firmware, resulting in a complex and time-consuming switching process. During switching, issues such as brief device disconnections and operational unavailability can easily occur. Additionally, existing protocol switching technologies carry the risk of device malfunction due to firmware flashing failures. Moreover, the lack of an effective data exchange mechanism between different protocol firmwares means that core user data such as network configuration information, device binding relationships, and hardware calibration parameters cannot be retained across protocols during switching. Each switch necessitates reconfiguring device network configuration and parameters, severely degrading the user experience. Therefore, existing IoT device protocol switching technologies have many shortcomings, mainly manifested in the following aspects: First, the utilization rate of storage resources is low. When switching firmware using OTA, the complete firmware image file needs to be temporarily stored in external storage, which significantly occupies the device's limited storage resources and increases hardware deployment costs. Second, the protocol switching process lacks reliability assurance. Existing solutions have not built a complete firmware integrity verification and abnormal rollback mechanism. If abnormal situations such as power outages or transmission interruptions occur during the switching process, firmware flashing failures are likely to occur, leading to the device becoming "bricked" and unable to function. Third, the data synchronization mechanism is lacking. An effective data sharing and interaction channel has not been established between the two sets of firmware protocols. User configuration data and device status data cannot be synchronously migrated during the protocol switching process, resulting in frequent data loss problems after the switch. Fourth, the protocol switching latency is high. OTA flashing of the complete firmware requires the transmission of a large-capacity firmware data packet, and the switching process is time-consuming, which cannot meet the user's need for immediate protocol switching and limits the practical application of protocol switching technology.

[0020] Reference Figure 1 The diagram shown is a flowchart illustrating a dynamic switching method for communication protocols according to an embodiment of this application. The dynamic switching method for communication protocols is applied to Internet of Things (IoT) devices with built-in internal Flash memory and external Flash memory, and includes the following steps.

[0021] S11, the internal Flash memory is divided into a bootloader partition, a protocol firmware partition, and a public data partition, and the external Flash memory is divided into an OTA upgrade partition, a blank reserved area, and a switching flag partition.

[0022] The IoT device (hereinafter referred to as the device) has built-in internal Flash memory and external Flash memory. Firstly, the internal Flash memory and external Flash memory can be partitioned separately. The internal Flash memory is divided into a bootloader partition, a protocol firmware partition, and a common data partition, as shown below. Figure 2As shown in Table 1. The protocol firmware partition includes at least a first protocol firmware partition (i.e., a ZigBee firmware partition) and a second protocol firmware partition (i.e., a Matter firmware partition), and the specific division is based on the actual application.

[0023] Table 1:

[0024] The address arrangement is as follows: Start Address → Bootloader → ZigBee Firmware → Matter Firmware → Common Data Partition → End Address. The Bootloader partition is located at the start address of the internal Flash memory. The ZigBee firmware partition and Matter firmware partition are located in different address spaces following the Bootloader partition. The common data partition is located at the end of the internal Flash memory. Both firmware versions have built-in Bluetooth functionality, allowing for network configuration, device management, and OTA upgrades via Bluetooth.

[0025] To facilitate understanding of the inventive concept of this application, the design basis for each partition of the internal Flash memory is provided below: (1) Bootloader partition: placed at the starting address.

[0026] When partitioning the firmware storage of embedded devices, because ARM Cortex-M series processors, after a hardware reset, read the initial stack pointer (MSP) from the Flash's starting address (0x00000000) and the reset vector from offset 0x00000004 as the jump address for the first instruction, this is a hardware behavior of the ARM architecture and cannot be changed. Therefore, the Bootloader partition must be placed at the starting address to ensure it is executed first after the chip powers on. The Bootloader is responsible for reading the switching flag, verifying the integrity of the target firmware, and determining which firmware partition to boot from, serving as the core entry point for the entire firmware switching mechanism.

[0027] (2) ZigBee firmware partition and Matter firmware partition: Independent partitions, placed after Bootloader.

[0028] Since the ZigBee and Matter protocol stacks are two completely different network protocol implementations, with different initialization processes, network management layers, data link layers, and security mechanisms, they cannot be merged into a single firmware for operation. Therefore, setting the ZigBee firmware partition and the Matter firmware partition as independent partitions and placing them after the bootloader allows the following to be achieved: A. Isolation: The two firmware versions are stored in their own independent partitions, ensuring the integrity of the other firmware is not affected when upgrading one firmware version via OTA. For example, when upgrading ZigBee firmware, even if the upgrade process is interrupted and data is corrupted, the data in the Matter firmware partition remains intact.

[0029] B. Independent Addressing: The bootloader starts the target firmware by directly jumping to the starting address of the corresponding partition, without the need for additional address mapping or relocation operations, resulting in higher firmware startup efficiency.

[0030] C. Independent OTA: The two firmware partitions are physically independent and perform OTA upgrades separately. The upgrade frequency and version can be asynchronous. Users can switch to Matter firmware based on the latest version of ZigBee firmware.

[0031] D. Flexibility: Each partition is completely isolated and does not interfere with each other. If it is necessary to change one of the firmware sets in the future (such as replacing it with Thread protocol firmware), only the contents of the corresponding partition need to be modified, without affecting other partitions.

[0032] (3) Public data partition: placed at the end.

[0033] Due to common best practices in embedded system design, persistent non-volatile memory (NVM) data in embedded devices is typically placed in the end region of Flash memory, which allows for: A. Avoiding accidental firmware updates: During OTA upgrades, the write range of new firmware expands from the partition's starting address towards higher addresses. If the common data area is located between firmware partitions, when the size of a firmware update increases in version iterations, it may overwrite the common data area.

[0034] B. Wear Leveling: User data (such as distribution network information and calibration parameters) in the public data partition will be frequently written and erased during operation. Flash has a limited write / erase life (usually 100,000 times). Separating the frequently written data area from the code area facilitates the implementation of wear leveling strategies in the future and extends the life of Flash.

[0035] C. Accessible by both firmware versions: The address of the public data area is fixed and known to both firmware versions. Regardless of whether ZigBee firmware or Matter firmware is currently running, the public data area can be accessed through the same address, without the need for an additional address mapping mechanism.

[0036] D. Data security: The end area is relatively far from the firmware code area, so even in extreme abnormal situations (such as pointer out-of-bounds writing), it is not easy to accidentally write to the public data area.

[0037] Simultaneously, the external Flash memory can be divided into an OTA upgrade partition, a blank reserved area, and a switching flag partition, as shown in the following reference. Figure 3 As shown in Table 2. The OTA upgrade partition includes at least a first OTA upgrade partition (i.e., the ZigBee OTA partition) and a second OTA upgrade partition (i.e., the Matter OTA partition), and the specific division is based on the actual application.

[0038] Table 2:

[0039] The address arrangement is as follows: starting address → ZigBee OTA partition → Matter OTA partition → blank reserved area → switching flag partition → ending address. External Flash is used to store OTA upgrade images. Devices can independently upgrade the corresponding firmware in the internal Flash via three channels: ZigBee OTA, Matter OTA, or Bluetooth OTA. The Bluetooth OTA channel is provided by the built-in Bluetooth function of each of the two firmware sets; firmware upgrades and protocol switching do not affect each other.

[0040] To facilitate understanding of the inventive concept of this application, the design basis for each partition of the external Flash memory is provided below: (1) ZigBee OTA partition and Matter OTA partition: independent partitions.

[0041] Because ZigBee firmware and Matter firmware differ in size (the Matter protocol stack is larger than the ZigBee protocol stack), the OTA upgrade packages also differ in size. Storing the two OTAs separately allows for flexible space allocation based on the actual size of each firmware, enabling the following: A. Independent Upgrade: The two firmware versions can simultaneously receive OTA upgrade packages from different sources without blocking each other. For example, the device can receive Matter firmware upgrade packages via Bluetooth OTA in ZigBee mode, and vice versa.

[0042] B. Space allocation on demand: Matter firmware is typically larger than ZigBee firmware, therefore Matter OTA partitions can be allocated more space, while ZigBee OTA partitions can be allocated less space, avoiding wasted storage space. C. Upgrade Security: The OTA image is temporarily stored in external Flash memory and only flashed to the corresponding firmware partition in internal Flash memory after the writing process is complete. If the OTA transfer has... In the event of a power outage or data corruption, only the OTA partition of the external Flash memory is affected; the firmware in the internal Flash memory remains intact, and the device can boot normally.

[0043] D. Multi-channel OTA support: The ZigBee OTA partition can be written to the upgrade package via either the ZigBee gateway OTA or Bluetooth OTA channel; the Matter OTA partition can be written to the upgrade package via either the Matter OTA or Bluetooth OTA channel. This partition independence allows OTA operations on different channels to be performed independently without interference.

[0044] (2) Blank reserved area: reserved space.

[0045] As the firmware functionality of IoT devices iterates throughout the product lifecycle, the firmware size may gradually increase. Furthermore, future additions of features (such as support for more sensor types, increased local AI inference, etc.) will require additional storage space, which can be achieved through: A. Version iteration margin: Reserved space for firmware size increases. When the size of the new firmware exceeds the current OTA partition size, the blank reserved area can be used to expand the OTA partition.

[0046] B. Functionality Expansion Capability: Future additions to functions may require additional Flash space (such as new protocol stacks, data buffers, etc.), and the blank reserved area can be flexibly allocated to new functions.

[0047] C. Reduce hardware costs: By reserving space reasonably, it is possible to avoid replacing the Flash chip with a larger capacity due to the increase in firmware size, thereby reducing hardware BOM costs.

[0048] (3) Switching flag partition: placed at the end.

[0049] Because the data size of the switching flag partition is very small (containing only flag bits, version number, CRC checksum, timestamp, etc., usually not exceeding 1KB), but the data reliability requirements are extremely high—if the switching flag is miswritten or corrupted, it will cause firmware switching failure or even prevent the device from booting normally. This can be addressed by: A. Avoid accidental overwriting during OTA updates: OTA upgrade packages are written starting from the address of the external Flash memory. During the OTA partition writing process, errors may occur due to upgrade errors. There is a risk of out-of-bounds writes due to changes in packet size or write anomalies. Placing the switching flag at the end, furthest from the OTA write area, minimizes the risk of it being accidentally overwritten during the OTA process.

[0050] B. Data Criticality Protection: The switching flag is core data in the firmware switching mechanism, and its importance far exceeds that of the OTA image data. The most critical data should be placed in... The safest position (end) is where the switching flag can still ensure the bootloader makes the correct boot decision even if all the preceding OTA partition data is corrupted.

[0051] C. Low write frequency: The switching flag is only written once when the user triggers a firmware switch, which is extremely infrequent and does not need to be placed in a location that is easily accessible. Placing it at the end does not affect read and write performance.

[0052] D. Isolation from the common data partition: The switching flag is stored in the external Flash memory rather than the common data partition of the internal Flash memory because the switching flag is written by the current firmware during normal device operation, while the common data partition of the internal Flash memory may be performing data synchronization operations at this time. Separate storage can avoid read / write conflicts and improve system reliability.

[0053] Therefore, refer to together Figure 4 The internal Flash memory stores the high-speed Bootloader partition, ZigBee firmware partition, Matter firmware partition, and public data partition, featuring fast access speed and high reliability, and carrying frequently read / write runtime code and user data. The external Flash memory is divided into a ZigBee OTA partition, a Matter OTA partition, a switching flag partition, and a blank reserved area. These are used to store large-capacity OTA firmware images and low-frequency write switching flags, meeting the requirements of large storage and low cost. During normal device operation, the device directly loads the corresponding firmware from the internal Flash memory, with real-time data read / write services provided by the public data partition. During OTA upgrades, the new firmware image is first wirelessly written to the corresponding OTA partition in the external Flash memory, and after verification, it is then flashed to the target firmware partition in the internal Flash memory. When switching protocol firmware, the currently running firmware writes the switching command to the switching flag partition in the external Flash memory, and simultaneously backs up user data to the public data partition in the internal Flash memory, subsequently triggering a device reboot. After rebooting, the Bootloader reads the switching flag in the external Flash memory to complete verification and booting, and then starts the target protocol firmware from the internal Flash memory. After the target firmware boots, it reads and restores complete user data from the public data partition, quickly completing a seamless protocol switch. To facilitate understanding of the inventive concept of this application, a clear division of responsibilities and differentiated storage design between internal Flash and external Flash is provided in Table 3 below.

[0054] Table 3:

[0055] S12, when a protocol switching command input by the user is received during normal operation, the current protocol firmware is controlled to write the user configuration data into the public data partition and write integrity verification information into the switching flag partition.

[0056] The current protocol firmware is the protocol firmware that the IoT device runs under normal operating conditions, such as either ZigBee firmware or Matter firmware.

[0057] After the space allocation of the internal Flash memory and external Flash memory is completed, refer to... Figure 5 Users can trigger protocol switching operations via physical buttons (or virtual buttons) on the device. Specifically, when the device is in normal operating condition with the current communication protocol firmware, it monitors button input events in real time. When it detects that the user has triggered a preset button combination, such as a button press exceeding a preset time threshold, the device immediately responds to the button trigger and enters the protocol switching pre-confirmation process. The device uses LED indicators or other visual prompts to intuitively indicate the target communication protocol type to be switched to, using specified flashing frequencies and light colors, thus conveying the user's intention. Next, a confirmation waiting window of a preset duration is opened. If the user triggers the button again within this confirmation window to complete the switch confirmation command, the switch preparation process officially begins. If no confirmation command is received after the timeout, the switch request is automatically invalidated and the process terminates.

[0058] Upon receiving the user's handover confirmation command, the currently running source protocol firmware (i.e., the current protocol firmware, also known as the current firmware) first performs a data persistence operation, writing all current user-related data (also known as user configuration data), including sensor calibration parameters, device network configuration information, and real-time operating status data, into a pre-defined public data partition, thus completing the retention and backup of cross-firmware shared data. The current protocol firmware partition can be either a first protocol firmware partition or a second protocol firmware partition. If the current protocol firmware partition is the first protocol firmware partition, then the target protocol firmware partition after the handover will be the second protocol firmware partition.

[0059] After writing the user configuration data, the current protocol firmware writes a dedicated switching flag bit to the switching flag partition in the external Flash memory, marking the specific type of the target communication protocol to be switched to. Simultaneously, the firmware version number, CRC integrity check value, and other integrity verification information are also written to the switching flag partition. After the integrity verification information is written, the device performs a secondary verification operation on the written switching flag bit and integrity verification data to confirm that all data is written accurately and completely, preventing write errors from causing subsequent switching process failures. After all the above pre-processing operations are completed, the device triggers a system reset, handing over the subsequent firmware booting and protocol switching startup logic to the Bootloader partition.

[0060] In one optional implementation, during the secondary verification operation, the device first stores the user configuration data and integrity verification information as the original data and temporarily stores them locally in a preset temporary storage location (e.g., RAM) before performing a Flash write operation. After the write is complete, all written data is read back from the Flash physical address, and the read-back written data is compared byte by byte with the original data stored in memory. At the same time, the verification digest of the written data is recalculated and matched with the expected verification value. If all comparisons and matches are consistent, the write is deemed valid; otherwise, the data is cleared, a retry is triggered, or the handover is terminated. Specifically, the device first retains a complete copy of the original data before the write operation in its RAM. After the write operation is completed, the device immediately re-addresses the physical storage address of the switching flag partition corresponding to this write operation and reads out all the flag fields, version information fields, and verification information fields that were just written. Then, on the one hand, the actual stored data read out is compared byte by byte with the original data copy retained in RAM to confirm that there are no write deviations such as byte errors, address offsets, or data omissions. On the other hand, the verification digest is recalculated for the entire data segment read out and checked again with the pre-stored benchmark verification result. When both the byte-by-byte comparison and the verification digest check pass, it is confirmed that the writing of the switching flag and verification information is accurate and complete, and there are no data corruption problems caused by power failure interference, storage medium bit flipping, or communication abnormalities. The write process is deemed reliable and error-free, and the device can then trigger a system reset, handing over the subsequent firmware boot switching process to the Bootloader. If any comparison result does not match, the write operation is deemed abnormal. The device actively clears the invalid content written in this operation from the switch flag partition, invalidates the protocol switch request, and the device continues to maintain the current protocol and operate normally. At the same time, the abnormal log of this write verification failure is recorded, which effectively avoids the risk of subsequent bootloader failure, device inability to start normally, or even bricking due to incorrect data writing, and greatly improves the reliability and fault tolerance of the entire protocol switch process.

[0061] S13, execute system reset, and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information.

[0062] Refer to together Figure 5 and Figure 6After data synchronization and flag writing are completed, the current protocol firmware triggers a system soft reset. After the system restarts, it enters the bootloader process. In some embodiments, after the device power-on reset is completed and the bootloader partition starts, the boot decision logic is executed first. The bootloader program in the bootloader partition (i.e., the bootloader) reads the preset switching flag partition in the external Flash memory, reads the switching flag bit field pre-written in the partition, and accurately determines whether there is a valid protocol switching execution request in the current system through the definition of the validity of the flag bit. When it is determined that the current switching flag bit is valid and there is a protocol switching request, the bootloader synchronously reads the integrity verification information corresponding to the target protocol firmware (also known as the target firmware) pre-stored in the switching flag partition. This integrity verification information includes at least the firmware version identifier and the preset CRC baseline check value. Then, the bootloader performs a full traversal operation on the corresponding target protocol firmware partition in the internal Flash memory, calculates the real-time check value of the target protocol firmware partition in real time, and compares the calculated real-time check value with the read preset baseline check value (i.e., the preset check value). When the real-time calculated checksum perfectly matches the preset checksum, the target protocol firmware integrity check is considered successful. At this point, the preset checksum changes its system boot configuration to the target protocol firmware partition, simultaneously clears the current switch flag in the switch flag partition, eliminates any residual switch request flags, and then directly jumps to the program execution address to run the program code in the target protocol firmware partition, completing the loading and booting of the target firmware. When the real-time checksum does not match the preset checksum, and the checksum fails, the preset checksum determines that the target protocol firmware partition has data corruption or anomalies. It maintains the original current protocol firmware boot logic unchanged, simultaneously clears the switch flag in the switch flag partition, records the corresponding runtime error log for this checksum failure, and then jumps to the original current protocol firmware partition before the switch, ensuring stable and normal device boot and operation.

[0063] Alternatively, if the bootloader determines that there is no valid switching request after reading the switching flag, it will directly use the device's factory default boot configuration or the firmware partition record from the last successful and stable boot of the device to complete the normal boot process for this device firmware. For example, the bootloader may maintain the current protocol firmware boot logic before the switch without making any changes, clear the current switching flag in the switching flag partition, and then jump back to the current protocol firmware partition to continue running the original protocol firmware, ensuring that the device will not fail to boot and run normally due to target firmware verification errors.

[0064] S14, when the integrity verification result is determined to be successful, the target protocol firmware is controlled to start and complete initialization, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

[0065] In some embodiments, after the bootloader verifies the integrity of the target protocol firmware partition, the device immediately controls the corresponding target protocol firmware to officially start and execute the complete initialization process. For example, if the device is currently running ZigBee firmware, its corresponding first communication protocol is the ZigBee protocol; if the target protocol firmware to be switched to is Matter firmware, its corresponding second communication protocol is the Matter protocol. After verifying that the target firmware partition data is complete and undamaged, the bootloader jumps to the program execution entry point, loads and runs the Matter target protocol firmware, and drives the firmware to complete the initialization of all modules, including the underlying hardware, protocol stack, and network link. Once the target firmware initialization process is successfully completed, the IoT device can leave the original ZigBee protocol operating mode and smoothly switch to and access the IoT ecosystem corresponding to the Matter protocol. The entire process requires no additional firmware rewriting or hardware unit replacement, quickly completing a dynamic and smooth switch across communication protocols. This ensures that the device can stably and normally conduct communication and business operations based on the new protocol after the switch, significantly improving the user's cross-ecosystem experience. When the switch is confirmed to be successful, an LED indicates to the user that the protocol switch was successful.

[0066] In an optional implementation, the method further includes: Determine whether the target protocol firmware has completed initialization within a preset time period; When it is determined that the target protocol firmware has not completed initialization within the preset time period, a system reset is performed; Once the system reset is complete, the bootloader partition is controlled to read the failure counter of the target protocol firmware and increment the failure counter. Determine whether the accumulated failure counter value is less than a preset anomaly detection threshold; If the failure counter value is less than the anomaly determination threshold, the bootloader partition is controlled to retry starting the target protocol firmware partition.

[0067] Refer to together Figure 6 and Figure 7In some embodiments, after the target protocol firmware starts, the device monitors the initialization progress of the target protocol firmware in real time and continuously determines whether the target protocol firmware can complete the complete initialization process within a preset timeout period. When it is detected that the target protocol firmware fails to complete the initialization normally within the preset time period due to problems such as program freezing, resource abnormalities, or protocol stack loading failures, the device's built-in watchdog timer is triggered, controlling the entire IoT device to perform a forced system reset.

[0068] After the device completes this system reset, the Bootloader partition reads the failure counter value corresponding to the pre-maintained target protocol firmware and performs a value increment update operation on the failure counter. Then, it compares the incremented failure counter value with the pre-configured exception judgment threshold N. If the incremented failure counter value is less than the preset exception judgment threshold, the boot failure is determined to be an occasional temporary exception, and the Bootloader partition automatically re-attempts to load and start the target protocol firmware partition, and executes the protocol switching process again.

[0069] If the accumulated failure counter value is greater than or equal to the preset anomaly judgment threshold, it is determined that the current target protocol firmware has a persistent operational anomaly, rather than a temporary or occasional failure. At this time, the bootloader actively clears the protocol switching flag bit remaining in the switching flag partition, terminates the current protocol switching process, and completely rolls back the device's firmware boot link to the current protocol firmware partition before the execution of this protocol switching operation. It loads and runs the original current protocol firmware partition, restoring the IoT device to the first communication protocol working mode before the switch. At the same time, the device outputs preset visual or perceptible status prompt signals, such as controlling the LED indicator to flash in a preset manner, intuitively informing the user that the cross-protocol switching operation ultimately failed, ensuring that the device can always operate stably and normally, and completely avoiding the risk of device crashing and being unable to recover due to a single switching anomaly.

[0070] In an optional implementation, after the target protocol firmware is started and initialized, the method further includes: Read the user configuration data from the public data partition; The user configuration data is parsed and then restored to the runtime data structure of the target protocol firmware. Perform integrity verification on the restored user configuration data and compare the real-time verification results with the pre-stored valid verification benchmarks; When the real-time data verification result meets the valid verification benchmark, the second communication protocol is loaded and the system enters normal working state through the second communication protocol. When the real-time data verification result does not meet the valid verification benchmark, the user configuration data is discarded, and the target protocol firmware is started by loading the preset default configuration.

[0071] In some embodiments, after completing the startup and initialization process of the target protocol firmware, the target protocol firmware first accesses a pre-divided public data partition and reads the pre-persistently stored user configuration data from this public data partition. Next, the target protocol firmware performs compliance parsing on the read user configuration data, and according to its own data definition rules, completely maps and restores the parsed user configuration data to the target protocol firmware's dedicated runtime data structure, thus restoring the data context. After the data restoration and writing are complete, the target protocol firmware performs integrity verification on all the currently restored user configuration data, calculates the real-time verification result (e.g., cyclic redundancy check CRC value) corresponding to the data, and compares this real-time verification result with pre-stored valid verification benchmarks item by item. If the calculated real-time verification result matches and meets the preset valid verification benchmarks, the user configuration data is determined to be complete and valid. The IoT device loads the dedicated operating parameters corresponding to the target protocol firmware, switches to the second communication protocol, and formally enters a stable and normal device operating state. If the real-time data verification result does not match the valid verification benchmark and the verification fails, it is determined that the read and recovered user configuration data is corrupted or abnormal. The device will directly discard the abnormal user configuration data read at the moment and load the device's factory default configuration to start the target protocol firmware, ensuring that the device can still operate normally. At the same time, the abnormal records related to this data recovery will be retained.

[0072] In an optional implementation, the method further includes: When the user configuration data is stored in the public data partition, the user configuration data is also synchronously stored in the private data partition corresponding to the current protocol firmware. Monitor user data change events in the current protocol firmware, and when a change in the user configuration data is detected, synchronously write the changed user configuration data to the public data partition; Within the public data partition, a corresponding version identifier is maintained for the user configuration data, and the freshness of the user configuration data is determined based on the version identifier. The latest user configuration data is selected according to the freshness.

[0073] In some embodiments, to ensure user data consistency between the two firmware sets (i.e., the current protocol firmware and the target protocol firmware), the device employs a real-time data synchronization mechanism. See also... Figure 8Specifically, to ensure consistent user data and seamless switching between the two firmware sets, the device stores generated user configuration data simultaneously in both the current protocol firmware's dedicated private data area and the public data partition during operation, achieving dual redundant backup. The device monitors user configuration data changes in real time. When network information, sensor calibration parameters, or device operating configurations are updated, the firmware does not directly overwrite the original official data address. Instead, it uses an atomic write method to synchronize the data. First, the latest changed data is completely written to a pre-allocated temporary storage location. After the write integrity is verified, the valid data access pointer is updated to officially take effect, completely avoiding data corruption caused by power outages, resets, or other anomalies during the write process. Simultaneously, each piece of user configuration data in the public data partition maintains a continuously incrementing independent version number. When performing cross-protocol firmware switching or when the target firmware starts reading data, the freshness of the data can be accurately distinguished by comparing the version numbers, filtering and loading the latest and valid user configuration data, and automatically ignoring expired or ineffective dirty data, further improving the accuracy and reliability of data recovery after protocol switching.

[0074] Reference Figure 9 The diagram shown illustrates a framework of a dynamic communication protocol switching system according to an embodiment of this application. The system hardware layer includes internal Flash, external Flash, and a processor; the software layer sequentially comprises an application layer, a protocol layer, an engine layer, and a hardware layer driver module. The application layer includes a ZigBee application layer and a Matter application layer, serving as the main execution entities for the ZigBee and Matter dual-protocol firmware, respectively. The protocol layer configures corresponding ZigBee and Matter protocol stacks, responsible for protocol parsing and data interaction of the communication link. The engine layer integrates data synchronization management, read / write interfaces, and version management modules, used to manage the real-time synchronization and consistency maintenance of user data in the public data partition. In the hardware layer, the internal Flash is divided into a Bootloader partition, a ZigBee firmware partition, a Matter firmware partition, and a public data partition, used for system booting, dual-protocol firmware storage, and cross-firmware data sharing, respectively. The external Flash is divided into a ZigBee OTA partition, a Matter OTA partition, a blank reserved area, and a switching flag partition, used to store OTA upgrade images and switching flag information.

[0075] When the system is running, the processor responds to the switching request, synchronously writes user data to the public data partition through the engine layer, and writes a flag to the external Flash switching flag partition. After reset, the bootloader reads the flag and verifies the target firmware. If it passes, the target protocol firmware is started to realize the dynamic switching between ZigBee and Matter protocols. If initialization fails, it automatically rolls back based on the failure count and watchdog mechanism to maintain the normal operation of the original protocol.

[0076] This application can be applied to any IoT device. The following example uses a door magnetic sensor based on the nRF54L15 chip to demonstrate how to switch a door magnetic sensor from ZigBee to Matter. The specific implementation steps include: Step 1: When the device leaves the factory, the internal Flash memory contains a pre-installed Bootloader, ZigBee firmware (including Bluetooth functionality), and Matter firmware (including Bluetooth functionality), which runs in ZigBee mode by default.

[0077] Step 2: The user presses and holds the device button for 5 seconds. The device's LED indicator flashes green 3 times, indicating that it is about to switch to the Matter protocol.

[0078] Step 3: The user presses the button again within 3 seconds to confirm the switch.

[0079] Step 4: The ZigBee firmware writes the current sensor calibration parameters (magnetic induction sensitivity, door status reporting interval, etc.) and device configuration information to the public data partition.

[0080] Step 5: The ZigBee firmware writes the target protocol flag (Matter) and the target firmware CRC check value to the external Flash switching flag partition.

[0081] Step 6: The device performs a soft reset and enters the Bootloader.

[0082] Step 7: The Bootloader reads the switching flag and confirms that the target is Matter firmware.

[0083] Step 8: The Bootloader performs a CRC check on the Matter firmware partition in the internal Flash, and the check passes.

[0084] Step 9: The Bootloader clears the switching flag and boots from the Matter firmware partition.

[0085] Step 10: After the Matter firmware boots up, it reads and restores the sensor calibration parameters from the public data partition.

[0086] Step 11: The device's LED indicator light will stay green for 2 seconds, indicating a successful switch. The device will then begin normal operation in Matter protocol mode, and the Bluetooth function will be ready at the same time.

[0087] Additionally, using the same door magnetic sensor as an example, assuming there is an anomaly in the ZigBee firmware, how to automatically roll back from Matter to ZigBee? The specific automatic rollback process includes: Step 1: The user triggers the switching process from Matter to ZigBee (similar to Example 1).

[0088] Step 2: The Bootloader verifies the ZigBee firmware CRC and starts the ZigBee firmware.

[0089] Step 3: If an exception is encountered during the ZigBee firmware startup process (such as hardware initialization failure), the watchdog timer will time out and trigger a system reset.

[0090] Step 4: The Bootloader detects that the ZigBee firmware startup failure counter value is 1 (less than the threshold, assuming the threshold is 3), and tries to start the ZigBee firmware again.

[0091] Step 5: If the bootloader fails to start three times in a row, it determines that the ZigBee firmware is abnormal and automatically rolls back to the Matter firmware before the switch.

[0092] Step 6: The device resumes operation in Matter protocol mode, and the LED indicator flashes red to indicate that the switching failed.

[0093] Additionally, this paper provides an example of OTA upgrades using ZigBee firmware via Bluetooth, demonstrating a low-cost, seamless, and downtime-free independent remote over-the-air upgrade for a single firmware without affecting existing operating protocols or modifying other firmware partitions. Specific implementation steps include: Step 1: The device is running normally in ZigBee mode, and the Bluetooth function is ready.

[0094] Step 2: The user sends the ZigBee firmware OTA upgrade package to the device via the Bluetooth channel of the mobile app.

[0095] Step 3: Write the OTA upgrade package to the ZigBee OTA partition in the external Flash memory.

[0096] Step 4: After the upgrade package is written, the device performs a firmware update, flashing the new firmware from the external Flash to the ZigBee firmware partition in the internal Flash.

[0097] Step 5: After the update is complete, the Bootloader verifies the new ZigBee firmware. If the verification is successful, the system will boot with the new ZigBee firmware.

[0098] Step 6: The entire OTA upgrade process does not affect the Matter firmware partition and the public data partition.

[0099] Reference Figure 10 The diagram shown is a functional block diagram of a communication protocol dynamic switching device according to an embodiment of this application.

[0100] In some embodiments, the communication protocol dynamic switching device 10 may include multiple functional modules composed of computer program segments. The computer programs of each program segment of the communication protocol dynamic switching device 10 may be stored in the memory of the Internet of Things (IoT) device and executed by at least one processor to perform (see details). Figure 1 (Description) The communication protocol dynamically switches. Based on its function, it can be divided into multiple functional modules. These functional modules may include: a storage partitioning module 101, an instruction processing module 102, a reset verification module 103, and a switching startup module 104. The module referred to in this application is a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0101] The storage partitioning module 101 is used to divide the internal Flash memory into a bootloader partition, a protocol firmware partition, and a public data partition, and to divide the external Flash memory into an OTA upgrade partition, a blank reserved area, and a switching flag partition; the protocol firmware partition includes at least a first protocol firmware partition and a second protocol firmware partition, and the OTA upgrade partition includes at least a first OTA upgrade partition and a second OTA upgrade partition.

[0102] The instruction processing module 102 is used to control the current protocol firmware to write user configuration data into the public data partition and write integrity verification information into the switching flag partition when it receives a protocol switching instruction input by the user in normal operation.

[0103] The reset verification module 103 is used to perform system reset and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information.

[0104] The switching startup module 104 is used to control the target protocol firmware to start and complete initialization when the integrity verification result is determined to be successful, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

[0105] It should be understood that the various variations and specific embodiments of the communication protocol dynamic switching method provided in the above embodiments are also applicable to the communication protocol dynamic switching device of this embodiment. Through the foregoing detailed description of the communication protocol dynamic switching method, those skilled in the art can clearly understand the implementation method of the communication protocol dynamic switching device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0106] See Figure 11 The diagram shown is a schematic representation of the structure of an IoT device according to an embodiment of this application. In a preferred embodiment of this application, the IoT device 11 includes a memory 111, at least one processor 112, and at least one communication bus 113.

[0107] Those skilled in the art should understand that Figure 11 The structure of the IoT device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The IoT device 11 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0108] In some embodiments, the Internet of Things (IoT) device 11 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The IoT device 11 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0109] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and IoT devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0110] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0111] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0112] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, portable hard drive, read-only memory (ROM). Various media that can store program code, such as only memory, random access memory (RAM), magnetic disks or optical disks.

[0113] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0114] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0115] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for dynamically switching communication protocols, characterized in that, The method, applicable to Internet of Things (IoT) devices with built-in internal Flash memory and external Flash memory, includes: The internal Flash memory is divided into a bootloader partition, a protocol firmware partition, and a common data partition, and the external Flash memory is divided into an OTA upgrade partition, a blank reserved area, and a switching flag partition; the protocol firmware partition includes at least a first protocol firmware partition and a second protocol firmware partition, and the OTA upgrade partition includes at least a first OTA upgrade partition and a second OTA upgrade partition. When a protocol switching command is received from the user during normal operation, the current protocol firmware is controlled to write the user configuration data into the public data partition and write integrity verification information into the switching flag partition; the current protocol firmware is the protocol firmware that the IoT device runs under normal operation. Perform a system reset and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information; When the integrity verification result is determined to be successful, the target protocol firmware is controlled to start and complete initialization, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

2. The method for dynamic switching of communication protocols according to claim 1, characterized in that, The step of controlling the bootloader partition to read the switching flag partition and performing integrity verification on the target protocol firmware partition based on the integrity verification information includes: Read the switching flag bit in the switching flag partition, and determine whether there is a valid switching request based on the switching flag bit; When a valid handover request is determined, the verification value of the target protocol firmware is calculated based on the integrity verification information, and the verification value is compared with a preset verification value. When the verification value is consistent with the preset verification value, the verification result is determined to be successful. The bootloader partition is configured to start as the target protocol firmware partition. The switching flag bit in the switching flag partition is cleared. The program code in the target protocol firmware partition is then jumped to and executed. When the verification value is inconsistent with the preset verification value, the verification result is determined to be a verification failure. The current protocol firmware is maintained unchanged, the switching flag bit in the switching flag partition is cleared, and the process jumps back to the current protocol firmware partition to continue running.

3. The method for dynamic switching of communication protocols according to claim 1, characterized in that, The method further includes: Determine whether the target protocol firmware has completed initialization within a preset time period; When it is determined that the target protocol firmware has not completed initialization within the preset time period, a system reset is performed; Once the system reset is complete, the bootloader partition is controlled to read the failure counter of the target protocol firmware and increment the failure counter. Determine whether the accumulated failure counter value is less than a preset anomaly detection threshold; If the failure counter value is less than the anomaly determination threshold, the bootloader partition is controlled to retry starting the target protocol firmware partition.

4. The method for dynamic switching of communication protocols according to claim 3, characterized in that, The method further includes: If the failure counter value is greater than or equal to the anomaly determination threshold, it is determined that the target protocol firmware has an operational anomaly, and the switching flag bit in the switching flag partition is cleared; Roll back the firmware boot link to the current protocol firmware partition before the handover operation was performed; Load and start the current protocol firmware partition, restore to the first communication protocol before the switch, and output a preset status prompt signal to inform the user that the protocol switch operation has failed.

5. The method for dynamic switching of communication protocols according to claim 1, characterized in that, After the target protocol firmware is started and initialized, the method further includes: Read the user configuration data from the public data partition; The user configuration data is parsed and then restored to the runtime data structure of the target protocol firmware. Perform integrity verification on the restored user configuration data and compare the real-time verification results with the pre-stored valid verification benchmarks; When the real-time data verification result meets the valid verification benchmark, the second communication protocol is loaded and the system enters normal working state through the second communication protocol. When the real-time data verification result does not meet the valid verification benchmark, the user configuration data is discarded, and the target protocol firmware is started by loading the preset default configuration.

6. The method for dynamic switching of communication protocols according to claim 1, characterized in that, After the current protocol firmware writes user configuration data to the public data partition and writes integrity verification information to the switching flag partition, the method further includes: The user configuration data and integrity verification information are identified as the original data to be retained, and the original data to be retained is temporarily stored in a preset temporary storage location; The original data to be retained is compared bit by bit with the data already written obtained from the switching flag partition; If the retained original data matches the written data completely, it is determined that the retained original data was successfully written. If any data in the retained original data and the written data are inconsistent, it is determined that the retained original data was written abnormally, and the written data in the switching flag partition is cleared.

7. The method for dynamic switching of communication protocols according to any one of claims 1 to 6, characterized in that, The method further includes: When the user configuration data is stored in the public data partition, the user configuration data is also synchronously stored in the private data partition corresponding to the current protocol firmware. Monitor user data change events in the current protocol firmware, and when a change in the user configuration data is detected, synchronously write the changed user configuration data to the public data partition; Within the public data partition, a corresponding version identifier is maintained for the user configuration data, and the freshness of the user configuration data is determined based on the version identifier. The latest user configuration data is selected according to the freshness.

8. A communication protocol dynamic switching device, characterized in that, An Internet of Things (IoT) device applicable to both built-in internal Flash memory and external Flash memory, the device comprising: The storage partitioning module is used to divide the internal Flash memory into a bootloader partition, a protocol firmware partition, and a common data partition, and to divide the external Flash memory into an OTA upgrade partition, a blank reserved area, and a switching flag partition; the protocol firmware partition includes at least a first protocol firmware partition and a second protocol firmware partition, and the OTA upgrade partition includes at least a first OTA upgrade partition and a second OTA upgrade partition. The instruction processing module is used to control the current protocol firmware to write user configuration data into the public data partition and write integrity verification information into the switching flag partition when a protocol switching instruction input by the user is received during normal operation; the current protocol firmware is the protocol firmware running on the IoT device during normal operation. The reset verification module is used to perform system reset and control the bootloader partition to read the switching flag partition, and perform integrity verification on the target protocol firmware partition according to the integrity verification information. The switching startup module is used to control the target protocol firmware to start and complete initialization when the integrity verification result is determined to be successful, thereby switching from the first communication protocol corresponding to the current protocol firmware to the second communication protocol corresponding to the target protocol firmware.

9. An Internet of Things (IoT) device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The memory includes an internal Flash memory and an external Flash memory. When the processor executes the computer program, it implements the steps of the communication protocol dynamic switching method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the communication protocol dynamic switching method according to any one of claims 1 to 7.

Images