An embedded device wireless debugging method based on BLE Bluetooth communication

Abstract

This invention discloses a wireless debugging method for embedded devices based on BLE Bluetooth communication, comprising the following steps: Step 1: A debugging host computer scans and connects to the target embedded device based on the BLE protocol, establishing a wireless communication link; Step 2: The debugging host computer receives firmware operation log information actively pushed by the target embedded device through the wireless communication link and displays it in real time. Through the implementation of this invention, a complete, efficient, and reliable wireless debugging solution is provided, effectively solving the core pain points of traditional wired debugging and existing wireless debugging solutions in terms of mobility, convenience, real-time performance, power consumption, and offline adaptability. It is particularly suitable for the development and maintenance stages of complex industrial environments, mobile equipment, and closed embedded products.

Description

Technical Field

[0001] This invention relates to the field of embedded system development tools, and in particular to a wireless debugging method for embedded devices based on BLE Bluetooth communication. Background Technology

[0002] As the core control unit of various electronic devices and products, embedded systems require crucial debugging throughout their firmware development, testing, verification, and subsequent maintenance lifecycle. Traditional and mainstream debugging methods heavily rely on physical cable connections, primarily including in-circuit debuggers based on hardware debugging interfaces (such as JTAG and SWD) and serial port logging based on Universal Asynchronous Receiver / Transmitter (UART). Hardware debuggers allow developers to perform single-step execution, breakpoint setting, and register viewing, making them powerful tools for in-depth code logic verification; serial port logging provides real-time textual evidence for functional verification and anomaly troubleshooting by outputting the program's runtime status, variables, and prompts.

[0003] However, with the diversification of embedded device forms and the increasing complexity of application scenarios, the limitations of the aforementioned wired debugging methods are becoming increasingly apparent, specifically in the following aspects:

[0004] Due to physical connection limitations and operational inconvenience, most mass-produced products, for safety, reliability, and aesthetic reasons, do not expose debugging interfaces externally, but rather encapsulate them within the equipment structure. When equipment malfunctions during field operation or production testing, technicians must disassemble the equipment to connect debugging tools. This process is not only cumbersome and time-consuming, but may also lead to power outages or loss of operational status, making it extremely difficult to reproduce and locate transient problems, severely reducing troubleshooting efficiency.

[0005] Poor adaptability to mobile and dynamic scenarios: In many application scenarios, the device to be debugged is in a state of continuous movement or frequent changes in spatial location, such as controllers installed on vehicles such as ships, vehicles, and drones. In such scenarios, dragging long communication cables is neither practical nor safe, and the cables are easily pulled, tangled, or interfered with, leading to unstable connections or even damage, making traditional wired debugging methods completely impossible to implement.

[0006] Shortcomings of existing wireless alternatives: To get rid of the constraints of cables, the industry has explored some wireless debugging solutions, but each has significant drawbacks:

[0007] While Wi-Fi debugging offers high bandwidth, Wi-Fi modules consume a lot of power, which is detrimental to battery-powered devices. Furthermore, it typically requires complex network configuration (such as SSID, password, and IP address), making it inconvenient to deploy in temporary or closed testing environments.

[0008] Traditional Bluetooth pass-through modules, including early Bluetooth modules or simple BLE (Bluetooth Low Energy) pass-through solutions, often only achieve transparent data transmission and lack optimization for debugging scenarios. For example, they do not support dynamically adjusting the processing method based on the data content (such as distinguishing between log text and binary commands), cannot flexibly adapt to different serial port baud rates, and have relatively limited functionality.

[0009] Cloud-based debugging platforms rely on internet connectivity and cloud servers, making them unusable in offline environments with no or poor network signal, such as during long-distance ship voyages or field operations. Furthermore, network transmission introduces uncontrollable latency, making them unsuitable for debugging interactions with high real-time requirements.

[0010] In summary, a wireless debugging method for embedded devices based on BLE Bluetooth communication is needed to address the shortcomings of existing technologies. Summary of the Invention

[0011] To address the shortcomings of existing technologies, this invention provides a wireless debugging method for embedded devices based on BLE Bluetooth communication, aiming to solve the limitations of traditional wired debugging tools in mobile scenarios and enclosed devices.

[0012] This application provides a wireless debugging method for embedded devices based on BLE Bluetooth communication, including the following steps:

[0013] Step 1: The host computer scans and connects to the target embedded device based on the BLE protocol to establish a wireless communication link;

[0014] Step 2: The debugging host computer receives firmware operation log information actively pushed by the target embedded device through a wireless communication link and displays it in real time;

[0015] Step 3: The debugging host computer sends debugging instructions to the target embedded device through a wireless communication link. The target embedded device adjusts its operating status or returns status data according to the received debugging instructions.

[0016] Step 4: The debugging host computer and the target embedded device interact with each other in full-duplex according to a predefined bidirectional communication protocol. This protocol defines at least two message frame formats, corresponding to the transmission of text-based prompts and the exchange of binary data. By utilizing BLE communication, the physical limitations of wired debugging are overcome, enabling non-contact debugging within a specific range and avoiding state loss due to disassembly. The customized bidirectional communication protocol achieves full-duplex real-time interaction between log uploads and command issuance, significantly improving debugging efficiency and proactivity. This solution is particularly suitable for mobile scenarios such as ships and features low power consumption, flexible protocols, and high reliability, effectively solving key problems of traditional debugging methods in terms of mobility, convenience, and real-time performance.

[0017] Furthermore, in step 1, when the debugging host computer detects that the wireless communication link with the target embedded device is disconnected, it automatically initiates a reconnection process to rescan and reconnect.

[0018] Furthermore, the debugging host computer provides an application programming interface (API), which encapsulates the functions of device scanning, connection, command sending, and log reception; external scripts or programs call the API to perform corresponding operations.

[0019] Furthermore, in step 2, the debugging host computer stores and exports the received firmware operation log information locally in text file format.

[0020] Furthermore, in step 3, the debugging command is a custom command entered by the user in character form through the graphical interface of the debugging host computer. The custom command includes instructions to enable, disable, or configure specific functional modules in the target embedded device.

[0021] Furthermore, the message frame format in the predefined bidirectional communication protocol includes:

[0022] A message frame includes a frame start flag, a type field, a length field, a text data payload, and a check field. The type field identifies the frame as a text message frame.

[0023] A data frame includes a frame start flag, a type field, a length field, a binary data payload, and a check field. The type field identifies the frame as a binary data frame and the data flow direction.

[0024] Furthermore, the debugging host computer is implemented using a multi-threaded architecture, including at least:

[0025] The BLE communication thread performs scanning, connection, and data transmission and reception for underlying Bluetooth devices.

[0026] The protocol parsing thread performs unpacking, verification, and format conversion on the received raw data, and encapsulates the data to be sent.

[0027] The graphical user interface thread provides a human-computer interaction interface, displaying logs, inputting commands, and showing status.

[0028] Furthermore, in step 2, when the debugging host computer receives log information, the debugging host computer subscribes to the first feature value with notification attribute in the BLE service of the target embedded device. After the target embedded device writes the firmware running log information into the first feature value, it actively notifies the debugging host computer to read it.

[0029] Furthermore, in step 3, when the debugging host computer issues a debugging command, the debugging host computer writes the debugging command into the second feature value with write attribute in the BLE service of the target embedded device, and the target embedded device listens to and reads the contents of the second feature value.

[0030] On the other hand, this application also provides an embedded device wireless debugging system based on BLE Bluetooth communication, including:

[0031] An embedded device with an integrated BLE communication module is configured to run firmware to be debugged and publish feature values ​​for log pushing and command reception via BLE service;

[0032] Debugging the host computer, running on a PC, includes:

[0033] The device management module is configured to perform scanning, connection, and management of the embedded devices;

[0034] The communication protocol module is configured to encapsulate and decapsulate interactive data according to the predefined bidirectional communication protocol.

[0035] The log processing module is configured to perform real-time display, recording, and export of log information received from the embedded device;

[0036] The instruction interaction module is configured to generate and send debugging instructions to the embedded device.

[0037] The graphical user interface is configured to integrate and display the functional status of the device management module, log processing module, and command interaction module.

[0038] The substantial effects of this invention:

[0039] 1. In this invention, by utilizing BLE Bluetooth communication, the effective coverage radius is large, enabling technicians to debug embedded devices located in closed enclosures or mobile vehicles (such as ship engine rooms) without physical contact or disassembly of the device casing. This avoids the risk of device status loss due to disassembly, as well as the inconvenience and safety hazards of cable connections in mobile scenarios, greatly expanding the feasible scope of debugging operations.

[0040] 2. In this invention, by defining a bidirectional communication protocol that includes at least two message frame formats and implementing full-duplex communication on the same BLE link, it not only supports the device to actively and continuously report operation logs, but also supports the host computer to actively and instantly issue various debugging commands. Through integrated real-time interactive capabilities, the debugging process is upgraded to an active and interactive problem exploration and verification, which significantly accelerates the speed of problem location and resolution.

