MCUXpresso IDE: Importing Kinetis Design Studio Projects

Many of my currently active projects are using Kinetis Design Studio (KDS) V3.2.0 from NXP (I have published many of my projects on GitHub). Now with the advent of the MCUXpresso IDE (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“), I have migrated several projects from KDS to MCUXpresso. This post is about how to easily get KDS projects ported and running in MCUXpresso IDE.

Debugging KDS Project in MCUXpresso IDE

Debugging KDS Project in MCUXpresso IDE

MCUXpresso IDE Series

This article is part of a series to get up to speed using the new NXP MCUXpresso IDE. Published so far are:

Outline

MCUXpresso IDE is using the newer (Neon) Eclipse IDE than KDS (Luna) with a different build system: MCUXpresso IDE is using the same build system and integration as LPCXpresso, while KDS is using the GNU ARM Eclipse plugins. Both approaches have their pros and cons (as always). Plus MCUXpresso IDE does not include Processor Expert, but KDS does. To migrate and use KDS projects with MCUXpresso IDE, there are the following basic approaches:

  1. Importing KDS (non-Processor Expert) projects: for this the GNU ARM Eclipse plugins needs to be installed, along with the GNU ARM Eclipse build tools. This allows to use KDS projects as in KDS, but with the extra functionalities of MCUXpresso IDE.
  2. Importing Processor Expert projects: same as above, but this needs the installation of Processor Expert plugins too. That way I can continue to use Processor Expert projects as in KDS, but keep in mind that NXP does not offer newer device support for Processor Expert.
  3. Porting KDS projects to MCUXpresso IDE: this means to migrate a KDS project to the MCUXpresso build system. This is a fairly simple approach, basically with creating a new project in MCUXpresso IDE and then move the files over.

💡 In general I follow the approach not to switch IDE or toolchain for projects. Migrating or porting a project only makes sense where it is really necessary. I do have many projects I keep maintained in older toolchains like CodeWarrior, and only migrate projects which I continue to develop and evolve.

Because it is too much to describe everything in one post, I focus on approach 1 in this article.

Software Used

At the time of this article, I’m using the following software:

I’m using Windows as host, but similar steps apply to the Mac and Linux hosts. I’m assuming you already have Kinetis Design Studio V3.2.0 installed. If not, the steps below install everything you need to use Kinetis Design Studio projects in MCUXpresso, and you don’t need KDS V3.2.0 installed (e.g. if you downloaded a project from somewhere).

💡 Note that tutorial does not include the installation of Processor Expert into MCUXpresso IDE: this is subject of a next article.

GNU ARM Embedded Toolchain

KDS has pre-installed the GNU ARM Embedded Toolchain. While it would be possible to use that same version, I’m using the latest version from https://launchpad.net/gcc-arm-embedded which is the 6-2017-q1-update I can get from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads:

GNU ARM Embedded Toolchain 6-2017-q1-update

GNU ARM Embedded Toolchain 6-2017-q1-update

I recommend to download the installer and run the setup with the default settings:

Installing GNU ARM Embedded Toolchain

Installing GNU ARM Embedded Toolchain

Installation of GNU ARM Eclipse Build Tools

On Windows, I need to install other build tools which are already part of Kinetis Design Studio (inside the <kds>\bin folder).

Follow the instructions on http://gnuarmeclipse.github.io/windows-build-tools/install/ and download the latest setup from https://github.com/gnuarmeclipse/windows-build-tools/releases, then run the setup with the default settings:

GNU ARM Eclipse Build Tools Setup

GNU ARM Eclipse Build Tools Setup

GNU ARM Eclipse Plugins

To have the build tools working in Eclipse, I need to install the GNU ARM Eclipse plugins, otherwise KDS projects in MCUXpresso IDE will show an error message similar to the one below:

Orphaned configuration. No base extension cfg exists for ilg.gnuarmeclipse.managedbuild.cross.config.elf.debug.1376620489
Orphaned Configuration

Orphaned Configuration

Basically it means that the project (.cproject file) needs the ilg.gnuarmeclipse.managedbuild.cross.config.elf build plugin/integration which is not installed by default in MCUXpresso IDE. The general process is described in http://gnuarmeclipse.github.io/install/.

To install the plugins, I have two ways:

  1. Eclipse Marketplace (preferred)
  2. Install new Software

Eclipse Marketplace

With the Eclipse Marketplace you need that plugin installed (see “MCUXpresso IDE: Adding the Eclipse Marketplace Client“), use the menu Help > Eclipse Marketplace:

Eclipse Marketplace Menu

Eclipse Marketplace Menu

Search for the plugin and install it:

GNU ARM Eclipse in Eclipse Marketplace

GNU ARM Eclipse in Eclipse Marketplace

I recommend to install all plugins: that way it is possible to create and debug any ARM Cortex-M projects (beyond NXP):

Installing from Marketplace

Installing from Marketplace

If you are running into a ‘handshake’ problem, then there is a problem with the security settings to get access to SourceForge (see this link).

Handshake problem

Handshake problem

In that case, I recommend to download a zip file described in the next step.

Install New Software

I can use the menu Help > Install New Software and point to the following update site:

http://gnuarmeclipse.sourceforge.net/updates

But be aware that this might not work because SourceForge has recently changed the security settings (see this link). Instead, I recommend to download the zip file from

https://sourceforge.net/projects/gnuarmeclipse/files/Current%20Releases/

and then use that zip file in the dialog accessible by Help > Install New Software:

💡 I can drag&drop the zip file into the dialog.

Installing GNU ARM Eclipse plugins from zip file

Installing GNU ARM Eclipse plugins from zip file

Importing Projects

NOTE: Be warned! I recommend to *copy* the projects, and *not* to try to use with MCUXpresso and KDS in parallel. MCUXpresso is using a newer Eclipse, but while it *might* work to open that project afterwards in KDS again, it is certainly not something I would like to do. So make a copy/backups of the project before importing (and changing) it in MCUXpresso! Likewise, you should NEVER share a workspace folder with different Eclipse versions.

With this, I have everything to import, build and debug Kinetis Design Studio V3.2.0 projects :-). There are multiple ways to import projects, the easiest one is to use the Quickstart panel and use ‘Import project(s) from file system…’:

Import Projects from file system

Import Projects from file system

💡 Alternatively use the normal Eclipse way using the menu File > Import > General > Existing Projects into Workspace

Then browse to the folder or use the zip archive:

Importing Project Directory

Importing Project Directory

Then go through the dialog to import the project(s).

Verify Project Settings

With the installed plugins and software in the previous steps, everything should be in place to build and debug the imported projects. Here are a few things to verify and check if everything is configured correctly.

Use the ‘edit project settings’ menu in the Quickstart panel (or use the menu Project > Settings):

Quickstart Panel Project Settings

Quickstart Panel Project Settings

Opening the project properties, the settings should show up as in KDS:

KDS Project in MCUXpresso

KDS Project in MCUXpresso

There is a small glitch in that Quickstart menu action that it might show only the ‘Error Parsers’. In that case, use the ‘left’ icon to get to the left side of the panels:

Only shows Error Parser

Only shows Error Parser

The toolchain shall show up as ‘GNU Tools for ARM Embedded Processors‘ in the project settings:

Tools Path in Project Settings

Tools Path in Project Settings

The GNU ARM Eclipse plugins allow a very flexible and powerful tool chain configuration (up to separate tool chains for each project). Below are the workspace settings (menu Window > Preferences). It specifies which toolchain and build tools are used, and it shows where I have installed them in the previous steps:

Global Tools Paths

Global Tools Paths

💡 I’m using here *different* (newer) build tools and tool chain than what is installed in KDS v3.2.0! If you have KDS installed, and if you want to use the same toolchain, then you can configure that in that dialog.

MCU Settings

MCUXpresso has an extra setting in the project to specify the microcontroller used. Because that project has been created outside MCUXpresso IDE, the MCU is not correctly assigned. This setting is not important for building it with the GNU ARM tools, but is needed if I want to use other advanced MCUXpresso IDE settings like automatic probe discovery (more about this later).

I recommend to go to the C/C++ Build > MCU settings and assign the correct MCU used in that project:

MCU Settings

MCU Settings

However, I need the MCUXpresso SDK (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“) installed for that MCU!

