What I love with Eclipse: it has lots of small and useful features, either built-in or available as plug-in. Recently I started to use a feature which is present in Eclipse for some time: the ability to save screen real estate during debugging with the ‘breadcrumb’ view option:
Expanded Breadcrumb View
A while back I wrote two articles about Semihosting: “Semihosting with GNU ARM Embedded (LaunchPad) and GNU ARM Eclipse Debug Plugins” and Semihosting with Kinetis Design Studio. With using the GNU ARM Embedded (lauchpad) in my Kinetis Design Studio, time for a ‘summary’ post :-).
Semihosting Output in Console
The Teensy is a great and tiny board (see “USB CDC with the Teensy 3.1 Board“), but it lacks real SWD/JTAG debugging capabilities (see “Hacking the Teensy V3.1 for SWD Debugging“). The Freescale Freedom boards are great, but for many applications too big, and have potentially too many components on it. So what about building a breadboard friendly tiny board which *has* SWD debugging ability *and* can be used to debug another boards?
So here is a working prototype based on the FRDM-K20D50M:
FRDM-K20D50M used as debug probe
If you have read my article “Serial Terminal View with Eclipse Kepler“, then you are aware that using a Terminal view to a serial connection (COM port) under Eclipse Kepler is pretty much broken. I’m moving some of my projects to the more recent Eclipse Luna release, and the good news is that support is back 🙂
Terminal View with connection to board
P&E has upgraded their GDB implementation and interface used in combination with the GNU ARM Eclipse plugins: they support now advanced flash programming options plus the ability to attach/connect to a running target :-). This update is available as Eclipse update.
Advanced Options
There are cases where my application runs find for days, weeks or even months, but then from time to time there is an application crash. Yes, the watchdog will recover it, but still it would be good to know what happened? One solution would be to hook up a trace probe (like the one I have described in this post: “First Steps with the P&E Tracelink“). But having such a trace probe attached all the time is first not cheap and second not always possible. So what if the application would leave ‘breadcrumbs’ behind which would tell me the flow of the program leading to the problem? I have found a functionality in the GNU tools which seems not be widely known or use, but is incredibly helpful in such cases.
So what if I could get a log like this telling me which functions get called by whom?
{ 00000E88->00000DA0 ???->DEMO_Init
} 00000E88<-00000DA0 ???<-DEMO_Init
{ 00000E8C->00000D40 ???->DEMO_Run
 { 00000D62->00000CE8 DEMO_Run:0x0022->decide
 { 00000D0E->00000C60 decide:0x0026->calcValue
 } 00000D0E<-00000C60 decide:0x0026<-calcValue
 { 00000D16->00000CA0 decide:0x002E->getValue
  { 00000CC6->00000C60 getValue:0x0026->calcValue
  } 00000CC6<-00000C60 getValue:0x0026<-calcValue
 } 00000D16<-00000CA0 decide:0x002E<-getValue
 } 00000D62<-00000CE8 DEMO_Run:0x0022<-decide
 { 00000D62->00000CE8 DEMO_Run:0x0022->decide
Eclipse with GDB is great: it comes with a graphical front end for debugging. But sometimes it is all about to download a program. Is it really necessary to launch an IDE like Eclipse to program or quickly debug a board? With the GNU Debugger (GDB), the answer is ‘no’: GDB comes with a command line debugger which is designed exactly for this: providing a command line interface for programming/downloading and debugging, bypassing any GUI (Graphical User Interface).
Combination of GDB Debugging Probes and Boards (P&E, Segger and FRDM-KL25Z)
OpenOCD is an open source and free-of-charge debugging solution, which is a great option here at the University of Lucerne, as students do not need to buy an expensive debugging probe. Still, I recommend to buy professional probes like the P&E or Segger ones, as they are worth every (Euro) cent. But for a ‘zero’ budget, OpenOCD with CMSIS-DAP is something to consider. And with Kinetis Design Studio using the GNU ARM Eclipse Plugins, OpenOCD is not that hard to be used. And because both Freescale and GNU ARM Eclipse offer OpenOCD Windows binaries, that connection method is in the reach of Windows users too.
FRDM-KL25Z with OpenOCD Debug
This happens several times for me: I have a board running for a while (even for days), and then it crashes or is stuck somewhere. Yes, I usually use a watchdog do recover from that situation. But it would be good to know and debug the problem. With CodeWarrior I had the functionality in the debugger to ‘attach’ or ‘connect’ to a running (stuck/crashed) board. However, with Eclipse/Kinetis Design Studio/GDB this is a different debugger, and not possible. At connection time with the debugger the target does a reset, so I don’t know any more where the application crashed. But now I have a solution, at least with the Segger GDB :-).
Debug Hard Fault Attached Target
For everyone who wants to combine the power of Eclipse and Processor Expert with the IAR Embedded Workbench IDE, here is how to get them working side by side:
Continue reading
MCU on Eclipse 