Dual-mode OTA firmware upgrading system and method based on LoRa and BLE

Abstract

The invention provides a dual-mode OTA firmware upgrading system and method based on LoRa and BLE, relates to the technical field of Internet of Things equipment management, and solves the technical problems that the prior art is limited by a single communication mode and cannot give consideration to the requirements of coverage, efficiency, reliability and safety in Internet of Things equipment upgrading. The system comprises a Web management background which is used for obtaining a user instruction and issuing an upgrading task to a central gateway; the central gateway is used for downloading the upgrading firmware package according to the upgrading task and generating an upgrading instruction; communicating with a terminal device through a LoRa network, and transmitting an upgrade instruction and an upgrade firmware package in a broadcast mode; the mobile terminal App is used for establishing Bluetooth connection with specified terminal equipment in a BLE mode and transmitting an upgrading firmware package; and the terminal equipment is used for receiving and analyzing the upgrading instruction and the upgrading firmware package from the central gateway or the mobile terminal App, and executing firmware verification, updating and rollback operations. The OTA firmware upgrading method and device are used in the OTA firmware upgrading process.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) device management technology, and in particular to a dual-mode OTA firmware upgrade system and method based on LoRa and BLE. Background Technology

[0002] Current wireless firmware upgrades for IoT devices primarily rely on single communication technologies, such as Bluetooth Low Energy (BLE) or long-range LoRa radio. BLE-based upgrade solutions are limited by their short communication range and typically only support point-to-point connections, making efficient deployment and management of a large number of dispersed devices difficult. While LoRa-based upgrade solutions can achieve long-range coverage, when performing concurrent OTA upgrades on multiple devices, the large number of broadcast data packets are prone to collisions in the limited channel, leading to high packet loss rates and an unstable upgrade process. Furthermore, existing solutions generally lack effective mechanisms for secure and reliable upgrades of the device's underlying In-Application Program (IAP), and their anti-interference and fault tolerance capabilities during the upgrade process are insufficient, resulting in a high risk of upgrade failure and failing to meet the needs of large-scale, high-reliability IoT operations and maintenance. Summary of the Invention

[0003] This application provides a dual-mode OTA firmware upgrade system and method based on LoRa and BLE, which solves the technical problem that the existing technology is limited by a single communication mode and cannot meet the requirements of coverage, efficiency, reliability and security in the upgrade of IoT devices.

[0004] To achieve the above objectives, this application adopts the following technical solution: Firstly, a dual-mode OTA firmware upgrade system based on LoRa and BLE is provided, including a web management backend, a central gateway, a mobile terminal App, and terminal devices; The web management backend is used to obtain user instructions, manage terminal device information, and send upgrade tasks to the central gateway; wherein, the upgrade task includes the target terminal device identifier, upgrade firmware version information, and a specified upgrade mode, the upgrade mode including LoRa mode or BLE mode; The central gateway is equipped with a LoRa communication module and a network connection module, used to receive upgrade tasks, download upgrade firmware packages from a remote server according to the upgrade tasks and generate upgrade instructions; and communicate with terminal devices through the LoRa network to transmit upgrade instructions and upgrade firmware packages in a broadcast manner. The mobile terminal App is used to establish a Bluetooth connection with a designated terminal device in BLE mode and to transmit upgrade firmware packages. The terminal device has a built-in LoRa communication module, BLE module and OTA upgrade management unit, which is used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update and rollback operations.

[0005] Based on the above technical solutions, the dual-mode OTA firmware upgrade system based on LoRa and BLE provided in this application constructs an adaptive scenario-based collaborative upgrade system by organically integrating the dual-mode communication capabilities of LoRa and BLE. The system can intelligently schedule and seamlessly complement the wide-area, efficient broadcasting of LoRa and the precise, reliable point-to-point transmission of BLE according to device distribution, signal quality, and upgrade requirements. This ensures high reliability during the upgrade process while significantly improving upgrade coverage and operational flexibility. Terminal devices can autonomously or upon instruction select the optimal communication path to receive upgrade data and execute a complete security process from data verification and secure writing to abnormal rollback, achieving secure, efficient, and unified firmware management for large-scale IoT devices across all scenarios.

[0006] In conjunction with the first aspect described above, in one possible implementation, the central gateway further includes a firmware package preprocessing module; wherein the firmware package preprocessing module includes: The firmware upgrade package is divided into multiple consecutively numbered data fragments. Generate a first checksum for each data fragment packet and a second checksum for the upgrade firmware packet; The data fragment packets, the first checksum, the second checksum, and the upgrade firmware package are cached in local storage.

[0007] In conjunction with the first aspect described above, one possible implementation also includes dynamic mode selection; wherein the dynamic mode selection includes: The central gateway broadcasts an upgrade command via the LoRa network, the upgrade command including a preset RSSI threshold; The OTA upgrade management unit is configured to: after receiving an upgrade command, measure the LoRa signal strength from the central gateway; if the LoRa signal strength is lower than the RSSI threshold, actively switch to BLE mode and send a mode switching request to the mobile terminal App or the central gateway, and receive the upgrade firmware package through the BLE channel.

[0008] In conjunction with the first aspect above, in one possible implementation, the central gateway further includes a reliable transmission control module for performing data broadcasting and packet re-uploading processes in LoRa mode; wherein, the reliable transmission control module includes: Data fragment packets are sent sequentially in broadcast or multicast format; Listen to and record the ACK or NACK information returned by the terminal device for each data fragment packet to obtain feedback information; Generate a list of missing fragment packages for different terminal devices based on feedback information; By using LoRa unicast or adjusting communication parameters, the list of missing fragment packets can be retransmitted in a targeted manner.

[0009] In conjunction with the first aspect above, in one possible implementation, the mobile terminal App further includes: Synchronously obtain upgrade tasks and corresponding upgrade firmware packages from the web management backend or central gateway; In BLE mode, the central device establishes a point-to-point connection with the terminal devices. According to the preset data packet format and transmission rate, the data of the upgrade firmware package is transmitted to the terminal device in fragments using an end-to-end ACK mechanism.