💡 I recommend to have the SDK installed. Otherwise (and if there is no SDK for the MCU used in the project), I recommend to set a matching ‘generic’ MCU from the preinstalled MCUs

Generic MCU

Generic MCU

With this, everything is set up to build and debug!

Clean First!

An important step after importing projects is to get rid of any old files with a ‘clean’. The easiest way is to use the ‘clean’ in the Quickstart panel (or use the menu Project > Clean):

Clean project after importing

Clean project after importing

Build

Yet again, us the Quickstart panel to build the project (or use the menu Project > Build):

Build Project

Build Project

This should build the project without errors (as in KDS).

Debug

KDS projects use normal Eclipse launch configuration files and settings. The launch files are usually stored in a ‘settings’ folder inside the project:

KDS project debug launch configurations

KDS project debug launch configurations

MCUXpresso IDE, on the other side, is able to detect debug probes automatically and to create and manage the launch configurations (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“).

I can continue to use the launch configurations in the project, the same way as in KDS. I can check them using the Debug Configurations menu:

Debug Configurations Menu

Debug Configurations Menu

The screenshot below shows some debug configurations in my workspace:

Debug Configurations

Debug Configurations

Compared to KDS, there is a group on the top for launch configurations for the LPC-Link/LPC-Link2 debug connection.

Because the debug plugin for P&E are the same (provided by P&E), the group combines both imported KDS and MCUXpresso configurations.

Notice that there are two groups for the Segger debug plugin: one for MCUXpresso and one for the GNU ARM Eclipse Segger plugin we have installed in one of the previous steps. The one on the bottom is exactly the one you know from KDS.

💡 If you compare the features and responsiveness of the GNU ARM Eclipse SEGGER plugin and the one installed with the GNU ARM Eclipse plugins, then you might like the one from GNU ARM Eclipse more, especially as it provides more detailed settings. The good thing is that with installing the GNU ARM Eclipse plugins you can use it for any project. However, it won’t work with the MCUXpresso automatic probe detection.

Which Segger J-Link binaries are used by the GNU ARM Eclipse debugger plugin is a setting behind the menu Window > Preferences > Run/Debug > SEGGER J-Link:

GNU ARM Eclipse Path to SEGGER

GNU ARM Eclipse Path to SEGGER

Verify the folder settings or use the ‘Restore Defaults’ folder if you have updated the SEGGER files.

With this, I can debug my KDS project in MCUXpresso IDE:

Debugging KDS Project in MCUXpresso IDE

Debugging KDS Project in MCUXpresso IDE

Using MCUXpresso Probe Detection

One benefit of the ‘combined’ IDE and plugins is that now I can use the extra features of MCUXpresso for my imported project. And one of it is the automatic probe detection (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“). For this I launch the debugger with the blue debug icon (instead with the normal green one):

Debug (blue) button

Debug (blue) button

If you get a dialog about “No MCU associated with this project. Please select an MCU before continuing”, then check the section “MCU Settings” from above: it means that project settings no MCU assigned.

No MCU associated with this project

No MCU associated with this project

Otherwise, I get the automatic probe discovery dialog:

Probes automatically discovered

Probes automatically discovered

And then it will create the selected debug connection/configuration and I can debug with it.

To re-trigger the automatic probe discovery, a simple way is to remove the created launch configurations (but then I will lose any custom settings I have made):

Automatic Probe Launch Configurations

Automatic Probe Launch Configurations

Processor Expert Projects?

The presented approach even works with Processor Expert projects, only that you won’t be able to generate Processor Expert code with it. So as long you have generated code in the KDS project, you can import it as any normal project using the above approach.

As for how you could continue to use Processor Expert projects in MCUXpresso and fully using Processor Expert as in KDS: this is subject of a future article.

Summary

I can easily import existing Kinetis Design Studio (KDS) projects. With installing the toolchain (if not already installed) plus the GNU ARM Eclipse plugins in MCUXpresso IDE, I can build and debug existing KDS projects without any porting effort or any project conversion: they simply work. Compared with the original KDS, I have a newer Eclipse, the latest toolchain and can use the extra features offered in MCUXpresso. I have this now working with several existing KDS projects, and this works very well. To the point I might leave KDS behind and continue to use all KDS projects with the MCUXpresso IDE.

