ARM Cortex-M Debugging With Thread Awareness and Real Time Expressions
Thanks to a plugin update, anyone debugging an ARM Cortex-M (using FreeRTOS) can see variables while a target is running and have a better view of your threads.
Join the DZone community and get the full member experience.
Join For FreeP&E has a new version of their GDB/Eclipse debug plugins available on their Eclipse update site, and it comes with two great features: Real Time Expressions (show variables while the target is running) and FreeRTOS thread awareness.
This post is about these two new and great features for P&E-based run control for ARM Cortex-M — and how to install and use these new features.
With FreeRTOS as one of the most popular real-time operating systems, there is growing support for it in the industry. Both OpenOCD and Segger support FreeRTOS thread-aware debugging built into their run control. Now P&E has added that too: with this, the gdb/Eclipse thread view shows all the running tasks and it is easy to switch and debug them.
But not only that: The other thing with the Freescale/NXP move from CodeWarrior to Kinetis Design Studio is that I have lost CodeWarrior's ability to show/update variables/expressions while the target is running (see Live View for Variables and Memory). Now, this is back in Kinetis Design Studio, or any other similar Eclipse tool, using this new P&E Plugin.
I have used it with both the OpenSDA P&E firmware and with native P&E probes, like the Multilink Universal:
Installation
The version you are looking for is the 2.8.5 (or later).
An earlier version of the plugin available from P&E crashed if configUSE_PORT_OPTIMISED_TASK_SELECTION was set to 0 which I have reported to P&E. The version 2.8.5 works now fine.
The update site also lists the E200 plugin, which should not be enabled for ARM/Kinetis development. Click ‘Next’ and go through the usual installation process. Restart Eclipse at the end of the installation.
Using the new plugins and debugging a FreeRTOS application, it shows the FreeRTOS threads in the Eclipse debug view:
Clicking on a Thread changes the context (stack frame, registers, variables). So with this, I can see and debug all the FreeRTOS threads running.
The plugin uses FreeRTOS global variables (e.g. a list of tasks) for thread awareness. This is done automatically in the background. I have not seen any problems with it, but just in case, there is an option in the Eclipse launch configuration to turn it off.
By adding...
-kernel=none
...to the Server Parameters, it turns it off:
I really like the fact that the feature is turned on by default. If I really do not want it (which I think never will be the case) or if there would be any side effects, I still can turn it off.
ConfigTASK_RETURN_ADDRESS
FreeRTOS on ARM usually sets the return address of a task to zero. For this, I have the following defined in my FreeRTOSConfig.h:
#define configTASK_RETURN_ADDRESS 0 /* return address of task is zero */
For smaller code, I have usually that macro defined.
If that define is not defined, the tasks are set up to use a special function prvTaskExitError() as the caller function. This function does catch the case if the task returns (which would be a programming error), defined in port.c:
void prvTaskExitError(void) {
/* A function that implements a task must not exit or attempt to return to
its caller as there is nothing to return to. If a task wants to exit it
should instead call vTaskDelete( NULL ).
Artificially force an assert() to be triggered if configASSERT() is
defined, then stop here so application writers can catch the error. */
configASSERT(uxCriticalNesting == ~0UL);
portDISABLE_INTERRUPTS();
for(;;) {
/* wait here */
}
}
The screenshot below shows such a case where the Led task is leaving the task scope:
While catching the error works (great!), you can see that the stack unwinding is not correct, showing uxListRemove(). I investigated whether this was a problem with gdb or with the initial stack layout, and I have not come to a conclusion. For me, it is not a problem, as I have configTASK_RETURN_ADDRESS set to zero. So I recommend that you use:
#define configTASK_RETURN_ADDRESS 0 /* return address of task is zero */
Another great feature added with the update is the ‘Real Time Expressions View’, accessible through Window > Show View > Other:
This adds a new view where I can add expressions. The expressions are updated while the target is running:
That way I can easily watch the state of my application without the need to stop it :-). The view mirrors the variables present in the normal expressions view, but is able to read them while the target is running:
There is a button that I can press to pause the update. This is useful for when I’m concerned about intrusiveness (but I did not really see any impact with a handful of variables):
The view reads the variable content from the memory of the running target. If dereferencing a pointer it would mean that the debugger needs to read the pointer, then indirect it to read the targeting memory. Because this requires two accesses, the expression might not be right:
Summary
I have used the plugin with FreeRTOS V9.0.0 (McuOnEclipse port) successfully and it works like a charm. I have not tested it with older FreeRTOS versions, but I know for other FreeRTOS-kernel-aware support, e.g. in OpenOCD, it heavily depends on the version of RTOS used. So I recommend that you use the latest RTOS. You can find a snapshot of FreeRTOS for ARM Cortex-M as part of the McuOnEclipse Library on GitHub.
The Real Time Expressions view closes a big gap left with the move from CodeWarrior to Kinetis Design Studio and is really helpful to inspect variables while the target is running.
Links
- P&E website: http://pemicro.com/
- Comparison Codewarrior with Kinetis Design Studio: Comparing CodeWarrior with Kinetis Design Studio
- Live Variable View in CodeWarrior: Live View for Variables and Memory
- FreeRTOS Thread Awareness with OpenOCD: Search FreeRTOS Thread Debugging with Eclipse and OpenOCD
- FreeRTOS Thread Awareness with SEGGER: FreeRTOS Thread Debugging with Segger GDB in Eclipse
Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments