Debugging method and device of embedded device and embedded device

Abstract

The application discloses a debugging method and device of an embedded device and the embedded device, and relates to the field of computers.The method comprises the following steps: creating an independent command receiving thread, a UDP socket and binding to a preset port; receiving a UDP data packet of a debugging device, extracting a payload command string and network address information; performing word segmentation processing on the command string to obtain a command name and a command parameter; searching for a match in a command table by using the command name, and obtaining a corresponding function function when the match is successful; calling the function function and inputting the command parameter, executing a debugging operation and obtaining execution result data; and encapsulating the execution result data into a UDP data packet by using the UDP socket according to the network address information, and returning the execution result data to the debugging device. The application realizes remote receiving and execution of commands by using an independent thread in combination with a UDP protocol, reduces the occupation of processing resources of the embedded device by the debugging function, and meanwhile, the command table driving mechanism has good scalability.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a debugging method, apparatus, and embedded device for embedded devices. Background Technology

[0002] During the development and maintenance phases of embedded devices, debugging methods are typically required to obtain device operating status and log information. As embedded products become increasingly complex, a single device often integrates multiple functional modules, and the operating status of each module needs to be monitored and debugged separately, leading to a diversification of debugging needs.

[0003] Currently, most common debugging methods for embedded devices rely on wired physical interfaces such as serial ports, requiring on-site access by debugging personnel, which is difficult to meet the operational needs of remote maintenance scenarios. Furthermore, some debugging tools require continuous maintenance of network connectivity during operation, consuming additional device processing and memory resources, which can easily affect the normal operation of core business processes on resource-constrained embedded devices. Additionally, some debugging solutions are highly complex and unsuitable for deployment on resource-limited embedded devices.

[0004] In summary, existing debugging methods struggle to achieve a balance between remote operation capability, resource consumption, and implementation complexity, and there is a lack of a debugging solution that combines lightweight design with remote operability. Summary of the Invention

[0005] This application provides a debugging method, apparatus, and embedded device for embedded devices, which can solve the technical problem in the prior art where remote debugging methods for embedded devices struggle to balance resource consumption, implementation complexity, and remote operability. The technical solution is as follows: In a first aspect, embodiments of this application provide a debugging method for an embedded device, including: Create an independent command receiving thread, and create a UDP socket in the command receiving thread, and bind the UDP socket to a preset port; The UDP socket is used to receive UDP packets from the debugging device, and the payload command string and the network address information of the debugging device are extracted from the UDP packets. The payload command string is segmented to extract the command name and at least one command parameter; Based on the command name, a search is performed in the predefined command table; if a match is found, the function corresponding to the command name is retrieved. The function is invoked, and the command parameters are passed as input parameters to perform debugging operations and obtain the execution result data generated by the debugging operations. Based on the network address information, the execution result data is encapsulated into a UDP data packet via the UDP socket, and the UDP data packet is sent to the debugging device.

[0006] Secondly, embodiments of this application provide a debugging apparatus for an embedded device, the apparatus comprising: A module is created to create an independent command receiving thread, and within the command receiving thread, a UDP socket is created and bound to a preset port; The extraction module is used to receive UDP packets from the debugging device through the UDP socket, and extract the payload command string and the network address information of the debugging device from the UDP packets; The word segmentation module is used to segment the payload command string into words and extract the command name and at least one command parameter. The matching module is used to search for a match in a predefined command table based on the command name; if a match is successful, the function corresponding to the command name is obtained. An execution module is used to call the function and pass the command parameters as input parameters to perform debugging operations and obtain the execution result data generated by the debugging operations. The encapsulation module is used to encapsulate the execution result data into a UDP data packet through the UDP socket according to the network address information, and to send the UDP data packet to the debugging device.

[0007] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0008] Fourthly, embodiments of this application provide an embedded device, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0009] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: This application creates an independent command receiving thread and creates a UDP socket in the thread to bind to a preset port, so that the receiving and processing of debugging commands are completed in an independent thread, which is isolated from the main business thread of the embedded device. The main business thread will not be blocked while waiting for debugging commands, ensuring the normal operation of the core functions of the device. At the same time, the independent operation of the thread and the resource separation and reclamation mechanism also avoid the debugging function from continuously occupying the main business processing resources.

[0010] Based on this, this application uses the UDP protocol as the transmission carrier for debugging commands. It receives UDP data packets from the debugging device through UDP sockets and extracts the payload command strings. Taking advantage of the connectionless nature of the UDP protocol, it eliminates the need for connection establishment, link maintenance, and connection disconnection operations as required by the TCP protocol. This effectively reduces the network communication's impact on the processing and memory resources of the embedded device, enabling the debugging function to run in a lightweight manner on resource-constrained embedded devices.

[0011] Furthermore, this application extracts the command name and command parameters from the payload command string through word segmentation, then performs a match search in a predefined command table using the command name as an index. Upon successful matching, the corresponding function is retrieved and executed. Finally, the execution result data is transmitted back to the debugging device via a UDP socket. This command table-driven mechanism allows adding a new debugging command to simply register a new entry and corresponding function in the command table, without altering the core processes of command reception, parsing, and distribution. The implementation is simple, highly scalable, and the entire debugging process does not require on-site physical access to the device; remote debugging can be completed solely through the network. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a video surveillance system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a debugging method for an embedded device provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a debugging device for an embedded device provided in this application; Figure 4 This is a schematic diagram of a computer storage medium provided in this application; Figure 5 This is a schematic diagram of the structure of an embedded device provided in this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] It should be noted that the debugging method for embedded devices provided in this application is generally executed by the embedded device, and correspondingly, the debugging device for embedded devices is generally set in the embedded device.

[0016] See Figure 1 As shown in the figure, an embodiment of this application provides an embedded debugging system, including a debugging device 1 and an embedded device 2. The debugging device 1 and the embedded device 2 are connected via a network, which can be an Ethernet, a wireless LAN, or other communication network that supports UDP (User Datagram Protocol) transmission. The debugging device 1 is used to send debugging commands to the embedded device 2 and receive execution results, and the embedded device 2 is used to receive and execute debugging commands and return execution results to the debugging device 1.

[0017] Debugging device 1 can be a computing device with network communication capabilities, such as a personal computer, industrial control host computer, mobile terminal, or dedicated debugging terminal. Debugging device 1 runs a debugging client program, which provides a command input interface for developers or maintenance personnel to input the debugging command string to be executed. After obtaining the debugging command string, debugging device 1 encapsulates it into a UDP data packet and sends it to a preset port of embedded device 2 via the network. In a preferred embodiment, before encapsulating the UDP data packet, debugging device 1 also performs a CRC32 calculation on the debugging command string and packages the calculated CRC32 checksum along with the debugging command string into the payload area of ​​the UDP data packet for integrity verification by embedded device 2. Simultaneously, debugging device 1 listens for return data packets from embedded device 2 on a preset receiving port, parses the execution result data from it, and displays it to the user.