[0041] 3. In this invention, the reliance on dedicated hardware debuggers is eliminated by setting the interface, which also reduces production and maintenance downtime caused by equipment disassembly and reassembly; a lightweight BLE protocol stack is adopted, making the connection process simple and quick, without the need for complex network configuration; the host computer provides a graphical interface with real-time log display and intuitive command input, lowering the usage threshold for technical personnel; BLE technology itself has low power consumption characteristics, making it suitable for long-term debugging and monitoring of power-sensitive embedded devices without easily affecting the normal operation of the device.

[0042] 4. In this invention, a verification field is designed through the communication data message, and combined with the data retransmission control mechanism, the accuracy and reliability of data transmission in the wireless environment are ensured, effectively combating interference in the wireless channel and avoiding debugging misjudgments caused by data errors or loss. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a schematic diagram of the process of the present invention.

[0045] Figure 2 This is a schematic diagram of the principle of the present invention.

[0046] Figure 3 This is a schematic diagram of the debugging host computer graphical interface of the present invention.

[0047] Figure 4 This is a schematic diagram of the message frame of the present invention.

[0048] Figure 5 This is a schematic diagram of the data frame of the present invention.

[0049] Figure 6 This is a schematic diagram of the data transmission control process of the present invention.

[0050] Figure 7 This is a schematic diagram of the data receiving control process of the present invention.

[0051] Figure 8 This is a schematic diagram illustrating the target embedded device scanning implementation process of the present invention.

[0052] Figure 9 This is a schematic diagram illustrating the implementation process of the target embedded device connection control in this invention.

[0053] Figure 10This is a schematic diagram of the log export process of the present invention. Detailed Implementation

[0054] To facilitate understanding of the present invention, a more detailed description is provided below with reference to the accompanying drawings and specific embodiments. It should be noted that when an element is described as being "fixed to" another element, it can be directly on the other element, or one or more intermediate elements may exist between them. When an element is described as being "connected to" another element, it can be directly connected to the other element, or one or more intermediate elements may exist between them. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this specification are for illustrative purposes only.

[0055] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0056] Example 1:

[0057] Reference Figures 1-10 As shown, a wireless debugging method for embedded devices based on BLE Bluetooth communication includes the following steps:

[0058] Step 1: The host computer scans and connects to the target embedded device based on the BLE protocol to establish a wireless communication link;

[0059] Step 2: The host computer receives firmware operation log information actively pushed by the target embedded device through a wireless communication link and displays it in real time;

[0060] Step 3: The host computer sends debugging commands to the target embedded device via a wireless communication link. The target embedded device adjusts its operating status or returns status data according to the received debugging commands.

[0061] Step 4: Debug the full-duplex data interaction between the host computer and the target embedded device according to the predefined bidirectional communication protocol. The bidirectional communication protocol defines at least two message frame formats, corresponding to the transmission of text-based prompt information and the exchange of binary data, respectively.

[0062] In one implementation, in step 1, when the debugging host computer detects that the wireless communication link with the target embedded device is disconnected, it automatically initiates a reconnection process to rescan and reconnect.

[0063] In mobile, high-interference environments (such as ship engine rooms), BLE connections may be accidentally disconnected due to transient distance changes or electromagnetic interference. This function can automatically and quickly restore the connection, ensuring that log collection and command issuance are not interrupted for a long time, avoiding the loss of critical debugging information due to connection interruption, and enabling the debugging session to continue seamlessly.

[0064] During long-term stability testing or automated test script execution, the system can recover automatically even if it experiences a brief disconnection, thus supporting uninterrupted automated monitoring and testing, significantly reducing the cost of manual monitoring, and improving the reliability and efficiency of testing.

[0065] For debugging personnel, there is no need to constantly monitor the connection status or manually perform tedious rescanning and pairing processes after disconnection. The system automatically completes the reconnection "seamlessly," hiding the complexity of the operation in the background. This allows technicians to focus more on the debugging task itself, reduces the technical threshold and psychological burden of using the tool, and improves overall work efficiency.

[0066] As one implementation method, the debugging host computer provides an application programming interface (API), which encapsulates the functions of device scanning, connection, command sending, and log reception; external scripts or programs call the API to perform the corresponding operations.