I’m running out of time this week-end. What I have not covered in this article is how to get Processor Expert running in MCUXpresso IDE, or how to switch the toolchain/project from KDS to the native MCUXpresso one. So this next on my list of things. I hope that what I was able to write-up is already useful for you.

Happy Importing 🙂

Links

Advertisements

22 thoughts on “MCUXpresso IDE: Importing Kinetis Design Studio Projects

  1. I have been working with frdm-kl25 and frdm-k64f with ksdk 1.3. For now I plan to continue using kds because the KSDK 1.3 is integrated with Processor Expert. The disadvantage of this is that KDS will no longer be supported by NXP. 😦

    Like

  2. Thanks for posting this, I was about to look at doing this myself soon. This will save me a lot of time sorting things out. I haven’t gotten to kick the tires yet, but it feels like MCUXpresso is at least heading in a good direction.

    Like

  3. Good day Erich,
    I was curious as to your thoughts as to why NXP (Freescale) would create yet another software tool for us to have to use and maintain? I say this, as Freescale originally had CodeWarrior Classic… then migrated to CodeWarrior Eclipse (multiple versions)… then to KDS… where again multiple versions that has issues with past version code… and now we have MCUXpresso. It really, really is tough to try and maintain all these toolsets for a company’s released products that were written, tested, and debugged with various toolsets and versions.
    Anyway, I am just trying to understand their motivation besides causing the firmware developer to go bonkers.
    Thanks in advance as well as your continued efforts to enlighten us!
    Cheers,
    Sam

    Like

    • Hi Sam,
      I feel like you, and I have the same kind of problem. I have projects for CodeWarrior (non-Eclipse, classic), for CodeWarrior (Eclipse based), for Kinetis Design Studio, LPCXpresso and now MCUXpresso. But this is not a NXP problem (I do have a similar problem with other vendors like STM or Microchip). Not only for NXP, there is a ‘constant change’, and I think we see here a reflection of what is going on in the industry with all the mergers. And I completely understand that NXP does not want to carry forward multiple IDEs, so getting things consolidated sounds like a good thing to me. I was hoping that using IAR or Keil would be better, but I faced the same issue: they update their tools/compilers/project formats which puts many times roadblocks into the way too. But this is not only on the tools side: I have a similar challenge on the host operating system side: for example a project with tools I have to maintain which is still running on Windows 2000 probably for several years.
      As mentioned in my post, I think we always need to evaluate what is it worth to migrate things or keep it where they are. I would not migrate a project which is in production or has been started if not really necessary.
      Are there alternatives? Yes, there are things like using stock Eclipse, add GNU tools and plugins and there you go (see https://mcuoneclipse.com/2013/07/20/dyi-free-toolchain-for-kinetis-part-1-gnu-arm-build-tools/): I’m using that approach for a few other projects too.
      I think we all have to deal with these constant changes the best we can. The good thing is that we still have plenty of choices, and as long there is a choice, things tend to move into the right direction.

      Cheers,
      Erich

      Like

      • Erich (or anyone here),
        Speaking of the large number of toolchains, are you aware of any tools that bridge the gap between system design, PCB layout, and firmware development? I know for very simple projects, the system and the pin configuration will be trivial, but what about for medium to large sized projects? Has anyone made a toolchain that links up the firmware and hardware development?

        Like

      • Good day Erich,
        Thank you for your response!
        After reviewing the MCUXpresso I think I see the motivation for the new tool. I hate to say it, but it looks as if one of the motivations was the ability to offer a Pro/ Paid version. This kind of bites, as Codewarrior was/is a pricey tool in its time (those that paid for the Pro version) and was effectively abandoned for use with the newer Kinetis parts. KDS looked to be a suitable path given that the tools were free and thus softened the financial blow to the CW purchased user. Now this looks like it might change with the paid/pro version of MCUXpresso… I guess we shall see.
        Cheers,
        Sam

        Like

      • Hi Sam,
        I don’t think that this paid/Pro version is really the driver. I think it is more to offer the same as the LPCXpresso users had (getting a direct email support way instead of relying on free (and non-direct) community support). Yes, in LPCXpresso this Pro unlocked the code size limitation too, but there is no such code size limit in MCUXpresso! So with this, apart of tha rather minor interrupt trace features it unlocks, it is really about getting email support for the IDE. Other than that, I don’t see a compelling reason for the Pro reason. So MCUXpresso is still free, and if you want to have direct support for $495, then you can get.
        Erich

        Like

  4. Thanks Erich. Do you know anything about the upcoming Peripherals Tool for MCUXpresso (“coming 2017”) ? I’m wondering if it’s worth waiting for that, for more ‘native’ project support than going down the “hack PE into MCUXpresso” path. PE seems fairly nice to use, and I wonder what advantage Peripherals Tool will give us.
    Cheers

    Like

    • Hi Rhys,
      there is little information about this present on http://www.nxp.com/products/software-and-tools/run-time-software/mcuxpresso-software-and-tools:MCUXPRESSO?tid=vanmcuxpresso. I expect it to be very similar as the Pins and Clocks tool, that it will have a graphical user interface to configure the peripherals like UART, SPI, I2C, ADC, etc, basically providing configuration functions and structures as the Pins and Clocks tool. Long term that seems to me the only way to go. Using PE in MCUXpresso won’t be supported by NXP, and my primary motivation is to have something until that Peripherals tool will be out, plus having a way to migrate and continue to use my existing projects inside MCUXpresso. The benefit I see with PE compared with the existing Pins and Clocks is that PE is integrated in Eclipse, so provides a seamless integration and development flow. The advantage of the Peripherals tool will be that it should support out of the box all the SDK supported parts.
      I hope this helps,
      Erich

      Like

  5. Pingback: MCUXpresso IDE: Installing Processor Expert into Eclipse Neon | MCU on Eclipse

  6. Pingback: MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse

  7. Pingback: MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse

  8. Pingback: MCUXpresso IDE: Adding the Eclipse Marketplace Client | MCU on Eclipse

  9. There’s something wrong with my ‘Kinetis Design Studio 3 IDE’.When i debug,it says
    “Error with command: gdb –version
    Cannot run program “gdb”: Launching failed”
    can you help me with this.Thanks a lot

    Like

    • Have you used the ‘green’ or the ‘blue’ debug button? For the ‘blue’ one it should autodetect the probe. If you are using the ‘green’, then you need to make sure that you have a launch configuration, and the that the path to the gdb executable is valid. Usually ${cross_prefix}gdb${cross_suffix} is used as gdb execuable. You can try temporarily an absolute path to the arm-none-eabi-gdb.exe. Or setup your paths/variables to point to the correct gdb.

      Like

  10. I have several KSDK2.0 projects so for me porting them to MCUXpresso and MCUXpresso SDK’s would be my prefered approach. It would be awesome if there was a way to do that with a few mouse clicks. In reality it looks like I would almost need to recreate the projects and only copy the application code over to the new project. Is there a simpler / faster way, thats provided by NXP?

    Like

    • Hi Chad,
      my current approach for a ‘native’ port is indeed to create a new project and then move the application files over. That seems to work very well and guarantees that the ported project is ‘clean’. Any kind of fancy importers or conversion wizard have worked for me in the past for very simple projects only.

      Like

  11. Hello Erich,
    thanks a lot for this post.
    How can you choose correct .cfx file?

    For example on KE02 there’s no SDK support, so how can I create a project from scratch for that micro?

    If I liked to use the newest gcc version, would you advise me to use MCUXpresso or Eclipse Neon DIY for that micro?
    Anyway in both cases I don’t know how to get the plugin for the project wizard.

    Thank you very much indeed for your support.

    Best Regards
    Roberto

    Like

    • Hi Roberto,
      the plugin to create new projects for Processor Expert (and as well non-Processor Expert) is part of the Processor Expert bundle. So you have to install Processor Expert for this.
      I hope this helps,
      Erich

      Like

  12. Does that approach work for KDS KSDK v2 projects? I didn’t understand very well the part that you talked over toolchain update. Is MCUXpresso GNU toolchain version different from KDS’s? What if I keep the GNU toolchain as default both in KDS and MCUXpresso?

    Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s