Debugging method and device of real-time operating system, equipment and medium

Abstract

The invention discloses a debugging method and device for a real-time operating system, equipment and a medium, and the method comprises the steps: determining an exception stack pointer when a processor is abnormal in response to monitoring that the processor corresponding to the real-time operating system has a system exception error; reading abnormal field data of the processor from the abnormal stack pointer; the abnormal field data comprises a program counter address; if the program counter address is a legal address, searching abnormal debugging information corresponding to the program counter address from a preset debugging database; and if the program counter address is an illegal address, obtaining a target legal address from the abnormal stack pointer, and searching abnormal debugging information corresponding to the target legal address from a preset debugging database. According to the embodiment of the invention, when the hardware error of the processor is monitored, the complete and accurate abnormal field data is read from the stack pointer when the abnormality occurs, and the abnormal field data and the debugging database are further combined to quickly position and output the abnormal debugging information.

Description

Technical Field

[0001] This application belongs to the field of processor debugging technology, specifically relating to a debugging method for a real-time operating system, a debugging device for a real-time operating system, an electronic device, and a readable storage medium. Background Technology

[0002] With the widespread application of the Internet of Things (IoT) and smart devices, Real-Time Operating Systems (RTOS) have become the core architecture of embedded systems. RTOS ensures system real-time performance through task scheduling, synchronization primitives (such as semaphores and queues), and interrupt management; however, its inherent concurrency and non-determinism pose fundamental challenges to system debugging. In practical applications, system anomalies or crashes are inevitable, requiring technicians to promptly locate and analyze the root causes.

[0003] In related technologies, in-circuit debuggers are commonly used to debug the processor's internal workings, setting trigger conditions or interrupting the execution process. However, this method only works when the program counter always points to a meaningful, valid address. If the program counter points to a non-existent, invalid address, the in-circuit debugger cannot locate the cause of the exception. Technicians must manually analyze massive amounts of data, such as the exception stack and register data, to deduce the cause of the exception, resulting in high debugging difficulty and low efficiency. Summary of the Invention

[0004] This application provides a debugging method, apparatus, device, and medium for a real-time operating system, aiming to improve the problem of high debugging difficulty and low efficiency caused by the difficulty in accurately setting trigger conditions in existing processor debugging methods.

[0005] This application discloses a debugging method for a real-time operating system, the method comprising: In response to detecting a system error in the processor corresponding to the real-time operating system, the exception stack pointer at the time of the processor error is determined. Read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; If the program counter address is a valid address, then retrieve the abnormal debugging information corresponding to the program counter address from the preset debugging database; If the program counter address is an invalid address, the target valid address is obtained from the exception stack pointer, and the exception debugging information corresponding to the target valid address is retrieved from the preset debugging database.

[0006] In some feasible implementations, the method further includes: Obtain task monitoring data for each task in the real-time operating system; The task monitoring data is compared with preset task parameters to filter out abnormal tasks and output abnormal warning information for the abnormal tasks.

[0007] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the step of comparing the task monitoring data with the preset task parameters to filter out abnormal tasks with anomalies from the various tasks includes: The task execution time is compared with the maximum execution time threshold; If the running time is greater than the maximum running time threshold, then the task is determined to be a time-abnormal task.

[0008] In some feasible implementations, the task monitoring data includes stack usage information, the preset task parameters include watermark addresses, the abnormal tasks include overflow abnormal tasks, and the step of comparing the task monitoring data with the preset task parameters to filter out abnormal tasks with abnormalities includes: If the stack trace uses information to indicate that the watermarked address has been accessed, then the task is determined to be an overflow exception task.

[0009] In some feasible implementations, the output of abnormal warning information for the abnormal task includes: The timeout time of the time-abnormal task is obtained by calculating using the running time and the maximum running time threshold. The timeout period is used to determine the anomaly level of the time-abnormal task; A graded processing strategy corresponding to the anomaly level is executed for the time-abnormal task.

[0010] In some feasible implementations, the output of abnormal warning information for the abnormal task includes: The stack overflow depth of the overflow exception task is obtained by calculating using the stack usage information and the watermark address. The exception level of the overflow exception task is determined based on the stack overflow depth; The overflow exception task is handled using a tiered processing strategy corresponding to the exception level.

[0011] In some feasible implementations, determining the exception stack pointer when the processor encounters an exception includes: Obtain the link register data of the processor; The link register data is analyzed to determine the abnormal stack pointer of the processor.