[0010] In conjunction with the first aspect above, in one possible implementation, the OTA upgrade management unit further includes: Dual-mode communication control subunit: used for initialization, mode switching and data link maintenance of LoRa and BLE communication; Data verification and reassembly subunit: used to perform first-level CRC verification on data fragment packets based on the first verification code, and to perform integrity verification on the entire reassembled firmware packet based on the second verification code after reception; Security Upgrade Execution Subunit: After successful verification, the firmware package is written to the specified Flash storage area. After writing is completed, read and verification operations are performed. Once confirmed to be correct, the device is restarted and the IAP bootloader completes the final program jump and update.

[0011] In conjunction with the first aspect described above, in one possible implementation, the security upgrade execution subunit further includes a rollback mechanism; wherein the rollback mechanism includes: Before writing new firmware, back up the currently running valid firmware to a separate storage area; If the new firmware fails to boot or malfunctions, a rollback process is triggered to restore the original firmware from the backup area and report the upgrade failure status.

[0012] In conjunction with the first aspect described above, in one possible implementation, the Web management backend further includes a visual monitoring interface; wherein the visual monitoring interface includes: Displays the execution status of each central gateway upgrade task; Displays the current mode, upgrade progress, reception success rate, and final upgrade result of each terminal device; The display shows the overall network upgrade success rate and a list of terminal devices that failed to upgrade.

[0013] In conjunction with the first aspect mentioned above, in one possible implementation, the central gateway has an incremental upgrade cache in its local storage for storing differential upgrade packages between different firmware versions; when the upgrade task issued by the Web management backend is an incremental upgrade, the central gateway directly obtains the differential upgrade package from the cache or a remote server for processing.

[0014] Secondly, a dual-mode OTA firmware upgrade method based on LoRa and BLE is provided, including: The upgrade instructions and upgrade firmware package are obtained from the central gateway or mobile terminal App through the LoRa communication module or BLE module; wherein, the upgrade instructions include firmware identifier and upgrade mode indication; If the upgrade mode is specified, the communication module corresponding to the specified mode will be used to prepare to receive data; if the upgrade mode is set to automatic selection, the LoRa mode or BLE mode will be used for subsequent communication based on the preset strategy or the real-time measured wireless signal quality. According to the determined pattern, the upgrade firmware package, which is divided into multiple data fragments, is received, and a first-level verification is performed on each data fragment; after all data fragments have been received, a second-level verification is performed on the complete firmware package obtained by reassembling all data fragments. Once both levels of verification pass, the complete firmware package is written to the target area of ​​the non-volatile memory, and a verification operation is performed after the writing is completed. After successful verification, the control device restarts, and the new firmware is activated and run by the built-in IAP bootloader.

[0015] Thirdly, an electronic device is provided, comprising: a communication unit and a processing unit; the communication unit is used to acquire user instructions, manage terminal device information, and send upgrade tasks to a central gateway; the processing unit is used to receive upgrade tasks, download upgrade firmware packages from a remote server according to the upgrade tasks, and generate upgrade instructions; communicate with terminal devices via a LoRa network, and transmit upgrade instructions and upgrade firmware packages in a broadcast manner; in BLE mode, establish a Bluetooth connection with a designated terminal device and transmit upgrade firmware packages; receive and parse upgrade instructions and upgrade firmware packages from a central gateway or a mobile terminal App, and perform firmware verification, update, and rollback operations.

[0016] Fourthly, this application provides an electronic device, including: a processor and a storage medium; the storage medium includes instructions, and the processor is configured to execute the instructions to implement the methods described in the first aspect and any possible implementation thereof. The electronic device may be an electronic device or a chip within an electronic device.

[0017] Fifthly, this application provides a dual-mode OTA firmware upgrade system based on LoRa and BLE, including: a web management backend, a central gateway, a mobile terminal app, and terminal devices; wherein, the web management backend is used to obtain user instructions, manage terminal device information, and issue upgrade tasks to the central gateway; the central gateway is used to receive upgrade tasks, download upgrade firmware packages from a remote server according to the upgrade tasks, and generate upgrade instructions; it communicates with terminal devices through a LoRa network and transmits upgrade instructions and upgrade firmware packages in a broadcast manner; the mobile terminal app is used to establish a Bluetooth connection with a designated terminal device in BLE mode and transmit upgrade firmware packages; the terminal devices are used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or the mobile terminal app, and perform firmware verification, update, and rollback operations.

[0018] In a sixth aspect, this application provides a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0019] In a seventh aspect, this application provides a computer program product containing instructions that, when run on an electronic device, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0020] This application provides a dual-mode OTA firmware upgrade system and method based on LoRa and BLE. By constructing a dual-mode collaborative upgrade system integrating LoRa and BLE, the inherent defects of a single communication mode are effectively overcome. The system can intelligently select the optimal communication path based on the device signal strength. Combined with broadcast distribution and intelligent targeted packet replenishment mechanisms, it significantly alleviates channel conflict problems during concurrent upgrades of multiple devices, greatly improving the upgrade success rate and efficiency. By employing a dual verification mechanism of data fragmentation and overall firmware, secure write verification, and automatic rollback functions, it ensures extremely high reliability of data transmission and update processes, and supports full-stack firmware security upgrades, including IAP. Simultaneously, the system supports incremental upgrades and visual monitoring, achieving flexible, efficient, reliable, and secure unified firmware management for a wide-area distributed device group.

[0021] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0022] Figure 1 A system architecture diagram of a dual-mode OTA firmware upgrade system based on LoRa and BLE provided for embodiments of this application; Figure 2 A flowchart illustrating a dual-mode OTA firmware upgrade method based on LoRa and BLE provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0024] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0025] The dual-mode OTA firmware upgrade system based on LoRa and BLE provided in this application embodiment can be applied to, for example... Figure 1 In the dual-mode OTA firmware upgrade system 100 based on LoRa and BLE shown, as Figure 1 As shown, the communication system includes: a web management backend 10, a central gateway 20, a mobile terminal App 30, and terminal devices 40; Among them, the Web management backend 10 is used to obtain user instructions, manage terminal device information, and send upgrade tasks to the central gateway; The central gateway 20 is used to receive upgrade tasks, download upgrade firmware packages from remote servers according to upgrade tasks, and generate upgrade instructions; it communicates with terminal devices through the LoRa network and transmits upgrade instructions and upgrade firmware packages in a broadcast manner. Mobile terminal App30 is used to establish a Bluetooth connection with a designated terminal device in BLE mode and to transmit upgrade firmware packages; Terminal device 40 is used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update and rollback operations.

