49 thoughts on “Eclipse MCUXpresso IDE 10.1 with integrated MCUXpresso Configuration Tools”

1. Thanks for the writeup, very informative as always. Looking forward for the report on the iMX RT kit :).

   LikeLike

   Reply ↓

2. MKL27Z256xxx doesn’t seem to be supported in the peripherals tool.
   Changing packages in the pins tool causes an error that doesn’t go away even though the correct package is shown.
   Seem to be no way to disable debug console when using the new project wizard.

   LikeLike

   Reply ↓

   • Hi Brad,
     I quickly checked, and indeed it seems that only MKL27Z32xxx4 and MKL27Z64xxx4 seem to be supported in the peripherals tool today. As the data files are stored on a server, I hope/expect that more parts will be supported going forward.

     LikeLike

     Reply ↓

   • Hi Brad, not sure which debug console you mean?

     LikeLike

     Reply ↓

3. Thanks for posting! You already heard my discovery about how the new version breaks Processor Expert, so I’m probably not going to be able to use the new tools for a little bit. I’m using the standalone clocks tool and the graphical interface is something that’s been needed for a long time – and I like that it’s pretty good about telling you what consumes each clock. I hope someday they can expand that diagram to show peripheral clocks.

   The i.MX RT is interesting but what I want is more powerful low pin count devices. Atmel has a 300 MHz Cortex-M7 in a 64-pin LQFP that I’ve been drooling over. I keep hoping NXP will put out something to match it. BGA packages are tough for small volume applications, and I need board flex and vibration tolerance. My dream part would be a 48-LQFP with a bunch of fast serial interfaces and as much RAM as can be crammed in there, but I don’t see that happening anytime soon.

   I know you don’t like printf(), but I’ve gone the other direction with a couple of my bigger projects. My serial debug console has a bunch of performance tweaks, prints timestamps intelligently without cluttering up the display, shows the FreeRTOS task each line came from, and uses ANSI color codes. I love it. I’d never use it on a small project, but its great for complex systems where you really need to be able to see the complete sequence of events.

   LikeLike

   Reply ↓

   • Maybe I should have been more specific about my printf() rant: The rant is about the standard library printf() which is bloated, usually allocates tons of memory and the main reason for stack overflows. What I’m using in my projects is a more embedded microcontroller friendly version of printf: https://mcuoneclipse.com/2014/08/17/xformat-a-lightweight-printf-and-sprintf-alternative/

     About the lower pin count packages: yes, I share the same desire: BGA devices are really nasty, so a small breakout board which could be soldered on another board would be an option. That EVB board is reather expensive and huge, I’m wondering if someone will come up with a smaller and more affordable version so it could be used in a low volume production run.

     LikeLike

     Reply ↓

4. Many thanks for this article Erich. I hope these guys are paying you for this; you’re a great evangelist for their tools.
   Looking forward to porting an PE project into MCUX soon! 🙂

   LikeLike

   Reply ↓

