Tired by the tool chains provided by your silicon vendor? Do you want to use a free and open tool chain? Then you probably followed by “DIY Free Toolchain” series already. In “DIY Free Toolchain for Kinetis: Part 2 – Eclipse IDE” I used the standard GNU Eclipse plugins. As mentioned in above post, there is an even better and more powerful plugin available: the GNU ARM Eclipse plug-ins. There is a dedicated blog site which provides excellent documentation and direct access to new and frequent releases. And these days there is a true a Christmas gift for every Eclipse lover: the version 1.1.7 with the addition of J-Link debugger plugin :-).
GNU ARM Eclipse
List of Tutorials
- Part 1: Setting up ARM GNU tool chain
- Part 2: Setting up Eclipse IDE
- Part 3: Setting up the debugger (P&E and Segger)
- Part 4: Setting up Processor Expert
- Part 5: Setting up FreeRTOS Kernel Awareness
- Part 6: Linux Host Support with OpenOCD and CMSIS-DAP
- Part 7: GNU ARM Eclipse Plugins
- Part 8: Processor Expert with GNU ARM Eclipse Plugins
- Part 9: DIY Free Toolchain for Kinetis: Part 9 – Express Setup in 8 Steps
- Part 10 – Project Creation with GNU ARM Eclipse 2.1.1
About GNU ARM Eclipse
The GNU ARM Eclipse plugins are now maintained by Liviu Ionescu. The project is hosted on sourceforge (https://sourceforge.net/projects/gnuarmeclipse/). Liviu does an outstanding job doing this (I received response on inquires within hours!). To make the plugins easy to use, Liviu maintains dedicated blog site for it.
That site is full of excellent information, tutorial and all kind of useful information. The plugins are far easier to use than the default GNU Eclipse plugins. And they run on Windows, GNU/Linux and Mac OS X. I use the plugins with my Eclipse Kepler under Windows.
GNU ARM Eclipse is using the GDB hardware Debugging Plugin. The GNU GDB is ok for hobby or experimental debugging. But I have to say that the GNU GDB is far away from the quality and usefulness of ‘commercial’ plugins for example in CodeWarrior. Nothing wrong with the GNU GDB, but it requires to start/stop the server by hand, has not a user-friendly interface, no real reset/restart functionality, and I have found GNU GDB not very stable. Sure, GDB has improved over time, and will continue to do so. But to me the better debugging support is what makes a difference between paid and free tools.
The good news is that GNU ARM Eclipse has added a Segger J-Link hardware debugging plugin which closes that gap :-). That plugin is still marked as ‘experimental’, but I was very pleased with it.
GNU ARM Eclipse Installation
I have installed the plugins into my Eclipse Kepler. Follow the usual Eclipse process:
- Menu Help > Install New Software
- Use following update site: gnuarmeclipse.sourceforge.net/updates
- Select the plugin(s) andclick through the installation process
Installing GNU ARM Eclipse Plugins
💡 The latest plugin collection comes STM32 project templates which gives a good starting point for anyone using the STM32 devices.
Segger Installation
Next define a String Substitution to the Segger Installation path.
💡 By default, Segger installs on Windows on my machine into a path with spaces. I faced problems with paths having spaces, so make sure you install into a path *without* spaces. I have filed a ticket, but until this is fixed, better always use paths without spaces. UPDATE: this issue has been fixed, and will be available with the next release of the plugins.
J-Link Installation Variable
Either a Segger J-Link or the FRDM OpenSDA Segger Firmware can be used.
Creating Project for FRDM-KL25Z
Next, I showing how to use the plugin to use a project for the Freescale FRDM-KL25Z (Freescale Kinetis ARM Cortex-M0+) board. The steps are pretty generic, and can be used for other boards too.
The completed project is found on GitHub.
Creating a Project
❗ Do *not* use a workspace or project path with spaces! As stated below, that might cause problems (which hopefully will be fixed soon).
Use the menu File > New C (or C++) Project:
New C or C++ Project
I give the project a name and select ‘Empty Project’ with ‘Cross ARM GCC’:
Cross ARM GCC Empty Project
Press Next: here we can go with the default configuration:
Select Configurations
Press next, and I have the opportunity to select the toolchain:
Cross GNU ARM Toolchain
I’m using GNU ARM 4.7. The feature of this plugin is that it allows a very flexible toolchain configuration.
Press ‘Finish’, and the empty project gets created.
Empty Project Created
Adding Folder and Files
With the menu File > New > Source Folder I add my source folders, then I add my source files:
Source Folder and Files
💡 You can use my sources as starting point from GitHub here.
Beside of the startup code and source files, you need to add as well the linker (*.ld) file, for example in a linker folder.
Build Options
The build options need changed for my source file structure and processor used. For this I select the project properties (select the project, then menu Project > Properties).
First, I configure the processor used. For the KL25Z this is an ARM Cortex-M0+ (cortex-m0plus):
Selected ARM family
Next I specify the include paths for the compiler. I’m using the ${ProjDirPath} variable to have things project relative:
Include Path Settings
For the linker I need to specify the linker file. Additionally I’m using my startup file:
Linker Settings
❗ If the path to the linker file has a space in it (includes the workspace path!), then double quote the file name e.g. with double quotes. Note that in 1.1.7-201312221905 this did not help, but should be fixed in a newer version of the plugins. I filed a ticket on this. UPDATE: this issue has been fixed, and will be available with the next release of the plugins.
Optionally I can configure it to produce a Flash Image or to Print the Size. With everything set up, I can build the project, and this should go without errors.
Building the Project (Console Output)
Debugging with Segger J-Link
For debugging I can use either my Segger J-Link or using the Segger OpenSDA firmware. Make sure you have at least V4.80 downloaded: this is the version at the time of this writing. Check out as well the steps on the GNU ARM Eclipse site.
Creating Debugger Configuration
Use the menu Run > Debug Configurations…
There select ‘GDB SEGGER J-Link Debugging’ and press the ‘new’ button:
GDB SEGGER J-Link Debugging
This creates a new debug configuration:
New Created Debug Configuration
Debugger Settings
In the debugger tab, because I’m using an ARM Cortex-M0+ with SWD, I make sure ‘SWD’ is selected. The Device name I get from the Segger with the web link near that setting. Finally I verify the path to the Segger Command Line (CL) debug server. Here I’m using the variable $(jlink_path) I have set up earlier:
Debugger Settings
Startup Settings
In the debugger Startup options I disable semihosting and SWO (as not supported with my FRDM-KL25Z):
Debugger Startup Options
❗ Having SWO enabled for a target which does not support SWO will crash the Segger server (at least for Segger V4.80). UPDATE: Issue has been reported to Segger, and they are working on fixing it.
With this, I’m ready to debug my target :-).
Debugging: Reset and Restart
Debugging with Segger means that it is very fast, offers unlimited hardware breakpoints in flash, and what is now possible is a working reset and restart:
Reset and Restart
CodeWarrior has a similar feature (with dedicated reset), and moving to GDB this was one of the many features I missed in GDB. Now at least with Segger it is possible to reset and restart the target :-).
❓ I still cannot believe why such a fundamental thing like resetting a target is not present in normal GDB debugging solutions? It sounds not like a big deal, but ‘reset’ is such a fundamental thing in Embedded Systems debugging.
The debug view has added ‘target’ entires to show the Segger console output or for the semihosting.
💡 Semihosting is a technique with application serial communication routed through the debugger instead through a real serial connection. It sounds like a great feature, but has very limited usage (and can be even problematic for realtime applications), so I’m not really interested in it.
Summary
For me, the GNU ARM Eclipse plugins are the state-of-the-art Eclipse plugins for any ARM development on Eclipse. They work great out of the box, and any issues get addressed very fast. The GNU ARM Eclipse blog and web site comes with a lot of very useful information and tutorials, and the project is hosted on Sourceforge (https://sourceforge.net/projects/gnuarmeclipse/). With the added ease-of-use for Segger the GNU ARM Eclipse plugins set the bar very high for any other Eclipse based solution ;-).
I was able to run a project for the FRDM-KL25Z board within less than half an hour. And with the example on GitHub it will take even less time :-).
There is a way in the plugins to add template projects (they come with templates for the STMicroelectronics STM32). If I find time, I should check out if this could be extended to other devices too. That would make things working out of the box even better.
Happy GNU ARM Eclipsing 🙂
MCU on Eclipse 
Pingback: DIY Free Toolchain for Kinetis: Part 1 – GNU ARM Build Tools | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 2 – Eclipse IDE | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 3 – Debugger (GDB Server with P&E and Segger) | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 4 – Processor Expert for Eclipse | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 5 – FreeRTOS Eclipse Kernel Awareness with GDB | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 6 – Linux Host with OpenOCD and CMSIS-DAP | MCU on Eclipse
Thank you Erich for your very detailed review, it is highly appreciated. 🙂
The problem with spaces in the GDB server/client path, being under the plug-in control, was (hopefully) solved, a new release will be available soon.
The problem with spaces in the project names is somewhere deep in CDT. A few weeks ago I pushed a patch for that one too into CDT Gerrit, it was accepted and will be available from Kepler SR2, in January.
I would appreciate bug reports and feature request tickets in the SourceForge trackers, from all those who use the plug-ins and have problems or suggestions, to help make these plug-ins better.
LikeLike
Hi Liviu,
a big ‘thank you’ to you for providing this great plugin! And thanks for your support!
Yes, there are constant problems in tool chains for paths and file names having spaces. As a general rule, I avoid spaces or non-simple-ASCII character in paths whenever possible. As an update for that minor Segger problem: I reported this to Segger, and within hours they confirmed the issues and will work on it to have it fixed. All great news 🙂
LikeLike
> constant problems in tool chains for paths and file names having spaces.
yes, same is on OS X, just that, affecting me directly, I already fixed them. unfortunately the fix did not apply to Windows too.
> As a general rule, I avoid spaces…
well, I don’t, exactly for this reason, to spot the problems. on Windows, my friend doing testing avoided spaces, and… the problem slipped undetected. 😦
> … Segger
yes, they have a great support, another reason I recommend J-Link.
LikeLike
Pingback: Version 1.1.7-201312241058 released | GNU ARM Eclipse
Version 1.1.7-201312241058 was released, fixing the path issues with spaces (gnuarmeclipse.livius.net/blog/2013/12/24/version-1-1-7-201312241058-released/).
Many thank to Erich for identifying the bugs and for helping diagnose and test them.
LikeLike
Hi Liviu
Great work.
Sometime we just wante to download code to chip, if add support in run configuration just for downloading code , that would be a greate help.
LikeLike
Hi Kevin,
yes, I agree. I made that request to a Eclipse distributor too, and they are going to add this at least on their side. CodeWarrior has this with the ‘simple flash programmer’ (https://mcuoneclipse.com/2012/04/30/flashing-with-a-button-and-a-magic-wand/). It does not have to be that way: just a way to solect a *.s19/*.elf/etc file in the launch configuration (without the need of a project) and then flash it to the target.
LikeLike
Yes, I thought about it, but implementation was not easy, so did not get very high priority. Could you register a feature request for this?
LikeLike
I have a short comment about using the ‘${ProjDirPath}’ macro as absolute path of project include folders.
There is nothing wrong with it, except the paths can be very long, and sometimes might exceed the Windows command line maximum length.
A shorter (and easier to read) solution is to use relative paths. For example the projects created by the GNU ARM Eclipse Templates use definitions like “../include”, “../libs/CMSIS/include”, etc.
It might not work in all possible configuration, but in most cases the build folders (Debug and Release) are located immediately below the project root, so the ‘..’ should be enough.
LikeLike
The problem with using ../include style of include paths is that it might not be clear or defined what the ‘current’ directory is. Different compilers handle this very different, causing problems. In the worst case, the wrong files get included. I learned the hard way to use macros which end up in absolute paths. As you say: it might not work in all configurations, that’s exactly the reason why I use these macros.
About the Windows command line maximum length: that’s something I noted that the current plugins will easily run into (I was thinking about filing a feature request on this subject). The ARM GCC plugins in CodeWarrior handle this very well in my view as they pass the list of files in an argument file (and not on the command line). That way they do not run into this problem for larger projects. Maybe something to implement for the GNU ARM Eclipse plugins too?
LikeLike
> Different compilers handle this very different
that’s correct, the standard leaves this to be decided at implementation level, but since the plug-in is dedicated to GNU toolchains, the behaviour is more or less uniform among GNU toolchains, where paths are relative to the current folder, which is guaranteed by the plug-in to be the build folder. so it isn’t that bad.
> CodeWarrior handle this very well in my view as they pass the list of files … Maybe something to implement
yes, I investigated this, but it requires either major changes in CDT (difficult to push) or significant code duplication from CDT into the plug-in, which translates into maintenance hurdles to keep it in sync with the original branch.
LikeLike
Hi Liviu,
ok, good information. Too bad as this CodeWarrior extension is not easy to leverage. I have some very large projects with hundreds of source files. I cannot build it with other tool chains, only with CodeWarrior as it uses files for option passing. Using relative paths does not help, as the sum of the source file names (pluse relative directories is more than 8k I believe. Yes, I could use make files (and pass parameters by hand), but this is a lot of work. I considered using libraries for subparts of the project files, but this yet again is additional work. I believe that problem might get bigger in the future. Typical ARM Cortex M based devices are now in the 128-256 kByte FLASH range, but I see this growing up to several MBytes FLASH. Means projects will get bigger and bigger.
I’ll use your advide on using relative paths. It will help me at least to push out the point where things will fail.
LikeLike
The Windows command line limit is only half of the problem. It can be avoided with separate files, as you suggest, but then you might face a second problem, reaching an internal limitation of the Windows make program, that will fail to build the dependencies graphs. (it happened to a friend of mine, and there was no way to avoid it). Any idea what make program is used inside CodeWarrior?
One alternative that I’m considering is the Eclipse internal build system. It seems functional even for large projects. Unfortunately it has some bugs when dealing with secondary targets (creating the hex/s19 files, the listing, printing the size), so I could not use it directly with my plug-in. Perhaps I should investigate these CDT bugs, and fix them.
LikeLike
CodeWarrior is using the MinGW GNU Make v3.82:
GNU Make 3.82
Built for Windows32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
LikeLike
A similar comment on linker script path: it might be constructed with ‘${ProjDirPath}’, but it is shorter to add a library path “../ldscripts” in the linker options, and then list the script files without any path at all. The GNU ARM Eclipse Templates uses multiple .ld files (libs.ld, mem.ld, sections.ld), and a single relative -L for the library path.
LikeLike
Frohe Weihnachten
Thanks for all you contribute to all your followers.
-Bill
LikeLike
Merry Christmas! And many thanks for all the reading and commenting out there!
Erich
LikeLike
Pingback: DIY Free Toolchain for Kinetis: Part 8 – Processor Expert, Eclipse and GNU ARM Eclipse Plugins | MCU on Eclipse
How can you have unlimited “hardware” breakpoints with this setup? I thought the kl25z only offers 2 hardware breakpoints and the tool can then offer additional software breakpoints. Not unless I don’t understand the meaning of hardware breakpoints.
LikeLike
The correct name is ‘J-Link Unlimited Flash Breakpoints’, since it is a SEGGER feature; I guess it works by replacing flash code with breakpoints. (http://www.segger.com/jlink-unlimited-flash-breakpoints.html).
LikeLike
I got it thanks. Erich wrote about this: https://mcuoneclipse.com/2012/07/29/software-and-hardware-breakpoints/
LikeLike
Yes, the KL25Z hardware only has the two hardware breakpoints. What Segger does is ‘programming the flash with software breakpoints’ (see https://mcuoneclipse.com/2012/07/29/software-and-hardware-breakpoints/). Because they are very close at the hardware with their debug device (no need to do this from the host), they can do this so fast that programming the flash blocks is so fast that it is not really noticable.
LikeLike
Pingback: DIY Free Toolchain for Kinetis: Part 9 – Express Setup in 8 Steps | MCU on Eclipse
Pingback: DIY Free Toolchain for Kinetis: Part 10 – Project Creation with GNU ARM Eclipse 2.1.1 | MCU on Eclipse
Pingback: FTF: FRDM-K64F, Kinetis Design Studio and Kinetis SDK | MCU on Eclipse
Pingback: P&E Eclipse Update Site for GNU ARM Eclipse Plugins | MCU on Eclipse
Just a small omission from the instructions in this tutorial: In the “Adding Folder and Files” section you also need to add the /linker directory and the MKL25Z128_flash.ld file.
Otherwise, I’ve followed the instructions up to this point and am debugging the sample app on my own hardware, with JLink. Thanks very much, guys!
LikeLike
Indeed, I have missed that piece and instructions, sorry about that. I have now added a few words about it, so that should be more clear now. Thanks!
LikeLike
How can I set up a “Run Configuration” that downloads an image to the target through JLink and runs it? CW does this. I have made a second Debug Configuration and uncheck the “Load Symbols”, “Set breakpoint at” and “Pre-run reset and halt” check boxes. The image then downloads to the target and runs immediately, but the debugger is still running in Eclipse, and I still have to Terminate the debugger. It is OK, but is there a more elegant option?
LikeLike
Not sure why, but somehow the ‘Run’ configurations in Eclipse Kepler indeed do not work/run. If the debugger is a problem for you, you might use the command line debugger/gdb to do what you want? Would be a script or something similar which would download and run the application. I have not made an example yet myself, but should be doable.
LikeLike
Pingback: OpenOCD/CMSIS-DAP Debugging with Eclipse and without an IDE | MCU on Eclipse