[0026] To address the technical problem that existing technologies are limited by a single communication mode and cannot simultaneously meet the requirements of coverage, efficiency, reliability, and security in IoT device upgrades, this application provides a dual-mode OTA firmware upgrade system based on LoRa and BLE. The system includes: a web management backend, a central gateway, a mobile terminal App, and terminal devices. The web management backend is used to obtain user instructions, manage terminal device information, and send upgrade tasks to the central gateway; wherein, the upgrade task includes the target terminal device identifier, upgrade firmware version information, and a specified upgrade mode, the upgrade mode including LoRa mode or BLE mode; The central gateway is equipped with a LoRa communication module and a network connection module, used to receive upgrade tasks, download upgrade firmware packages from a remote server according to the upgrade tasks and generate upgrade instructions; and communicate with terminal devices through the LoRa network to transmit upgrade instructions and upgrade firmware packages in a broadcast manner. The mobile terminal App is used to establish a Bluetooth connection with a designated terminal device in BLE mode and to transmit upgrade firmware packages. The terminal device has a built-in LoRa communication module, BLE module and OTA upgrade management unit, which is used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update and rollback operations.

[0027] Based on this, the technical problem that existing technologies are limited by a single communication mode and cannot simultaneously meet the requirements of coverage, efficiency, reliability and security in the upgrade of IoT devices is solved.

[0028] The dual-mode OTA firmware upgrade system based on LoRa and BLE provided in this application includes: The web-based management backend is used to obtain user commands, manage terminal device information, and send upgrade tasks to the central gateway.

[0029] The upgrade task includes the target terminal device identifier, upgrade firmware version information, and a specified upgrade mode, which includes LoRa mode or BLE mode.

[0030] It should be noted that by using a pre-configuration mechanism for tasks, the mode decision-making is transformed from real-time negotiation to planned scheduling. This not only preserves the scenario adaptability of the dual-mode system, but also reduces the decision-making complexity and communication overhead of terminal devices in the early stages of upgrades through predefined modes. At the same time, it provides a basis for the backend to predict the global upgrade progress and optimize resource allocation, significantly improving the manageability and execution efficiency of large-scale device upgrade tasks.

[0031] For example, users can select the device group to be upgraded, upload the new firmware file, and specify LoRa mode (for batch upgrades of remote device groups) or BLE mode (for point-to-point upgrades of specific devices in the field) in the task configuration through the visual interface of the web management backend. The backend system automatically encapsulates the device list, firmware storage path, and mode parameters into a structured upgrade task, adds it to the task queue, and sends it to the corresponding central gateway in real time. The gateway automatically calls the corresponding communication module to execute the upgrade process based on the device identifier and mode command in the task. This design realizes centralized configuration and one-click deployment of upgrade strategies. Through task-level mode predefinition, the system can coordinate communication resources in advance, effectively avoiding mode switching delays and command conflicts during the upgrade process.

[0032] In some implementations, the web management backend further includes a visual monitoring interface; wherein the visual monitoring interface includes: Displays the execution status of each central gateway upgrade task; Displays the current mode, upgrade progress, reception success rate, and final upgrade result of each terminal device; The display shows the overall network upgrade success rate and a list of terminal devices that failed to upgrade.

[0033] It should be noted that by establishing an end-to-end real-time status feedback and centralized visualization mechanism, the decentralized device upgrade process is transformed into a globally observable and measurable operation and maintenance view. This enables administrators to grasp the upgrade status of the entire network in real time, quickly locate bottleneck gateways or abnormal devices, and make precise interventions or retries based on the failure list, which greatly improves the transparency, controllability and operation and maintenance efficiency of large-scale upgrade tasks.

[0034] For example, the visual monitoring interface establishes a real-time data link with the central gateway and terminal devices to dynamically acquire and integrate upgrade process data: the central gateway periodically reports its task queue status and the number of broadcast / retransmissions of each data packet; when the terminal device reports a heartbeat or status change, it synchronizes its current communication mode, the number of received fragments / total fragments, data verification results, and the final upgrade success / failure code; the background service associates this real-time data with task configuration information, dynamically renders it to the monitoring interface in the form of charts and lists, and calculates statistical indicators such as the overall network success rate in real time.

[0035] The central gateway, equipped with a LoRa communication module and a network connection module, is used to receive upgrade tasks, download upgrade firmware packages from remote servers according to upgrade tasks, and generate upgrade instructions; it communicates with terminal devices through the LoRa network and transmits upgrade instructions and upgrade firmware packages in a broadcast manner.

[0036] It should be noted that by using a closed-loop control process of "preprocessing-broadcasting-listening-precise retransmission", the massive data flood that is indiscriminate in traditional LoRa broadcast upgrades is optimized into reliable data distribution that is traceable and retransmittable. This greatly alleviates the channel contention and data collision problems when multiple devices are running concurrently. While maintaining the wide coverage advantage of LoRa, it significantly improves the success rate and timeliness of large-scale device group upgrades.

[0037] For example, after receiving the upgrade task from the Web management backend, the central gateway first downloads the complete upgrade firmware package from the designated firmware server through its network connection module, and preprocesses the firmware package by dividing it into multiple data fragments with consecutive sequence numbers. At the same time, it generates a first-level checksum for each fragment and a second-level checksum for the entire package. Subsequently, the gateway uses the LoRa module to cyclically broadcast upgrade metadata instructions (including firmware version, total number of fragments, and checksum information) to the target device group at a specific power and spreading factor. Then, it sends data packets fragment by fragment in a time-division broadcast manner. During the broadcast, the gateway synchronously listens for ACK / NACK confirmation information returned by the terminal devices through LoRa, dynamically maintains the fragment reception status table of each device, and after completing the first round of broadcast, it initiates low-power, targeted unicast retransmission only for the missing fragment sequences of different devices.

