I have been working with
FreeRTOS for a while and finally decided to figure out how to properly get Eclipse to show the tasks as threads. It is quite useful to know what other tasks are doing when you are debugging problems in your firmware. This is a matter of enabling features within
OpenOCD by changing configuration files for your target. This post will center around configuring this for
STMicroelectronics chips. The first thing I would like to show is a working Eclipse/OpenOCD/GDB debug setup.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8k17SBLUfZHJUMUO8JjNK_KzdLrWxD2t9m-tIWy6E7Hj2HGAscvDPvpwnw8acwZypGMPBOugxczcqSD7PYFfgoXkOZ10jUw5Sn88bfDtWItMtI49mjMmhKOukVaaqpS2qJo_aQ1gMP04/s320/Non_RTOS_Setup_01.png) |
Non RTOS based Debug Setup Part 1
|
The above picture shows the normal setup I was using, a single configuration file for my target board.
The next picture shows the settings I used, to stop in main.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRzolQCPQJHayIaZqYrXHkLuxpNEysoRNDOZPdaUnxJyFf8mUXcmPQHCjzPvcqXAbxZ-fDHmbYtr616114RR8jRo5eFeYgQuYCpoyFB87tCERoFNHCAdopyKD_j8xzEXnziuBu7GY26zY/s320/Non_RTOS_Setup_02.png) |
Non RTOS based Debug Setup Part 2
|
The contents of that file is below:
## This is the Test Rom Board
## Core429I Board
## STM32F429IGT6 ARM Cortex-M4
## Use the STLINK V2 Debug Probe
source [find interface/stlink-v2.cfg]
## This is setup with Serial Wire Debug
set WORKAREASIZE 0x20000
transport select hla_swd
## Use Generic STM32F4x chip setup support
source [find target/stm32f4x.cfg]
## Reset (software only reset)
reset_config srst_only srst_nogate
## Boost Adapter speed to 4 MHz
adapter_khz 4000
## Configure SWO/SWV
## System Core Clock 180 MHz
## Baud Rate 2 Mbaud/s
tpiu config internal debug.log uart off 180000000 2000000
The results of all of this configuration are shown below in the debugging screenshot:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGVJH4gl7Ok1zloqrnRhy_YDD6vcHil3na643qP3bo43nDKrJVwT1thYjW0Wv9PA09iWP9BwlWzbA2TUqSCKj1X13nmFwg6hyphenhyphenvLEngvdjTLRsMVT89cPp47qQo_vDvCfIDrTH8kIz9Qlg/s320/Non_RTOS_Debugging.png) |
Non RTOS Debugging Session |
As you can see, there is a single thread. This only allows me to see the exact spot in the code that I have currently stopped. I would much rather be able to see what other tasks were running at the same time, and where they were in their execution at the exact moment the debugger halted everything.
In order for this to work, as the manual describes, we have to change the configuration file for the target to support using RTOS features. Since I am using the STM32F4 series chips, I copied the stm32f4x.cfg file from /usr/share/openocd/scripts/target/stm32f4x.cfg to my utility directory in my code repository. Once this file was copied I modified it to use the RTOS auto discovery, as shown below:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpevzp_G2hnoJ8AhwkI0se_ozermWrm3XitaiiuF6x6npJNzTpMsDpZiOi24YnxcGiq3YYDNI7-4t-uvpa6Sk44atwCjM4gVIU5X1MS8FiVb6DXcHB2Eszy4i7G0akhSsXuvhY5xJFbrM/s320/Adjusted_TargetFile.png) |
Modifying the stm32f4x.cfg file for RTOS debugging |
I have highlighted the added text to enable auto discovery of RTOS usage. The next thing I did was add a file called FreeRTOS_openocd.c to my project, the contents of this file are below:
/*
* Since at least FreeRTOS V7.5.3 uxTopUsedPriority is no longer
* present in the kernel, so it has to be supplied by other means for
* OpenOCD's threads awareness.
*
* Add this file to your project, and, if you're using --gc-sections,
* ``--undefined=uxTopUsedPriority'' (or
* ``-Wl,--undefined=uxTopUsedPriority'' when using gcc for final
* linking) to your LDFLAGS; same with all the other symbols you need.
*/
#include "FreeRTOS.h"
#ifdef __GNUC__
#define USED __attribute__((used))
#else
#define USED
#endif
const int USED uxTopUsedPriority = (configMAX_PRIORITIES -1);
Next, I modified my makefile to include a new linker option, which allows OpenOCD to work correctly with the RTOS features. The linker option I added was:
-Wl,--undefined=uxTopUsedPriority
I rebuilt the entire project (make distclean; make all -j16) to rebuild all the modules. I usually only do this when I need to rebuild standard peripheral libraries, FreeRTOS etc. Usually, I only have to rebuild the application code I am working in.
I then tested this by using OpenOCD and GDB from the command line to ensure that this worked, the steps are below:
- run in a terminal: openocd -f interface/stlink-v2.cfg -f stm32f4x_RTOS.cfg
- run in a terminal: arm-none-eabi-gdb build/debug/core4x9i.elf
- execute the following commands inside the GDB session:
- target remote localhost:3333
- continue
- Control-C
- info threads
The first step is shown below
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_HaovVLnbQnImLeUOmUU72VRZld3Knl3HRVHhB21qcK4aMa5nvExsYNcG5vRT_V6DuPEqrEdbrbiQ_YRjk9MEYK1fLkPOeyuBEs_ZMOOsb-Ul7xW7M5dkY-yVajpRY2f87WZITFsgFVU/s320/OpenOCD_GDB_Connected.png) |
Running OpenOCD configured for RTOS debugging
|
The second step is shown in the following screenshot:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwU2dJ9Gyrw66TEKfyotSXXhyphenhyphen6SbYcQJiLwSndeCxWp1IN-mUIGo73B_IubhCz5yyFgOiD9TCbbFaCHr6HOXTr7fNEwEID0fSSnzKqQ6LIJS7jTvE76698GNLlWXV4BNSpWKBliKKLaW4/s320/GDB_Debugger_connected.png) |
Connecting GDB to OpenOCD for RTOS debugging |
The third step, which shows the threads feature working is below:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGrEy0GdVOTM94B9tDI8nq70Da3-4hKN_JlGy1gHSbdpQW5z2Tx1k018ktwl0b8dAd4q7N0_aKTM0uX6X-hloiQH0G6AIJHbByh9t7HGgaqbKUs0MMGGefD1XBynj7I4V6kAIF0-NlUe8/s320/GDB_Debugger_Thread_Info.png) |
RTOS task info as threads in GDB |
This is great, it's all working properly now. Might as well set this up inside Eclipse so we can debug in an easier way.
The first debug configuration page in Eclipse starts out with the proper files for starting OpenOCD as follows:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnFj7bkRRwZWT-QikIgbZ1ojaGnyE7hXIAtQbkuqb-I-DYkb0qqy5wie5sJyhQJLBtpA8ijrv3HnTIoEbg-brt2Js1YnPlzUYSblLKkw_NahfxhWUrbIAt1314RU6KjUqwZnFMe0_NT6g/s320/RTOS_Setup_01.png) |
RTOS debug setup part 1 |
The second configuration page is below:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGCb29UUwkmYO0mIko-cCThO-wf7Z-mJZV9AbBPizyBEeW5klPsGjjUauEN5jnVHhpUUcHybvKmzMNatEoZDPeoUo4N2BXt2avY4GI7db7n-q9oqybFGHOzMfDdoUyuesib9UMGmi5O0M/s320/RTOS_Setup_02.png) |
RTOS debug setup part 2 |
You may have noticed the change to the "Set breakpoint at" setting, this value has been changed to the first task that gets started: logger_task. You need to do this, otherwise the debugger will become confused and not present you with the normal Eclipse debug experience. This stems from the fact that it won't know about the tasks unless you allow them all to start, prior to hitting a break point. I know, I know, there are times when you want to debug without the RTOS threads! So keep two configurations, RTOS enabled and not. This way you can debug start up as well as the RTOS tasks.
Either way, once you have this all completed and working, it should look like the debug session below:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgP0DCHGNkh-snMTlcgP9v9rk9YxcVvGzgM0OtAbQpsq9Ojqg-O-o8XdhvvJaGEbMyZwALAA3V0jUFoh1SYz_PpNnKSurOqBYXxcbCSBDhiNdUDtV0lll49ntZK37pylktT3bZSpFHXtAY/s320/RTOS_Debugging.png) |
RTOS debug session in Eclipse |
Now, like me, you can have two debug configurations. Have fun coding!