NXP MCUXpresso IDE 11.7.0

It is the exam and grading time at the university, and the same time I’m preparing the lectures and labs for the new semester starting mid of February. I’m always heading for using the latest and greatest tools in my labs. A few days ago, NXP released the new version of the MCUXpresso IDE, version 11.7.0. Time to check it out…

NXP MCUXpresso IDE 11.7.0

Outline

This release is following the previous 11.6.0 and 11.6.1 releases. I still can keep any existing releases installed. I keep them until I have my projects moved over to the new IDE.

The major change for sure is the updated Eclipse version (2022.6, platform 4.24.0 and CDT 10.7.0), and the IDE is now integrated with Eclipse Temurin JRE. Temurin will be of interest for all the Apple M1 host users, as this should allow native execution of Eclipse on that Apple host platform. I don’t own a Mac, so cannot comment much, and my students are using less Mac machines than in the past, but it should give such users a boost. To my understanding this would be only for the IDE, because the ARM build tools are still not compiled for native Apple M1 and run on Rosetta 2 instead.

It comes with updated (V13) configuration tools and support for the SDK v2.13.x. It includes updated debug probe support (SEGGER, P&E, NXP LinkServer). The LinkServer supports now WinUSB. More about this and other notable changes in the sections below….

LinkServer, MCU-Link and WinUSB

The NXP MCU-Link and Pro debug probes support now CMSIS-DAP 2.1 and WinUSB.

NXP MCU-Link Pro Debug Probe with LPC55S16 EVK
NXP LPC55S16-EVK with NXP MCU-Link Pro Debug Probe

There is NXP article describing the change. In a nutshell, WinUSB provides higher performance compared to the previous USB HID implementation. For using WinUSB, the probe firmware has to be updated (Version 3.x), and WinUSB based debug probes are only recognized with the IDE 11.7.0 (or later). Previous probes with older firmware continue to work with 11.7.0, but newer probe firmware won’t work if used with a previous IDE version, unless I would downgrade the probe firmware. I have upgraded my MCU-Link Pro(s) with the firmware 3.108, and indeed debugging feels faster now. I keep a few probes on the previous firmware version: that way I don’t have to switch the probe firmware if I want to use it with the previous IDE. Overall, I’m very pleased with the increased performance.

Explicit Encoding Set

The new Eclipse version wants to have an explicit coding set for each project. Importing projects from earlier Eclipse versions gives a warning:

Project <...> has no explicit encoding set
Warning about ‘has no explicit encoding set’

I could ignore it, or better fix it. The easiest way is to use the context menu and use ‘Quick Fix’:

Quick Fix

With this, I can fix it for all projects in the workspace:

Quick Fix for multiple projects

The other way would be to change it directly in the project Resource properties:

Resource UFT-8 setting

Open-CMSIS-Pack Support

The IDE comes with support for Open-CMSIS-Pack. ARM started years ago the CMSIS-Pack initiative to simplify software and driver distribution, which was not successful. ARM then had transferred the CMSIS-Pack technolgy to Linaro, with the hope to make it more open and acceptable outside of the ARM world. In my view, this will depend on adoption and the availability of software packs. But at least the IDE is providing support to consume Open-CMSIS-Packs once they are available.

In the workspace settings I can configure the folder and repositories:

CMSIS-Pack Workspace Settings

Eclipse has added a dedicated CMSIS-Pack Manager Perspective:

CMSIS-Pack Manager

The perspective gives me views for the devices, boards and packs:

CMSIS-Pack Perspective

The project view includes a container for the packs added to the project:

Project Container for Packs
Adding Open-CMSIS-Pack components

💡 To have that menu item available, remove and SDK support with the context menu and use ‘Remove SDK support’.

Binary Project ELF File Importer

A really cool new feature is the ability to import an executable (ELF/Dwarf) file into the workspace and being able to debug it, without the need for the sources or other files.

With the menu File > Import I can select the importer;

Then select the ELF/Dwarf file and specify the MCU:

This then creates a container ‘project’ which I can use to debug the binary without the sources:

Debugging ELF Executable File

Watchpoints

A nice addition is the ablity to set a watchpoint directly on a peripheral register, making debugging easier:

RTOS Thread Awareness Logs

The IDE comes with RTOS thread aware debugging (TAD) and views for FreeRTOS, ThreadX/Azure and Zephyr.

TAD Logs

The plugins create folders and files which are stored and ‘clutter’ the workspace folder: this can be of an issue if running automated tests or if I want to keep the workspace folder as clean as possible. The new IDE comes with a setting to disable creation of the log files which is appreciated:

Energy Measurement

Several fixes have been applied in the area of energy measurement and power profiling.

The MCU-Link Pro has differerent measurement ranges which can be set with a jumper. That range is now shown in the list of data sources:

Note that the above information is only shown with the LinkServer probe firmware v3.x (WinUSB, see above).

SWO

The release notes lists many fixes and improvements for SWO trace. For example the SWO configuration shows both the trace and target core clock speed are shown: this makes sense for devices like the M7 where they are not the same. I’m not having such a device on my desk, but it should show below the core clock speed in the dialog below (this one is for the LPC55S16, and there the clocks are the same, so no extra clock is shown). I will try it with an M7 once I get one in my hands.