[0038] In some implementations, the central gateway further includes a firmware package preprocessing module; wherein the firmware package preprocessing module includes: The firmware upgrade package is divided into multiple consecutively numbered data fragments. Generate a first checksum for each data fragment packet and a second checksum for the upgrade firmware packet; The data fragment packets, the first checksum, the second checksum, and the upgrade firmware package are cached in local storage.

[0039] It should be noted that by adapting to the intelligent fragmentation and two-level verification mechanism of the wireless link, not only is the efficiency and compatibility of data transmission optimized, but a dual integrity verification barrier from fragmentation to the whole is also built, enabling the system to accurately locate and recover data corruption at any level in unreliable wireless environments. The local cache structure provides core data support for achieving efficient packet re-uploading, breakpoint resumption, and even multi-version firmware management, significantly improving the robustness and maintainability of the upgrade process.

[0040] For example, after downloading the upgrade firmware package, the firmware package preprocessing module of the central gateway first dynamically divides the firmware package into a series of data fragment packets with incremental sequence numbers according to the preset maximum transmission unit (MTU) of the LoRa network or the optimal packet length of the BLE protocol, ensuring that each fragment conforms to the wireless transmission specifications. Then, it uses the CRC-16 algorithm to generate a first checksum (fragment checksum) for each independent fragment, and uses the CRC-32 or SHA-256 algorithm to generate a global second checksum (complete packet fingerprint) for the complete firmware package. Finally, these fragment packets, the two levels of checksums, and the metadata of the firmware package (such as version number and size) are organized in key-value pairs or database form and cached in the gateway's local non-volatile memory, providing a complete data source for subsequent controlled broadcasting and on-demand retransmission.

[0041] In some implementations, the central gateway further includes a reliable transmission control module for performing data broadcasting and packet re-uploading processes in LoRa mode; wherein, the reliable transmission control module includes: Data fragment packets are sent sequentially in broadcast or multicast format; Listen to and record the ACK or NACK information returned by the terminal device for each data fragment packet to obtain feedback information; Generate a list of missing fragment packages for different terminal devices based on feedback information; By using LoRa unicast or adjusting communication parameters, the list of missing fragment packets can be retransmitted in a targeted manner.

[0042] It should be noted that by using a two-stage hybrid transmission strategy of "state tracking broadcast + parameter-optimized unicast retransmission", the redundant traffic of traditional blind and repeated broadcasts is transformed into directional data recovery based on precise feedback and the minimum necessary amount. This effectively solves the inherent channel conflict and data packet loss problems when LoRa devices are upgraded concurrently, while greatly saving channel occupation time and overall energy consumption, achieving the best balance between reliability and efficiency.

[0043] For example, when the reliable transmission control module performs an upgrade in LoRa mode, it first broadcasts all fragment packets to all target terminal devices at a lower spreading factor and rated power. At the same time, the module opens a listening window to receive and parse the ACK or NACK information carried by the specific fragment sequence number transmitted back by each terminal device within the reserved time slot, and updates this information in real time to a receive status bitmap indexed by device ID and fragment number. After the first round of broadcasting, the module analyzes the bitmap and automatically generates a personalized missing list for each device, containing only the fragment sequence numbers of its unacknowledged reception. Subsequently, the gateway switches to a higher reliability mode (such as a higher spreading factor or a lower coding rate) and performs LoRa unicast targeted retransmission to each device one by one according to these lists until the status bitmap of all devices shows complete reception.

[0044] In some implementations, the central gateway has an incremental upgrade cache in its local storage to store differential upgrade packages between different firmware versions. When the upgrade task issued by the Web management backend is an incremental upgrade, the central gateway directly obtains the differential upgrade package from the cache or a remote server for processing.

[0045] It should be noted that by using a localized and versioned differential packet caching and management system, the amount of data to be transmitted during the upgrade process is minimized. Especially in large-scale, multi-version device maintenance scenarios, this can significantly reduce gateway bandwidth consumption and download latency, shorten the overall upgrade time window, and reduce network congestion and energy consumption caused by transmitting large amounts of duplicate data, thereby greatly improving upgrade efficiency and economy.

[0046] For example, the incremental upgrade cache of the central gateway is synchronized with the remote server through the version management service. When the server releases a new version of firmware, it will simultaneously generate and store differential upgrade packages for that version relative to multiple historical versions. When the central gateway periodically synchronizes or receives upgrade tasks, it will actively query its cache to see if a differential package matching "current device version - target version" already exists. If it exists, it will be directly called. If it does not exist, it will download the differential package from the server and store it in the cache (managing storage space according to LRU and other strategies). Then, the differential package will be fragmented and verified as a regular firmware package. This mechanism enables the gateway to avoid repeatedly downloading the complete firmware package when facing a large number of devices running different old firmware versions. Instead, it will intelligently select the smallest incremental data for distribution.

[0047] The mobile terminal app is used to establish a Bluetooth connection with a specified terminal device in BLE mode and to transmit upgrade firmware packages.

[0048] It should be noted that the mobile terminal app enables highly interactive and reliable near-field point-to-point upgrades, effectively compensating for the unreliable transmission issues that LoRa broadcasts may have in complex environments or signal edge areas. Its reliable transmission mechanism based on connection handshake ensures the success rate of each data fragment delivery, providing on-site maintenance personnel with a flexible and powerful tool for precise and secure firmware updates of specific devices, and becoming an important supplement and backup guarantee for wide-area LoRa upgrade networks.

