@@ -54,10 +54,11 @@ For further info on gdb debugging in eclipse see e.g., http://gnuarmeclipse.gith
...
@@ -54,10 +54,11 @@ For further info on gdb debugging in eclipse see e.g., http://gnuarmeclipse.gith
The trace_printf is redirected to the ITM port, and you should get a trace of your program in the terminal.
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.
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
The `BREAKPOINT` macro infers a compiler barrier that "should" allow you to break at those
is creating interrupts is also wonky, e.g., if sigle stepping over a `JOB_REQUEST` (that "pends" the corresponding interrupt handler),
(there are two such `BREAKPOINT`s in the exampe, try put a breakpoint on those to see how it works) . Stepping in code that
the pend bit is correctly handeled. This is not a problem for this project only, but a general problem of the gdb integration, so
causes interrupts is also wonky, e.g., when sigle stepping over a `JOB_REQUEST` (that "pends" the corresponding interrupt handler),
be aware.
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
## Problems
...
@@ -66,7 +67,11 @@ ordinary file but rather a (linux/posix) FIFO, allowing the openocd to pipe data
...
@@ -66,7 +67,11 @@ ordinary file but rather a (linux/posix) FIFO, allowing the openocd to pipe data
and restart it, and try to launch the debugger again.
and restart it, and try to launch the debugger again.
## Tips
## 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