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.
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:
- MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers
- MCUXpresso IDE: S-Record, Intel Hex and Binary Files
- MCUXpresso IDE: Adding the Eclipse Marketplace Client
- MCUXpresso IDE: Importing Kinetis Design Studio Projects
- MCUXpresso IDE: Installing Processor Expert into Eclipse Neon
- MCUXpresso IDE: Terminate and Disconnect a Debug Session
- MCUXpresso IDE: Blinky the NXP LPC800-DIP Board
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:
- 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.
- 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.
- 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:
- KDS projects using Kinetis Design Studio V3.2.0
- MCUXpresso IDE V10.0.0 build 344
- GNU ARM Embedded Toolchain v6-2017-q1
- GNU ARM Eclipse Build tools v2.8-201611221915
- GNU ARM Eclipse plugins v3.3.1-201702251311
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:
I recommend to download the installer and run the setup with the default settings:
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 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
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:
- Eclipse Marketplace (preferred)
- Install new Software
💡 Latest GNU ARM (now MCU) Eclipse plugins starting with v4.1.1 require CDT 8.2.1. MCUXpresso IDE uses CDT 8.1, so it will not install the latest version. Instead, go to the releases download page (https://github.com/gnu-mcu-eclipse/eclipse-plugins/releases) and download the GNU ARM Eclipse plug-ins v3.4.1-201704251808 and install that zip file using the menu Help > 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:
Search for the plugin and install it:
I recommend to install all plugins: that way it is possible to create and debug any ARM Cortex-M projects (beyond NXP):
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).
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.
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…’:
💡 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:
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):
Opening the project properties, the settings should show up as in KDS:
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:
The toolchain shall show up as ‘GNU Tools for ARM Embedded Processors‘ in the 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:
💡 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:
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
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):
Build
Yet again, us the Quickstart panel to build the project (or use the menu Project > Build):
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:
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:
The screenshot below shows some debug configurations in my workspace:
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:
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:
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):
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.
Otherwise, I get the automatic probe discovery dialog:
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):
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
- MCUXpresso IDE web page: http://www.nxp.com/mcuxpresso/ide
- MCUXpresso IDE community: http://www.nxp.com/mcuxpresso/ide/forum
- MCUXpresso Config tools and SDK: https://mcuxpresso.nxp.com/
- GNU ARM Embedded Toolchain: https://launchpad.net/gcc-arm-embedded
- GNU ARM Eclipse: http://gnuarmeclipse.github.io/
- GNU ARM Eclipse plugins: http://gnuarmeclipse.github.io/developer/releases/
- GNU ARM Eclipse build tools: http://gnuarmeclipse.github.io/windows-build-tools/install/
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. 😦
LikeLike
I have mixed feelings about the SDK 1.3. While as you say it has Processor Expert support, the SDK 1.3 itself is not easy to use. From that perspective, the SDK v2 is much better. But as you say, there is no Processor Expert support by NXP. What I’m doing is to use at least my own components with the SDK v2 (see https://mcuoneclipse.com/2017/03/25/tutorial-using-eclipse-with-nxp-mcuxpresso-sdk-v2-and-processor-expert/).
LikeLike
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.
LikeLike
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
LikeLike
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
LikeLike
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?
LikeLike
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
LikeLike
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
LikeLike
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
LikeLike
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
LikeLike
Pingback: MCUXpresso IDE: Installing Processor Expert into Eclipse Neon | MCU on Eclipse
Pingback: MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse
Pingback: MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse
Pingback: MCUXpresso IDE: Adding the Eclipse Marketplace Client | MCU on Eclipse
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
LikeLike
That means it cannot find the gdb executable. For me it is in
C:\nxp\KDS_3.2.0\Toolchain\bin\arm-none-eabi-gdb.exe
LikeLike
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.
LikeLike
Sorry for reply you that late and thanks for your help.
I check my gdb.exe.It is in the right place.I can also run it successfully.I think maybe it the path problem.I have tryed to change the path as you said.It did’nt work.By the way,i have asked my teacher about this problem,he says it can not solved and try more time it will be ok.However,it’s not okay at all.Hope you can tell me about how to change the path correctly so that i can try.Thanks a lot~
LikeLike
Ih meko,
with such little information, I really cannot help much. What is your host platform (Windows)? What is your debug interface (P&E? Segger?). What are your launch configuration settings? Have you created a project for KDS V3.2.0 with the wizard (as this will create a workign version for you). Have you updated the Segger and P&E plugins already?
That error message really means that the GDB executable is not found. Maybe you made a mistake in the path. Or your firewall is blocking access to it (try disable virus scanner/firewalls).
Maybe check https://mcuoneclipse.com/2016/03/11/solving-launching-configuring-gdb-aborting-configuring-gdb/.
I hope this helps,
Erich
LikeLike
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?
LikeLike
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.
LikeLike
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
LikeLike
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
LikeLike
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?
LikeLike
Hi Marco,
this is something I have started an article about. It basically means to port the project from the KDS build system to the MCUXpresso build system. I have done this with a) creating a new project in MCUXpresso and then b) moving over the application source code.
LikeLike
In a nutshell, you mean that I have to use approach 3. In this article, you are showing approach 1, right? With approach 3, it wouldn´t be necessary the installation of GNU ARM Eclipse Tools and the settings described in this article, right?
LikeLike
Hi Marco,
yes, that’s correct.
Erich
LikeLike
Thank you, Erich
For Processor Expert projects done in KDS, it it possible to import PE settings (.pef file) to MCUXpresso, like it was possible from CodeWarrior to KDS (except for CPU bean)?
What is the best approach in this case?
LikeLike
Hi Marco,
I have not used .pef files at all, but I don’t see any reason why the same would not work for MCUXpresso. As for Processor Expert, see https://mcuoneclipse.com/2017/04/09/mcuxpresso-ide-installing-processor-expert-into-eclipse-neon/.
What I’m using (and what might be the best approach for you) is to copy the .pe file from the KDS project, or if you have KDS open, copy-paste the component from KDS to MCUXpresso (see https://mcuoneclipse.com/2014/10/26/export-and-import-processor-expert-component-settings/ and https://mcuoneclipse.com/2013/03/31/copy-of-processor-expert-components/)
LikeLike
Pingback: Using Eclipse to Program Binary Files to an Embedded Target | MCU on Eclipse
Pingback: MCUXpresso IDE: Terminate and Disconnect a Debug Session | MCU on Eclipse
Pingback: MCUXPresso IDE: Blinky the NXP LPC800-DIP Board | MCU on Eclipse
Thanks Erich as always. Question though about migrating a project from KDS with GCC 4.8.4 to new GCC 6.x: What about the runtime library? KDS had horribly misconfigured newlib (free storage problems; you’ve seen https://community.nxp.com/thread/441637). What do you recommend? Has NXP fixed the problems with newlib? Or, use redlib instead?
Thanks!
Best Regards, Dave
LikeLike
Usually I don’t use newlib at all, and otherwise I have used newlib-nano without issues in the past. However, I rarely use functions or the heap management of it: most of my applications are using FreeRTOS, and it comes with a better and thread aware heap manager. And as for printf() and the other things, I avoid them whenever I can (see https://mcuoneclipse.com/2013/04/19/why-i-dont-like-printf/).
As for my ported KDS projects to MCUXpresso I have mostly used newlib-nano, for a few as well RedLib.
I hope this helps,
Erich
LikeLike
sprintf (for text formatting) drags in free storage in newlib (newlib-nano ?) as was distributed with KDS, hence the repeated questions about why sprintf of float number doesn’t work in KDS forum. And newlib free storage is not thread-safe unless properly configured (which it wasn’t despite newlib provisions for this)…
Anyway, what libraries does the GCC 6 package you explain above include, and which do you recommend to avoid free-storage issues?
Thanks Erich!
LikeLike
Hi Dave,
as I avoid sprintf(), it seems that I have not seen that issue :-). I’m using xprintf() instead (https://mcuoneclipse.com/2014/08/17/xformat-a-lightweight-printf-and-sprintf-alternative/), much smaller, faster and does not expose such kind of problems. And I’m using XFormat, see https://mcuoneclipse.com/2017/05/06/mcuoneclipse-components-06-may-2017-release/.
LikeLike
Apologies Erich, I didn’t start from the beginning…
1) As normal for professional developers, we want to, as much as possible, use language-defined standard libraries and tools.
2) sprintf is frequently used in our applications to format output data (not printf for debugging!).
3) FreeRTOS is used for many (these days, most) of our products.
4) To help ensure robust embedded products, we do not use malloc/free (nor FreeRTOS equivalents), except for initial setup.
5) newlib internally uses malloc/free family, in particular within printf family floating point
6) newlib requires external configuration of heap location and boundaries, and also provides facilities for OS-aware free storage (locking etc). Freescale failed to provide proper setup of either in KDS tool chain and examples (quite a fiasco, illustrated in the trivial example I linked above).
So…. I did look at your printf alternates, but again we really want to use complete mainstream implementations, implemented per language specifications, and hopefully supported by the vendor. We’d also like to use current GCC as you’ve recommended. But I’m wondering if you’ve researched:
a) do any of the library variants you mentioned completely avoid internal use of malloc/free? redlib?
b) if the libraries do use malloc/free internally, are they properly configured to avoid above fiasco?
c) where are the configurations used to build the circulated libraries documented?
If you haven’t dug into this I’ll make sure to let you know what I can find out…
Thanks as always!
Best Regards, Dave
LikeLike
I understand your point about using the standard libraries. But even sprintf() should be avoided as it can easily cause a buffer overflow. That’s why it is banned from many application types (safety or medical applications), so better use your own/safe variant instead. At least this is what I’m doing. And then you know its internal dependencies.
And yes, the variants I have mentioned completely avoid any dynamic memory allocation. I have not looked into details how newlib/redlib implement the snprintf() and variants, because as said above I’m not using it and I’m not trusting it.
I hope this helps,
Erich
LikeLike
Thanks for the helpful guide on porting KDS projects to MCUXpresso. This helped me a great deal.
As far as I can tell, the newest release of GNU MCU Plugin (4.1) is incompatible with MCUXpresso IDE 10.0.2. (At least, I spent several hours poking at it and gave up in frustration.) Eclipse installation problems are something of a black art, but I think the underlying issue is that GNU MCU Plugin 4.1 requires CDT 9.2, but MCUXpresso uses CDT 9.1 and it cannot be uninstalled or upgraded.
However, the older version of GNU MCU Plugin, 3.4, installed with no drama at all, once I gave up trying to install 4.1
LikeLike
Yes, indeed it needs CDT 9.2.1:
Missing requirement: GNU MCU C/C++ Core 4.1.1.201707111115 (ilg.gnumcueclipse.core 4.1.1.201707111115) requires 'bundle org.eclipse.cdt 9.2.1' but it could not be found
It seems there has been a lot of changes on GNU ARM (now MCU) Eclipse.
As you I was able to get the 3.4.1 installed (downloadable from https://github.com/gnu-mcu-eclipse/eclipse-plugins/releases => ilg.gnuarmeclipse.repository-3.4.1-201704251808.zip)
I have updated the article about this, so thanks for pointing this out!
LikeLike
Pingback: Tutorial: Porting BLE+NRF Kinetis Design Studio Project to MCUXpresso IDE | MCU on Eclipse
Hi, Erich,
I’ve succeeded in install the and GNU ARM Eclipse Plug and Processor Export within MCUXpresso, And import a project (KDS PE project), everything was OK, but when I build project, I got the error as following:
——
make all
Building file: ../Static_Code/System/CPU_Init.c
Invoking: Cross ARM C Compiler
arm-none-eabi-gcc -mcpu=cortex-m0plus -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -I”C:/Users/robert/Documents/MCUXpressoIDE_10.1.1_606/workspace/Ke06Motor/Static_Code/System” -I”C:/Users/robert/Documents/MCUXpressoIDE_10.1.1_606/workspace/Ke06Motor/Static_Code/PDD” -I”C:/Users/robert/Documents/MCUXpressoIDE_10.1.1_606/workspace/Ke06Motor/Static_Code/IO_Map” -I”C:\NXP\MCUXpressoIDE_10.1.1_606\ide\ProcessorExpert/lib/Kinetis/pdd/inc” -I”C:/Users/robert/Documents/MCUXpressoIDE_10.1.1_606/workspace/Ke06Motor/Sources” -I”C:/Users/robert/Documents/MCUXpressoIDE_10.1.1_606/workspace/Ke06Motor/Generated_Code” -std=c99 -MMD -MP -MF”Static_Code/System/CPU_Init.d” -MT”Static_Code/System/CPU_Init.o” -c -o “Static_Code/System/CPU_Init.o” “../Static_Code/System/CPU_Init.c”
make: *** [Static_Code/System/CPU_Init.o] Error -1073741502
———-
How could I do to fix it?
Thanks
Robert
LikeLike
I have not seen such a thing yet and that error code. From the command line nothign looks wrong. Does it happen only for CPU_Init.c or other files too? You might temporarily exclude CPU_Init.c (see https://mcuoneclipse.com/2014/07/22/exclude-source-files-from-build-in-eclipse/) to check if it is a general problem or isolated to that source file.
I hope this helps,
Erich
LikeLike
Hi Erich,
i am trying to import my old project which using KDS 2.0.0 to MCUXpresso, i installed same version of GNU ARM Eclipse and plugins used in KDS2.0.0, follow your guide, after i import the project to MCUXpresso, i fail to clean, detail below:
Cannot run program “make”: Launching failed
Error: Program “make” not found in PATH
PATH=[C:/nxp/MCUXpressoIDE_10.2.1_795/ide/jre/bin/client;C:/nxp/MCUXpressoIDE_10.2.1_795/ide/jre/bin;C:/nxp/MCUXpressoIDE_10.2.1_795/ide/jre/lib/i386;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\nxp\MCUXpressoIDE_10.2.1_795\ide]
by the way, i didn’t see tools path in the project settings of latest MCUXpresso, not sure why?
Thanks in advance.
LikeLike
Hi Ting,
yes, it seems that the Tools Path entry is indeed not present any more (I did not notice).
Can you check your global tools path (menu Window > Preferences, then MCU > Global Build Tools Path) that it points to the make utility?
My setting is:
C:/Program Files (x86)/GNU ARM Eclipse/Build Tools/2.8-201611221915/bin
I hope this helps,
Erich
LikeLike
Hi Erich,
there is no global tool path on my MCUXpresso (menu Window > Preferences, then MCU > Global Build Tools Path)
and i also can’t see Tool Paths item on Properities->C/C++ build.
But i really install it in C:\Program Files\GNU MCU Eclipse\Build Tools\2.9-20170629-1013
LikeLike
I do have this present:
Window > Preferences > MCU > Global Build Tools Path
But I think I saw it not present in another plugin version, but now it is there.
Here is what I have installed:
GNU MCU C/C++ ARM Cross Compiler 2.6.3.201807211108 ilg.gnumcueclipse.managedbuild.cross.arm.feature.feature.group Liviu Ionescu
GNU MCU C/C++ Documentation (Placeholder) 1.1.2.201807211108 ilg.gnumcueclipse.doc.user.feature.feature.group Liviu Ionescu
GNU MCU C/C++ Freescale Project Templates 2.2.9.201807211108 ilg.gnumcueclipse.templates.freescale.feature.feature.group Liviu Ionescu
GNU MCU C/C++ Generic Cortex-M Project Template 1.4.4.201807211108 ilg.gnumcueclipse.templates.cortexm.feature.feature.group Liviu Ionescu
GNU MCU C/C++ J-Link Debugging 4.3.3.201807211108 ilg.gnumcueclipse.debug.gdbjtag.jlink.feature.feature.group Liviu Ionescu
LikeLike
Hi Erich,
Because i use KDS2.0, so i installed very old version which is same as KDS2.0.0, as below:
GNU ARM C/C++ Cross Compiler Support 1.10.2.201407190854 ilg.gnuarmeclipse.managedbuild.cross.feature.group Liviu Ionescu
GNU ARM C/C++ Freescale Project Templates 2.1.1.201407190854 ilg.gnuarmeclipse.templates.freescale.feature.group Liviu Ionescu
GNU ARM C/C++ Generic Cortex-M Project Template 1.1.1.201407190854 ilg.gnuarmeclipse.templates.cortexm.feature.group Liviu Ionescu
GNU ARM C/C++ STM32Fx Project Templates 2.1.1.201407190854 ilg.gnuarmeclipse.templates.stm.feature.group Liviu Ionescu
GNU ARM Packs Support (Experimental) 1.1.1.201407190854 ilg.gnuarmeclipse.packs.feature.group Liviu Ionescu
Can i use your version in KDS2.0, Will there be conflict?
LikeLike
Hi Erich,
I tried to install your version, the good thing is that the old error gone away, i can clean the project, but once i build it, it report new issue,
make all
‘Building file: C:/Freescale/KDS_2.0.0/eclipse/ProcessorExpert/lib/Kinetis/pdd2/MKE06Z128LK4/system/CPU_Init.c’
‘Invoking: Cross ARM GNU C Compiler’
arm-none-eabi-gcc -mcpu=cortex-m33 -mthumb -O2 -g -std=gnu11 -MMD -MP -MF”Static_Code/System/CPU_Init.d” -MT”Static_Code/System/CPU_Init.o” -c -o “Static_Code/System/CPU_Init.o” “C:/Freescale/KDS_2.0.0/eclipse/ProcessorExpert/lib/Kinetis/pdd2/MKE06Z128LK4/system/CPU_Init.c”
‘arm-none-eabi-gcc’ is not recognized as an internal or external command,
operable program or batch file.
make: *** [Static_Code/System/CPU_Init.o] Error 1
Is it because the version I installed is inconsistent with KDS2.0?
LikeLike
it has nothing to do with which version of KDS. Your problem is that MCUXpresso IDE does not find the compiler (arm-none-eabi-gcc).
Check your settings/path in Window > Preferences > MCU > Global ARM Toolchains
I hope this helps,
Erich
LikeLike
Thanks Erich, I can finally compile now, but I run into the last compiling problem,
arm-none-eabi-g++: error: unrecognized command line option ‘-nanolibc’
do you know how can i have MCUXpresso support this lib?
LikeLike
The -nanolibc option is one for an old GNU ARM toolchain. It has been changed later to –specs=nano.specs if you are using the MCU Eclipse plugins.
LikeLike
And, once i remove -nanolibc, there is new complier error:
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r’:
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-writer.o): In function `_write_r’:
writer.c:(.text._write_r+0x10): undefined reference to `_write’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-closer.o): In function `_close_r’:
closer.c:(.text._close_r+0xc): undefined reference to `_close’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-fstatr.o): In function `_fstat_r’:
fstatr.c:(.text._fstat_r+0xe): undefined reference to `_fstat’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-isattyr.o): In function `_isatty_r’:
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-lseekr.o): In function `_lseek_r’:
lseekr.c:(.text._lseek_r+0x10): undefined reference to `_lseek’
c:/program files/gnu tools arm embedded/4.8 2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m\libg.a(lib_a-readr.o): In function `_read_r’:
readr.c:(.text._read_r+0x10): undefined reference to `_read’
collect2.exe: error: ld returned 1 exit status
make: *** [UVMonitoring.elf] Error 1
LikeLike
Have you added -specs=nosys.specs to the linker options already?
LikeLike
Erich,I tried to use –specs=nano.specs and -specs=nosys.specs, and it can be successfully compiled by using -specs=nosys.specs. Thanks so much!! is this new toolchain in MCUXpresso?
LikeLike
Glad to hear it is working for you! MCUXpresso uses an even more modern GNU toolchain. The NXP recommendation is to use MCUXpresso IDE as this is the recommended IDE and toolchain for all Kinetis/LPC parts.
LikeLike
Does this PE file support FRDM k64F?
LikeLike
Not sure if I understand your question. But Processor Expert does support the FRDM-K64F board, yes.
LikeLike
Erich, first of all, thank you for all the work you do for the embedded community. I have seen your name appear so many times! I would not bother you if I hadn’t tried everything, but I wonder if you can help. I used KDS for a few years before I retired from teaching college, and now want to get back into the genre at home using my home computer. I saved all my KDS projects and have tried following your instruction above but still no worky! I am getting make: *** No rule to make target ‘all’. Stop.
Obviously I am missing a step somewhere, but I can’t see it. Can you help?
The project worked fine the last time I used it under KDS. I want to move forward and don’t have space in my root partition for both KDS and mcuexpresso!
I am using the latest downloaded version of mcuexpresso, under SuSE LEAP 15.0
Thanks in advance, Nigel
LikeLike
Hi Nigel,
not sure if your problem is SuSE a I believe this is not officially supported? The ‘no rule to make target’ basically means it does not find the make file or the make/makefile is missinig.
I recommend you create a new project with the KDS wizard and check if this works. If it does, it is a problem with your project itself and not the host system.
LikeLike
It wasn’t SuSE, Eric. I deleted all instances of eclipse and mcuexpresso config files and re-installed KDS. I still got the same problem from that saved project so I guess it was not saved correctly. After symlinking to use the prior version of udev I can compile and debug using CMSIS-DAP just fine, so I will cut and paste the code into the new project. I don’t need to live on the bleeding edge, for now anyway 🙂
Thanks, Nigel
LikeLike
Hi Nigel,
ok, thanks for closing the loop!
Erich
LikeLike