Memory data acquisition and waveform display method based on hardware debugger

Abstract

The invention relates to a memory data acquisition and waveform display method based on a hardware debugger, which comprises the following steps of: 1, determining a code part needing to be debugged by a user, and operating and setting a program breakpoint position in a debugging framework; 2, debugging a starting process, namely starting a development board, openocd, a debugging frame, loading a symbol table, initializing a debugging session and loading a target program; step 3, when the program runs to a specified breakpoint, the debugger pauses the processor; 4, reading the memory data of the specified address; 5, drawing a memory waveform: after a user specifies waveform length data, calculating and obtaining memory data corresponding to a specific physical address through a debugging framework; and step 6, ending debugging. The problems that in software development, code modification is assisted by a debugging technology, the application range is limited, and follow-up processing is insufficient are solved, the debugging process can be greatly simplified, the debugging cost is reduced, and the debugging efficiency is remarkably improved.

Description

Technical Field

[0001] The invention relates to the field of computer technology, and in particular to an application of a hardware debugger in the process of debugging a computer program. Background Art

[0002] In the process of software development, debugging technology is often needed to assist in code modification. Existing patents mainly focus on data collection and processing rather than the software debugging process, resulting in poor debugging.

[0003] For example, the invention of CN117665356A focuses on analog waveform data acquisition and digital waveform data acquisition, and its application scope is limited. The waveform display focuses on displaying the target analog waveform and the target digital waveform at the same time in the interactive interface.

[0004] For example, the invention of CN114237949A solves the data collection problem by using a built-in debugging information engine module and a non-volatile memory, but does not perform subsequent data processing. Summary of the invention

[0005] Aiming at the problem that the debugging technology is used to assist in code modification in software development, which has limited application scope and insufficient subsequent processing, a method for memory data acquisition and waveform display based on hardware debugger is proposed. The present invention mainly focuses on the integrated development process, provides a set of methods based on hardware debugger data acquisition, data processing, integrated development and debugging, and uses hardware debugger to design and implement memory waveform display tools in software development and debugging.

[0006] The technical solution of the present invention is:

[0007] A memory data acquisition and waveform display method based on a hardware debugger comprises the following steps:

[0008] Step 1: Configure program breakpoints

[0009] The user first determines the code section that needs to be debugged, and then sets the program breakpoint position in the debugging framework. The debugging framework converts the program breakpoint in the user interface into a GDB command and sends it to GDB. GDB controls openocd to set the breakpoint based on the symbol table and debugging information. The debugging framework then provides a status prompt feedback based on the breakpoint setting status. When the correct icon appears, it means that the breakpoint is set successfully, and the debugger can pause the program at the code position set by the user.

[0010] Step 2: Debug startup process

[0011] Step 2.1, start the development board: load the development board control and debug configuration in sequence. The debug configuration includes the parameter configuration of the hardware debugger and debug session;

[0012] Step 2.2, start openocd: openocd is configured and started before the debugging framework is started. The configuration is integrated in the debugging configuration user interface. After reading the necessary information and starting successfully, it runs in the background and can be stopped or restarted by the user.

[0013] Step 2.3, start the debugging framework: The debugging framework uses the CDT debugging framework; in CDT, the user's mouse click, move, and hover operations, as well as the keyboard keys and key combinations are converted into one or more GDB commands through the debugging framework. Starting the debugging process means executing several GDB commands. The user interface is initialized according to the current debugging configuration and the openocd startup status for the next user operation;

[0014] Step 2.4, load the symbol table, and establish a connection between GDB and openocd: Loading the symbol table means loading a table containing all symbols in the program and their corresponding address information into GDB when debugging the program; after loading, GDB establishes a connection with openocd;

[0015] Step 2.5, Initialize the debugging session: During the initialization of the debugging session, GDB controls the debugger through openocd to download the developed system image and user program image to the specified address of the development board, and sends the user breakpoints set by the debugging framework to openocd. At this time, the development board has not started the user program, so it is necessary to set the development board PC register to start the program running;

