In this post I'll detail some things I ran into when trying to set up a development environment for Freescale's Kinetis parts on my Linux machine. There is some excellent information scattered around the Internet, this post just puts it all together for my own future reference and in case anyone else may find it useful.

This project started because I have a little Freedom KL02Z board, and I wanted to start developing software on it in my favorite development environment, Linux. I needed to take care of setting up:

  • A cross compiling environment
  • A debugging environment
  • The physical debugging connection

What about Codewarrior, KDS?

Freescale has somewhat of a checkered past when it comes to supporting development on a Linux host. The Codewarrior IDE used to be available for Linux. This makes sense as it is built on open source components that are cross-platform. Then suddenly they just dropped support for Linux. No explanation, just gone from version 10.3 to 10.4.

Now it seems Freescale is coming out with the Kinetis Design Studio (KDS), which will once again support Linux. Excuse me for being a little skeptic, but I'm at this point not certain how committed Freescale management is to continuous support of Linux. If I'm going to develop a product based on their part, I'd rather not have my development environment be discontinued out of the blue.

So instead of relying on them, I decided to set up my own development environment based on freely available components, and hopefully make it easier for others to do so too.

Turn OpenSDA into J-Link

I started out with the last requirement: Getting the physical debugging link to work. After some Googling I knew the other two requirements were possible, but I wasn't too sure if Linux support for the physical link would be available, so everything depended on this.

The Freedom board comes with an OpenSDA debugger on board. Even though this interface has the word "open" in it, it is actually closed source and proprietary. What's more, certain older versions of the OpenSDA component ship with a bootloader that is not compatible with anything but Windows 7 or less. So I needed to boot into my Windows partition on my laptop for this step.

To do this, you need to go to P&E micro's OpenSDA page and give up your email address to get a download link. The ZIP you download with updated firmware contains an update to the bootloader to make the OpenSDA component compatible with Linux (and Mac and Windows 8). You can follow the P&E instructions, but I'll summarize them here. First, you plug in the Freedom board USB while holding down the reset button, this will create a BOOTLOADER mass storage device. You copy the updated bootloader SDA file to this drive. The bootloader will be updated on the next boot of the board. One snag I ran into was that trying to copy this straight out of the ZIP file did not work. For some reason, it only worked if I copied the file when it already was extracted.

This part is all you need to do in Windows. If your bootloader is recent enough, you may be able to skip the preceding step.

Next it is time to turn the OpenSDA component into an actual JTAG/SWD probe. Go to Segger's OpenSDA page and download the firmware. Install it to the OpenSDA component by again plugging in the board while holding reset, and copying the SDA file to the BOOTLOADER mass storage device. After unplugging and replugging the board, the OpenSDA should now work as a Segger J-Link, with some limitations.

To actually debug a system with the J-Link, we need software support on the host. The first step is to install the J-Link GDB server. Go to Segger's JLINK download page and download the correct package for your distro. The download page will ask for a serial number, which you won't have because this is an OpenSDA development board. Click on the "I do not have a serial number..." link at the bottom. On the next page, check the checkbox to indicate you will not use the software with illegal clones, then download the software. The install worked flawlessly on my 64-bit Ubuntu system. A great guide for this step can be found on the GNU ARM Eclipse project's J-Link page.

Getting a cross compiler

Most guides send you to the "GNU Tools for ARM Embedded Processors" page, so that's where I got my cross compiler. Since I'm running Ubuntu, I decided to use the PPA mentioned on this page, but this turned out to be a mistake. It looks like the software found in this repository is NOT equivalent to the software found in the tarball. When I tried to compile example code, I invariably ran into trouble with code that tried to use the newlib-nano C library. It seems the nano.specs file for this smaller library is not included in the software in the repo, but it is present in the tarball. So I used the tarball. Another good reason to use this instead of a continuously updated toolset from a repository is that to support legacy projects, it is very helpful if you can keep maintaining them with their original toolset in the future.

I installed my tools in the /opt directory. I did not add these tools to the system path since I did not intend to do my development from the command line, but from the Eclipse IDE. Again, more details are to be found on the GNU ARM Eclipse project's toolchain page.

Setting up the Eclipse IDE

I decided to set up a development and debugging environment using Eclipse and the excellent "GNU ARM Eclipse" tools, which I already referenced several times above. These tools are tested on Eclipse Kepler, while the version of Eclipse in the Ubuntu repo is still 3.8, so I went and installed Eclipse Kepler manually into /opt.

To set up Eclipse with the GNU ARM Eclipse plugin, I suggest you read the project's excellent documentation.

Starting FRDM-KL02Z development

One problem I ran into was that the GNU ARM Eclipse tools do not (yet) include a template for the KL02Z I was using. I tried generating a KL25Z project and altering it, but I ran into problems where the CMSIS files for the KL25Z didn't all have equivalent KL02Z counterparts in Freescale's KL02-SC package. I also tried generating a generic Cortex-M Hello World package, but I noticed a lot of STM32 specific stuff I would have had to change.

Eventually I decided to generate an empty Cross ARM GCC project, and populate it with files from Martin Kojtal's Kinetis KLxx GCC GitHub repository, which has a KL02Z sample program. This proved to be the most successful approach for me. There are a couple of things to note when doing this:

  • It might help to have a dummy KL25Z template project sitting around to be able to duplicate most settings in your KL02Z project. One difference I noted though was that I needed to uncheck the -nostartfiles linker option to make things work with Martin's code.
  • Semihosting is not set up in Martin's project, so it needs to be turned off in the Eclipse debug configuration, or I had problems when debugging my code.
  • Eclipse only recognizes capitalized .S files, so make sure to rename startup_MKL02Z4.s accordingly.

I now have a nice development environment to start my project. I hope this info will be helpful to anyone who wants to start developing with these powerful little micros on a Linux host!

This blog post was posted to Techie Brain Showers on Sunday April 27th, 2014 at 6:43PM

Leave a Comment

You can use bbcode in the comment: e.g. [b]This is bold[/b], [url][/url], [code python]import this[/code]
Preview Posting...
Previewing comment, please wait a moment...

My name is Patrick Van Oosterwijck. Welcome to my spot on the web where I will hopefully regularly dump some of my brain content for the benefit of whomever may find it useful.

You are reading my tech blog. See the homepage for my other blogs.

Search for Posts
Possibly related posts
Popular Tags
© 2010 Patrick Van Oosterwijck.

Using technoblog blog engine by Will McGugan