5. Cool. Getting usable now. I’ll think about doing a project in it now that it’s got some closure. Of course, the problem now is porting your stuff into it 😉

   This is bundling FreeRTOS (V9) in it. Do you know if they’ve put the hooks for any of the RTOS trace tools in there? If so which one(s)? I see they have a middleware option of emWin now (They push this on some LPC parts) which would lead me to think they might have put the Segger hooks into it.

   LikeLike

   Reply ↓

   • Hi Randy,
     it provides hooks for FreeRTOS+Trace, means you can use it with Segger SystemView and Percepio tracealyzer. But the first thing I usually do is to replace the FreeRTOS version in the SDK with the McuOnEclipse one, as that port includes several fixes and extensions, plus enabling trace is a matter of turning on a define in the configuration. I have it running now as well on FreeRTOS v10 (see https://mcuoneclipse.com/2017/12/09/new-freertos-v10-0-0-amazon-segger-systemview-and-percepio-tracealyzer/) while the SDK still is on the older v9.

     LikeLike

     Reply ↓

     • sounds like a plan to me… thanx!

       LikeLike

       Reply ↓

6. Hello, Erich

   Congratulations! Such a great article! I’m a Processor Expert fan, but I think there is no way for NXP to come back to it, since SDK Peripherals Tool completes the set of code initialization tools and no doubt that SDK generates less init code compared to Processor Expert, although it does not have the famous, convenient and helpful “Methods”, but the SDK API is well documented and is not difficult to use and understand.

   What is the best method to use complex stacks like USB or LWIP, for example? I still see that, for such cases, the easiest way to go is to clone a demo code, reuse it and modify it according to the application. Clock, Pins and Peripherals Tools still can be used in these cases, but in a template project and then you can copy and paste the generated code.

   LikeLike

   Reply ↓

   • I’m not sure I agree with the ‘well documented’ assertion. My experience has been that the documentation is inconsistent in quantity and quality, ugly (it’s all auto-generated from Doxygen or a similar tool with little cleanup), and the in-documentation examples can’t be trusted.

     I think the biggest problem is that the level of detail provided in the documentation is not consistent with the level of abstraction provided by the components. For a simple example, take the WDOG chapter. It neglects to say what the watchdog timer is or what it does, what modes it works in, what the lock mechanism is, or how the windowing works.

     At the moment I want to set up the WDOG so that it doesn’t run in STOP mode. The API docs say there’s a boolEnableStop field in struct wdog_work_mode_t that “Enables or disables WDOG in stop mode.” Is that “enable the WDOG to run in stop mode” or “enable the WDOG to enter stop mode”? PEx has had this ambiguity before, where ‘enable DMA in debug mode’ enables the disable flag, or vice versa.

     Next, where does wdog_work_mode_t go? We have to skim through the section to see that it’s a member of struct wdog_config_t, then we have to scroll back up a page or two to see that WDOG_Init() takes a wdog_config_t parameter.

     If you’re already intimately familiar with the hardware, you can look at the examples and use the docs as a reference to work backwards to help figure out what’s going on, but you’d go insane trying to write something from scratch using only the API docs.

     Doxygen is a great tool for producing documentation if you take the time to actually add information and structure things appropriately. I think the main thing the API documentation accomplishes is giving the appearance to management that there’s a lot of documentation, when it’s mostly useless fluffl like “enum wdog_clock_prescaler_t { kWDOG_ClockPrescalerDivide1 = 0x0U, kWDOG_ClockPrescalerDivide2 = 0x1U, …}” – obvious, useless, and it doesn’t tell you where it goes.

     This isn’t a new phenomenon. I started a job 20 years ago where I inherited bookcases of CDRL-mandated documentation binders that were just this sort of auto-generated junk. I doubt any developer on that system had ever referred to them. But at least they weren’t presented to the end user as legitimate documentation.

     LikeLike

     Reply ↓

     • I have to agree with you. Doxygen in general gives lousy documentation largely because the people who are writing the code (who put the stuff that doxygen uses) aren’t the right people to write user facing documentation. And you really don’t want that level of crap in your source files anyway.

       What you get is basically a 30,000ft (or M) view of the structure of the code without actually telling you anything about how to use it. What it means is that you have to be able to go to the code to figure out what it’s doing really anyway. But you can at least get pointed to the existence of it (if that’s all you get).

       LikeLike

       Reply ↓

       • Doxygen is a great tool to explore ‘unknown’ code, but only if it has decent comments too. Just running doxygen over a bunch of files with useless comments does not generate anything useful, I agree. In the past there were dedicated documentation teams which have put together good documentation (for me, the HC11 documentation was one of the best ever). These days everything seems to be a copy-paste of older reference manuals, and API documentation is minimal or only the one writing the API might be able to understand it 😦

         LikeLike

     • I should have been more clear about the documentation (will update that part): I was referring to the IDE and config tools documentation, not to the SDK documentation. The SDK documentation indeed looks more like a bunch of minimal doxygen generated documentation (nothing against doxygen, but if it is used for’having some documentation is better than having no documentation’ there is indeed no value). The series by Jay Carlson (see https://mcuoneclipse.com/2017/11/19/exploring-a-microcontroller-and-software-and-tools-for-the-next-project/) has some insights on this aspect too.

       LikeLike

       Reply ↓

7. I am pleased that the Kinetis KE0x family is now supported in MCUxpresso, as well as the KE1x; this means we should be able to use a single IDE for all our current projects.
   However, so far I’ve spent 1-1/2 days getting a working KDS KE06Z project just to compile under MCUxpresso – admittedly part of that was the CMSIS / register changes, but there’s so much difference in the two IDEs it’s incredible!
   Maybe simple projects are not so hard, but our projects have a proprietary bootloader which means the actual project needs to link that bootloader code, be relocated in FLASH, have a checksum added, and many other requirements that are challenging with the managed script and other IDE changes.
   And then there’s all the “slightly different version features / bugs” – for example I’ve just discovered that a copyright text string is being optimized out in the 10.1, but it wasn’t in the 10.0 MCUxpresso! I’ve had to add “–require-defined=OPERATIONALcopyright” to the linker commands to resolve it.

   I guess this is why I rarely ever update my software tools, once they are working.

   LikeLike

   Reply ↓

   • Same story here – changing tools is a lot of pain. I’ve also got a copyright string (plus a hidden version in case anyone skims through with a hex editor) and as a cross-platform fix I just memcpy it into a RAM buffer at startup so it’ll never get deadstripped.

     LikeLike

     Reply ↓

     • I think this is because of the new GNU toolchain. That the linker dead-strips unused objects has been a struggle all the time with the GNU linker, and the ‘used’ attribute does not help in all cases. Artificially using things (e.g. using it with a pointer) is one way to deal with it.

       LikeLike

       Reply ↓

   • Probably it is the linker which removes some objects you are not using? Might be because the compiler/linker version is upgraded.

     LikeLike

     Reply ↓

     • I’ll have to keep an eye out for that dead stripping if the behavior has changed from CW10. I use an auto-start mechanism in some of my projects, where a macro adds an entry for a module’s entry point to a special section and the startup code scans the section and calls all of the auto-start functions. The linker has to be able to force inclusion of all objects in that section. I was never able to do that automatically with the HCS08 linker.

       I use the same mechanism for my shell commands. Each shell function is declared using a macro that adds its name, function pointer, options, and description to a table. It lets me make the shell modular without a lot of defines – if I want file manipulation commands in my shell, I just add the appropriate .c file to the project and they get linked in and show up in the ‘help’ list. So far it all seems to be working in MCUX, but I’m not using the same toolchain for all projects.

       LikeLike

       Reply ↓

       • It definitely has changed from CW10. This has been always kind of floating in the gcc compiler versions, and CW10 is using a really old one. The later GCC versions are much more agressive.
         Btw, nice and cool way to build up a shell!

         LikeLike

8. Oh … and why is there a tiny little exclamation indicator on the project icon in project explorer? It looks like it’s giving me a warning, but I can’t see any way to query and find out what is wrong 😦

   LikeLike

   Reply ↓

   • Not sure. I wrote something about these icon decorators in general here: https://mcuoneclipse.com/2012/07/30/icon-and-label-decorators-in-eclipse/
     There is an icon decorator in case the MCU is not assigned in the project. Plus if you import a project, you have to have the SDK for it installed, otherwise it will complain about it too.
     Maybe this is the case here?

     LikeLike

     Reply ↓

9. Erich,
   Do you know about how the linkscript/etc decides the name for the files it creates? I made an original “TEST2” project, later renamed the project within MCUXpresso, later copied to a new project, different name … but that “TEST2” still lingers in the build file names!
   example: TEST2_PGTbuild_memory.ld

   I’ve explored all the settings I can within MCUXpresso and can’t find where to change it (I suppose I could edit the “.project” files but I don’t really want to do that)

   LikeLike

   Reply ↓

   • Hi Ian,
     it seems it takes it from the project name plus the configuration name. You can see the name it is using inside the project settings: Project > Properties > C/C++ build > Settings > Tool Settings > MCU Linker > Managed Linker Script.
     If I rename the project and do a Project > Clean, that file name gets changed to for me.

     LikeLike

     Reply ↓

     • Thanks Erich. You’re right I see the name there but it appears that it’s not “always” what is used. One project I just checked showed the desired name but was still using TEST2… as the actual name – even doing “clean”, deleting the TEST2 build files and then building, just re-created the TEST2 files.
       I just toggled off / on the “use managed linker”, and that project now is using the name it says it would use – no idea if that is a fix every time but at least I have somewhere to check and try now.

       It’s so much easier to copy / paste an existing project than to create from empty every time, and it so nearly works perfectly – it’s just a bit hard to discover the places where it doesn’t quite work 😉

       LikeLike

       Reply ↓

10. Hello, Erich

    I just installed MCUXpresso v. 10.1.0 to play with Config Tools. I don’t know why Peripherals Tool does not appear for me (only peripherals.c and peripherals.h files). I have MCUXpresso v. 10.0.2 installed in my computer as well as SDK v. 2.2. When I first opened MCUXpresso v. 10.1, all SDK v. 2.2 that were in MCUXpresso v. 10.0.2 were automatically installed in the new workspace.

    At first, I thought SDK v. 2.3 and v. 2.2 might be conflicting with each other. So I uninstalled SDK v. 2.2 from the workspace and tried it again. No way!

    The SDK I’m trying to use is SDK v. 2.3 for MK64FN1M0 and the board used is FRDM-K64F.

    Regards,

    LikeLike

    Reply ↓

    • Hi, Erich

      Forget about it! I noticed that I have to manually add Peripherals window.

      But I have another issue now: PIT does not show in the list of MK64FN1M0 peripherals.

      LikeLike

      Reply ↓

      • Hi Marco,
        I’m using the MK64FN1Mxx12, and the PIT register shows up for mi in the Peripherals+ view? Not sure what is different on your side? I’m using the SDK_2.x_FRDM-K64F 2.3.0.

        LikeLike

        Reply ↓

        • Hello, Erich

          It is the same SDK as mine, but for me PIT doesn’t show up.

          I opened a discussion in NXP Community and Alice Yang from NXP confirmed that PIT is also missing in Peripherals View on her side too:

          https://community.nxp.com/thread/465857

          Strange to say the least!

          Regards!

          Marco Coelho

          LikeLike

        • Hi Marco,
          oh, I see. I was thinking it is about the Peripherals+ tools (the tool to see the Periopherals in the debugger/IDE on the target), not the ‘Peripherals’ tool to initialize the PIT. That’s indeed missing in that other tool.

          LikeLike

        • No problem, Erich!

          LikeLike

11. Pingback: MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor | MCU on Eclipse

12. Pingback: Debugging the Teensy 3.6 with Eclipse MCUXpresso IDE and CMSIS-DAP LPC-Link2 | MCU on Eclipse

13. Hi Erich!

    I am starting a project for Kinetis KV5 processor. I have been working for a while in Code Warrior environment (both Classic and Eclipse based). I also did some minor projects in Kinetis Design Studio and it worked very well for me, using FatFS, FreeRTOS and so on via Processor Expert is excellent.

    Processor Expert tool is the only reason why I chose the Freescale/NXP processor and not the other manufacturer. I am pretty confident that Processor Expert will speed up the development process.

    Do you think it is worth switching to MCUExpresso for this particular project? Of course I will do my own research about this, but maybe you have some thoughts? If choose on environment it will be hard to change it.

    By the way thank you for your articles and tutorials, your web page is an incredible source of knowledge.

    LikeLike

    Reply ↓

    • You are welcome, glad to hear that my articles are helpful 🙂
      I have used the TWR-KV58F220M with KDS only (see https://mcuoneclipse.com/2016/06/24/first-steps-arm-cortex-m7-and-freertos-on-nxp-twr-kv58f220m/). Keep in mind that Processor Expert has been discontinued by NXP, and it is possible to install it into MCUXpresso IDE 10.1 because of plugin incompatibilities with the new MCUXpresso Configuration tools. So moving to MCUXpresso IDE 10.1 means burning bridges and going full blown SDK v2.x. The good thing is that this route is supposed to be supported by NXP.

      LikeLike

      Reply ↓

14. Pingback: Flash-Resident USB-HID Bootloader with the NXP Kinetis K22 Microcontroller | MCU on Eclipse

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

16. Hello Erich,
    I must update a my old project based on kinetis MK64 over proprietary board, few years ago, developed by MCU CW 10.6 with large use of PE components (usb, uart, spi, i2c, ADC, DAC, CRC, RTC, several timer and, finally, read/write on flash by a custom bootloader program).
    Now my hope is migrate to MK66 device (double flash and 180MHz of clock) but… PE is lost!
    I have appreciate your last acrobatics to merge PE with SDK, but at now, what do you suggest me? Develop entire project interfacing with the new SDK API or try to use almost all old code merging this with PE over SDK (as your article https://mcuoneclipse.com/2017/03/25/tutorial-using-eclipse-with-nxp-mcuxpresso-sdk-v2-and-processor-expert/)?
    I am very perplexed…

    LikeLike

    Reply ↓

    • Hi Antonio,
      unfortunately NXP stopped developing Processor Expert. As you have read, I have made some efforts for a compatbility layer which works fine for some of my projects. But I never will be able to carry on for all the peripherals.
      So what I do is to stick as much as possible with the ‘older’ devices which are still supported by Processor Expert because things are much easier that way.
      As for the K66, I’m affraid that probably the best way is that you restart from scratch and learn the SDK and develop your application again :-(.

      LikeLike

      Reply ↓

17. Hello Erich,
    trying to init the LPTMR peripheral on MCUXpresso 10.1.1 builded around a kinetis k66 device, i have noted the absence of LPTMR component also if this peripheral is activated by “manage SDK components” and also if the fsl_lptmr.c/.h files are presents on drivers folder. I think “don’t worry” because i can use anyway the API functions described on fsl_lptmr.h… but, how i can intercept the IRQ handler to, for example, increment a timer-marker variable on every timer-overflow interrupt?

    LikeLike

    Reply ↓

    • You have to put your IRQ handler into a function named LPTMR0_DriverIRQHandler(). See \startup\startup_mk66f18.c
      I hope this helps,
      Erich

      LikeLiked by 1 person

      Reply ↓

      • TNX Erich,
        i noted if i write the new (and re-named) LPTMR0_IRQHandler() as my ISR, the compiler dont make exception because the original ISR is attributed as ((weak)), and work 🙂

        LikeLike

        Reply ↓

18. Hello Erich,
    i ask me if exist a macro to enable/disable lite interrupts on MCUXpresso IDE, like a CriticalSection(Enter/Exit) of PE…

    LikeLike

    Reply ↓

    • Hi Antonio,
      The IDE does not provide anything like this, it would be the SDK. The MCUXpresso SDK comes with CMSIS, but to my understanding there is no such nice critical section handling as in Processor Expert. It only has things like __enable_irq() and __disable_irq(). The simplest way would be that you use the Macros/Code from Processor Expert in your code.

      LikeLike

      Reply ↓

19. Pingback: Overview of MCUXpresso IDE v10.2.0 | MCU on Eclipse

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

21. Pingback: Porting Processor Expert Projects to MCUXpresso IDE | MCU on Eclipse

22. Pingback: Investigating ARM Cortex® M33 core with TrustZone® – Using the Pins Config Tool | MCU on Eclipse

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