[0016] Step 2.5, load the target program: After completing the above steps, the debugging process is completed. During and after the startup, users can add or delete breakpoints. The debugging framework will add breakpoint commands to the GDB execution sequence and wait for openocd to respond to GDB commands one by one;

[0017] Step 3: Pause the program

[0018] When the program runs to a specified breakpoint, the debugger pauses the processor and the program pauses at the breakpoint. At this time, the debugging framework controls the debugger through GDB commands to obtain register and thread data;

[0019] Step 4: Read the memory data at the specified address

[0020] When in the paused state, the development board memory remains unchanged. At this time, the GDB memory read command can be executed through the debugging framework. GDB sends the control command to openocd and obtains the memory data of the specified address of the development board through the hardware debugger. After the debugging framework obtains the memory data, it can be used for the next step of processing;

[0021] Step 5: Memory waveform drawing

[0022] When the user program is paused, the memory data can be used to draw waveforms. The debugging framework converts the binary memory data into the specified data type. After the user specifies the waveform length data, the debugging framework calculates and obtains the memory data corresponding to the specific physical address, which is consistent with the method of obtaining memory data in step 4. The waveform drawing interface uses the address and memory data value as the vertical coordinate, punctuates and connects the coordinate axis to form the final waveform image.

[0023] When the program continues to run, the memory data is modified through the debugging framework, and the user sets different waveform drawing lengths, the waveform image will be redrawn. The memory waveform drawing tool triggers the image redrawing callback by adding events in the debugging framework. The memory address that needs to be reloaded is calculated, and the required memory address data is updated through the memory data loading method in step 4, and the waveform image is redrawn to update the memory waveform.

[0024] Step 6, end debugging: The user determines whether to end debugging based on the display effect. If yes, continue debugging; otherwise, end debugging.

[0025] Furthermore, the tools for memory data acquisition and waveform display are divided into a lower computer part and a host computer part. The lower computer part includes a debugger, also known as a hardware debugger, and a development board, which is connected to the development board through an EJTAG interface and connected to the host computer using a universal serial port; the development board is a circuit board used for development, and the application runs on the development board; the debugger is used to control the hardware equipment of the development board during the debugging process; during the software debugging process of the host computer, it is used to manage and control the hardware debugger, and the host computer includes three parts: a debugging framework, openocd, and data drawing; the debugging framework provides a user interaction interface, and establishes data communication with openocd by integrating GDB. The user's operations are converted into GDB commands through the debugging framework and sent to openocd. Openocd interacts with the hardware debugger to control the start and pause of the development board, and can also obtain and modify the registers and memory data of the development board.

[0026] Furthermore, in step 2.4, GDB can map the memory address back to the symbol name in the source code to locate the code. If there is no symbol table, GDB can also provide current execution information, but it cannot establish a connection with the source code.

[0027] Furthermore, in step 3, the pause may be controlled in different ways depending on the processor model.

[0028] Optionally, in step 5, the data type is floating point data.

[0029] The beneficial effects of the present invention are:

[0030] The present invention aims to provide a method for acquiring memory data and displaying waveforms during debugging, and assisting in the development of application codes by utilizing the control capability of a hardware debugger on a development board.

[0031] The present invention aims to provide a method for acquiring memory data and displaying waveforms during debugging. This function fully utilizes the control capability of the hardware debugger over the development board, and aims to assist developers in writing and optimizing application codes. Through this innovative technology, developers can observe the waveform changes of each signal line on the development board in real time, so as to more intuitively understand the execution process of the code and the working status of the hardware.

[0032] During the debugging process, the hardware debugger acts as a bridge between developers and hardware devices. By integrating the waveform display function into the hardware debugger, developers can easily monitor and analyze the signals on the development board in real time without the need for additional waveform generation or acquisition equipment. This function greatly simplifies the debugging process, reduces debugging costs, and significantly improves debugging efficiency.

[0033] The waveform display function can capture and display the waveforms of each key memory location on the development board. Developers can quickly locate potential problems in the code by observing the shape, frequency, phase and other characteristics of these waveforms. At the same time, the waveform display function also supports operations such as scaling, panning, and measuring the waveform, so that developers can analyze the waveform details more deeply and find the root cause of the problem more accurately.

[0034] In addition, the present invention also provides a wealth of waveform analysis tools and auxiliary functions, such as waveform triggering, waveform storage and playback, to further meet the diverse needs of developers during the debugging process. The addition of these tools and functions enables developers to more efficiently use the waveform display function for code debugging and optimization, thereby accelerating the product development process.

[0035] In summary, the waveform display function in the debugging process provided by the present invention not only fully utilizes the control capability of the hardware debugger, but also provides developers with an intuitive, efficient and convenient debugging method. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is the overall structure diagram of the memory data acquisition and waveform display method of the present invention;

[0037] Figure 2 This is an overall processing flow chart of the memory data acquisition and waveform display method of the present invention;

[0038] Figure 3 Loading flow chart for the debugging session of the present invention. DETAILED DESCRIPTION

[0039] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.

[0040] The memory data acquisition and waveform display method based on the hardware debugger of the present invention, the memory data acquisition and waveform display tool is divided into a lower computer part and a host computer part, such as Figure 1 As shown in the figure, the lower computer part is composed of specific hardware, including a debugger (also known as a hardware debugger) and a development board. It is connected to the development board through the EJTAG interface and connected to the upper computer using a universal serial port. The development board is a circuit board used for development, and the application runs on the development board; the debugger is used to control the hardware device of the development board during the debugging process, and provides functions such as information reading and program suspension. During the debugging process of the upper computer software, it is used to manage and control the hardware debugger. The upper computer includes three parts: a debugging framework (also known as the CDT debugging framework in Eclipse debugging, hereinafter referred to as the debugging framework or CDT), openocd, and data drawing. The debugging framework provides a user interaction interface, and establishes data communication with openocd by integrating GDB. The user's operation is converted into a GDB command through the debugging framework and sent to openocd. Openocd interacts with the hardware debugger to start and pause the development board, and can also obtain and modify the registers and memory data of the development board.

[0041] The overall process of implementing the method is as follows Figure 2 As shown, it includes a series of startup steps:

[0042] Step 1: Configure program breakpoints

[0043] A program breakpoint is a pause point set manually during program execution. The developer first determines the code section that needs to be debugged, and then sets the program breakpoint position in the debugging framework. The debugging framework converts the program breakpoint in the user interface into a GDB command and sends it to GDB. GDB controls openocd to set the breakpoint based on the symbol table and debugging information. The debugging framework then provides a status prompt feedback based on the breakpoint setting status. When the correct icon appears, it means that the breakpoint is set successfully, and the debugger can pause the program at the code position set by the user.

[0044] Step 2: Debug startup process

[0045] Step 2.1, start the development board: debug and start as follows Figure 3 As shown, the development board control and debug configuration are loaded in sequence. The debug configuration includes the parameter configuration of the hardware debugger and the debug session.

[0046] Step 2.2, start openocd: openocd is a tool designed for online programming and debugging of embedded systems. It provides support for JTAG. According to the different processor chips used by the development board, different configuration files are adapted to control the debugger to control each processor core. openocd is configured and started before the debugging framework is started. The configuration is integrated in the debugging configuration user interface. After reading the necessary information and starting successfully, it runs in the background and can be stopped or restarted by the user.

[0047] Step 2.3, start the debugging framework: The debugging framework uses the CDT debugging framework. In CDT, the user's mouse click, move, and hover operations, as well as keyboard keys and key combinations are converted into one or more GDB commands through the debugging framework. Starting the debugging process means executing several GDB commands. The user interface is initialized according to the current debugging configuration and the openocd startup state for the next user operation.

[0048] Step 2.4, load the symbol table, and establish a connection between GDB and openocd: Loading the symbol table refers to the process of loading a table containing all symbols in the program (such as variable names, function names, class names, etc.) and their corresponding address information into GDB when debugging a program. GDB can map memory addresses back to symbol names in the source code to locate the location of the code. If there is no symbol table, GDB can also provide current execution information, but it cannot establish a connection with the source code. After loading is completed, GDB establishes a connection with openocd.