[0049] For example, after receiving a BLE mode upgrade task from the web management backend, the mobile terminal app first initiates a Bluetooth pairing and connection request with the target terminal device. After establishing a stable GATT connection, the app encapsulates each data fragment and its first-level checksum into a custom BLE data feature value based on the firmware fragment information synchronized from the central gateway, and transmits it packet by packet through a "write-acknowledge-read" handshake mechanism. After the terminal device successfully receives and verifies each fragment, it sends back an ACK confirmation via the Bluetooth link. If the verification fails, it sends back a NACK and the fragment number, and the app triggers the immediate retransmission of the corresponding fragment accordingly. After all fragments have been transmitted, the app sends out the complete second-level checksum and waits for the terminal device to report the final integrated verification result.

[0050] In some implementations, the mobile terminal App further includes: Synchronously obtain upgrade tasks and corresponding upgrade firmware packages from the web management backend or central gateway; In BLE mode, the central device establishes a point-to-point connection with the terminal devices. According to the preset data packet format and transmission rate, the data of the upgrade firmware package is transmitted to the terminal device in fragments using an end-to-end ACK mechanism.

[0051] It should be noted that the mobile terminal app is an intelligent and independent near-field upgrade execution unit. It not only ensures the authority and consistency of upgrade commands and data sources through a task synchronization mechanism, but also overcomes the problems of interference and packet loss in traditional Bluetooth transmission by its reliable streaming transmission design based on connection sessions. It provides a stable, controllable, and remote network-independent supplementary upgrade method for complex electromagnetic environments or field scenarios with extremely high requirements for upgrade success rate, effectively improving the robustness and scenario coverage of the entire dual-mode upgrade system.

[0052] For example, the mobile terminal app synchronizes tasks with the web management backend or central gateway via API. When the user selects to perform a near-field upgrade, the app automatically searches for a matching target terminal device in the local network environment and sends a BLE connection request based on the task information. After the connection is established, the app converts the upgrade firmware package into continuous data frames according to the optimized fragment size based on the predefined BLE GATT service and feature value format. It achieves highly reliable fragment transmission by using a controllable transmission interval and sliding window mechanism, combined with end-to-end ACK confirmation for each frame. If a fragment transmission fails, the app will immediately reorder and retransmit the fragment in the local queue based on NACK feedback or a timeout mechanism until all fragments are confirmed to be received by the terminal device.

[0053] The terminal device has a built-in LoRa communication module, BLE module and OTA upgrade management unit, which is used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update and rollback operations.

[0054] It should be noted that the closed-loop process of dual-mode adaptive reception, dual verification, secure backup and automatic rollback ensures that the upgrade process itself will not brick the device in the event of unreliable wireless environment or unexpected interruption. This greatly improves the autonomous reliability of single-point device upgrades and is a solid foundation for the entire dual-mode system to achieve large-scale, high-success-rate firmware deployment.

[0055] For example, after startup, the device continuously listens to the LoRa channel. When it receives an upgrade command broadcast by the central gateway, it first parses the firmware metadata and mode prompts in the command. If the command explicitly requires it or the local signal strength is below the threshold, it switches to BLE mode and waits to establish a connection with the mobile terminal app. Regardless of the mode, the device performs an instant CRC check and replies with ACK / NACK when receiving each data fragment. After all fragments are received, a second check is performed on the overall firmware package. After the check passes, the unit first backs up the currently running firmware to an independent storage area, then writes the new firmware to the target area. After writing, a readback verification is performed. If the verification is successful, the startup flag is updated and the device restarts, with the IAP program handling the transition. If the new firmware fails to start, the IAP program will automatically restore the old version from the backup area and report the error log.

[0056] Some implementations also include dynamic mode selection; wherein, the dynamic mode selection includes: The central gateway broadcasts an upgrade command via the LoRa network, the upgrade command including a preset RSSI threshold; The OTA upgrade management unit is configured to: after receiving an upgrade command, measure the LoRa signal strength from the central gateway; if the LoRa signal strength is lower than the RSSI threshold, actively switch to BLE mode and send a mode switching request to the mobile terminal App or the central gateway, and receive the upgrade firmware package through the BLE channel.

[0057] It should be noted that by using the threshold triggering mechanism embedded in the broadcast command, the device side can autonomously and in real-time assess and make decisions on communication quality. This enables the system to intelligently allocate appropriate communication modes to each device based on its actual physical environment (such as distance and obstruction), and to convert potentially unsuccessful far-field transmissions into reliable near-field operations in advance. This not only significantly improves the upgrade success rate of devices located in signal edge areas, but also optimizes the spectrum resource utilization of the entire network and avoids unnecessary data retransmissions on low-quality links, thereby enhancing the system's adaptability to different deployment scenarios and overall upgrade efficiency.

[0058] For example, the central gateway embeds a configurable RSSI signal strength threshold parameter (e.g., -110dBm) in the upgrade command broadcast via LoRa. After receiving the command, the OTA upgrade management unit of the terminal device immediately activates the received signal strength indicator built into its LoRa module, samples the signal of the current channel multiple times, takes the average value, and compares the measured value with the threshold in the command. If the measured value is lower than the threshold, it indicates that the device is at the far edge of the gateway's coverage, and the communication quality may not guarantee the reliability of the upgrade. At this time, the device will actively switch its internal state to "BLE waiting to connect" mode and send a short mode switching notification data packet to the gateway via the LoRa link (if basic communication with the gateway can still be maintained), or directly activate the BLE module and broadcast a specific beacon containing the ID of this upgrade task. After scanning the beacon, the nearby mobile terminal App holding the corresponding upgrade task can actively initiate a BLE connection and establish a dedicated near-field upgrade channel.

[0059] In some implementations, the OTA upgrade management unit further includes: Dual-mode communication control subunit: used for initialization, mode switching and data link maintenance of LoRa and BLE communication; Data verification and reassembly subunit: used to perform first-level CRC verification on data fragment packets based on the first verification code, and to perform integrity verification on the entire reassembled firmware packet based on the second verification code after reception; Security Upgrade Execution Subunit: After successful verification, the firmware package is written to the specified Flash storage area. After writing is completed, read and verification operations are performed. Once confirmed to be correct, the device is restarted and the IAP bootloader completes the final program jump and update.