[0018] Embedded device 2 can be a resource-constrained embedded system such as a low-power video surveillance device, IoT gateway device, industrial control device, smart home device, or automotive embedded device based on the Linux operating system. Embedded device 2 is equipped with a debugging service module, which executes the described process from steps S101 to S106 upon startup. Specifically, embedded device 2 creates a UDP socket on a preset port and listens. Upon receiving a UDP data packet from debugging device 1, it sequentially performs operations such as IP whitelist verification, CRC32 integrity verification, command string segmentation and parsing, command table matching and lookup, function calls, and result feedback. Embedded device 2 processes all the above operations through a separate command receiving thread, which is isolated from the main business thread of embedded device 2 and does not block each other.

[0019] Communication between debugging device 1 and embedded device 2 uses the UDP protocol throughout. Debugging device 1 sends a UDP data packet encapsulating a debugging command string to a preset port of embedded device 2. After executing the command, embedded device 2 sends a UDP data packet containing the execution result data to a preset receiving port of debugging device 1. Due to the connectionless nature of the UDP protocol, the entire communication process does not require connection establishment, link maintenance, or connection termination, effectively reducing communication overhead and system resource consumption.

[0020] The following will be combined with the appendix Figure 2 This application provides a detailed description of the debugging method for embedded devices according to embodiments of the present application. The debugging device for the embedded device in these embodiments may be... Figure 1 The embedded device shown.

[0021] Please see Figure 2 This is a flowchart illustrating a debugging method for an embedded device provided in an embodiment of this application. Figure 2 As shown, the method described in this application embodiment may include the following steps: S101. Create an independent command receiving thread, and create a UDP socket in the command receiving thread, and bind the UDP socket to a preset port.

[0022] During the main program initialization phase, the embedded device calls the thread creation interface to generate an independent command receiving thread. This thread runs separately from the main program thread; the main program does not need to wait for its completion or perform thread reclamation. The entry point of the command receiving thread is specified as a command listening loop function. When this loop function is first scheduled for execution, the embedded device calls the socket creation function to generate a UDP socket of type datagram. Subsequently, the embedded device sets the address reuse option for this socket, so that when the socket is closed, the same port can be immediately rebound, avoiding service interruption due to the port being in a waiting state. Next, the embedded device constructs a network address structure, specifying the address family as Internet Protocol version 4 (IPL4), setting the IP address to a wildcard address to bind to all available network interfaces of the device, and setting the port number to the preset debug listening port. Finally, the embedded device calls the binding function to associate the UDP socket with the address structure, completing the opening of the listening port. At this point, the command receiving thread enters a blocked waiting state for data.

[0023] Assuming the default port is 8822, in the embedded network camera device, after system startup, `pthread_create` is called, using the command listening loop function `RshellCmdBody` as the thread entry point. Then, `pthread_detach` is called to detach the thread. Inside the thread function, a socket of type `AF_INET` and `SOCK_DGRAM` is established using `socket`, `setsockopt` is used to set `SO_REUSEADDR`, `sin_addr` in `sockaddr_in` is set to `INADDR_ANY`, and `sin_port` is set to `htons(8822)`. Finally, `bind` succeeds, and the device begins listening on port 8822.

[0024] S102. Receive UDP packets from the debugging device via UDP socket, and extract the payload command string and network address information of the debugging device from the UDP packets.

[0025] In its command receiving thread, the embedded device calls the datagram receiving function in a blocking manner to read a complete UDP packet from the bound UDP socket. The received data is stored in a pre-allocated buffer, and the actual length of the packet is recorded. Simultaneously, the receiving function populates a network address structure containing the sender's network address information, primarily the source IP address and source port number of the debugging device. The embedded device extracts and temporarily stores the debugging device's network address information from this address structure for later use in the response. Then, the embedded device parses the payload command string from the buffer; this string represents the main content of the command sent by the debugging device.

[0026] For example, the debugging device sends a string command "log_enable 1" to port 8822 of the camera device via UDP. The receiving thread calls the recvfrom function to store the data in the buffer array buf, and at the same time obtains the address information from 192.168.1.100. The embedded device records this source IP address and extracts the null-terminated string "log_enable 1" from buf as the payload command string.

[0027] S103. Perform word segmentation on the payload command string to extract the command name and at least one command parameter.

[0028] The embedded device uses whitespace characters as delimiters to segment the payload command string. The segmentation process starts from the first character of the string and sequentially obtains segments composed of non-whitespace characters. The first segment obtained is identified as the command name and stored in a command name storage variable. If subsequent segments exist, they are stored one by one in a parameter array in their original order, while a parameter counter variable records the number of parameters already stored. During the segmentation process, the embedded device monitors the parameter counter variable in real time to see if it reaches a preset upper limit. Once the upper limit is reached, segmentation immediately stops, and a parameter over-limit warning message is output to the log system. However, the previously successfully parsed command name and parameters are retained, and subsequent steps can be used normally. After segmentation, a command name representing the debugging intent and zero or more command parameters are obtained.

[0029] S104. Search for a match in the predefined command table based on the command name; if a match is found, retrieve the function corresponding to the command name.

[0030] The embedded device maintains a command table, either statically configured or dynamically registered. Each record in the table contains at least a command name string and a corresponding function pointer. After obtaining the command name, the embedded device iterates through the command table, comparing the command name with the command name strings of each entry in the table. If no match is found after the iteration, it indicates that the current command request is invalid. The embedded device directly discards the entire received and buffered UDP packet, performs no operation, and does not return any data to the debugging device. If a match is found, the pre-registered function pointer is retrieved from the table entry and saved for subsequent calls.

[0031] For example, the command table sShellCmdTbl has a registered entry for "log_enable", with the corresponding function being RShellLogEnable. When the command name is "log_enable", strcmp matches successfully, and the function pointer is retrieved. If the command name is "unknown_cmd", the search fails, and the embedded device discards the entire UDP packet.

[0032] S105. Call the function and pass the command parameters as input parameters to perform the debugging operation and obtain the execution result data generated by the debugging operation.

[0033] The embedded device initiates a call by obtaining a function pointer, passing the segmented command parameter array and the number of parameters as actual arguments. Internally, the function performs specific debugging operations based on the command parameters, such as dynamically enabling or disabling log output for a module, reading system status registers, and modifying configuration items. After the operation is complete, the function organizes the execution result into a string or other agreed-upon format and returns it as the execution result data to the main command processing flow. If the command does not require returning specific data, it can return a brief status description indicating success or failure.

[0034] For example, calling RShellLogEnable with the parameter "1" sets the logging enable flag for the specified module and then returns the string "log module enabled". This string is the execution result data.