[0012] This application also discloses a debugging device for a real-time operating system, the device comprising: An anomaly monitoring module is used to determine the anomaly stack pointer when the processor corresponding to the real-time operating system is detected to have a system anomaly error. The data acquisition module is used to read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; The exception analysis module is used to retrieve exception debugging information corresponding to the program counter address from a preset debugging database if the program counter address is a valid address; and to obtain the target valid address from the exception stack pointer and retrieve the exception debugging information corresponding to the target valid address from the preset debugging database if the program counter address is an invalid address.

[0013] In some feasible implementations, the apparatus further includes: The task monitoring module is used to acquire task monitoring data for each task in the real-time operating system. The abnormal task analysis module is used to compare the task monitoring data with preset task parameters, filter out abnormal tasks with abnormalities from the tasks, and output abnormal warning information for the abnormal tasks.

[0014] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the abnormal task analysis module includes: The time-abnormal task analysis submodule is used to compare the task's running time with the maximum running time threshold; if the running time is greater than the maximum running time threshold, the task is determined to be a time-abnormal task.

[0015] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the abnormal task analysis module includes: The overflow exception task analysis submodule is used to determine that the task is an overflow exception task if the stack usage information indicates that the watermark address has access behavior.

[0016] In some feasible implementations, the time anomaly task analysis submodule includes: The first early warning subunit is used to calculate the timeout time of the time-abnormal task using the running time and the maximum running time threshold; determine the abnormality level of the time-abnormal task using the timeout time; and execute a graded processing strategy corresponding to the abnormality level on the time-abnormal task.

[0017] In some feasible implementations, the overflow exception task analysis submodule includes: The second early warning subunit calculates the stack overflow depth of the overflow exception task using the stack usage information and the watermark address; determines the exception level of the overflow exception task based on the stack overflow depth; and executes a graded processing strategy corresponding to the exception level on the overflow exception task.

[0018] In some feasible implementations, the anomaly monitoring module is specifically used for: Obtain the link register data of the processor; The link register data is analyzed to determine the abnormal stack pointer of the processor.

[0019] This application also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method described in any of the embodiments of this application.

[0020] This application also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described in this application.

[0021] The embodiments of this application have the following advantages: In this embodiment, in response to detecting a system error in the processor corresponding to the real-time operating system, the system determines the exception stack pointer at the time of the exception; reads the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; if the program counter address is a valid address, it searches for exception debugging information corresponding to the program counter address from a preset debugging database; if the program counter address is an invalid address, it obtains the target valid address from the exception stack pointer and searches for exception debugging information corresponding to the target valid address from the preset debugging database. In this embodiment, when a hardware error is detected in the processor, complete and accurate exception context data is read from the stack pointer at the time of the exception. Further analysis of the program counter address in the exception context data determines whether the processor instruction address at the time of the exception points to a valid or invalid address. If it points to a valid address, exception debugging information is quickly output in conjunction with the debugging database; if it points to an invalid address, a valid address is searched from the exception stack pointer to quickly output exception debugging information. This achieves automatic analysis and rapid location of the root cause of the system error by combining the exception context data and preset debugging information. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a debugging method for a real-time operating system provided in an embodiment of this application; Figure 2 This is an architecture diagram of a debug monitor provided in an embodiment of this application; Figure 3 This is a schematic diagram of the time anomaly monitoring task provided in the embodiments of this application; Figure 4 This is a schematic diagram illustrating the acquisition of abnormal scene data provided in an embodiment of this application; Figure 5 This is a schematic diagram of remote analysis and diagnosis of abnormal on-site data provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the location of the root cause of anomalies based on abnormal on-site data provided in an embodiment of this application; Figure 7 This is a schematic diagram of real-time operating system debugging provided in an embodiment of this application; Figure 8 This is a structural diagram of a debugging device for a real-time operating system provided in an embodiment of this application; Figure 9 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] With the widespread application of the Internet of Things (IoT) and smart devices, Real-Time Operating Systems (RTOS) have become the core architecture of embedded systems. RTOS ensures system real-time performance through task scheduling, synchronization primitives (such as semaphores and queues), and interrupt management; however, its inherent concurrency and non-determinism pose fundamental challenges to system debugging. In practical applications, system anomalies or crashes are inevitable, requiring technicians to promptly locate and analyze the root causes.

