Code debugging method and device of embedded system, equipment and medium
By calling the trace_event component API in the embedded system to create custom events for instrumentation and data parsing, the debugging problems of resource-constrained and time-sensitive systems are solved, and real-time code debugging without delay is achieved.
Patent Information
- Application Number
- CN202512053138.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-05-05
AI Technical Summary
In resource-constrained and timing-sensitive embedded systems, existing debuggers or printf printing methods cannot meet real-time requirements, resulting in disrupted system timing or debugging difficulties.
Instrumentation is performed by calling the API of the trace_event component to create custom events. The API is used to parse and format event data at compile time and save it to a circular buffer. Finally, the event logs are parsed and printed according to the preset format for debugging.
It enables the recording and parsing of custom event data in resource-constrained embedded systems without pausing the CPU or introducing delays, thus meeting the real-time requirements of code debugging.
Smart Images
Figure CN121979766A_ABST
Abstract
Description
Technical Field
[0001] This application relates to, but is not limited to, the field of fault debugging technology, and in particular to a code debugging method, apparatus, device, and medium for embedded systems. Background Technology
[0002] Due to resource constraints and timing sensitivity in embedded systems like the XR875, debugging the code for such systems typically involves using a debugger or printing with `printf`. However, debugging with a debugger (such as JTAG / SWD) requires the debugger to connect to the chip via a dedicated hardware interface (like JTAG). This allows developers to pause program execution, single-step, view / modify variables and registers, and set breakpoints. When setting breakpoints or single-stepping, the CPU completely stops, disrupting the system's real-time performance and causing communication timeouts. Furthermore, many functions in embedded systems are real-time; pausing the CPU in the debugger completely disrupts timing, potentially causing problems to disappear (Heisenberg bug) or generating new exceptions, making code debugging impossible. Using `printf` (or serial port printing) requires manually adding code, print formatting, and timestamps, and cannot be dynamically toggled. Serial port printing is also time-consuming and cannot meet the debugging requirements of resource-constrained embedded systems. Summary of the Invention
[0003] This application provides a method, apparatus, device, and medium for debugging code in an embedded system, which can meet the requirements for code debugging in resource-constrained embedded systems.
[0004] In a first aspect, embodiments of this application provide a code debugging method for an embedded system, applied to an embedded system, including: The trace_event component is called at the location where the code is to be debugged. The API is used to create custom events for instrumentation, and the parameter data corresponding to the custom event is passed in. The API is used to expand the code during compilation, parse and format the parameter data to obtain formatted event data, and save the event data to a circular buffer. The event data in the circular buffer is parsed and printed according to a preset format to obtain the event log corresponding to the custom event, and the code is debugged based on the event log.
[0005] Secondly, according to an embodiment of this application, a code debugging device for an embedded system is provided, applied to an embedded system, comprising: An instrumentation module is used to call the API of the trace_event component to create custom events at the location where the code is to be debugged, and at the same time pass in the parameter data corresponding to the custom event; The compilation module is used to expand the code during compilation using the API, parse and format the parameter data to obtain formatted event data, and save the event data to a circular buffer. The debugging module is used to parse and print the event data of the circular buffer according to a preset format to obtain the event log corresponding to the custom event, and to debug the code based on the event log.
[0006] Thirdly, an electronic device provided according to an embodiment of this application includes: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the code debugging method of the embedded system according to any of the first aspects is implemented.
[0007] Fourthly, according to the embodiments of the application, a computer-readable storage medium is provided, storing computer-executable instructions, which are used to execute a code debugging method for implementing any of the embedded systems described in the first aspect.
[0008] In summary, the above embodiments of this application include: calling the trace_event component's API for creating custom events at the location of code to be debugged, and passing in the parameter data corresponding to the custom event; expanding the API during code compilation, parsing and formatting the parameter data to obtain formatted event data, and saving the event data to a circular buffer; parsing and printing the event data in the circular buffer according to a preset format to obtain the event log corresponding to the custom event, and debugging the code based on the event log. This embodiment first uses a pre-defined `trace_event` component to instrument custom events at the location where the code needs debugging, by calling the `trace_event` component's API to create custom events and passing in the corresponding parameter data for the custom events, without needing to manually add code. Then, the API automatically expands the code during compilation, parses and formats the parameter data to obtain formatted event data, and saves the event data to a circular buffer. Compared to existing debuggers or `printf` printing, this method does not require pausing the CPU or introducing delays, and can leverage the low-overhead and real-time advantages of the `trace_event` component to record custom event data and save it to the circular buffer. Finally, the event data in the circular buffer is parsed and printed according to a pre-defined format to obtain the event log corresponding to the custom event. This allows for code debugging based on the event log, thus meeting the code debugging requirements in resource-constrained embedded systems. Attached Figure Description
[0009] Figure 1 This is a flowchart illustrating the steps of a code debugging method for an embedded system provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a code debugging method for an embedded system provided in one embodiment of this application; Figure 3 This is a schematic diagram of a configuration interface provided in one embodiment of this application; Figure 4 This is a schematic diagram of printed event data provided in one embodiment of this application; Figure 5 This is a schematic diagram illustrating the implementation principle of the trace_event component provided in one embodiment of this application; Figure 6 This is a hardware schematic diagram of an electronic device provided in one embodiment of this application. Detailed Implementation
[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0011] It is understandable that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, or the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0012] Due to resource constraints and timing sensitivity in embedded systems like the XR875, debugging the code for such systems typically involves using a debugger or printing with `printf`. However, debugging with a debugger (such as JTAG / SWD) requires the debugger to connect to the chip via a dedicated hardware interface (like JTAG). This allows developers to pause program execution, single-step, view / modify variables and registers, and set breakpoints. When setting breakpoints or single-stepping, the CPU completely stops, disrupting the system's real-time performance and causing communication timeouts. Furthermore, many functions in embedded systems are real-time; pausing the CPU in the debugger completely disrupts timing, potentially causing problems to disappear (Heisenberg bug) or generating new exceptions, making code debugging impossible. Using `printf` (or serial printing) requires manually adding code, print format, and timestamps, and cannot be dynamically switched on or off; serial printing is also time-consuming. Therefore, these methods fail to meet the debugging requirements of resource-constrained embedded systems.
[0013] Based on this, embodiments of this application provide a code debugging method, apparatus, device, and medium for embedded systems, which can meet the requirements of code debugging in resource-constrained embedded systems.
[0014] In this embodiment, the trace_event component is called at the location where the code is to be debugged to create a custom event via an API for instrumentation, while passing in the parameter data corresponding to the custom event. The API expands the code during compilation, parses and formats the parameter data to obtain formatted event data, and saves the event data to a circular buffer. The event data in the circular buffer is parsed and printed according to a preset format to obtain the event log corresponding to the custom event, and the code is debugged based on the event log. This embodiment first uses a pre-defined `trace_event` component to instrument custom events at the location where the code needs debugging, by calling the `trace_event` component's API to create custom events and passing in the corresponding parameter data for the custom events, without needing to manually add code. Then, the API automatically expands the code during compilation, parses and formats the parameter data to obtain formatted event data, and saves the event data to a circular buffer. Compared to existing debuggers or `printf` printing, this method does not require pausing the CPU or introducing delays, and can leverage the low-overhead and real-time advantages of the `trace_event` component to record custom event data and save it to the circular buffer. Finally, the event data in the circular buffer is parsed and printed according to a pre-defined format to obtain the event log corresponding to the custom event. This allows for code debugging based on the event log, thus meeting the code debugging requirements in resource-constrained embedded systems.
[0015] This application provides a code debugging method for an embedded system, applied to an embedded system, as described below. Figure 1 and Figure 2 As shown, including but not limited to the following steps: Step S100: At the location where the code is to be debugged, call the trace_event component's API for creating custom events to perform instrumentation, and pass in the parameter data corresponding to the custom event.
[0016] Understandably, the trace_event component completes event logging, and users only need to instrument the events at the points they need to record. For system-related events such as scheduling, memory allocation, interrupts, semaphores, spinlocks, and VFS, the trace_event component has already instrumented them by default, and users can directly configure and use them.
[0017] For example, the trace_event component has five APIs for creating custom events. The first four APIs (trace_event, trace_event_begin, trace_event_end, and trace_event_count) are all encapsulated from the fifth API (_trace_event). The fifth API specifies the event type by passing in EV_TYPE_XXX, while the first four APIs do not require manually passing in the event type parameter. The events created by these four APIs correspond to the following four event types: EV_TYPE_MARK, EV_TYPE_BEGIN, EV_TYPE_END, and EV_TYPE_CNT. EV_TYPE_MARK is used to record some event information, EV_TYPE_BEGIN is used to mark the start of the event, EV_TYPE_END is used to mark the end of the event, and EV_TYPE_CNT is used to record value changes, such as total memory usage. When instrumenting, users only need to call and pass parameter data (i.e., parameter type and value) according to the convention. Other information such as interrupt status and timestamp will be filled in by the trace_event component.
[0018] For example, the API of the `trace_event` component's custom event can be called at a location in the code to be debugged to instrument the custom event as a trigger point to trigger event logging. When the custom event is not enabled, the overhead of this line of code is close to zero, so it can be safely inserted into time-sensitive scheduler code.
[0019] In some embodiments, the trace_event component includes an event type, an event attribution module, event description information, and event parameters. The event type is used to define a custom event record, the event attribution module is used to assign the custom event, and the event description information and event parameters describe the custom event.
[0020] In some embodiments, the event types include: EV_TYPE_MARK, EV_TYPE_BEGIN, EV_TYPE_END, and EV_TYPE_CNT.
[0021] For example, each custom event in the `trace_event` component includes an event type, an event-assigned module, an event description, and the event itself. The four API functions—`trace_event`, `trace_event_begin`, `trace_event_end`, and `trace_event_count`—have their event type parameters pre-defined. The event-assigned module is used to assign a custom event to a specific module / subsystem. The user-provided event description indicates that events of the same type generated by the same module can have different descriptions; this description is a constant string. The event parameters can obtain dynamic data from the software runtime, serving as supplementary information to the event description.
[0022] For example, the event-assigning module is declared and defined in the header file, distinguishing the module / subsystem that generates the event, and setting the enable control interface corresponding to the custom event, as shown in the reference. Figure 3 As shown, users can access the configuration interface via the `makemenuconfig` command, select the custom events they want to record, and decide whether to start recording custom events by default after system startup.
[0023] For example, the event types are defined in the event_list.txt file, as shown in Table 1 below: Table 1
[0024] Specifically, taking the user's custom event EV_USR0 as an example, the following four functions can be used to record information related to the custom event: (i) The trace_event function is used to record custom events. The parameters of the trace_event function include: the first parameter is the event type; the second parameter is the event description, which must be a string constant and cannot be a string variable; the third to tenth parameters are variable special parameters, with a maximum of 8 variable special parameters supported. The trace_event function has no return value.
[0025] (ii) The trace_event_begin function is used to record the start of a custom event. The parameters of the trace_event_begin function include: the first parameter is the event type; the second parameter is the event description, which must be a string constant and cannot be a string variable; the third to tenth parameters are variable special parameters, with a maximum of 8 variable special parameters supported. The trace_event_begin function has no return value.
[0026] (III) The trace_event_end function is used to record the end of a custom event. The parameters of the trace_event_end function include: the first parameter is the event type; the second parameter is the event description, which must be a string constant and cannot be a string variable; the third to tenth parameters are variable special parameters, with a maximum of 8 variable special parameters supported. The trace_event_end function has no return value.
[0027] (iv) The trace_event_count function is used to record the value of a variable. The event type of the trace_event_count function is as follows: the first parameter is the event type; the second parameter is the event description, which is ignored; the third parameter is the address of the variable; and the fourth parameter is a special parameter used to record the value of the variable.
[0028] For example, special parameters are used when calling interfaces related to the trace_event component. The same special parameter format is used to pass special parameters, and the format of the special parameters satisfies the expression: `ARG_$(type){_RENAME}.
[0029] Specifically, _RENAME is optional. If the custom event used does not have this suffix, the passed-in variable name will be used as the string; otherwise, the specified string will be used.
[0030] Specifically, `type` can be: PTR, STR, CHAR, BYTE, INT, UINT, LONG, or ULONG; where PTR indicates that the parameter is a pointer, and its value will be printed using `%p`; STR indicates that the parameter is a string, and its value will be printed using `%s`; CHAR indicates that the parameter is a character, and its value will be printed using `%c`; BYTE indicates that the parameter is a byte, and its value will be printed using `%x`; INT indicates that the parameter is an integer, and its value will be printed using `%d`; UINT indicates that the parameter is an unsigned integer, and its value will be printed using `%u`; LONG indicates that the parameter is a long integer, and its value will be printed using `%ld`; ULONG indicates that the parameter is an unsigned long integer, and its value will be printed using `%lu`.
[0031] Step S110: Expand the parameter data during code compilation using the API, parse and format the data to obtain formatted event data, and save the event data to a circular buffer.
[0032] In some embodiments, expanding the API during code compilation, parsing and formatting the parameter data to obtain formatted event data, and saving the event data to a circular buffer includes: the compiler of the embedded system compiles and expands the API to obtain macros; the macros parse and format the parameter data to obtain a data structure template and a format description document for the event data; requesting storage space from the circular buffer according to the data structure template, and writing the real-time data corresponding to the API during the compilation process into the storage space according to the format description document.
[0033] For example, when the compiler compiles the code, it expands the API corresponding to the inserted custom event, generating an internal structure named `struct os_event` as a data structure template. This data structure template specifies how many bytes are needed to record the custom event (e.g., two `uint32_t` arrays and two fixed-length arrays), and the offset of each data item within the structure. Simultaneously, the compiler generates a format description document based on the data structure template. This format description document indicates how to interpret the data structure template and is registered in the system. The format description document does not directly participate in runtime recording but is used later to parse binary data into text.
[0034] In some embodiments, requesting storage space from the circular buffer according to the data structure template and writing real-time data corresponding to the API during the compilation process into the storage space according to the format description document includes: calculating the remaining writable capacity of the current circular buffer based on the positions of the write pointer and read pointer of the circular buffer; if the remaining writable capacity meets the size of the data structure template, requesting storage space corresponding to the size of the data structure template from the circular buffer; and writing real-time data in the contiguous storage space pointed to by the write pointer according to the layout defined by the format description document and the data structure template, wherein the real-time data includes timestamps and interrupt status.
[0035] For example, firstly, based on the positions of the write pointer and read pointer of the circular buffer, the remaining writable capacity of the current circular buffer is calculated; then, the number and size of the parameters of the data structure template are calculated. If the remaining writable capacity meets the size of the data structure template, the write pointer is atomically moved to request storage space corresponding to the size of the data structure template from the circular buffer; in the contiguous storage space pointed to by the write pointer, real-time data is written according to the layout defined by the format description document and the data structure template, wherein the real-time data includes timestamps and interrupt status.
[0036] Step S120: Parse and print the event data in the circular buffer according to the preset format to obtain the event log corresponding to the custom event, and debug the code based on the event log.
[0037] In some embodiments, parsing and printing the event data in the circular buffer according to a preset format to obtain the event log corresponding to the custom event includes: reading the event data stored in the circular buffer; obtaining the format string corresponding to the type identifier of the event data, wherein the format string indicates the field layout and type of the event data to be printed; extracting the data to be printed from the event data according to the type; and combining and printing the data to be printed according to the field layout to obtain the event log.
[0038] For example, refer to Figure 4 As shown, the data to be printed is combined and printed according to the field layout to obtain the event log. The first column is the task name; the second column is the CPU ID, which is currently fixed at 0 because only single-core is currently supported; the third column is the status, which currently has two types: the first is whether interrupts are enabled, and the second 0 indicates that the current interrupt nesting number is 0 (i.e., in thread context); the fourth column is the timestamp, with the integer part in seconds; the fifth column is fixed at tracing_mark_write.
[0039] It is understood that the embodiments of this application can further process the event logs and then perform code debugging. The embodiments of this application can save the printed event logs to a file on the PC and then use open-source tools such as perfetto to visualize the event logs.
[0040] In some embodiments, reading event data stored in a circular buffer includes: locating the starting point of the event data in the circular buffer according to a preset magic number; determining the ending point of the event data according to the header data of the event data; and obtaining the event data corresponding to a custom event from the circular buffer according to the starting point and the ending point.
[0041] For example, in this application embodiment, the event data stored in the circular buffer can be read out using the dump command, and then the starting point of the event data corresponding to each custom event can be located using a preset magic number. Based on the number of parameters stored in the event data header, the size of the entire custom event can be determined according to the parameter size, thereby obtaining the end point of the event data. Then, the complete event data corresponding to the custom event can be obtained from the circular buffer based on the starting point and the end point.
[0042] It is understood that the embodiments of this application use the trace_event to implement the parameter parsing mechanism, automatically parse parameters, initialize events, so that users can quickly insert trace_event events in most places without having to worry too much about timestamps, interrupts, parameter types, etc., and can quickly record some information of certain key code locations to support dynamic event enabling.
[0043] For example, refer to Figure 5As shown, the trace_event component can be implemented through the following steps: (I) Data Format: The interface definition is (event type, event type string, event name, parameter 1, parameter 2, .); os_event includes: magic number, interrupt status, number of parameters, size, data format, timestamp, event description, and parameter value; event_class is a string recording all event types and enable flags; (II) Parameter Analysis: A parameter is expanded into three parameters: parameter type, parameter name, and parameter value. Parameter initialization includes: using a macro to calculate the number of parameters, calling the macro _count_ev_arg_X to calculate the parameter size based on the number of parameters, obtaining a specified amount of space from the buffer based on the parameter size, generating an event name based on the parameter (event name: parameter type; parameter name..), and calling the macro _init_arg_type_X to initialize the parameter based on the parameter type. (III) Circular Buffer Zone: The magic number is used to mark the start of event data, and writing to the circular buffer is achieved through an array and a write offset.
[0044] This application provides a code debugging device for an embedded system, which includes: an instrumentation module, used to call the trace_event component's API for creating custom events at the location of the code to be debugged, and passing in parameter data corresponding to the custom events; a compilation module, used to expand the code during compilation via the API, parse and format the parameter data to obtain formatted event data, and save the event data to a circular buffer; and a debugging module, used to parse and print the event data in the circular buffer according to a preset format to obtain event logs corresponding to the custom events, and to debug the code based on the event logs.
[0045] It is understandable that the specific implementation of the code debugging device for the embedded system is the same as the specific implementation of the code debugging method for the embedded system described above, and will not be elaborated here.
[0046] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the code debugging method of the embedded system described above. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.
[0047] Please see Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 601 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 602 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 602 and is called and executed by the processor 601 using the code debugging method of the embedded system in the embodiments of this application. The input / output interface 603 is used to implement information input and output; The communication interface 604 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 605 transmits information between various components of the device (e.g., processor 601, memory 602, input / output interface 603, and communication interface 604); The processor 601, memory 602, input / output interface 603, and communication interface 604 are connected to each other within the device via bus 605.
[0048] In some embodiments, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the code debugging method of the embedded system described above.
[0049] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0050] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0051] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0052] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0053] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0054] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0055] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0056] In the several 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 the units described above 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.
[0057] The units described above 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.
[0058] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.
[0059] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
Claims
1. A code debugging method for an embedded system, characterized in that, Applications in embedded systems, including: The trace_event component is called at the location where the code is to be debugged. The API is used to create custom events for instrumentation, and the parameter data corresponding to the custom event is passed in. The API is used to expand the code during compilation, parse and format the parameter data to obtain formatted event data, and save the event data to a circular buffer. The event data in the circular buffer is parsed and printed according to a preset format to obtain the event log corresponding to the custom event, and the code is debugged based on the event log.
2. The code debugging method for an embedded system according to claim 1, characterized in that, The trace_event component includes an event type, an event attribution module, event description information, and event parameters. The event type is used to define the custom event record, the event attribution module is used to assign the custom event, and the event description information and event parameters describe the custom event.
3. The code debugging method for an embedded system according to claim 2, characterized in that, The event types include: EV_TYPE_MARK, EV_TYPE_BEGIN, EV_TYPE_END, and EV_TYPE_CNT.
4. The code debugging method for an embedded system according to claim 1, characterized in that, The step of expanding the parameter data at compile time using the API, parsing and formatting the parameter data to obtain formatted event data, and saving the event data to a circular buffer includes: The compiler of the embedded system compiles and expands the API to obtain macros, which parse and format the parameter data to obtain the data structure template and format description document of the event data. According to the data structure template, storage space is requested from the circular buffer, and the real-time data corresponding to the API during the compilation process is written into the storage space according to the format description document.
5. The code debugging method for an embedded system according to claim 4, characterized in that, The step of requesting storage space from the circular buffer according to the data structure template and writing the real-time data corresponding to the API during the compilation process into the storage space according to the format description document includes: Based on the positions of the write pointer and read pointer of the circular buffer, calculate the remaining writable capacity of the current circular buffer; If the remaining writable capacity meets the size of the data structure template, request the storage space corresponding to the size of the data structure template from the circular buffer; In the contiguous storage space pointed to by the write pointer, the real-time data is written according to the format description document and the layout defined by the data structure template, wherein the real-time data includes timestamps and interrupt status.
6. The code debugging method for an embedded system according to claim 1, characterized in that, The step of parsing and printing the event data in the circular buffer according to a preset format to obtain the event log corresponding to the custom event includes: Read the event data stored in the circular buffer; Obtain the format string corresponding to the type identifier of the event data, wherein the format string indicates the field layout and type of the event data to be printed; Extract the data to be printed from the event data according to the type; The data to be printed is combined and printed according to the field layout to obtain the event log.
7. The code debugging method for an embedded system according to claim 6, characterized in that, Reading the event data stored in the circular buffer includes: The starting point of the event data in the circular buffer is located according to the preset magic number; The endpoint of the event data is determined based on the header data of the event data; The event data corresponding to the custom event is obtained from the circular buffer based on the starting point and the ending point.
8. A code debugging device for an embedded system, characterized in that, Applications in embedded systems, including: An instrumentation module is used to call the API of the trace_event component to create custom events at the location where the code is to be debugged, and at the same time pass in the parameter data corresponding to the custom event; The compilation module is used to expand the code during compilation using the API, parse and format the parameter data to obtain formatted event data, and save the event data to a circular buffer. The debugging module is used to parse and print the event data of the circular buffer according to a preset format to obtain the event log corresponding to the custom event, and to debug the code based on the event log.
9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the code debugging method of the embedded system as described in any one of claims 1 to 7 is implemented.
10. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the code debugging method of any of the embedded systems described in claims 1 to 7.