[0035] S106. Based on the network address information, encapsulate the execution result data into a UDP data packet via a UDP socket, and send the UDP data packet to the debugging device.

[0036] The embedded device retrieves the temporarily stored network address information of the debugging device, including the source IP address and source port number. Using the execution result data as the UDP payload, it calls the datagram sending function, encapsulates the payload into a new UDP packet through the same UDP socket, and sends it directly to the aforementioned network address. Sending can be done in either non-blocking or blocking mode. After sending is complete, the current command processing loop ends, and the thread returns to the receiving state to continue listening for the next UDP packet.

[0037] For example, given the returned result "log module enabled", the embedded device calls the sendto function to send this string to the source port 192.168.1.100 via a socket. The debugging device can then display this result upon receiving the UDP packet, completing a full remote debugging interaction.

[0038] In one possible embodiment, creating a separate command receiving thread includes: S1011, Execute the initialization function.

[0039] After an embedded device powers on and boots into the user space main program, it first executes a set of pre-defined initialization operations. This initialization function is part of the main program's startup phase and is responsible for completing basic system configurations and preparing for subsequent debugging functions. The initialization function executes before the main program enters its core business logic, ensuring that the debugging channel is ready before the main business begins running. Inside the initialization function, in addition to creating a command receiving thread, it can also include other necessary system initialization work, such as loading configuration files and starting the logging system. The initialization function is executed only once in the main program's main thread context.

[0040] In one example, taking an embedded network camera, after its main program function starts, it calls several initialization functions in sequence, including RShellCmdInit. This function is the initialization entry point for enabling remote command debugging in this application's technical solution. After executing RShellCmdInit, the main program continues to load other business components such as the video encoding module and the network transmission module.

[0041] S1012. In the initialization function, the pthread_create interface is called to create the command receiving thread, and the command listening loop function is specified as the thread entry function.

[0042] Inside the initialization function, the embedded device calls the POSIX-compliant thread creation interface `pthread_create` to generate a command receiving thread independent of the main program's execution flow. Calling this interface requires passing several parameters, including attribute parameters specifying thread properties, a pointer to the thread's entry function, and optional parameters to be passed to the entry function. In this application, the name of the command listening loop function is passed as the entry function pointer, making it the first function executed after the new thread starts. After successful thread creation, the interface returns a success flag, and the new thread immediately enters a schedulable state, scheduled for execution by the operating system kernel. At this point, the main program and the command receiving thread form two concurrent execution flows; the main program continues executing the remaining steps in the initialization function, while the command receiving thread begins running independently.

[0043] For example, in the `RShellCmdInit` function, the embedded device calls `pthread_create`, sets the first thread attribute parameter to null to indicate the use of default attributes, specifies the entry function parameter as `RshellCmdBody`, and sets the parameter passed to null. After the call is completed, a new execution thread named `RshellCmdBody` is added. This thread runs concurrently with the main thread and does not block each other.

[0044] S1013. After the command receiving thread is successfully created, call the pthread_detach interface to set the command receiving thread to the detach attribute so that the thread will automatically release resources after it finishes running, without the need for the main thread to reclaim them. When the command listening loop function is executed, the UDP socket is created and bound to the preset port.

[0045] After the command receiving thread is successfully created, the embedded device immediately calls the `pthread_detach` interface to change the thread's state attribute from the default joinable attribute to the detached attribute. The core purpose of setting the detached attribute is that when the command receiving thread terminates and exits at some point in the future, the system resources it occupies, such as the thread descriptor and stack space, will be automatically reclaimed and released by the operating system. The main program thread does not need to call the `pthread_join` interface in subsequent code to wait for the thread to terminate or manually reclaim its resources. This design allows the main program to completely ignore the lifecycle management of the command receiving thread, simplifying program logic and avoiding memory leaks caused by forgetting to reclaim thread resources. Afterward, the command receiving thread runs completely independently, continuously listening on the UDP port and processing command requests throughout its lifecycle until the system shuts down or the thread is explicitly terminated.

[0046] For example, after `pthread_create` returns successfully in the `RShellCmdInit` function, `pthread_detach` is immediately called, passing the previously created thread identifier as an argument. From this point on, the `RshellCmdBody` thread is set to a detached state. If this thread exits for any reason in the future, the resources it occupied will be automatically reclaimed by the system, and the video encoding, network transmission, and other business logic in the main thread will be completely unaffected.

[0047] In one possible embodiment, the step of creating a UDP socket in the command receiving thread and binding the UDP socket to a preset port includes: S1014. Call the socket function to create a UDP socket. The protocol family parameter of the socket function is specified as AF_INET, and the transport type parameter is specified as SOCK_DGRAM.

[0048] Inside the command listening loop function, the embedded device first calls the socket creation function `socket` to generate a socket descriptor for network communication. The `socket` function requires three parameters: protocol family, transport type, and specific protocol. In this application, the protocol family parameter is specified as `AF_INET`, indicating that the socket will use the Internet Protocol version 4 (IPv4) address family for communication. The transport type parameter is specified as `SOCK_DGRAM`, indicating that the socket is a datagram type, and the corresponding transport layer uses the User Datagram Protocol (UDP). The third parameter is usually passed as 0, allowing the system to automatically select the default protocol based on the first two parameters. After a successful call to the `socket` function, a non-negative integer socket descriptor is returned, which serves as a handle for all subsequent socket operations.

[0049] For example, after the command listening loop function RshellCmdBody is scheduled to execute, it first performs a socket call, passing in three parameters: AF_INET, SOCK_DGRAM, and 0. The function returns an integer value, such as 3, which serves as the newly created UDP socket descriptor. Subsequent setsockopt and bind operations revolve around this descriptor 3.

[0050] S1015. Call the setsockopt function to set the SO_REUSEADDR option for the UDP socket to allow the port to be reused immediately after the socket is closed.

[0051] After a UDP socket is successfully created, the embedded device immediately calls the `setsockopt` function to set socket options. The `setsockopt` function allows configuration of specific behaviors at the socket level. In this application, the option level parameter is specified as `SOL_SOCKET` (generic socket layer), the option name parameter is specified as `SO_REUSEADDR` (address reuse option), and the option value is set to 1 to enable it. This option ensures that when the UDP socket is released due to process exit or active closure, the operating system kernel will immediately allow the same port to be re-bound by a newly created socket without waiting. In embedded device debugging scenarios, if the command receiving thread needs to be restarted after an abnormal exit, this option ensures that the preset port can be quickly re-occupied, avoiding prolonged unavailability of the debugging service due to the port being in a waiting state.