[0026] In related technologies, the common practice is to rely on JTAG (Joint Test Action Group) online debuggers, which use TAP (Test Access Port) to test the processor's internals and set trigger conditions or interrupt the execution process. However, this method only works when the program counter always points to a meaningful and valid address. If the program counter points to a non-existent or invalid address, the online debugger cannot locate the cause of the exception. Technicians must manually analyze massive amounts of data, such as the exception stack and register data, to deduce the cause of the exception, resulting in high debugging difficulty and low efficiency.

[0027] Based on this, the embodiments of this application aim to improve the problem of high debugging difficulty and low efficiency caused by the difficulty in accurately setting trigger conditions in existing processor debugging methods. They monitor the processor's operation in real time, and when a hardware error is detected, read complete and accurate exception context data from the stack pointer at the time of the exception. Furthermore, by analyzing the program counter address in the exception context data, they determine whether the processor instruction address at the time of the exception points to a legal or illegal address. If it points to a legal address, they quickly output exception debugging information in conjunction with the debugging database; if it points to an illegal address, they search for a legal address from the exception stack pointer to quickly output exception debugging information. This achieves automatic analysis and rapid location of the root cause of system exception errors by combining exception context data and pre-set debugging information.

[0028] It should be noted that the embodiments of this application can be applied to debug monitors, which monitor and debug real-time operating systems in real time. As an example, the debug monitor is DebugMonitor IP, see reference... Figure 2 This paper demonstrates the integration of DebugMonitor IP into a real-time operating system. In a real-time operating system, the processor core (i.e., the CPU, Central Processing Unit) is connected to multiple modules via an AHB Bus Matrix (Advanced High-performance Bus Matrix), including memory (eFLASH), peripherals (such as CANFD and UART), and debug access ports. DebugMonitor IP, acting as a debug monitor, connects to the AHB2APB Bridge (AHB to APB Bridge) via the APB Bus (Advanced Peripheral Bus), thereby connecting to the bus matrix. Through the bus matrix, DebugMonitor IP can comprehensively monitor the system's operating status and write debug information to the eFLASH. Specifically, this embodiment uses the DebugMonitor IP debug monitor as an example for illustrative purposes.

[0029] Reference Figure 1 This application provides a flowchart of a debugging method for a real-time operating system, which includes the following steps: Step 101: In response to detecting a system error in the processor corresponding to the real-time operating system, determine the exception stack pointer at the time the processor error occurred; In this embodiment, when an exception occurs, the processor automatically pushes register data onto the currently used stack pointer. The currently used stack pointer can be the main stack pointer (MSP) or the process stack pointer (PSP), depending on the stack used by the processor at the time of the exception. Therefore, this embodiment monitors the processor's operation in real time using a debug monitor. When a system exception error is detected, the exception stack pointer at the time of the exception is determined to identify which stack pointer to read the exception context data from. System exception errors include, but are not limited to, hardware faults, memory management faults, bus faults, and usage faults.

[0030] Step 102: Read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; In this embodiment, after determining the stack pointer used at the time of the processor exception, exception context data is read from the stack memory of the exception stack pointer. The exception context data can be understood as a snapshot of the exception state, capturing the complete context of the exception. By analyzing the exception context data, the cause of the processor exception error can be diagnosed. The exception context data includes at least the contents of general-purpose registers (such as R0-R15), the status register (xPSR), the link register (LR), and the program counter (PC). The program counter address (PC address) represents the address of the instruction being executed or about to be executed when the processor exception occurs. Therefore, the location of program execution at the time of the exception can be determined through the PC address, thereby locating the erroneous instruction.

[0031] Step 103: If the program counter address is a valid address, then retrieve the abnormal debugging information corresponding to the program counter address from the preset debugging database; In this embodiment, the debug database is pre-stored in eFLASH. The debug database contains at least a linker map file and a disassembled file, detailing information such as function names, function locations, addresses, assemblers, instructions, and function context calls. After obtaining the PC address, it is verified whether the PC address is within the program code address range (i.e., whether it is a valid code address). If the PC address is a valid code address, it can be understood as a normal code address, indicating that the exception occurred within the program code. By querying the debug database, exception debugging information such as the assembly statements, functions, and function context call relationships corresponding to the PC address can be quickly obtained, thereby quickly locating the root cause of the exception.

[0032] Step 104: If the program counter address is an invalid address, obtain the target valid address from the exception stack pointer and search for the exception debugging information corresponding to the target valid address from the preset debugging database.