[0060] It should be noted that, through three highly collaborative dedicated sub-units, a complete autonomous upgrade chain is constructed on the terminal device side, from intelligent communication and reliable reception to secure execution. Its core value lies in internalizing the complex dual-mode switching, multi-verification, and secure programming process into a standard operation that the device can complete independently. This not only significantly reduces the dependence on the stability of external networks and the real-time performance of host computer software, but also provides an underlying guarantee for the device to achieve "one-time upgrade, permanent reliability" in unpredictable field environments through hardware-level verification, backup, and rollback mechanisms. It is the cornerstone of the overall robustness of the system.

[0061] For example, after the device starts up, the dual-mode communication control subunit first initializes the LoRa module to enter a low-power listening state and periodically turns on the BLE module for broadcasting to facilitate discovery. When a LoRa upgrade command is received, the subunit compares the preset RSSI threshold in the command with the real-time measured signal strength. If the strength is insufficient, it actively turns off LoRa reception, switches to BLE slave mode, and broadcasts a specific service UUID containing the device ID to guide the mobile terminal app to initiate a connection. The data verification and reassembly subunit calculates the checksum of each data fragment received through any channel using a hardware CRC module and compares it with the first checksum embedded in the packet header. If the verification fails, it immediately requests retransmission through the original link. After all fragments are received without errors, the subunit reassembles the complete firmware packet in memory according to the sequence number and calculates its hash value for a final comparison with the second checksum (such as SHA-256) at the end of the data packet. After the security upgrade execution subunit passes the verification, it first backs up the current running firmware to the reserved sector of Flash. Then, it writes the new firmware to the target application area through write protection unlocking, sector erasure, and paging programming. After completion, it immediately performs readback verification. After successful verification, the subunit sets the hardware boot flag and triggers the watchdog reset. After the device restarts, the IAP bootloader checks the flag, copies the new firmware from the application area to the running address, and jumps to execute it.

[0062] In some implementations, the security upgrade execution subunit further includes a rollback mechanism; wherein the rollback mechanism includes: Before writing new firmware, back up the currently running valid firmware to a separate storage area; If the new firmware fails to boot or malfunctions, a rollback process is triggered to restore the original firmware from the backup area and report the upgrade failure status.

[0063] It should be noted that by performing a full firmware backup before the upgrade and setting up intelligent boot failure detection after the upgrade, an automated and secure recovery loop that requires no manual intervention is constructed. This fundamentally eliminates the risk of devices becoming "bricked" due to defects in the new firmware itself, hardware compatibility issues, or unexpected power outages. It ensures that the device can automatically recover to a known stable working state after any abnormal upgrade, greatly enhancing the confidence and security of remote upgrades in unattended on-site environments. This is a key technological guarantee for improving the overall availability and intelligent operation and maintenance level of the system.

[0064] For example, before writing the new firmware package to the target Flash area, the sub-unit first copies the currently running valid firmware from its storage sector to a pre-defined, read-write protected independent backup area (usually a reserved sector of non-volatile memory), and records the version number and checksum of the backup firmware. Subsequently, the sub-unit sets a persistent counter flag (such as a specific byte stored in EEPROM or Flash) to mark "upgrade attempts" and sets its initial value to 0. After the new firmware is written and restarted, the IAP bootloader or the new firmware boot code checks this flag during the initialization phase. If the new firmware fails to boot consecutively, causing the system to reset, the counter value will accumulate. When it exceeds a preset threshold (such as 3 times), it is determined to be a "boot failure", thereby triggering the rollback process. At this time, the IAP program will automatically read the old firmware from the backup area, overwrite the new firmware area, and clear the flag after successful recovery. It will also report the upgrade failure status containing error codes to the host system through any available communication module (BLE preferred), so that the device can be restored to the old version that can work normally.

[0065] Based on the above technical solutions, the dual-mode OTA firmware upgrade system based on LoRa and BLE provided in this application effectively overcomes the inherent defects of a single communication mode by constructing a dual-mode collaborative upgrade system integrating LoRa and BLE. The system can intelligently select the optimal communication path based on the device signal strength, and combined with broadcast distribution and intelligent directional packet replenishment mechanisms, significantly alleviates channel conflict problems during concurrent upgrades of multiple devices, greatly improving the upgrade success rate and efficiency. By employing a dual verification mechanism of data fragmentation and overall firmware, secure write verification, and automatic rollback functions, extremely high reliability of data transmission and update processes is ensured, and full-stack firmware security upgrades, including IAP, are supported. Simultaneously, the system supports incremental upgrades and visual monitoring, achieving flexible, efficient, reliable, and secure unified firmware management for a wide-area distributed device group.

[0066] In one possible implementation, this application embodiment also provides a dual-mode OTA firmware upgrade method based on LoRa and BLE, such as... Figure 2 As shown, it includes: The upgrade instructions and upgrade firmware package are obtained from the central gateway or mobile terminal App through the LoRa communication module or BLE module; wherein, the upgrade instructions include firmware identifier and upgrade mode indication; If the upgrade mode is specified, the communication module corresponding to the specified mode will be used to prepare to receive data; if the upgrade mode is set to automatic selection, the LoRa mode or BLE mode will be used for subsequent communication based on the preset strategy or the real-time measured wireless signal quality. According to the determined pattern, the upgrade firmware package, which is divided into multiple data fragments, is received, and a first-level verification is performed on each data fragment; after all data fragments have been received, a second-level verification is performed on the complete firmware package obtained by reassembling all data fragments. Once both levels of verification pass, the complete firmware package is written to the target area of ​​the non-volatile memory, and a verification operation is performed after the writing is completed. After successful verification, the control device restarts, and the new firmware is activated and run by the built-in IAP bootloader.