[0052] For example, for socket descriptor 3, the embedded device calls setsockopt, passing SOL_SOCKET as the level parameter and SO_REUSEADDR as the option name parameter, setting the integer variable of the option value to 1. After successful setup, when the socket is closed, port 8822 will not enter a waiting state, and newly started listening threads can immediately rebind to port 8822.

[0053] S1016. Construct a sockaddr_in structure, set its address family field to AF_INET, its IP address field to INADDR_ANY, and its port number field to the port number of the preset port.

[0054] After completing the socket option settings, the embedded device begins preparing the necessary address information for binding. Specifically, the embedded device constructs a `sockaddr_in` structure variable in the stack space or static data area. This structure is a socket address structure specific to the IPv4 address family and contains three key fields. The first field is the address family field, also set to `AF_INET`, consistent with the protocol family when the socket was created. The second field is the IP address field, set to `INADDR_ANY`, i.e., a wildcard address. Its value is usually a constant 0.0.0.0, indicating that the socket will be bound to all available network interfaces on the embedded device, including wired, wireless, and local loopback interfaces, ensuring that UDP packets from any network path can be received. The third field is the port number field, set to the default port number. Since the network byte order may differ from the host byte order, a byte order conversion function needs to be called to convert the host byte order port number to the network byte order before filling this field.

[0055] For example, the default port is 8822. The embedded device defines a sockaddr_in variable addr, assigns addr.sin_family to AF_INET, addr.sin_addr.s_addr to INADDR_ANY, and addr.sin_port to htons(8822). The htons function converts the host byte order 8822 to network byte order, ensuring that port numbers are correctly recognized across different processor architectures.

[0056] S1017. Call the bind function to bind the UDP socket to the sockaddr_in structure to listen on the preset port.

[0057] After the address structure is constructed, the embedded device calls the `bind` function to associate and bind the previously created UDP socket with the constructed address structure. The `bind` function takes three parameters: the socket descriptor, a pointer to the address structure, and the size of the address structure. Essentially, the binding operation registers a local address for the socket in the operating system kernel. Thereafter, all data packets sent to the port corresponding to that address will be delivered to the socket by the kernel. The `bind` function returns 0 on success and a negative value on failure. After successful binding, the preset port enters the listening state, and the embedded device then enters the next command receiving loop, waiting in a blocking manner for UDP packets from the debugging device.

[0058] For example, given socket descriptor 3 and the constructed addr structure, the embedded device calls bind, passing in socket descriptor 3, a pointer to addr, and the size of the addr structure, sizeof(addr). After the bind call succeeds, the kernel associates port 8822 with socket descriptor 3, and any UDP packets sent to port 8822 of the embedded device will be received by this socket. The program then executes recvfrom to enter a blocking wait state.

[0059] In one possible embodiment, before performing word segmentation on the payload command string to extract the command name and at least one command parameter, the method further includes: A1. Extract the source IP address of the debugging device from the network address information.

[0060] After successfully receiving a UDP packet via the `recvfrom` function, the embedded device obtains not only the payload command string but also a `sockaddr_in` structure populated by the kernel, which records the sender's network address information. The embedded device extracts the source IP address of the debugging device from the corresponding field of this structure. This source IP address is a 32-bit IPv4 address, typically represented in dotted decimal notation, such as 192.168.1.100. The extracted source IP address is temporarily stored in a local variable for use in subsequent whitelist comparisons.

[0061] For example, after the debugging device sends a UDP packet to the embedded device, the sin_addr.s_addr field in the address structure returned by the receive function records the source IP address. The embedded device calls conversion functions such as inet_ntoa to convert this field into a readable string "192.168.1.100" and temporarily stores it in the variable client_ip for comparison with the whitelist of IP addresses.

[0062] A2. Compare the source IP address with the pre-stored whitelist of IP addresses one by one.

[0063] Embedded devices internally store a whitelist of IP addresses, containing one or more IP addresses authorized to send debug commands. This list can be a static array embedded in the code during compilation or a dynamic list loaded from a configuration file. When the embedded device performs whitelist verification, it iterates through each item in the whitelist, comparing the extracted source IP address with the current item using a string or binary value. This comparison process is performed one by one until a match is found or all list items have been traversed.

[0064] Suppose the whitelist of IP addresses contains three addresses: 192.168.1.100, 192.168.1.101, and 10.0.0.5. The embedded device first compares the client_ip with 192.168.1.100. If they match, a match is found, and the comparison ends. If they don't match, the comparison continues with the next address until all matches are completed.

[0065] A3. If the source IP address does not appear in the whitelist, the UDP packet is determined to be illegal and discarded.

[0066] If, after iterating through all entries in the whitelist of IP addresses, the source IP address does not match any record, the embedded device determines that the UDP packet is an illegal request from an unauthorized device. In this case, the embedded device does not perform any further parsing or processing of the payload command string; it simply discards the entire received and buffered UDP packet. Discarding means releasing the corresponding buffer space and does not return any response data to the sender via the UDP socket. This mechanism blocks unauthorized devices from gaining debugging access to the embedded device at the source.

[0067] For example, if the client_ip is 192.168.1.200, and the address is not included in the whitelist of IP addresses, the embedded device will determine that the data packet is illegal, release the buf buffer, and no longer perform word segmentation and command matching operations.

[0068] A4. Generate an access denial log containing the source IP address and the current timestamp.

[0069] Upon determining a UDP packet to be illegal and discarding it, the embedded device generates an access denial log entry. This log entry contains at least two key pieces of information: the source IP address of the denied request and the timestamp of the denial. The timestamp is typically taken from the system's real-time clock or runtime count since startup, and can be in Unix timestamp format or a readable date and time string. The log entry is output through the embedded device's own logging system, such as being written to a log file, sent to the serial console, or output to the system log buffer. By reviewing this log, device administrators can trace the source and time of unauthorized access attempts, thereby promptly identifying potential security threats and adjusting whitelist policies.

[0070] For example, after detecting an unauthorized access to 192.168.1.200, the embedded device calls the log output function to generate a log record in the format "Access denied from 192.168.1.200 at 1730419200", where 1730419200 is the Unix timestamp of the current time, corresponding to a certain time on July 26, 2026.

[0071] A5. If the source IP address appears in the whitelist, the IP whitelist verification is deemed successful, and word segmentation processing continues.

[0072] If the source IP address matches exactly with any item in the whitelisted IP address list during the comparison process, the embedded device determines that the IP whitelist verification has passed, indicating that the UDP packet originated from a trusted debugging device. At this point, the embedded device no longer generates a rejection log, but instead retains the extracted payload command string as valid, and the process continues to the next step of segmenting the payload command string. This path ensures that legitimate debugging devices can successfully execute subsequent command parsing and execution processes.

[0073] For example, when the client_ip is 192.168.1.100 and the whitelist is matched, the embedded device skips the discarding and logging logic and directly enters the strtok word segmentation process for the payload command string "log_enable 1", ensuring that the legitimate debugging command is executed normally.