[0033] In this embodiment, if the PC address is an illegal / abnormal address, it indicates that the instruction points to a range outside the program code. At this time, it is necessary to obtain multiple sets of address information from the exception stack pointer, filter out illegal addresses, and retain the legal addresses as the target legal address. The target legal address may be the address of the last legal function executed before the exception occurred. Then, the debug database is used to query the assembly statements, functions, and function context call relationships corresponding to the target legal address, as well as other exception debugging information.

[0034] This application embodiment reads complete and accurate exception context data from the stack pointer at the time of the exception when a hardware error is detected in the processor. Furthermore, by analyzing the program counter address in the exception context data, it determines whether the processor instruction address at the time of the exception points to a legal address or an illegal address. If it points to a legal address, it quickly outputs exception debugging information in conjunction with the debugging database. If it points to an illegal address, it searches for a legal address from the exception stack pointer to quickly output exception debugging information. This achieves automatic analysis and rapid location of the root cause of system exception errors by combining exception context data and pre-set debugging information.

[0035] In some feasible implementations, the method further includes: Obtain task monitoring data for each task in the real-time operating system; The task monitoring data is compared with preset task parameters to filter out abnormal tasks and output abnormal warning information for the abnormal tasks.

[0036] In this embodiment, each task in the real-time operating system has pre-set corresponding task parameters stored in the debug monitor. These parameters include, but are not limited to, task name, task status (e.g., Running, Ready, Blocked, Suspend, Deleted), maximum runtime threshold, stack space address, and watermark address. The debug monitor also monitors and acquires task monitoring data for each task in the real-time operating system in real time. By comparing the task monitoring data with the task parameters, tasks with anomalies are identified, and anomaly warnings are issued. This embodiment, through system anomaly error location and task monitoring and warning, not only passively monitors and locates system anomalies but also actively monitors the running status of each task, discovering potential risks within tasks. This allows for the repair of potential errors before processor anomalies occur, enabling rapid and accurate detection of system anomalies even in multi-tasking real-time operating system environments and in scenarios with low probability and long-term reproducibility.

[0037] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the step of comparing the task monitoring data with the preset task parameters to filter out abnormal tasks with anomalies from the various tasks includes: The task execution time is compared with the maximum execution time threshold; If the running time is greater than the maximum running time threshold, then the task is determined to be a time-abnormal task.

[0038] In this embodiment of the application, each task is pre-set with a corresponding running time. If the running time exceeds the expectation, it may affect other tasks. Therefore, this embodiment of the application monitors the running status of each task in real time through a debugging monitor, promptly detects abnormal tasks, and takes corresponding measures, such as interrupting the task, issuing an early warning, or recording logs.

[0039] As an example, refer to Figure 3 First, each task is initialized, and the maximum runtime threshold for each task is set and stored in the debug monitor. Next, each task will automatically obtain the corresponding timestamp from the debug monitor, and then the debug monitor will automatically time each task and obtain the exit timestamp of each task. The runtime of each task is calculated by using the entry timestamp and exit timestamp. Finally, the runtime of the task is compared with its corresponding maximum runtime threshold. If it exceeds the threshold, it indicates that the task has exceeded the expected runtime, and the task is determined to be a time-abnormal task. The time-abnormal task is interrupted, and the task with the runtime exceeding the expected time is alarmed and handled.

[0040] In some feasible implementations, the task monitoring data includes stack usage information, the preset task parameters include watermark addresses, the abnormal tasks include overflow abnormal tasks, and the step of comparing the task monitoring data with the preset task parameters to filter out abnormal tasks with abnormalities includes: If the stack trace uses information to indicate that the watermarked address has been accessed, then the task is determined to be an overflow exception task.

[0041] In this embodiment, each task is pre-set with a corresponding watermark address. The watermark address is obtained by adding a preset offset to the bottom value of the task stack. The watermark address serves as a warning line address. Since each task has a corresponding stack space, the stack typically grows from high to low addresses. A watermark address is then set at the bottom (low address) of the stack, slightly higher than the bottom of the stack (e.g., the bottom value plus 100 bytes). When stack usage reaches this watermark address, it indicates that stack usage is nearing its limit, and further usage will overflow into other memory areas. Therefore, this application uses a debug monitor to monitor the access to the task's watermark address in real time. Based on the task's stack usage information, it determines whether the stack pointer has accessed the watermark address. If it has, it indicates that the task has an overflow risk, classifying it as an overflow exception task and issuing a warning message for it. This embodiment, by monitoring the task's watermark address in real time, issues a warning message before a stack overflow occurs, thereby taking preventative measures to avoid system anomalies caused by stack overflow.

