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
In Eclipse, the usual way to add new plugins or extend the IDE is using the menu Help > Install New Software. Same thing for the newly released Freescale Kinetis Design Studio V3.0.0: I add the support for new devices in the Freescale Kinetis SDK from the SDK Eclipse update:
Installing Kinetis SDK v1.2 update in Eclipse
One thing I noticed with this (and all others updates I do) is that they take much time to install. That’s expected if the update needs to be downloaded from the web. But I was wondering why it takes so long even if the files are local?
Thanks to a tip (thank you, Marek!), there is a setting to cut the installation time :-). Continue reading
So now I have carefully set up my compiler include paths in Eclipse to tell the GNU compiler where to find my header files:
Include Paths
The question is: how can I apply these settings to another project?
One of the things missing for Embedded in the GNU linker is that it cannot generate a CRC checksum. Luckily, there is the solution of using SRecord:
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
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
In my classes I’m mainly using the Freescale FRDM-KL25Z board, as it provides the best value for the money, and 128 kByte FLASH with 16 kByte of RAM is enough for many smaller projects. I do have as well the FRDM-KL02Z Board (32 KByte FLASH, 4 KByte of RAM) which is an inexpensive board to evaluate the smaller KL02Z microcontroller. Because someone reported a problem not being able to use the UART over OpenSDA/USB-to-CDC bridge, I have created a demo project which communicates with a console on the host.
FRDM-KL02Z 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
There is a really annoying issue with using command line tools on Windows: the maximum length of the command line passed to cmd.exe is 8192 characters (see http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx). So you think this is not a problem for you, as you would not pass such a long command line to cmd.exe (the DOS shell under Windows)? Well, if you are using Eclipse (as I do) which generates make files (which is the normal way), then the cmd.exe very likely is involved to call the compiler/linker/etc, indirectly with the usage of make.exe. Compiling files is usually not a problem as it does not hit that 8192 limit. However, it is likely that link phase will end up with an error:
Error in the Problems View
If you have such a problem, there is a solution ….
MCU on Eclipse 