[0049] Step 2.5, Initialize the debugging session: During the initialization of the debugging session, GDB controls the debugger through openocd to download the developed system image and user program image to the specified address of the development board, and sends the user breakpoints set by the debugging framework to openocd. At this time, the development board has not started the user program, so it is necessary to set the development board PC register to start running the program.

[0050] Step 2.5, load the target program: After completing the above steps, the debugging process is completed. During the startup process and after successful startup, users can add or delete breakpoints. The debugging framework will add breakpoint commands to the GDB execution sequence and wait for openocd to respond to GDB commands one by one.

[0051] Step 3: Pause the program

[0052] When the program runs to the specified breakpoint, the debugger pauses the processor (different processor models have different control methods). When the program runs to the specified breakpoint, the debugger pauses the processor and the program pauses at the breakpoint. At this time, the debugging framework controls the debugger through GDB commands to obtain register and thread data.

[0053] Step 4: Read the memory data at the specified address

[0054] When in the paused state, the development board memory remains unchanged. At this time, the GDB memory read command can be executed through the debugging framework. GDB sends the control command to openocd and obtains the memory data of the specified address of the development board through the hardware debugger. After the debugging framework obtains the memory data, it can be used for the next step of processing.

[0055] Step 5: Memory waveform drawing

[0056] When the user program is paused, the memory data can be used to draw waveforms. The debugging framework converts the binary memory data into floating-point data according to the specified number of bytes and precision. Waveform drawing is often used in signal processing to display the current state of the signal. After the user specifies the waveform length data, the debugging framework calculates and obtains the memory data corresponding to the specific physical address, which is consistent with the method of obtaining memory data in step 4. The waveform drawing interface uses the address and the floating-point value of the memory data (other data types can also be used) as the vertical coordinate, punctuates and connects the coordinate axis to form the final waveform image.

[0057] When the program continues to run, the memory data is modified through the debugging framework, and the user sets different waveform drawing lengths, the waveform image will be redrawn. The memory waveform drawing tool triggers the image redrawing callback by adding events in the debugging framework. Calculate the memory address that needs to be reloaded, update the required memory address data through the memory data loading method in step 4, redraw the waveform image, and update the memory waveform.

[0058] Step 6, end debugging: The user determines whether to end debugging based on the display effect. If yes, continue debugging; otherwise, end debugging.

[0059] Example:

[0060] The debugging interface implements a user interface framework based on Eclipse open source software, uses the Eclipse plug-in system for software development, is integrated into the Ruihua embedded integrated development environment, and is suitable for corresponding adapted development boards.

[0061] 1. Hardware debugging configuration design

[0062] In the Eclipse debugging framework, add debugging configurations for basic debugging configuration, openocd configuration, and GDB configuration. During the debugging process, function calls will be made according to the configuration information. Openocd and GDB will be started when the debugging session is started, and will run in the background waiting for further instruction information.

[0063] 2. Memory update design

[0064] The memory status will change during program execution. The memory data will be updated according to user operations. The current memory data is read through the hardware debugger, and the interface calculates whether it needs to be redrawn based on the existing data and the updated data.

[0065] The above-mentioned embodiment only expresses one implementation mode of the present invention, and its description is relatively specific and detailed, but it cannot be understood as limiting the scope of the invention patent. It should be pointed out that for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

Claims

