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

Setup

Select the boxed d7020e_srp Debug oldgdb, and click the cogwheel. Under Debugger/GDB Client Setup, change the path to the executable (/home/arch/Downloads/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gdb).

Run/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.).

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 break at those (there are two such BREAKPOINTs in the exampe, try put a breakpoint on those to see how it works) . Stepping in code that causes interrupts is also wonky, e.g., when sigle stepping over a JOB_REQUEST (that "pends" the corresponding interrupt handler), the pend bit is not correctly handeled (and the corresponding interrupt not taken). These problems are present for this project only, but general to the gdb debug 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

If you want, you can inspect the BASEPRI register (you find it under Registers) to see the system ceiling, but be aware that the priority is the hardware prio, shifted. (See how we use the __set_BASEPRI_MAX in the LOCK macro.)

The current running priority is a bit harder to see, however you see the call stack (in the Debug window, and we know the prio for each task/job/interrupt handler). Notice, the call stack shows the name of the handlers, but we have defined the mapping, so its easy to reverse, right!