[0042] In some feasible implementations, the output of abnormal warning information for the abnormal task includes: The timeout time of the time-abnormal task is obtained by calculating using the running time and the maximum running time threshold. The timeout period is used to determine the anomaly level of the time-abnormal task; A graded processing strategy corresponding to the anomaly level is executed for the time-abnormal task.

[0043] In this embodiment, a warning message will be issued for abnormal tasks, reminding the user program to handle time-sensitive tasks in a tiered manner. Specifically, the difference between the running time and the maximum running time threshold is calculated to determine the timeout period of the abnormal task. The abnormality level of the time-sensitive task is determined based on the length of the timeout, and then corresponding processing strategies are adopted according to the abnormality level. This embodiment quantifies the timeout degree of abnormal tasks through timeout period, thereby adaptively adopting appropriate processing strategies based on the timeout degree, achieving refined management of time-sensitive tasks.

[0044] In some feasible implementations, the output of abnormal warning information for the abnormal task includes: The stack overflow depth of the overflow exception task is obtained by calculating using the stack usage information and the watermark address. The exception level of the overflow exception task is determined based on the stack overflow depth; The overflow exception task is handled using a tiered processing strategy corresponding to the exception level.

[0045] In this embodiment, the stack overflow depth is calculated using stack usage information and the watermark address, such as how many bytes it exceeds the watermark address. The exception level of the overflow exception task is then determined based on the stack overflow depth, and a corresponding processing strategy is adopted according to the exception level. This embodiment quantifies the overflow degree of the overflow exception task by stack overflow depth, thereby adaptively adopting appropriate processing strategies based on the overflow degree, achieving fine-grained management of overflow exception tasks.

[0046] In some feasible implementations, the anomaly level includes at least a fatal level, a severe level, a general level, and a negligible level, and the anomaly warning processing for the anomaly task includes: If the abnormal task is fatal, then the abnormal task is isolated. If the abnormal task is of a severe level, then the resources occupied by the abnormal task will be reclaimed; If the abnormal task is of the general level, then the abnormal task is analyzed and an analysis report of the abnormal task is generated. If the abnormal task is negligible, then the abnormal task is recorded.

[0047] In this embodiment, the anomaly level of abnormal tasks can be divided into fatal, severe, general, and negligible levels. If the abnormal task is fatal, it enters fault isolation mode to isolate the abnormal task, preventing the anomaly of a single task from spreading to the entire system. Furthermore, it can issue alarms requiring manual intervention and perform OTA (Over-The-Air) upgrades to remotely repair the anomaly. If the abnormal task is severe, the memory resources occupied by the abnormal task are released, the event is recorded and reported, and an alarm is triggered. If the abnormal task is general, the situation of the abnormal task is analyzed, and an analysis report is generated, thereby resolving potential dangers before the anomaly escalates. If the abnormal task is negligible, only the event is recorded, and no other processing is performed. This embodiment provides a hierarchical processing mechanism for abnormal tasks, achieving refined management of abnormal tasks through differentiated processing strategies.

[0048] In some feasible implementations, determining the exception stack pointer when the processor encounters an exception includes: Obtain the link register data of the processor; The link register data is analyzed to determine the abnormal stack pointer of the processor.

[0049] In this embodiment, when an exception occurs, the processor automatically stores a special value (EXC_RETURN) in the link register. This special value is not only used for exception return but also encodes system state information at the time of the exception. Specific bits of the EXC_RETURN value indicate the type of stack pointer used before the exception. Therefore, when a system exception error is detected, this embodiment analyzes the value of the link register to determine the stack pointer being used at the time of the exception. By using the correct exception stack pointer, the stack contents at the moment of the exception, i.e., the exception context data, can be accurately obtained.

[0050] As an example, refer to Figure 4 When the debug monitor detects a system exception error in the processor, it records the processor's context data (such as general-purpose registers R0~R15, main stack pointer MSP, process stack pointer PSP, and program status register PSR). It further reads the values ​​of the link registers. If R14 and 0xF are both 0x1, it reads the main stack pointer MSP; otherwise, it reads the process stack pointer PSP. The read stack contents are stored in the processor's static random access memory (SRAM) as unsigned 32-bit integers. The debug monitor then reads the program counter's PC address from the stack contents, queries the debug database to determine the function and function location corresponding to that PC address, thereby determining whether the exception error originated from an interrupt service routine or a normal program, and sets the flag bit dbg_src_flag for the exception context data.

[0051] In some feasible implementations, abnormal on-site data is remotely analyzed via a host computer or server to pinpoint the cause of system errors. (See reference...) Figure 5 The real-time operating system boots the BOOTROM (Boot Read-Only Memory) to reinitialize the hardware environment and configure the debug monitor. The host computer or server initiates a query request via CANFD (Controller Area Network with Flexible Data-Rate) or serial port to verify permissions. If the permissions are correct, the abnormal situation data stored in the processor's eFlash is transmitted to the host computer or server via CANFD or serial port. This allows the host computer or server to remotely diagnose the abnormal situation data and locate the root cause of the system abnormality. If the permissions are incorrect, the system starts normally and jumps to the eFlash application.

[0052] In this embodiment, in response to detecting a system error in the processor corresponding to the real-time operating system, the system determines the exception stack pointer at the time of the exception; reads the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; if the program counter address is a valid address, it searches for exception debugging information corresponding to the program counter address from a preset debugging database; if the program counter address is an invalid address, it obtains the target valid address from the exception stack pointer and searches for exception debugging information corresponding to the target valid address from the preset debugging database. In this embodiment, when a hardware error is detected in the processor, complete and accurate exception context data is read from the stack pointer at the time of the exception. Further analysis of the program counter address in the exception context data determines whether the processor instruction address at the time of the exception points to a valid or invalid address. If it points to a valid address, exception debugging information is quickly output in conjunction with the debugging database; if it points to an invalid address, a valid address is searched from the exception stack pointer to quickly output exception debugging information. This achieves automatic analysis and rapid location of the root cause of the system error by combining the exception context data and preset debugging information.

[0053] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the following examples are provided for illustrative purposes: Reference Figure 6 The process of analyzing abnormal field data and outputting abnormal debugging information includes the following steps: A1. Obtain abnormal situation data from the DebugMonitor IP or the processor's eFlash; A2. Obtain the pre-stored disassembly file and linker map file from the eFlash partition; A3. Determine the stack pointer type used when the exception occurs based on the context flags in the exception scene data; A4. Extract the program counter address (PC address) from the stack contents pointed to by the given stack pointer. A5. If the program counter address is verified as a valid address, then query the corresponding assembly instructions, function names and call relationships from the disassembler file and linker map file, generate exception debugging information and output it in the form of charts or strings, and output the corresponding function context disassembled code at the same time. A6. If the program counter address is an exception address, extract multiple sets of return addresses from the exception stack, filter out illegal addresses, query the assembly instructions and function information corresponding to the legal addresses from the disassembler file and linker map file, generate exception debugging information and output it in the form of charts or strings, and output the corresponding function context disassembled code at the same time.

[0054] Reference Figure 7 This application provides a real-time operating system debugging method based on DebugMonitor, which specifically includes the following steps: S1. Divide eFlash into multiple regions, store map files and disassembly files in a database, configure stack bottom threshold watermark address and task name for each task, and register task parameters to DebugMonitor IP. S2. Monitor the processor's abnormal error conditions in real time through DebugMonitor IP, and monitor whether there are hardware faults, memory management faults, bus faults, or usage faults. At the same time, monitor the access status of the watermark address of each task in real time. S3. If access to the watermark address corresponding to the task is detected, an abnormal interruption will occur for the task. S4. Obtain the task name of the abnormal task, obtain the stack usage and overflow depth of the exception based on the task name, and execute a graded handling strategy according to the severity of the overflow. S5. If a system exception error is detected in the processor, the complete processor context information is automatically saved, such as general-purpose registers R0-R15, link register LR, exception program status register EPSR, application status register APSR, and call stack information. S6. Determine the specific system exception type based on the program status register, such as hardware failure, memory management failure, bus failure, or usage failure, and then take different handling strategies according to the exception type.

[0055] This application also provides a debugging device 80 for a real-time operating system. Please refer to [link / reference]. Figure 8 ,include: Anomaly monitoring module 801 is used to determine the exception stack pointer when the processor corresponding to the real-time operating system is detected to have a system exception error. The data acquisition module 802 is used to read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; The exception analysis module 803 is used to retrieve exception debugging information corresponding to the program counter address from a preset debugging database if the program counter address is a valid address; and to obtain the target valid address from the exception stack pointer and retrieve the exception debugging information corresponding to the target valid address from the preset debugging database if the program counter address is an invalid address.