[0074] The embedded device incorporates an IP address-based network layer security filtering mechanism before command segmentation. This mechanism is implemented using a lightweight list comparison method, eliminating the need for complex encrypted authentication handshake processes, which aligns with the low-overhead characteristics of UDP's connectionless nature. Only UDP packets from debugging devices within the whitelist of IP addresses are allowed to enter the subsequent command parsing process; packets from unauthorized sources are directly discarded and logged as access denied. This prevents unauthorized remote access and provides administrators with auditable security event records. Because security filtering occurs before command segmentation, illegitimate packets do not consume CPU resources for segmentation and command matching, further reducing the processing overhead of the device when subjected to malicious scanning.

[0075] In one possible embodiment, the method further includes: B1. Extract the original command string and the first CRC check value from the load command string. The first CRC check value is generated by the debugging device by performing CRC32 calculation on the original command string.

[0076] Before sending a UDP packet, the debugging device performs a CRC32 calculation on the original command string to be sent, generating a fixed-length first CRC checksum. Then, the debugging device packages the original command string and the first CRC checksum according to a pre-defined format, sending them together as the payload content of the UDP packet. The embedded device receives and extracts the payload command string, then decompiles it in reverse according to the same pre-defined format. Specifically, the embedded device separates two parts from the payload command string based on a pre-defined delimiter or fixed bit offset: the first part is the original command string, and the second part is the first CRC checksum. The extracted first CRC checksum is calculated by the debugging device at the sending end and is used by the receiving end for data integrity comparison.

[0077] For example, the debug device sends a raw command string of "log_enable 1". The debug device calls a CRC32 calculation function on this string to obtain a 32-bit checksum, for example, 0xA1B2C3D4 in hexadecimal. The debug device concatenates the raw command string and the checksum using a vertical bar or other agreed-upon delimiter to form "log_enable 1|A1B2C3D4", and encapsulates this as the payload command string in a UDP packet for transmission. Upon receiving the packet, the embedded device locates the delimiter, extracts "log_enable 1" as the raw command string, and extracts "A1B2C3D4" as the first CRC checksum.

[0078] B2. Perform CRC32 calculation on the extracted original command string to generate a second CRC check value.

[0079] After successfully extracting the original command string from the payload command string, the embedded device independently performs a CRC32 checksum calculation on the original command string using the exact same algorithm as the debugging device. The calculation process iterates through each character in the original command string, generating a 32-bit checksum value according to the CRC32 polynomial. This calculation is performed locally on the embedded device and does not depend on network transmission. The calculated checksum value is called the second CRC checksum value and is used to compare it with the received first CRC checksum value.

[0080] For example, the embedded device takes the extracted original command string "log_enable 1" and calls its local CRC32 calculation function to generate a second CRC checksum, assuming the result is also 0xA1B2C3D4. This value is compared with the first CRC checksum extracted from B1. If the string has not changed during transmission, the two checksums should match.

[0081] B3. Compare the second CRC check value with the first CRC check value.

[0082] The embedded device compares the locally calculated second CRC checksum with the first CRC checksum extracted from the payload command string bit by bit. The comparison can be performed by performing a bitwise XOR operation on the two checksums, or by directly using a memory comparison function to determine if they are completely equal. Since the CRC32 checksum is a fixed-length, compact data set, the comparison operation only requires a few processor instruction cycles, resulting in minimal CPU overhead for the embedded device. The comparison result determines the execution path for subsequent steps.

[0083] For example, if the first CRC checksum is 0xA1B2C3D4 and the second CRC checksum is also 0xA1B2C3D4, then they are equal, and the comparison result is consistent. If a character in the payload command string undergoes a bit flip during transmission, for example, "log_enable 1" becomes "log_enable 0", then the locally calculated second CRC checksum will become a completely different value, and the comparison result will be inconsistent.

[0084] B4. If there is no consistency, the UDP packet is determined to be corrupted or tampered with, and the UDP packet is discarded.

[0085] If the comparison result of the second CRC checksum and the first CRC checksum is inconsistent, it indicates that there is a difference between the original command string extracted from the payload command string and the original content sent by the sender. There are two possible reasons for this difference: one is that the data packet is interfered with during network transmission, resulting in bit errors or data corruption; the other is that the data packet has been maliciously tampered with by a third party along the transmission path. Regardless of the situation, the embedded device determines that the UDP data packet is untrusted. In this case, the embedded device directly discards the entire received and buffered UDP data packet, without performing any word segmentation on the original command string or executing any command operations. After discarding, the embedded device returns to the receive blocking state and continues to wait for the next UDP data packet.

[0086] For example, if the CRC checksum in the received payload command string does not match the original command string, for example, due to network interference causing bit flipping in the original command string, the embedded device determines that the UDP packet is corrupted, releases the buffer, discards the packet, and returns recvfrom to block and wait.

[0087] B5. If they match, the CRC integrity check is deemed successful, and the original command string is used as the payload command string. The step of segmenting the payload command string is then performed.

[0088] If the second CRC checksum matches the first CRC checksum, it indicates that the content of the original command string remained intact and unchanged throughout the entire process from the debugging device to the embedded device, without any transmission errors or tampering. The embedded device determines that the CRC integrity check passed, and the content of the original command string is reliable. At this point, the embedded device uses the original command string as the valid payload command string, replacing the payload command string initially extracted from the UDP packet but not yet disassembled, and then proceeds to the word segmentation process. Subsequent word segmentation operations will use the verified original command string as the operation object, extracting the command name and command parameters, thereby completing command table matching and function calls.

[0089] For example, after the CRC check passes, the embedded device passes the verified original command string "log_enable 1" as the payload command string to the strtok word segmentation function. The word segmentation function then extracts the command name "log_enable" and the command parameter "1" from the string and continues with subsequent command table matching and execution steps.

[0090] Embedded devices incorporate a CRC32-based data integrity verification mechanism in their command execution flow. This mechanism effectively identifies and discards data packets with erroneous content due to transmission interference or malicious tampering before command segmentation, preventing the embedded device from executing incorrect or harmful debugging commands. The CRC32 algorithm has low computational overhead, requiring only a single traversal of the command string to generate a checksum, making it suitable for resource-constrained embedded environments. The practice of directly discarding UDP packets that fail verification without returning any response also reduces the risk of information exposure for the embedded device under malicious probing. CRC integrity verification, together with the aforementioned IP whitelist mechanism, constitutes a multi-layered security protection system. The former verifies the integrity and authenticity of the data content, while the latter identifies the legitimacy of the request source. Their collaborative operation enhances the reliability and security of remote debugging operations.