[0067] For example, in low-power listening mode, the terminal device receives an upgrade command broadcast by the central gateway via the LoRa channel, carrying the firmware ID, fragmentation policy, and RSSI threshold parameters. If the upgrade mode in the command is indicated as "automatic," the device calls the LoRa module to measure the current signal strength. If it is below the threshold (e.g., -105dBm) or determined to be a near-field device according to a preset policy, the device immediately shuts down the LoRa receiver, starts the BLE module, and broadcasts a service containing the task ID, waiting to establish a GATT connection with the mobile terminal app to switch to BLE mode. Subsequently, the device receives data fragments from the corresponding link according to the selected mode, and performs a hardware CRC check on each received fragment. The checksum is calculated and compared with the first-level checksum embedded in the fragment header. If the comparison fails, a NACK request for that fragment number is sent back via the original link for retransmission. After all fragments are received, the complete firmware packet is reassembled in memory in order, and its hash value is calculated and compared with the second-level checksum (such as SHA-256) attached at the end of the transmission for final consistency verification. After both levels of verification pass, the IAP bootloader first backs up the currently running firmware to a separate sector of Flash, then unlocks the target area, erases it, programs and writes the new firmware, and immediately reads back for verification. If the verification is successful, the boot flag is set and the watchdog timer is triggered to reset. After restarting, the IAP checks that the flag is valid, then copies the new firmware to the running address and performs a jump to complete the activation.

[0068] Based on the above technical solution, through autonomous signal evaluation and mode decision-making on the terminal device side, seamless and intelligent switching from wide-area broadcast to near-field point-to-point is achieved, ensuring that each device can be upgraded on the optimal channel. Combined with the triple security barriers of fragmented real-time verification, overall packet verification and post-write readback, as well as the firmware full backup mechanism before the upgrade, a highly reliable and secure localized upgrade execution closed loop is formed. This significantly improves the success rate and security of single-device upgrades in complex field environments and effectively prevents the risk of device unavailability due to upgrade failure.

[0069] The foregoing mainly describes the solutions of the embodiments of this application from the perspective of device implementation. It is understood that each device, such as an electronic device, includes at least one of the hardware structures and software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0070] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0071] When using integrated units, Figure 3 A possible structural schematic diagram of the electronic device (denoted as electronic device 50) involved in the above embodiments is shown. The electronic device 50 includes a processing unit 501 and a communication unit 502, and may also include a storage unit 503. Figure 3 The structural diagram shown can be used to illustrate the structure of the electronic device involved in the above embodiments.

[0072] when Figure 3 The schematic diagram shown is used to illustrate the structure of the electronic device involved in the above embodiments. The processing unit 501 is used to control and manage the operation of the electronic device, the communication unit 502 is used for the electronic device to communicate with other devices, and the storage unit 503 is used to store the program code and data of the electronic device.

[0073] For example, communication unit 502 is used to acquire user instructions, manage terminal device information, and send upgrade tasks to the central gateway; The processing unit 501 is used to receive upgrade tasks, download upgrade firmware packages from remote servers according to upgrade tasks, and generate upgrade instructions; communicate with terminal devices through the LoRa network and transmit upgrade instructions and upgrade firmware packages in a broadcast manner; establish Bluetooth connections with designated terminal devices in BLE mode and transmit upgrade firmware packages; receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update, and rollback operations.

[0074] The processing unit 501 can be a processor or a controller, and the communication unit 502 can be a communication interface, transceiver, transceiver circuit, transceiver device, etc. The term "communication interface" is a general term and may include one or more interfaces. The storage unit 503 can be a memory. When the electronic device 50 is a chip, the processing unit 501 can be a processor or a controller, and the communication unit 502 can be an input interface and / or an output interface, pins, or circuits, etc. The storage unit 503 can be a storage unit within the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip (e.g., read-only memory (ROM), random access memory (RAM, etc.).

[0075] The communication unit can also be called a transceiver unit. The antenna and control circuit with transceiver functions in the electronic device 50 can be considered as the communication unit 502 of the electronic device 50, and the processor with processing functions can be considered as the processing unit 501 of the electronic device 50. Optionally, the device in the communication unit 502 used to implement the receiving function can be considered as the communication unit. The communication unit is used to execute the receiving steps in the embodiments of this application, and the communication unit can be a receiver, a receiver circuit, etc. The device in the communication unit 502 used to implement the transmitting function can be considered as the transmitting unit. The transmitting unit is used to execute the transmitting steps in the embodiments of this application, and the transmitting unit can be a transmitter, a transmitter, a transmitting circuit, etc.

[0076] Figure 3 If the integrated units in the process are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, 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.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. Storage media for storing computer software products include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0077] Figure 3 The units in the process can also be called modules; for example, a processing unit can be called a processing module.

[0078] This application also provides a hardware structure diagram of an electronic device (denoted as electronic device 60), see [link to diagram]. Figure 4 The electronic device 60 includes a processor 601, and optionally, a memory 602 connected to the processor 601.

[0079] In the first possible implementation, see Figure 4 The electronic device 60 also includes a transceiver 603. The processor 601, memory 602, and transceiver 603 are connected via a bus. The transceiver 603 is used to communicate with other devices or communication networks. Optionally, the transceiver 603 may include a transmitter and a receiver. The device in the transceiver 603 that implements the receiving function can be considered as a receiver, which is used to perform the receiving steps in the embodiments of this application. The device in the transceiver 603 that implements the transmitting function can be considered as a transmitter, which is used to perform the transmitting steps in the embodiments of this application.

[0080] Based on the first possible implementation method Figure 4 The structural diagram shown can be used to illustrate the structure of the electronic device involved in the above embodiments.

[0081] in, Figure 4 This can also be illustrated by a system chip in an electronic device. In this case, the actions performed by the aforementioned electronic device can be implemented by this system chip; the specific actions performed can be found above and will not be repeated here.

[0082] In implementation, each step of the method provided in this embodiment can be completed by integrated logic circuits in the processor hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0083] The processor in this application may include, but is not limited to, at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., which are various computing devices that run software. Each computing device may include one or more cores for executing software instructions to perform calculations or processing. The processor may be a separate semiconductor chip or integrated with other circuits into a single semiconductor chip. For example, it may be integrated with other circuits (such as encoding / decoding circuits, hardware acceleration circuits, or various bus and interface circuits) to form a SoC (System-on-a-Chip), or it may be integrated as a built-in processor within an ASIC. The ASIC with the integrated processor may be packaged separately or together with other circuits. In addition to the cores for executing software instructions to perform calculations or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), PLDs (programmable logic devices), or logic circuits that implement dedicated logic operations.