[0056] In some feasible implementations, the apparatus further includes: The task monitoring module is used to acquire task monitoring data for each task in the real-time operating system. The abnormal task analysis module is used to compare the task monitoring data with preset task parameters, filter out abnormal tasks with abnormalities from the tasks, and output abnormal warning information for the abnormal tasks.

[0057] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the abnormal task analysis module includes: The time-abnormal task analysis submodule is used to compare the task's running time with the maximum running time threshold; if the running time is greater than the maximum running time threshold, the task is determined to be a time-abnormal task.

[0058] In some feasible implementations, the task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, the abnormal tasks include time-abnormal tasks, and the abnormal task analysis module includes: The overflow exception task analysis submodule is used to determine that the task is an overflow exception task if the stack usage information indicates that the watermark address has access behavior.

[0059] In some feasible implementations, the time anomaly task analysis submodule includes: The first early warning subunit is used to calculate the timeout time of the time-abnormal task using the running time and the maximum running time threshold; determine the abnormality level of the time-abnormal task using the timeout time; and execute a graded processing strategy corresponding to the abnormality level on the time-abnormal task.

[0060] In some feasible implementations, the overflow exception task analysis submodule includes: The second early warning subunit calculates the stack overflow depth of the overflow exception task using the stack usage information and the watermark address; determines the exception level of the overflow exception task based on the stack overflow depth; and executes a graded processing strategy corresponding to the exception level on the overflow exception task.

[0061] In some feasible implementations, the anomaly monitoring module 801 is specifically used for: Obtain the link register data of the processor; The link register data is analyzed to determine the abnormal stack pointer of the processor.

[0062] This application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here.

[0063] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any embodiment of this application.

[0064] Figure 9 A schematic diagram of the hardware structure of an electronic device for implementing the various embodiments of this application. The electronic device 900 includes, but is not limited to, components such as: a radio frequency unit 901, a network module 902, an audio output unit 903, an input unit 904, a sensor 905, a display unit 906, a user input unit 907, an interface unit 908, a memory 909, a processor 910, and a power supply 911. Those skilled in the art will understand that the electronic device structure described in the embodiments of this application does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this application, the electronic device includes, but is not limited to, mobile phones, tablet computers, laptops, PDAs, in-vehicle terminals, wearable devices, and pedometers.

[0065] It should be understood that, in this embodiment, the radio frequency unit 901 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink data from the base station and processes it with the processor 910; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 901 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, and a duplexer. Furthermore, the radio frequency unit 901 can also communicate with networks and other devices via a wireless communication system.

[0066] The electronic device provides users with wireless broadband internet access through the network module 902, such as helping users send and receive emails, browse web pages, and access streaming media.

[0067] The audio output unit 903 can convert audio data received by the radio frequency unit 901 or the network module 902 or stored in the memory 909 into audio signals and output them as sound. Furthermore, the audio output unit 903 can also provide audio output related to specific functions performed by the electronic device 900 (e.g., call signal reception sound, message reception sound, etc.). The audio output unit 903 includes a speaker, a buzzer, and a receiver, etc.

[0068] Input unit 904 is used to receive audio or video signals. Input unit 904 may include a graphics processing unit (GPU) 9041 and a microphone 9042. The GPU 9041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on display unit 906. The image frames processed by GPU 9041 can be stored in memory 909 (or other storage media) or transmitted via radio frequency unit 901 or network module 902. Microphone 9042 can receive sound and process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via radio frequency unit 901 in telephone call mode.

[0069] The electronic device 900 also includes at least one sensor 905, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 9061 according to the ambient light level, and the proximity sensor can turn off the display panel 9061 and / or backlight when the electronic device 900 is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used to identify the posture of the electronic device (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. The sensor 905 may also include a fingerprint sensor, pressure sensor, iris sensor, molecular sensor, gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be described in detail here.

[0070] The display unit 906 is used to display information input by the user or information provided to the user. The display unit 906 may include a display panel 9061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0071] User input unit 907 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of electronic devices. Specifically, user input unit 907 includes a touch panel 9071 and other input devices 9072. Touch panel 9071, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 9071). Touch panel 9071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to processor 910, which receives and executes commands from processor 910. In addition, touch panel 9071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to touch panel 9071, user input unit 907 may also include other input devices 9072. Specifically, other input devices 9072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