[0067] This API encapsulates core debugging operations (scanning, connecting, sending and receiving data) into standard functions or service interfaces. This allows developers or test engineers to automate complex, repetitive debugging task sequences (e.g., batch connecting multiple devices, automatically issuing test command sets, and cyclically collecting and analyzing logs) by writing scripts (such as Python scripts). It not only replaces a large amount of manual work, significantly saving time and manpower, but also seamlessly integrates the debugging process into continuous integration / continuous deployment (CI / CD) pipelines or automated testing frameworks, modernizing and increasing the efficiency of the development and testing process.

[0068] Furthermore, the API provides underlying capabilities, allowing users to flexibly combine and extend functions according to the needs of specific projects or special scenarios; for example, dedicated data analysis plugins can be developed, complex interactive debugging logic can be customized, or deep integration with other monitoring systems (such as data visualization platforms and defect management systems) can be achieved; this solves the problem that "one-size-fits-all" debugging tools cannot meet all subdivided scenarios, greatly expanding the applicability and vitality of this debugging method;

[0069] By providing a clearly defined API, this solution reduces the difficulty of secondary development for specific devices or protocols. Partners or advanced users can quickly develop customized debugging plugins or adaptation layers for their own products based on this API, without having to understand the entire communication protocol and host computer architecture from scratch. This helps to form a tool ecosystem around the core debugging method, enhancing the universal value and industry influence of this technology.

[0070] In one implementation, in step 2, the debugging host computer stores and exports the received firmware operation log information locally in text file format.

[0071] In one implementation, in step 3, the debugging command is a custom command entered by the user in character form through the graphical interface of the debugging host computer. The custom command includes instructions to enable, disable, or configure specific functional modules in the target embedded device.

[0072] As one implementation method, the message frame format in the predefined bidirectional communication protocol (refer to...) Figure 4 , 5 As shown, message frames are transmitted in text format to represent text-based debugging prompts, while data frames are transmitted in hex format for data exchange between the debugging host computer and the target embedded device. These include:

[0073] A message frame contains a frame start flag, a type field, a length field, a text data payload, and a checksum field. The type field identifies the frame as a text message frame.

[0074] A data frame contains a frame start flag, a type field, a length field, a binary data payload, and a check field. The type field identifies that the frame is a binary data frame and the direction of the data flow.

[0075] As one implementation method, the debugging host computer adopts a multi-threaded architecture, which includes at least:

[0076] The BLE communication thread performs scanning, connection, and data transmission and reception for underlying Bluetooth devices.

[0077] The protocol parsing thread performs unpacking, verification, and format conversion on the received raw data, and encapsulates the data to be sent.

[0078] The graphical user interface thread provides a human-computer interaction interface, displaying logs, inputting commands, and showing status.

[0079] In one implementation, in step 2, when the debugging host computer receives log information, the debugging host computer subscribes to the first feature value with notification attribute in the BLE service of the target embedded device. After the target embedded device writes the firmware running log information into the first feature value, it actively notifies the debugging host computer to read it.

[0080] In one implementation, in step 3, when the debugging host computer issues a debugging command, the debugging host computer writes the debugging command into the second feature value with write attribute in the BLE service of the target embedded device, and the target embedded device listens for and reads the contents of the second feature value.

[0081] Example 2:

[0082] This embodiment is basically the same as embodiment 1, except that the PC-based debugging host computer scans the target BLE slave device and establishes a wireless connection using a lightweight BLE protocol stack after pairing with it. The debugging host computer continuously receives log data actively printed by the target embedded device by subscribing to a specified feature value with notification attributes via UUID. The target embedded device receives debugging commands issued by the host computer by reading the feature value with write attributes, thus realizing real-time full-duplex communication between the debugging host computer and the target embedded device.

[0083] The debugging host computer can monitor the online status of the target embedded device in real time and supports automatic reconnection to the target embedded device after disconnection.

[0084] The debugging host computer prints out the communication data between the two parties in log format and supports exporting and saving the communication data as a text file.

[0085] The debugging host computer supports inputting and issuing custom debugging commands in character form to change the running status of the target embedded device, such as enabling or disabling the operation of functional modules.

[0086] Communication data packets are transmitted together with checksums and application data, and a retransmission control mechanism is used to ensure the reliability of the communication data.

[0087] Example 3:

[0088] This embodiment is basically the same as Embodiment 1, except that it provides an embedded device wireless debugging system based on BLE Bluetooth communication, including:

[0089] An embedded device with an integrated BLE communication module is configured to run firmware to be debugged and publish feature values ​​for log pushing and command reception via BLE service;

[0090] Debugging the host computer, running on a PC, includes:

[0091] The device management module is configured to perform scanning, connection, and management of embedded devices;

[0092] The communication protocol module is configured to encapsulate and decapsulate interactive data according to a predefined bidirectional communication protocol.

[0093] The log processing module is configured to perform real-time display, recording, and export of log information received from the embedded device;

[0094] The instruction interaction module is configured to generate and send debugging instructions to the embedded device.

[0095] The graphical user interface is configured to integrate and display the functional status of the device management module, log processing module, and command interaction module.

[0096] It should be noted that while the preferred embodiments of the present invention are provided in the specification and accompanying drawings, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. These embodiments are not intended to impose additional limitations on the content of the present invention; their purpose is to provide a more thorough and comprehensive understanding of the disclosure of the present invention. Furthermore, the above-described technical features can be combined with each other to form various embodiments not listed above, all of which are considered to be within the scope of the present invention specification. Moreover, those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A wireless debugging method for embedded devices based on BLE Bluetooth communication, characterized in that, Includes the following steps: Step 1: The host computer scans and connects to the target embedded device based on the BLE protocol to establish a wireless communication link; Step 2: The debugging host computer receives firmware operation log information actively pushed by the target embedded device through a wireless communication link and displays it in real time; Step 3: The debugging host computer sends debugging instructions to the target embedded device through a wireless communication link. The target embedded device adjusts its operating status or returns status data according to the received debugging instructions. Step 4: The debugging host computer and the target embedded device perform full-duplex data interaction according to a predefined bidirectional communication protocol. The bidirectional communication protocol defines at least two message frame formats, corresponding to the transmission of text-based prompt information and the exchange of binary data, respectively.

2. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, In step 1, when the debugging host computer detects that the wireless communication link with the target embedded device is disconnected, it automatically initiates the reconnection process, rescans and reconnects.

3. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, The debugging host computer provides an application programming interface (API), which encapsulates the functions of device scanning, connection, command sending, and log receiving; external scripts or programs call the API to perform the corresponding operations.

4. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, In step 2, the debugging host computer stores and exports the received firmware operation log information locally in text file format.

5. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, In step 3, the debugging command is a custom command that the user inputs in character form through the graphical interface of the debugging host computer. The custom command includes instructions to enable, disable, or configure specific functional modules in the target embedded device.

6. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, The message frame format in the predefined bidirectional communication protocol includes: A message frame includes a frame start flag, a type field, a length field, a text data payload, and a check field. The type field identifies the frame as a text message frame. A data frame includes a frame start flag, a type field, a length field, a binary data payload, and a check field. The type field identifies the frame as a binary data frame and the data flow direction.

7. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, The debugging host computer is implemented using a multi-threaded architecture, and includes at least: The BLE communication thread performs scanning, connection, and data transmission and reception for underlying Bluetooth devices. The protocol parsing thread performs unpacking, verification, and format conversion on the received raw data, and encapsulates the data to be sent. The graphical user interface thread provides a human-computer interaction interface, displaying logs, inputting commands, and showing status.

8. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, In step 2, when the debugging host computer receives log information, it subscribes to the first feature value with notification attribute in the BLE service of the target embedded device. After the target embedded device writes the firmware running log information into the first feature value, it actively notifies the debugging host computer to read it.

9. The embedded device wireless debugging method based on BLE Bluetooth communication according to claim 1, characterized in that, In step 3, when the debugging host computer issues a debugging command, the debugging host computer writes the debugging command into the second feature value with the write attribute in the BLE service of the target embedded device, and the target embedded device listens to and reads the contents of the second feature value.

10. A wireless debugging system for embedded devices based on BLE Bluetooth communication, characterized in that, To implement the debugging method as described in any one of claims 1-9, comprising: An embedded device with an integrated BLE communication module is configured to run firmware to be debugged and publish feature values ​​for log pushing and command reception via BLE service; Debugging the host computer, running on a PC, includes: The device management module is configured to perform scanning, connection, and management of the embedded devices; The communication protocol module is configured to encapsulate and decapsulate interactive data according to the predefined bidirectional communication protocol. The log processing module is configured to perform real-time display, recording, and export of log information received from the embedded device; The instruction interaction module is configured to generate and send debugging instructions to the embedded device. The graphical user interface is configured to integrate and display the functional status of the device management module, log processing module, and command interaction module.

Images