This document contains a history of the releases of MCUXpresso IDE, with links to the announcement blog for each release.
Receive email notification for new releases
If you would like to receive notifications when a new version of MCUXpresso IDE is released, please make sure to follow this document.
MCUXpresso IDE v11.2.1
MCUXpresso IDE v11.2.0
MCUXpresso IDE v11.1.1
MCUXpresso IDE v11.1.0
MCUXpresso IDE v11.1.0 SDK Handling Hotfix (January 2020)
MCUXpresso IDE v11.0.1
MCUXpresso IDE v11.0.1 Segger-LPC Debug Hotfix (September 2019)
MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix (October 2019)
MCUXpresso IDE v11.0.0
MCUXpresso IDE v10.3.1
MCUXpresso IDE v10.3.0
MCUXpresso IDE v10.2.1
MCUXpresso IDE v10.2.0
MCUXpresso IDE v10.1.1
MCUXpresso IDE v10.1.0
MCUXpresso IDE v10.0.2
MCUXpresso IDE v10.0.0
We are pleased to announce that MCUXpresso IDE v11.2.1 (build 4149) is now available.
This is a maintenance release that builds upon the previous MCUXpresso IDE v11.2.0 release, and we recommend that all existing users download and install this new version.
To download the installers for all platforms, please login to our download site via:
Additional information can be found in the updated User Guide and other documentation, which can be accessed from the built in help system available via IDE's Help menu and in PDF form from within the installation directory or downloaded from:
Notification of future releases
To receive notifications about future releases, please follow : MCUXpresso IDE - Release History
Summary of Changes - version 11.2.1 - October 2020
Upgraded: newer SEGGER J-Link software (v6.86).
Upgraded: newer PEmicro plugin (v4.7.6).
Upgraded: Version v8.1 of MCUXpresso Config Tools.
Added: i.MX RT1170 B0 support.
Added: i.MX RT1024 support.
Added: LPC55S06 support.
Added: K32W061 support.
Added: MCU-Link debug probe support. MCU-Link is a new debug probe solution being developed for NXP LPC, Kinetis and i.MX RT targets.
Feature: Auto-debug slave project(s) for multicore projects option becomes default option for multicore debug purpose (for LinkServer debug connection only). That means, in the case of multicore projects on which master project refers one or several slave projects, debug sessions will be automatically started for slave projects after initiating debug with the master project. Option is set by default on: Window -> Preferences -> MCUXpresso IDE -> Debug Options -> LinkServer Options -> Miscellaneous -> Enable Auto-debug slave project(s) for multicore projects. If you don't want to have this feature enabled (so if you want to start debug sessions for each core independently), uncheck this option.
Improvement: Community forum accessible now from the main toolbar too (together with the older link from Help->MCUXpresso IDE support forum). The default selection will open the community web inside the IDE. If you want to set the default browser as external browser, use Window->Preferences->General->Web browser->"Use external web browser".
Improvement: [RT600] Clean up on RT600 flash drivers (SDK now references the new drivers):
Add drivers for MXIC_OPI connected via FlexSPI_A port
Add drivers for QSPI drivers (SFDP) connected via FlexSPI_B port
Add drivers for QSPI drivers (SFDP) connected via FlexSPI_A port
Remove MIMXRT600_SFDP_* drivers generated by the old project
Fixed: [RT595] Cannot debug flash application with J-Link.
Fixed: [RT500][RT600] JLink launch config default resets:
Re-enable resets in JLink launches for RT500/RT600
The most recent JLink versions properly handle resets for RT500 & RT600 devices.
Fixed: [RT500] QSPI flash drivers: driver was incorrectly using QSPI DDR instead of SDR.
Fixed: [LPC55S69] Implemented DWT (Data Watchpoint and Trace) component for ArmV8. This fixes the SWO Data trace not working issue.
Fixed: Sometimes the linkserver semihosting console stops working.
Fixed: 'mismatched input' warning reported for linker file.
Fixed: Flash programming using JLink via JTAG.
Fixed: The running environment (PC/SP) for RAM applications is now properly initialized by the debugger when using JLink/PEmicro.
Fixed: JLink scripts needed by SDK examples are not copied correctly when installing the SDK from a folder.
Fixed: Selection of a driver in NPW makes the Library Type and Floating Type to become empty.
Fixed: [Dark Theme] highlighting makes text unreadable.
Fixed: [Dark Theme] not working on Ubuntu 18.
Fixed: [Dark Theme] Text is not visible for Blocked jobs in FreeRTOS.
Fixed: [Dark Theme] Peripherals view - some registers have yellow background making it hard to read.
Fixed: [Dark Theme] Line highlighting in editor makes variables text unreadable.
Fixed: [Dark Theme] Display issue for the "Probes discovered" window on Mac.
Fixed: [Dark Theme] Low contrast on text vs. background when a word is high-lighted by having cursor selection on it.
Fixed: [RT5xx] Unable to Restart flash-based session on EVK Rev C1 board.
Fixed: [LPC55xx] LinkServer debug cannot recover LPC55xx from deep sleep.
Fixed: [LPC4337] Flash programming over JTAG not working on the M4 core.
Fixed: [LPC845] Debug fails when SRAM is split into sub-blocks.
Fixed: [Dark Theme] Low contrast on text vs. background when a word is high-lighted by having cursor selection on it.
Fixed: Outline view displays empty table header when selecting an SDK.
Fixed: Not all dependency components are linked to project when the dependency is added from Config Tools.
Fixed: Initialize execution environment when debugging RAM target application using Segger J-Link.
Fixed: NPE occurred while using board SDK creator and adding a flash driver.
This exercise demonstrates how to port a project using MCUXpresso IDE and SDK from one RT MCU to another. The exercise starts with an SDK demo project for the MIMXRT1060-EVK board, and ports to the IMXRT1050-EVKB board.
The " MCUXpresso IDE User Guide " installed with the IDE gives this warning:
changing a project’s associated MCU should not be undertaken unless you have a total grasp of the consequence of this change. Therefore rather than changing a project’s associated MCU, it is strongly recommended that instead a new project is generated for the desired MCU and this new project is edited as required. However, on occasion it may be expedient to reset a project’s MCU (and associated SDK)
I also recommend using a SDK project intended for the final MCU, and just port the application source files to it. But here are the steps to port the project. Also note, these two boards use different flash types by default. In this example, the IMXRT1050-EVKB was reworked to use the QSPI flash on the board following Appnote AN12108. Once the RT1050 EVK is modified to use the QSPI flash, it is the same flash used on the RT1060 EVK.
Resources used in this exercise:
IMXRT1050-EVKB board RevA1
MIMXRT1060-EVK board RevA2
MCUXpresso IDE v11.2.0
MCUXpresso SDK from Welcome | MCUXpresso SDK Builder
Attached to this post are two projects:
Starting_evkmimxrt1060_iled_blinky.zip was the original SDK example running on the RT1060 EVK
evkbmimxrt1050_iled_blinky_ported.zip is the final ported project, running from QSPI and RT1050
Following the " MCUXpresso IDE User Guide " section "Changing the MCU (and associated SDK)", changed the MCU to MIMXRT1052xxxxB. Also changed the flash driver to MIMXRT1050_SFDP_QSPI.cfx. If using Segger JLink, see https://wiki.segger.com/i.MXRT1050 to change the flash algorithm to QSPI.
And then changed the package/part number to MIMXRT1052DVL6B.
Changed the project name to evkbmimxrt1050_iled_blinky_ported
Changed the C Compiler Preprocessor definitions to the SDK device CPU_MIMXRT1052DVL6B
Replaced the files from the SDK package EVKB-IMXRT1050_SDK_2.8.2 (Note: MCUXpresso IDE supports "SDK Project Component Management", which could also be used for updating some of these files. See section "SDK Project Component Management" of the IDE user guide. But I replaced the files manually myself from the RT1050 SDK package):
device folder with the SDK files from EVKB-IMXRT1050_SDK_2.8.2.zip\devices\MIMXRT1052.
startup file from \EVKB-IMXRT1050_SDK_2.8.2.zip\devices\MIMXRT1052\mcuxpresso\
drivers files from \EVKB-IMXRT1050_SDK_2.8.2.zip\devices\MIMXRT1052\drivers\
board files, can use an SDK example for the ported device, or generate the clock_config and pin_mux files from the MCUXpresso Config tools
xip files would also need to be updated if flash configuration changes. In this example, both boards are using the same QSPI flash, and these files are the same.
Delete the .launch debug configuration file in the project. MCUXpresso IDE will regenerate it.
With these changes, the ported project runs on the RT1050 EVK.
Dear Community, The purpose of this document is to show how to integrate projects from the file system to MCUXpresso IDE. It is actually not that complicated as you might have imagined. Let's begin... The import project(s) from file system option is included in the Quickstart Panel, which is located in the lower left corner of the IDE. Type / Paste the location of the folder (either zipped or unpacked). Then, click Next button. Finally, select all the project folders / examples you want to be imported. Now, they will be accessible and available from the Project explorer. Happy development! Best regards, Ivan R.
Checking disassemble code is often needed for programmers when developing a project. This article will introduce two methods of generating disassemble file with GNU utility objdump under MCUXpresso IDE 10.1.0. If user needs demo code, please send me community internal message.
For the previous KDS or CodeWarrior users, they may not create and use static library under MCUXpresso IDE without a hitch, because the methods are not exactly same. MCUXpresso IDE supports adding static library in user project with “Smart Update” wizard. This feature is derived from LPCXpresso IDE. However, “Smart Update” wizard is only available for natively supported LPC products in MCUXpresso 10.1.0 and lower versions. It will support all LPC and Kinetis product in MCUXpresso IDE future release. For MCUXpresso natively supported LPC product, using “Smart Update” to add library is very convenient. User can learn its usage from this article: Creating and Linking to Library Projectshttps://community.nxp.com/message/630594 For Kinetis product, the only way to add library to project is by hand. This article will take an example with MK64F demo, illustrating how to create and use static library under MCUXpresso IDE step by step. It will also be good for all LPC and Kinetis users to understand how user project works with external static libraries under MCUXpresso. If user needs demo code of this article, please send me community internal message. Thanks for the suggestion from LPCX support
This tip will show you how to re-trigger a full probe discovery. The feature is very useful for the customer who may use multiple debug probes. The first time you debug a project, MCUXpresso IDE will perform a probe discovery operation and display the discovered Debug Probes for selection. This will show all Supported Probes that are attached to your computer. (Here you can see the default P&E Micro OpenSDA of FRDM-KL25Z board was found.) For any future debug sessions, the stored probe selection will be automatically used to match the project being debugged with the previously used debug probe. This greatly simplifies the case where multiple debug probes are being used. However, if a debug operation is performed and the previously remembered debug probe cannot be found, then a debug probe discovery operation will be performed from within the same family e.g. MCUXpresso IDE LinkServer, P&E Micro or SEGGER J-Link. (Here you can see there are two Probe search options: Search for PEMicroDBB97E74 again and Search for other attached PE Micro probes.) But if you want to use a different debug probe(for example: debug FRDM-KL25Z board with SEGGER JLink), click this blue debug icon will meet problem. Supported Probes dialog only show P&E Micro probes, it will not search other family of debug probes e.g. MCUXpresso IDE LinkServer or SEGGER J-Link. Once a launch configuration file has been created, it will be used for the projects future debug operations. If you wish to use the project with a different debug probe, then simply delete the existing launch configuration and allow a new one to be automatically used on the next debug operation . Now click blue debug icon re-trigger a full probe discovery, and it show all Supported Probes that are attached to your computer again.
As a heads-up: several uses reported a problems with downloading the MCUXpresso IDE setup/installer program. If pressing the 'Download' button, you might come back to the login screen (to log into your NXP user account): The likely reason for this is that your NXP account needs re-activation. You should see a link to open a SR (Service Request) which you could use. Otherwise post a comment here so your account can be re-activated. I hope this helps, Erich
MCUXpresso IDE combines the best features of the LPCXpresso IDE and Kinetis Design Studio. For users more familiar with KDS, here’s a high level overview of some of the things that are different in basic interactions with this new tool. Quickstart Panel. One of the biggest and most useful changes is the Quickstart panel in the lower left hand corner of the IDE. This is where users import MCUXpresso SDK projects, build projects, debug projects, and modify some project settings. Importing SDK Example Projects This is now done via the Quickstart Panel, and by default will create a unique copy of the project inside the workspace directory with all the necessary source files for the board, drivers, and source so it can be easily shared. Debugging SDK Projects This is also now done via the Quickstart Panel, and is straightforward. One important thing to note though is that if you want to change the debugger protocol (ie move from CMSIS-DAP to Segger JLink) you need to delete both the .launch files in the project so that the debugger settings will reset. Semihosting If default options are kept when importing in SDK projects, semihosting is used for printf commands. See this Community post for details on how to use the UART for printf instead (which is connected to the OpenSDA circuit on development boards), as well as how to switch between the two options. Importing SDKs New device support is added to MCUXpresso IDE by importing SDK packages. There’s an XML file inside the SDK packages that tell it all the information the IDE needs to know. Reference this Community post for some of the options you have in how to import an SDK into the IDE, and also refer to Section 4 of the MCUXpresso User Guide or this in-depth training video. MCUXpresso SDK This is just a re-branding of Kinetis SDK 2.x now that it supports more than just Kinetis devices, so there are no significant differences with this new name change. Porting a KDS project to MCUXpresso There is no automatic tool to take a KDS project and convert it to a MCUXpresso project, so there is some manual work involved in porting a KDS project to MCUXpresso IDE. The recommended path would be to import/create the closest MCUXpresso SDK project, and then copy in the custom source code and other modifications. Minimal code re-write should be required since the drivers are the same. They are also both Eclipse/GCC based IDEs so predefines should be straight forward to port over.
MCUXpresso SDK packages are downloaded as .zip files. If you are using a 3 rd party IDE such as IAR or Keil, then the package must be unzipped in order to access the project files. Also an unzipped SDK folder must be available for the MCUXpresso Config Tools. This is why the default recommendation is to go ahead and unzip a downloaded SDK package. However if using MCUXpresso IDE, then either the zipped or unzipped SDK can be imported into the MCUXpresso IDE. A zipped SDK will save disk space and can be imported into the IDE more quickly than an unzipped SDK folder. MCUXpresso’s IDE part support is extended by importing MCUXpresso SDKs into the IDE, so this can save some time if you need to add a new device. Also note that your SDK package must support MCUXpresso, and thus must have been recently created in the SDK Builder (after March 24th) with explicit support for MCUXpresso in the package, else you will get an error when trying to import it. When an MCUXpresso SDK zip package or folder is drag-and-dropped into the IDE, a copy of that zip/folder is made and put into the C:\Users\<user_name>\mcuxpresso\SDKPackages directory. Thus you can delete the original copy that was downloaded to save disk space. If the imported SDK was zipped, then when creating or importing example projects, the SDK source files are always copied into the workspace. If the imported SDK was unzipped, then you are given the option to either copy the SDK source files into the workspace (which is the default), or the SDK files can be referenced directly as linked references. If an SDK is imported as a zipped file, it can be later unzipped from inside the MCUXpresso IDE. This unzipping has been optimized so it’s much faster than unzipping it via a program like WinZip. When unzipping inside the MCUXpresso IDE, the zip file that was in the MCUXpresso SDKPackages folder will automatically be deleted from the hard drive once its finished unzipping. You can then use this unzipped folder for that SDK location when using the MCUXpresso Config tools. You can also add MCUXpresso SDKs by placing an SDK package (zipped or unzipped) into that default SDKPackages directory ( C:\Users\<user_name>\mcuxpresso\SDKPackage) and restarting the MCUXpresso IDE. Finally you can also specify additional directories that MCUXpresso IDE should search for SDK files (both zipped or unzipped) by going to Window -> Preferences -> MCUXpresso IDE -> SDK Options. This can be useful for keeping a repository of SDKs in a special location on your hard drive. For SDKs stored outside the default location though, the "Delete SDK" function is disabled inside the IDE, and the extra search paths are only saved per workspace, so if you choose another workspace, it won't know about the new SDK folders until you re-add the path. If multiple SDKs are found for the same device in different locations, the IDE select the package to use by priority on the list (top has priority). More detailed information on pre-installed part support and importing SDKs can be found in Section 4 of the MCUXpresso IDE User's Guide, as well as in this informative training video.
Semihosting printf with MCUXpresso IDE When importing MCUXpresso SDK projects into MCUXpresso IDE, they will be configured by default to use “semihosting” for the terminal output. This means the project will use the debugger connection to send terminal characters instead of the UART. More information on semihosting can be found on this Community document and in Section 11.4 of the MCUXpresso User Guide. Note that the information in this post is only applicable when using the MCUXpresso IDE, as the projects for other IDEs will use the UART by default when opening up their respective MCUXpresso SDK projects. Also semihosting only works when there is an active debug connection to the device. printf with semihosting: printf with UART Terminal (with TeraTerm): How to choose UART output during the project import In order to use the UART for MCUXpresso IDE projects, some configuration settings need to be modified when importing in the project. First, you will need to uncheck the “Enable semihosting” option to clear the box. This will tell the project to use the normal libraries and not the semihosting libraries. Then on the next screen, you’ll want to uncheck the “Redirect SDK “PRINTF” to C library “printf”” box to clear it. This will tell the project to use the MCUXpresso SDK source files for printf instead of the generic C files. This allows you to debug, and modify if desired, the printf functionality found inside the MCUXpresso SDK. Section 5.1.2 of the MCUXpresso IDE User Guide describes the options on this screen in more detail. Switching between semihosting and UART If you’re already imported the project and wish to switch between using semihosting or the UART, you can do this from the “Quick Settings” menu inside the Quickstart panel. If moving from semi-hosting to UART, this will change the library used to “nohost-nf” and set SDK_DEBUGCONSOLE define to 1 inside the pre-processor settings. If moving from UART to semi-hosting, this will change the library to “semihost-nf” and set SDK_DEBUGCONSOLE define to 0. If you're not seeing any printf output, double check you have the right settings. Note that when importing the project initially and “Enable semihosting” is deselected and “Redirect SDK “PRINTF” to C library “printf”” is deselected in order to use the UART for terminal output, there is no SDK_DEBUGCONSOLE defined in the project settings. However inside the debug console SDK code itself, there is a #if statement so that if that value is not defined, then that define is set to 1, and hence why the SDK debug console is still used in that case.
The MCUXpresso IDE has a versatile way to create different binary files (S-Record/S19, Intel Hex or raw Binary) which then can be used by other tools like flash programmer or bootloaders. Check out the IDE documentation (menu Help > MCUXpresso IDE User Guide): where you can search for any topics like this: See as well the following article (external link) on that subject: MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse Enjoy!
As part of my university engagement, I have posted an overview article about the new MCUXpresso IDE: (external link): MCUXPresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse I hope you find it useful, Erich