[0084] The memory in the embodiments of this application may include at least one of the following types: read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; or electrically erasable programmable-only memory (EEPROM). In some scenarios, the memory may also be a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0085] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform any of the methods described above.

[0086] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods described above.

[0087] This application also provides a chip including a processor and an interface circuit. The interface circuit is coupled to the processor. The processor is used to run computer programs or instructions to implement the above-described method. The interface circuit is used to communicate with other modules outside the chip.

[0088] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0089] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0090] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A dual-mode OTA firmware upgrade system based on LoRa and BLE, characterized in that, This includes a web-based management backend, a central gateway, a mobile app, and terminal devices. The web management backend is used to obtain user instructions, manage terminal device information, and send upgrade tasks to the central gateway; wherein, the upgrade task includes the target terminal device identifier, upgrade firmware version information, and a specified upgrade mode, the upgrade mode including LoRa mode or BLE mode; The central gateway is equipped with a LoRa communication module and a network connection module, used to receive upgrade tasks, download upgrade firmware packages from a remote server according to the upgrade tasks and generate upgrade instructions; and communicate with terminal devices through the LoRa network to transmit upgrade instructions and upgrade firmware packages in a broadcast manner. The mobile terminal App is used to establish a Bluetooth connection with a designated terminal device in BLE mode and to transmit upgrade firmware packages. The terminal device has a built-in LoRa communication module, BLE module and OTA upgrade management unit, which is used to receive and parse upgrade instructions and upgrade firmware packages from the central gateway or mobile terminal App, and perform firmware verification, update and rollback operations.

2. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 1, characterized in that, The central gateway further includes a firmware package preprocessing module; wherein, the firmware package preprocessing module includes: The firmware upgrade package is divided into multiple consecutively numbered data fragments. Generate a first checksum for each data fragment packet and a second checksum for the upgrade firmware packet; The data fragments, first checksum, second checksum, and upgrade firmware package are cached in local storage.

3. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 1, characterized in that, It also includes dynamic mode selection; wherein, the dynamic mode selection includes: The central gateway broadcasts an upgrade command via the LoRa network, the upgrade command including a preset RSSI threshold; The OTA upgrade management unit is configured to: after receiving an upgrade command, measure the LoRa signal strength from the central gateway; if the LoRa signal strength is lower than the RSSI threshold, actively switch to BLE mode and send a mode switching request to the mobile terminal App or the central gateway, and receive the upgrade firmware package through the BLE channel.

4. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 2, characterized in that, The central gateway further includes a reliable transmission control module, used to perform data broadcasting and packet re-uploading processes in LoRa mode; wherein, the reliable transmission control module includes: Data fragment packets are sent sequentially in broadcast or multicast format; Listen to and record the ACK or NACK information returned by the terminal device for each data fragment packet to obtain feedback information; Generate a list of missing fragment packages for different terminal devices based on feedback information; By using LoRa unicast or adjusting communication parameters, the list of missing fragment packets can be retransmitted in a targeted manner.

5. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 1, characterized in that, The mobile terminal App also includes: Synchronously obtain upgrade tasks and corresponding upgrade firmware packages from the web management backend or central gateway; In BLE mode, the central device establishes a point-to-point connection with the terminal devices. According to the preset data packet format and transmission rate, the data of the upgrade firmware package is transmitted to the terminal device in fragments using an end-to-end ACK mechanism.

6. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 2, characterized in that, The OTA upgrade management unit also includes: Dual-mode communication control subunit: used for initialization, mode switching and data link maintenance of LoRa and BLE communication; Data verification and reassembly subunit: used to perform first-level CRC verification on data fragment packets based on the first verification code, and to perform integrity verification on the entire reassembled firmware packet based on the second verification code after reception; Security Upgrade Execution Subunit: After successful verification, the firmware package is written to the specified Flash storage area. After writing is completed, read and verification operations are performed. Once confirmed to be correct, the device is restarted and the IAP bootloader completes the final program jump and update.

7. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 6, characterized in that, The security upgrade execution subunit also includes a rollback mechanism; wherein the rollback mechanism includes: Before writing new firmware, back up the currently running valid firmware to a separate storage area; If the new firmware fails to boot or malfunctions, a rollback process is triggered to restore the original firmware from the backup area and report the upgrade failure status.

8. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 1, characterized in that, The web management backend also includes a visual monitoring interface; wherein, the visual monitoring interface includes: Displays the execution status of each central gateway upgrade task; Displays the current mode, upgrade progress, reception success rate, and final upgrade result of each terminal device; The display shows the overall network upgrade success rate and a list of terminal devices that failed to upgrade.

9. The dual-mode OTA firmware upgrade system based on LoRa and BLE according to claim 1, characterized in that, The central gateway has an incremental upgrade cache in its local storage, which is used to store differential upgrade packages between different firmware versions. When the upgrade task issued by the Web management backend is an incremental upgrade, the central gateway directly obtains the differential upgrade package from the cache or a remote server for processing.

10. A dual-mode OTA firmware upgrade method based on LoRa and BLE according to claim 1, characterized in that, include: The upgrade instructions and upgrade firmware package are obtained from the central gateway or mobile terminal App through the LoRa communication module or BLE module; wherein, the upgrade instructions include firmware identifier and upgrade mode indication; If the upgrade mode is specified, the communication module corresponding to the specified mode will be used to prepare to receive data; if the upgrade mode is set to automatic selection, the LoRa mode or BLE mode will be used for subsequent communication based on the preset strategy or the real-time measured wireless signal quality. According to the determined pattern, the upgrade firmware package, which is divided into multiple data fragments, is received, and a first-level verification is performed on each data fragment; after all data fragments have been received, a second-level verification is performed on the complete firmware package obtained by reassembling all data fragments. Once both levels of verification pass, the complete firmware package is written to the target area of ​​the non-volatile memory, and a verification operation is performed after the writing is completed. After successful verification, the control device restarts, and the new firmware is activated and run by the built-in IAP bootloader.

Images