Chapter 4. API Guides
idf.py debug targets It is also possible to execute the described debugging tools conveniently from idf.py. These
commands are supported:
1. idf.py openocd
Runs OpenOCD in a console with configuration defined in the environment or via command line. It uses default
script directory defined as OPENOCD_SCRIPTS environmental variable, which is automatically added from
an Export script (export.sh or export.bat). It is possible to override the script location using command
line argument --openocd-scripts.
As for the JTAG configuration of the current board, please use the environmental variable
OPENOCD_COMMANDS or --openocd-commands command line argument. If none of the above
is defined, OpenOCD is started with -f board/esp32s2-kaluga-1.cfg board definition.
2. idf.py gdb
Starts the gdb the same way as the Command Line, but generates the initial gdb scripts referring to the current
project elf file.
3. idf.py gdbtui
The same as 2, but starts the gdb with tui argument allowing very simple source code view.
4. idf.py gdbgui
Starts gdbgui debugger frontend enabling out-of-the-box debugging in a browser window.
It is possible to combine these debugging actions on a single command line allowing convenient setup of block-
ing and non-blocking actions in one step. idf.py implements a simple logic to move the background actions
(such as openocd) to the beginning and the interactive ones (such as gdb, monitor) to the end of the action list.
An example of a very useful combination is:
idf.py openocd gdbgui monitor
The above command runs OpenOCD in the background, starts gdbgui to open a browser window with active
debugger frontend and opens a serial monitor in the active console.
Debugging Examples
This section describes debugging with GDB from Eclipse as well as from Command Line.
Eclipse Verify if your target is ready and loaded with get-started/blink example. Configure and start debugger
following steps in section Eclipse. Pick up where target was left by debugger, i.e. having the application halted at
breakpoint established at app_main().
Examples in this section
1. Navigating through the code, call stack and threads
2. Setting and clearing breakpoints
3. Halting the target manually
4. Stepping through the code
5. Checking and setting memory
6. Watching and setting program variables
7. Setting conditional breakpoints
Navigating through the code, call stack and threads When the target is halted, debugger shows the list of threads
in “Debug”window. The line of code where program halted is highlighted in another window below, as shown on
the following picture. The LED stops blinking.
Specific thread where the program halted is expanded showing the call stack. It represents function calls that lead up
to the highlighted line of code, where the target halted. The first line of call stack under Thread #1 contains the last
called function app_main(), that in turn was called from function main_task() shown in a line below. Each
line of the stack also contains the file name and line number where the function was called. By clicking / highlighting
the stack entries, in window below, you will see contents of this file.
Espressif Systems 1392
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General