Skip to content
Snippets Groups Projects
Select Git revision
  • 639d90a0a4eb39d2631bd9ac8d5713486b877689
  • master default protected
  • klee
3 results

rtfm-klee-gdb

user avatar
Per authored
639d90a0
History

SRP lab in d7020e

Install

Open terminal

cd ~/workspace
git clone https://gitlab.henriktjader.com/d7020e/d7020e_srp.git

Start eclipse through the window manager

Import project to eclipse,

Import->Existing Projects into Workspace

Choose

d7020e_srp

and Finish

Compile

Here you have many options, you can use the Ctrl-B, or the Sledgehammer icon e.g.

ITM

We use the ITM tracing for this example. Open a terminal in eclipse (Shift-Ctrl-Alt T) or the terminal icon (monitor symbol) click Ok (default setting).

Start the ITM tracing tool

itmdump /tmp/swo.log

Notice, the itmdump tool must be started BEFORE the openocd session (see Debug) in order to capture the ITM trace.

Debug

To run the program you will use the debugger integrated in eclipse. It uses openocd to communicate with the nucleo board, and gdb to flash the image (generated .elf file) and interact (running, stepping, setting breakpoints etc.).

Click on the select the boxed d7020e_srp Debug oldgdb and click the boxed green bug icon. (There are other ways as well.)

This will start openocd and gdb, and by default break at main. To execute the program to end, click the play icon.

For further info on gdb debugging in eclipse see e.g., http://gnuarmeclipse.github.io/debug/

The trace_printf is redirected to the ITM port, and you should get a trace of your program in the terminal.

Notice, that setting breakpoints in the code may be a bit wonky, we use macros and that confuses the eclipse gdb interface. The BREAKPOINT macro infers a compiler barrier that "should" allow you to put breakpoints in the code. Stepping in code that is creating interrupts is also wonky, e.g., if sigle stepping over a JOB_REQUEST (that "pends" the corresponding interrupt handler), the pend bit is correctly handeled. This is not a problem for this project only, but a general problem of the gdb integration, so be aware.

Problems

If openocd fails to start, one possible error is that the /tmp/swo.log file has been locked to a bad state. Actually its not an ordinary file but rather a (linux/posix) FIFO, allowing the openocd to pipe data to the itmdump tool. You may want to stop the itmdump and restart it, and try to launch the debugger again.

Tips