[0091] In one possible embodiment, each command in the command table is preset with a permission level, which includes at least public, restricted, and high-risk levels. Before calling the function, passing the command parameters as input to perform the debugging operation, and obtaining the execution result data generated by the debugging operation, the method further includes: C1. Obtain the permission level corresponding to the command name from the command table.

[0092] After finding an entry matching the command name in the command table, the embedded device reads the corresponding permission level value from the permission level field of that entry, either before or simultaneously with obtaining the function pointer. Each command record in the command table contains two basic fields: the command name string and the function pointer, plus an additional permission level field, which is preset during command registration. The permission level field has at least three possible values: public, restricted, and high-risk. After reading this field, the embedded device temporarily stores it in a permission determination variable for subsequent steps to perform hierarchical judgments. By directly registering permission levels in the command table, the access control policy for each command is bound to the command definition, achieving centralized and modular permission management.

[0093] For example, in the command table sShellCmdTbl, the "log_enable" command entry contains three fields: the command name is "log_enable", the function pointer is RShellLogEnable, and the permission level field is preset to public. When the command name matches successfully, the embedded device reads the permission level as public from this entry, stores it in the variable cmd_level, and then proceeds to the next step of hierarchical processing logic.

[0094] C2. If it is public, then the function is allowed to be called.

[0095] If the read permission level is public, the embedded device performs no additional authentication and directly determines that the command call is permitted. Public permission is typically assigned to routine debugging commands that do not involve system security or have a significant impact on the device's operating status, such as logging on / off and status queries. The embedded device then skips subsequent permission verification steps and directly proceeds to the function call stage. This design ensures security while maintaining minimal access latency for frequently used, low-risk commands.

[0096] For example, the "log_enable" command has a public permission level. After the embedded device confirms that cmd_level is public, it does not perform any token verification or administrator verification, but directly calls the RShellLogEnable function, passing in the corresponding command parameters.

[0097] C3. If the access level is restricted, extract the token field from the UDP packet and compare it with a pre-stored valid token. If the comparison matches, the function call is allowed; if they do not match, the call is rejected, a restricted access log is recorded, and the UDP packet is discarded.

[0098] If the access level read is restricted, it means that the command can only be executed by a debug device holding a valid token. Restricted access is typically assigned to commands that may affect module operating parameters but do not pose a system-level risk, such as modifying specific module configurations or triggering one-time diagnostic operations. The embedded device first extracts the token field from the UDP packet payload according to a pre-defined format. This token field is embedded by the debug device during packet assembly. The extraction of the token field is usually similar to the extraction of the CRC checksum, parsed from the payload command string based on a pre-defined delimiter or offset. Then, the embedded device compares the extracted token field with pre-stored valid tokens. A valid token can be a pre-defined fixed string or a list of tokens that rotates periodically. If the comparison matches, the embedded device determines that the token verification is successful and allows the function call. If the comparison does not match, the embedded device refuses to call the function, generates a restricted access log, recording the source IP address of the request, the name of the requested command, the erroneous token carried, and the current timestamp. Finally, the entire UDP packet is discarded without returning any execution result.

[0099] For example, the "set_threshold" command is used to modify the sensor alarm threshold, and its permission level is preset to restricted. The embedded device extracts the token field, such as "TOKEN123", from the payload command string. It compares "TOKEN123" with a locally stored list of valid tokens. If "TOKEN123" exists in the list, the verification is successful, and the corresponding function is called; if the token is "TOKEN999" and not in the list, the call is rejected, a log message "Restricted access denied from 192.168.1.100 for set_threshold with invalid token at1730419200" is generated, and the UDP packet is discarded.

[0100] C4. If the risk level is high, extract the administrator credentials from the UDP packet and verify the administrator privileges. If the verification is successful, the function call is allowed; if the verification fails, the call is rejected, an alarm log is recorded, and the UDP packet is discarded.

[0101] If the read permission level is high-risk, it indicates that the command involves system security or may have a significant impact on the device's operating status, and only debugging devices with administrator privileges are allowed to execute it. High-risk levels are typically assigned to high-risk commands such as firmware upgrades, system resets, and security policy modifications. The embedded device extracts the administrator credential field from the UDP packet payload according to a predefined format. The administrator credential verification mechanism can be more stringent than token verification, such as using encrypted hash comparison, digital signature verification, or dynamic password verification. The embedded device sends the extracted administrator credential to the administrator permission verification module for verification. If the verification passes, it indicates that the debugging device holds valid administrator credentials and is allowed to call function calls. If the verification fails, the embedded device refuses to call function calls and generates an alarm log. The severity level of the alarm log is higher than that of ordinary access denial logs and restricted access logs. The recorded content also includes key information such as the source IP address, command name, and current timestamp. Finally, the entire UDP packet is discarded, and no execution result is returned.

[0102] For example, the "factory_reset" command is used to restore the device to factory settings, and its privilege level is preset to high risk. The embedded device extracts the administrator credential field from the payload command string, such as a password digest value processed by a hash algorithm. The extracted credential is sent to the verification module for comparison. If the credential matches the pre-stored administrator credential, the verification passes, and the corresponding function of factory_reset is called; if the credential is incorrect, the call is rejected, an alarm log "Critical: High-risk access denied from 192.168.1.100 for factory_resetat 1730419200" is generated, and the UDP packet is discarded.

[0103] In one possible embodiment, the step of segmenting the payload command string to extract the command name and at least one command parameter includes: S1031. Call the strtok function to segment the payload command string using a space character as a delimiter.

[0104] After receiving the payload command string that has passed all security checks, the embedded device begins word segmentation. The core of the word segmentation operation is calling the `strtok` string splitting function provided by the standard C library. When called, the first parameter is the address of the beginning of the payload command string, and the second parameter is a delimiter string containing only whitespace characters. The `strtok` function scans from the beginning of the payload command string, identifying consecutive whitespace characters as delimiters between segments. It marks the start of a segment when it encounters the first non-whitespace character and the end of a segment when it encounters another whitespace character or a string terminator. The function then writes a null character as a truncation at that end position and returns the start pointer of that segment as its return value. Subsequent calls to the function pass a null pointer as the first parameter, and `strtok` will automatically continue scanning from the last truncated position until the entire string has been scanned.

[0105] Assume the payload command string is "log_enable 1". The embedded device calls `strtok` for the first time, passing a pointer to the string and a space separator "". `strtok` starts recognizing the character "l", truncates the string when it encounters a space after "log_enable", and returns a pointer to "log_enable". The next call to `strtok`, passing a null pointer, skips the spaces and finds "1", truncates the string at the end, and returns a pointer to "1". The third call to `strtok` returns a null pointer, indicating that the string processing is complete.

[0106] S1032. The first word extracted is used as the command name and stored in the command name variable.