Otherwise: the detected speed is shown as well below.

SWO Trace Link and Target Speed

I’m currently working on SWO stdio redirection, so I plan to write more about SWO in a future article.

Summary

This is a very solid new release and update for me. The new and updated features will be very useful in the labs next semester, notably the enhancements around power and energy measurement/profiling which are part of a low-power and low-energy lab.

Happy Xpressing 🙂

Links

8 thoughts on “NXP MCUXpresso IDE 11.7.0

  1. How were you informed of the new release? I got emails announcing new SDKs for a few of the chips I use, but I don’t see any email about the new IDE release. Are we supposed to sign up for these announcements?

    Like

    • I saw the announcement with the community article (link at the end of my post). I have subscribed there with email notifications.
      Usually I receive email notifications for new product releases too, but they seem to be sent out in batches with some delays, so I get them withing a few days after release.
      But for this release, I have not received yet, maybe it shows up in a few days.

      Like

  2. Hello Erich,

    I re-read your article here because I am contemplating whether or not to upgrade to IDE 17.7.0. I really appreciate the rundown of features you give that show their practically. I like the easier watchpoint access.

    How concerned should I be when upgrading that there could be differences in the SDK or IDE that could affect the code functionality? I have read a general blanket statements not to upgrade IDE without a full functional test to prove the software’s functionality. It seems like the risk of upgrading MCUXpresso IDE and SDK is pretty low.

    Next, I read the link referencing the speed increase available because of the driver change: MCU-Link changes to use WinUSB for MCUXpresso IDE 11.7 and future releases.

    What kind of driver does the P&E USB Multilink Universal FX use? Will the speed change for the USB Multilink? I think the answer is no, but just asking.

    With the updated IDE and the correct version in the NXP MCU-Link Pro Debug Probe, which debugger operate faster the USB Multilink Universal FX or the NXP MCU-Link Pro Debug Probe?

    Like

    • Hi Kevin,
      me too: I don’t recommend to change build tools in the middle of a critical project. The NXP IDE comes not only with a new IDE, but with updated build tools and libraries. So there is always a risk that especially something in the gcc or libraries might be broken. But over the last years I can say that this risk was low. And I still have the previous IDE (with the build tools and libraries around, just in case). I’m now using the 11.7.0 for several of our current projects, and so far it is working well.
      As for the SDK: I only upgraded a few (LPC55S16, LC55S59 and K22FN): the LPC upgrade of SDK was not that smooth, it complained about changed power manager library and other things, but I managed to get that working. To me changing the SDK is of higher risk, and usually what I do is to create a new project with the SDK and then do a file compare to see what has been changed.
      As for the debug probe USB drives: this affects the NXP MCULink only. The J-Link and P&E one are not affected by that change. Both work fine, I only face some issues with the J-Link semihosting which I did not had before (file I/O operations in combination with gcof), and not sure about it (yet). I just upgraded to the latest J-Link V7.84e, as it lists in the release notes a fix for semihosting, but that one did not solve the problem on my side. Anyway, not that critcial for me.
      As for a speed comparison, this heavily depends on the target system too. Maybe I find some time to make a quick test.

      Like

      • Thanks for the great advice and especially: “To me changing the SDK is of higher risk, and usually what I do is to create a new project with the SDK and then do a file compare to see what has been changed.

        I am still using CodeWarrior IDE for my file compares. Is there a newer tool? What do you use?

        Like

        • I’m using the Eclipse file compare features which works great for me, as well for merging.
          The other tool I frequently use is git for this kind of things: I have the project in git, then do an upgrade (IDE or SDK), and then easily can see the changes in the git client (SourceTree). And because everything is in git, I can easily revert changes if I don’t like them. Using git has been a life safer for me.

          Like

  3. Hi Erich,
    I am interested in the Open-CMSIS-Pack Support and wondered whether you had used this feature with any packs. The reason I am interested is that the CMSIS-DSP library supplied in some SDK’s is very much outdated when compared to the latest DSP code (https://github.com/ARM-software/CMSIS-DSP). I asked NXP about this and they stated that the DSP code released on a SDK ensures compatibility with the chosen hardware platform. That’s fair but I wondered whether this new Open-CMSIS-Pack Support would allow for users to move away from the SDK to use more updated library code such as the CMSIS-DSP library.
    Thanks,
    Gavin

    Like

    • Hi Gavin,
      Open-CMSIS-Packs are kind of new, and I have only used it for some testing so far. Given the history of CMSIS-Packs, it might take some years until it gets widely adopted. I mean it could be a great way for vendors to distribute software, but it is not a necessity, at least not for CMSIS-DSP. It it is pretty easy to just download the zip file and add it to the application (e.g. see https://mcuoneclipse.com/2013/02/14/tutorial-using-the-arm-cmsis-library/) instead.
      Open-CMSIS-Pack imho won’t get you independence from the vendor SDKs, as the packs still need to work and integrate with some kind of SDK, unless they are not depending on the hardware.

      Like

What do you think?

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