62 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. 😦

   LikeLike

   Reply ↓

   • 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

     Reply ↓

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.

   LikeLike

   Reply ↓

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

   LikeLike

   Reply ↓

   • 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

     Reply ↓

     • 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

       Reply ↓

     • 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

       Reply ↓

       • 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

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

   LikeLike

   Reply ↓

   • 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

     Reply ↓

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

   LikeLike

   Reply ↓

   • 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

     Reply ↓

   • 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

     Reply ↓

     • 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

       Reply ↓

       • 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

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?

    LikeLike

    Reply ↓

    • 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

      Reply ↓

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

    LikeLike

    Reply ↓

    • 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

      Reply ↓

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?

    LikeLike

    Reply ↓

    • 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

      Reply ↓

      • 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

        Reply ↓

        • 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

13. Pingback: Using Eclipse to Program Binary Files to an Embedded Target | MCU on Eclipse

14. Pingback: MCUXpresso IDE: Terminate and Disconnect a Debug Session | MCU on Eclipse

15. Pingback: MCUXPresso IDE: Blinky the NXP LPC800-DIP Board | MCU on Eclipse

16. 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

    Reply ↓

    • 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

      Reply ↓

      • 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

        Reply ↓

        • 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

17. 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

    Reply ↓

    • 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

      Reply ↓

18. Pingback: Tutorial: Porting BLE+NRF Kinetis Design Studio Project to MCUXpresso IDE | MCU on Eclipse

19. 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

    Reply ↓

    • 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

      Reply ↓

20. 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

    Reply ↓

    • 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

      Reply ↓

      • 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

        Reply ↓

        • 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

      Reply ↓

      • Have you added -specs=nosys.specs to the linker options already?

        LikeLike

        Reply ↓

        • 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

21. Does this PE file support FRDM k64F?

    LikeLike

    Reply ↓

    • Not sure if I understand your question. But Processor Expert does support the FRDM-K64F board, yes.

      LikeLike

      Reply ↓

22. 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

    Reply ↓

    • 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

      Reply ↓

23. 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

    Reply ↓

    • Hi Nigel,
      ok, thanks for closing the loop!
      Erich

      LikeLike

      Reply ↓

This site uses Akismet to reduce spam. Learn how your comment data is processed.