[0107] The embedded device identifies the first non-empty term returned by the initial call to the strtok function as the command name for the current debugging command. The command name is the identifier for the debugging operation and is used for subsequent command table lookups. The embedded device stores a pointer or copy of this term in a predefined command name variable, typically a character array or character pointer, specifically designed to store the name of the currently processed command. Once stored, this variable remains unchanged throughout the command processing flow and is used by the command table matching step.

[0108] For example, given the payload command string "log_enable 1", the first call to strtok returns "log_enable". The embedded device stores this string pointer in the command name variable cmd_name, and subsequent steps retrieve the command name "log_enable" by accessing cmd_name.

[0109] S1033. Store the subsequent words that have been split out into the parameter array shellArgv in order.

[0110] After extracting the command name, the embedded device continues to call the strtok function on the remaining part of the payload command string, obtaining a subsequent segment with each call. These subsequent segments are identified as command parameters, each corresponding to an input value required for command execution. The embedded device stores the pointer or copy of each parameter into a predefined parameter array shellArgv in the order in which the segments are obtained. Each element of the shellArgv array stores a command parameter; the first parameter, shellArgv[0], corresponds to the first segment after the command name, the second parameter corresponds to the second segment, and so on. If the payload command string contains no segments other than the command name, the shellArgv array remains empty.

[0111] For example, in “log_enable 1”, “1” is the following word segment. The embedded device stores “1” in shellArgv[0]. If the payload command string is “set_level 3 verbose”, then “3” is stored in shellArgv[0] and “verbose” is stored in shellArgv[1].

[0112] S1034. Use the parameter counting variable shellArgc to record the number of parameters that have been stored.

[0113] The embedded device maintains an integer parameter counter variable, `shellArgc`, to dynamically record the number of parameters successfully stored in the parameter array `shellArgv`. Before tokenization begins, `shellArgc` is initialized to 0. Each time a new command parameter is stored in the `shellArgv` array, the value of `shellArgc` is incremented by 1. After all tokenization operations are complete, the final value of `shellArgc` represents the total number of command parameters carried in this command request. This variable will be passed as an input parameter when subsequent function calls are made. The function can determine the valid length of the parameter array based on the value of `shellArgc`, thus correctly processing the passed parameter list.

[0114] For example, when parsing "log_enable 1", after parsing the command name, shellArgc is initially 0. After storing "1" in shellArgv[0], shellArgc is incremented to 1, indicating that this command carries one command parameter. When parsing "set_level3 verbose", the final value of shellArgc is 2.

[0115] S1035. During the word segmentation process, detect in real time whether shellArgc has reached the preset upper limit value.

[0116] After each new parameter is added to the parameter array and the shellArgc counter is updated, the embedded device immediately compares the current value of shellArgc with a preset upper limit. The preset upper limit is a constant determined during compilation or initialization to limit the maximum number of parameters that can be carried in a single command request. The purpose of setting this upper limit is to prevent malicious or abnormally long parameter lists from causing parameter array overflow, consuming excessive memory, or causing excessively long parsing times. Real-time detection means that a boundary check is performed every time a parameter is added; once the upper limit condition is triggered, the rate-limiting process immediately begins, and the extraction of remaining segments from the payload command string is stopped.

[0117] Assume the preset upper limit is 32. When parsing a command with a large number of parameters, after storing each parameter in shellArgv and incrementing shellArgc by 1, the embedded device checks if shellArgc equals 32. Normal word segmentation continues when shellArgc is 30 or 31; once it reaches 32, the upper limit processing is immediately triggered.

[0118] S1036. If the preset upper limit value is reached, the word segmentation is stopped, and a parameter over-limit warning message is output to the log system. At the same time, the parsed parameters are retained for subsequent function calls.

[0119] When real-time detection determines that shellArgc has reached its preset upper limit, the embedded device immediately stops further word segmentation of the payload command string and ceases calling the strtok function to extract remaining segments. At this point, the payload command string may still contain unparsed content, but this will be ignored and not stored in the parameter array. Simultaneously, the embedded device outputs a parameter limit warning message through its logging system, recording key information such as the source IP address, command name, and number of parsed parameters for administrator investigation of abnormal requests. Although word segmentation has been prematurely terminated, the command parameters that have been successfully parsed and stored in the parameter array remain valid, and the contents of the shellArgv array and the shellArgc count remain unchanged. The embedded device continues to use these parsed valid parameters for subsequent command table matching and function call steps, ensuring that extracted parameters are not discarded due to exceeding the limit.

[0120] For example, a command's payload command string carries 35 parameters, exceeding the preset limit of 32. The embedded device triggers the limit after parsing the first 32 parameters and when shellArgc reaches 32. Parameters 33 and beyond are ignored and not stored in shellArgv. A warning log is output: "Parameter overflow from 192.168.1.100 for cmd_name:32 parameters parsed". Subsequently, the embedded device continues to execute the function call with shellArgc set to 32 and the 32 parameters already stored in shellArgv.

[0121] The embedded device implements a standardized word segmentation and parsing process for payload command strings. Using the `strtok` function with spaces as delimiters, it maintains consistency with command-line interaction conventions, allowing the debugging device to send commands without complex serialization formats. Through a combination of parameter counter variables and parameter arrays, command parameters are passed to the function in an ordered manner, ensuring the accuracy of command parsing and the predictability of execution logic. The setting of preset upper limits and the real-time detection mechanism effectively prevent buffer overflows and resource exhaustion risks caused by abnormal parameter lists, enhancing the system's robustness at the parsing level. The strategy of discarding only the excess parameters while retaining the parsed parameters when they exceed the limits balances security protection with maximizing the execution of some valid commands, avoiding the loss of debugging information caused by completely discarding valid parameters due to a single abnormal request.

[0122] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0123] Please see Figure 3This illustration shows a schematic diagram of the structure of a debugging apparatus for an embedded device provided in an exemplary embodiment of this application, hereinafter referred to as apparatus 3. Apparatus 3 can be implemented as all or part of an embedded device through software, hardware, or a combination of both. Apparatus 3 includes: A creation module 301 is used to create an independent command receiving thread, and to create a UDP socket in the command receiving thread and bind the UDP socket to a preset port; Extraction module 302 is used to receive UDP data packets from the debugging device through the UDP socket, and extract the payload command string and the network address information of the debugging device from the UDP data packets; The word segmentation module 303 is used to perform word segmentation on the payload command string and extract the command name and at least one command parameter; The matching module 304 is used to search for a match in a predefined command table based on the command name; if the match is successful, the function corresponding to the command name is obtained. The execution module 305 is used to call the function and pass the command parameters as input parameters to perform debugging operations and obtain the execution result data generated by the debugging operations; The encapsulation module 306 is used to encapsulate the execution result data into a UDP data packet through the UDP socket according to the network address information, and to send the UDP data packet to the debugging device.