1. A memory data acquisition and waveform display method based on a hardware debugger, characterized in that: The following steps are involved: Step 1: Configure program breakpoints The user first determines the code section that needs to be debugged, and then sets the program breakpoint position in the debugging framework. The debugging framework converts the program breakpoint in the user interface into a GDB command and sends it to GDB. GDB controls openocd to set the breakpoint based on the symbol table and debugging information. The debugging framework then provides a status prompt feedback based on the breakpoint setting status. When the correct icon appears, it means that the breakpoint is set successfully, and the debugger can pause the program at the code position set by the user. Step 2: Debug startup process Step 2.1, start the development board: load the development board control and debug configuration in sequence. The debug configuration includes the parameter configuration of the hardware debugger and debug session; Step 2.2, start openocd: openocd is configured and started before the debugging framework is started. The configuration is integrated in the debugging configuration user interface. After reading the necessary information and starting successfully, it runs in the background and can be stopped or restarted by the user. Step 2.3, start the debugging framework: The debugging framework uses the CDT debugging framework; in CDT, the user's mouse click, move, and hover operations, as well as the keyboard keys and key combinations are converted into one or more GDB commands through the debugging framework. Starting the debugging process means executing several GDB commands. The user interface is initialized according to the current debugging configuration and the openocd startup status for the next user operation; Step 2.4, load the symbol table, and establish a connection between GDB and openocd: Loading the symbol table means loading a table containing all symbols in the program and their corresponding address information into GDB when debugging the program; After loading is complete, GDB establishes a connection with openocd; Step 2.5, Initialize the debugging session: During the initialization of the debugging session, GDB controls the debugger through openocd to download the developed system image and user program image to the specified address of the development board, and sends the user breakpoints set by the debugging framework to openocd. At this time, the development board has not started the user program, so it is necessary to set the development board PC register to start the program running; Step 2.5, load the target program: After completing the above steps, the debugging process is completed. During and after the startup, users can add or delete breakpoints. The debugging framework will add breakpoint commands to the GDB execution sequence and wait for openocd to respond to GDB commands one by one; Step 3: Pause the program When the program runs to a specified breakpoint, the debugger pauses the processor and the program pauses at the breakpoint. At this time, the debugging framework controls the debugger through GDB commands to obtain register and thread data; Step 4: Read the memory data at the specified address When in the paused state, the development board memory remains unchanged. At this time, the GDB memory read command can be executed through the debugging framework. GDB sends the control command to openocd and obtains the memory data of the specified address of the development board through the hardware debugger. After the debugging framework obtains the memory data, it can be used for the next step of processing; Step 5: Memory waveform drawing When the user program is paused, the memory data can be used to draw waveforms. The debugging framework converts the binary memory data into the specified data type. After the user specifies the waveform length data, the debugging framework calculates and obtains the memory data corresponding to the specific physical address, which is consistent with the method of obtaining memory data in step 4. The waveform drawing interface uses the address and memory data value as the vertical coordinate, punctuates and connects the coordinate axis to form the final waveform image. When the program continues to run, the memory data is modified through the debugging framework, and the user sets different waveform drawing lengths, the waveform graphics will be redrawn; The memory waveform drawing tool triggers the image redrawing callback by adding events in the debugging framework; calculates the memory address that needs to be reloaded, updates the required memory address data through the memory data loading method in step 4, and redraws the waveform image to update the memory waveform; Step 6, end debugging: The user determines whether to end debugging based on the display effect. If yes, continue debugging; otherwise, end debugging.

2. The memory data acquisition and waveform display method based on the hardware debugger according to claim 1 is characterized in that: The tools for memory data acquisition and waveform display are divided into the lower computer part and the upper computer part. The lower computer part includes the debugger, also known as the hardware debugger, and the development board, which is connected to the development board through the EJTAG interface and connected to the upper computer using the universal serial port; the development board is a circuit board used for development, and the application runs on the development board; the debugger is used to control the hardware equipment of the development board during the debugging process; during the upper computer software debugging process, it is used to manage and control the hardware debugger. The upper computer includes three parts: debugging framework, openocd and data drawing; the debugging framework provides a user interaction interface, and establishes data communication with openocd by integrating GDB. The user's operations are converted into GDB commands through the debugging framework and sent to openocd. Openocd interacts with the hardware debugger to control the start and pause of the development board, and can also obtain and modify the registers and memory data of the development board.

3. The memory data acquisition and waveform display method based on the hardware debugger according to claim 1 is characterized in that: In step 2.4, GDB can map the memory address back to the symbol name in the source code to locate the code. If there is no symbol table, GDB can also provide current execution information, but it cannot establish a connection with the source code.

4. The memory data acquisition and waveform display method based on the hardware debugger according to claim 1, characterized in that: In step 3, the pause will be controlled in different ways depending on the processor model.

5. The memory data acquisition and waveform display method based on the hardware debugger according to claim 1, characterized in that: In step 5, the data type is floating point data.

Images