[0072] Furthermore, the touch panel 9071 can cover the display panel 9061. When the touch panel 9071 detects a touch operation on or near it, it transmits the information to the processor 910 to determine the type of touch event. Subsequently, the processor 910 provides corresponding visual output on the display panel 9061 based on the type of touch event. It is understood that in one embodiment, the touch panel 9071 and the display panel 9061 are implemented as two independent components to realize the input and output functions of the electronic device. However, in some embodiments, the touch panel 9071 and the display panel 9061 can be integrated to realize the input and output functions of the electronic device; the specific implementation is not limited here.

[0073] Interface unit 908 serves as an interface for connecting external devices to electronic device 900. For example, external devices may include a wired or wireless headphone port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 908 can be used to receive input from external devices (e.g., data, power, etc.) and transmit the received input to one or more components within electronic device 900, or it can be used to transmit data between electronic device 900 and external devices.

[0074] The memory 909 can be used to store software programs and various data. The memory 909 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 909 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0075] The processor 910 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 909, and by calling data stored in the memory 909, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 910 may include one or more processing units; preferably, the processor 910 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 910.

[0076] The electronic device 900 may also include a power supply 911 (such as a battery) that supplies power to various components. Preferably, the power supply 911 can be logically connected to the processor 910 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.

[0077] In addition, the electronic device 900 includes some functional modules not shown, which will not be described in detail here.

[0078] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0080] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0081] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0082] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0085] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0086] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0087] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A debugging method for a real-time operating system, characterized in that, The method includes: In response to detecting a system error in the processor corresponding to the real-time operating system, the exception stack pointer at the time of the processor error is determined. Read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; If the program counter address is a valid address, then retrieve the abnormal debugging information corresponding to the program counter address from the preset debugging database; If the program counter address is an invalid address, the target valid address is obtained from the exception stack pointer, and the exception debugging information corresponding to the target valid address is retrieved from the preset debugging database.

2. The method according to claim 1, characterized in that, The method further includes: Obtain task monitoring data for each task in the real-time operating system; The task monitoring data is compared with preset task parameters to filter out abnormal tasks and output abnormal warning information for the abnormal tasks.

3. The method according to claim 2, characterized in that, The task monitoring data includes task execution time, the preset task parameters include a maximum execution time threshold, and the abnormal tasks include time-abnormal tasks. The step of comparing the task monitoring data with the preset task parameters and filtering out abnormal tasks from the various tasks includes: The task execution time is compared with the maximum execution time threshold; If the running time is greater than the maximum running time threshold, then the task is determined to be a time-abnormal task.

4. The method according to claim 2, characterized in that, The task monitoring data includes stack usage information, the preset task parameters include watermark addresses, and the abnormal tasks include overflow abnormal tasks. The step of comparing the task monitoring data with the preset task parameters to filter out abnormal tasks with anomalies includes: If the stack trace uses information to indicate that the watermarked address has been accessed, then the task is determined to be an overflow exception task.

5. The method according to claim 3, characterized in that, The output of abnormal warning information for the abnormal task includes: The timeout time of the time-abnormal task is obtained by calculating using the running time and the maximum running time threshold. The timeout period is used to determine the anomaly level of the time-abnormal task; A graded processing strategy corresponding to the anomaly level is executed for the time-abnormal task.

6. The method according to claim 4, characterized in that, The output of abnormal warning information for the abnormal task includes: The stack overflow depth of the overflow exception task is obtained by calculating using the stack usage information and the watermark address. The exception level of the overflow exception task is determined based on the stack overflow depth; The overflow exception task is handled using a tiered processing strategy corresponding to the exception level.

7. The method according to claim 1, characterized in that, Determining the exception stack pointer when the processor encounters an exception includes: Obtain the link register data of the processor; The link register data is analyzed to determine the abnormal stack pointer of the processor.

8. A debugging device for a real-time operating system, characterized in that, The device includes: An anomaly monitoring module is used to determine the anomaly stack pointer when the processor corresponding to the real-time operating system is detected to have a system anomaly error. The data acquisition module is used to read the exception context data of the processor from the exception stack pointer; the exception context data includes the program counter address; The exception analysis module is used to retrieve exception debugging information corresponding to the program counter address from a preset debugging database if the program counter address is a valid address; and to obtain the target valid address from the exception stack pointer and retrieve the exception debugging information corresponding to the target valid address from the preset debugging database if the program counter address is an invalid address.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images