[0124] For other details regarding the implementation of the above technical solution by each module in the debugging device of the above embedded device, please refer to the description in the debugging method of the embedded device provided in the above embodiments of the invention, which will not be repeated here.

[0125] It should be noted that the above-described embodiment of the device 3, when executing the embedded device debugging method, only exemplifies the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. Furthermore, the embedded device debugging device and the embedded device debugging method embodiment provided in the above embodiment belong to the same concept, and their implementation process is detailed in the method embodiment, which will not be repeated here.

[0126] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0127] See Figure 4 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 4The computer program shown above), the instructions are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0128] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the debugging method of the embedded device as described in the above embodiments.

[0129] Please see Figure 5 This document provides a schematic diagram of the structure of an embedded device according to an embodiment of this application. Figure 5 As shown, the embedded device 500 may include: at least one processor 501, at least one network interface 504, memory 505, and at least one communication bus 502.

[0130] The communication bus 502 is used to enable communication between these components.

[0131] Optionally, the embedded device 500 also includes a user interface 503. The user interface 503 may include a touchscreen. Figure 5 Input units such as keyboard and display screen (not shown in the image).

[0132] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0133] The processor 501 may include one or more processing cores. The processor 501 connects to various parts within the embedded device 500 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 501.

[0134] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0135] exist Figure 5In the embedded device 500 shown, the user interface 503 is mainly used to provide an input interface for the user and obtain user input data; while the processor 501 can be used to call the application program stored in the memory 505 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0136] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0137] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A debugging method for an embedded device, characterized in that, The method includes: Create an independent command receiving thread, and create a UDP socket in the command receiving thread, and bind the UDP socket to a preset port; The UDP socket is used to receive UDP packets from the debugging device, and the payload command string and the network address information of the debugging device are extracted from the UDP packets. The payload command string is segmented to extract the command name and at least one command parameter; Based on the command name, a search is performed in the predefined command table; if a match is found, the function corresponding to the command name is retrieved. The function is invoked, and the command parameters are passed as input parameters to perform debugging operations and obtain the execution result data generated by the debugging operations. Based on the network address information, the execution result data is encapsulated into a UDP data packet via the UDP socket, and the UDP data packet is sent to the debugging device.

2. The method according to claim 1, characterized in that, The creation of an independent command receiving thread includes: Execute the initialization function; In the initialization function, the pthread_create interface is called to create the command receiving thread, and the command listening loop function is specified as the thread entry function; After the command receiving thread is successfully created, the pthread_detach interface is called to set the command receiving thread to the detach attribute, so that the thread automatically releases resources after it finishes running, without the main thread having to reclaim them; When the command listening loop function is executed, the UDP socket is created and bound to the preset port.

3. The method according to claim 1, characterized in that, The step of creating a UDP socket in the command receiving thread and binding the UDP socket to a preset port includes: Call the socket function to create a UDP socket, where the protocol family parameter of the socket function is specified as AF_INET and the transport type parameter is specified as SOCK_DGRAM; Call the setsockopt function to set the SO_REUSEADDR option for the UDP socket to allow the port to be reused immediately after the socket is closed; Construct a sockaddr_in structure, set its address family field to AF_INET, its IP address field to INADDR_ANY, and its port number field to the port number of the preset port; The bind function is called to bind the UDP socket to the sockaddr_in structure to listen on the preset port.

4. The method according to claim 1, characterized in that, Before performing word segmentation on the payload command string to extract the command name and at least one command parameter, the method further includes: Extract the source IP address of the debugging device from the network address information; The source IP address is compared one by one with the pre-stored whitelist of IP addresses; If the source IP address does not appear in the whitelist, the UDP packet is deemed invalid and discarded. Generate an access denial log containing the source IP address and the current timestamp; If the source IP address appears in the whitelist, the IP whitelist verification is deemed successful, and word segmentation processing continues.

5. The method according to claim 4, characterized in that, The method further includes: The original command string and the first CRC check value are extracted from the payload command string. The first CRC check value is generated by the debugging device by performing CRC32 calculation on the original command string. Perform CRC32 calculation on the extracted original command string to generate a second CRC check value; Compare the second CRC check value with the first CRC check value; If there is no discrepancy, the UDP packet is determined to be corrupted or tampered with, and the UDP packet is discarded. If they match, the CRC integrity check is deemed successful, and the original command string is used as the payload command string to continue the step of word segmentation of the payload command string.

6. The method according to claim 1, characterized in that, Each command in the command table has a preset permission level, which includes at least public, restricted, and high-risk levels. Before calling the function, passing the command parameters as input to perform the debugging operation, and obtaining the execution result data generated by the debugging operation, the method further includes: Retrieve the permission level corresponding to the command name from the command table; If it is public, then the function described is allowed to be called; If the access level is restricted, the token field is extracted from the UDP packet and compared with a pre-stored valid token. If the comparison matches, the function call is allowed; otherwise, the call is rejected, a restricted access log is recorded, and the UDP packet is discarded. If the risk level is high, the administrator credentials are extracted from the UDP packet and administrator privileges are verified. If the verification is successful, the function call is allowed; if the verification fails, the call is rejected, an alarm log is recorded, and the UDP packet is discarded.

7. The method according to claim 1, characterized in that, The step of segmenting the payload command string to extract the command name and at least one command parameter includes: The strtok function is called to segment the payload command string using a space character as a delimiter. The first word extracted is used as the command name and stored in the command name variable; The subsequent words that are split off are stored sequentially into the parameter array shellArgv; The parameter counter variable shellArgc is used to record the number of parameters that have been stored; During the word segmentation process, it is necessary to detect in real time whether the parameter counting variable shellArgc has reached the preset upper limit value; If the preset upper limit is reached, word segmentation will stop, and a parameter over-limit warning message will be output to the log system. At the same time, the parsed parameters will be retained for subsequent function calls.

8. A debugging device for an embedded device, characterized in that, include: A module is created to create an independent command receiving thread, and within the command receiving thread, a UDP socket is created and bound to a preset port; The extraction module is used to receive UDP packets from the debugging device through the UDP socket, and extract the payload command string and the network address information of the debugging device from the UDP packets; The word segmentation module is used to segment the payload command string into words and extract the command name and at least one command parameter. The matching module is used to search for a match in a predefined command table based on the command name; if a match is successful, the function corresponding to the command name is obtained. An execution module is used to call the function and pass the command parameters as input parameters to perform debugging operations and obtain the execution result data generated by the debugging operations. The encapsulation module is used to encapsulate the execution result data into a UDP data packet through the UDP socket according to the network address information, and to send the UDP data packet to the debugging device.

9. An embedded device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the debugging method of the embedded device as claimed in any one of claims 1 to 7.

Images