NXP published MCUXpresso SDK 2.9.0 on GitHub

There are many different aspects of Open Source projects: It is not only about the fact if the sources are available (‘open’). It is about the licensing terms (how permissible is it, what can I do with it), maintenance and continuous development (what has changed between releases), how and where is it delivered (Sourceforge, dedicated distribution, packaging) up to collaboration (how can I contribute or submit issues).

NXP has now published the MCUXpresso SDK on Github:

MCUXpresso SDK on GitHub

MCUXpresso SDK on GitHub

Something I was waiting for a long time.

NXP provides the SDK (at least the part of it which is NXP IP) with a very permissible BSD-3 license or see this license file on GitHub. The SDK is a set of device drivers (UART, SPI, USB, …), middle-ware (GUI library, RTOS, utilities, …), example projects, documentation and information for flash programming and debuggers.

Zip File Approach of the Past

The current SDK package concept so far used by NXP is basically a zip file which can be configured and downloaded from https://mcuxpresso.nxp.com or directly from the Eclipse based MCUXpresso IDE. That SDK concept is OK for a single project or device. For a more common development flow it is not good:

  • Per Device: It requires a separate SDK package/zip file for every device. Using multiple devices means having many SDK zip files, each around 50-120 MByte in size, and the zip files are maybe 90% the same, with just some device specific information being different. I want to have an SDK which includes all the devices I need, not multiple single device SDK.
  • Upgrade: You are on version 2.8.0, now 2.9.0 comes out with a new zip file: what are the changes? You have to compare the content of the files, making it really hard (or even impossible) to upgrade a project to a newer SDK version, especially if I had to do patches or changes to the previous SDK. I want to have an SDK which makes it easy for me to switch between versions with just providing a Tag for a checkout.
  • Build Integration: the zip file approach means that I have to integrate the SDK myself into my CI build system or build server. It is doable, but painful: I rather would pull all the files from a repository and I’m done. The zip file approach makes it difficult for a distributed engineering team: I have to distribute the SDK zip files and make sure it is built the same: having it pulled from a VCS makes things a lot easier. Sure I can put up the files of the SDK zip file on my own repository, but then again I will hit a wall if a new SDK version comes out. I want an SDK where I can pull things from an official site to be integrated into my builds.
  • Issue Tracking: There has been no transparency what has been changed or fixed from one release to another, except with the information in the release notes. How to be sure that the issue I have reported in the forum is addressed in the new release? I want to see what is changed on-going and pull from it if needed, and I want to be able to submit issues and PR’s (Pull Requests) to improve the SDK.

The good news is: most of this automatically gets resolved by hosting the SDK on public VCS like GitHub :-).

MCUXpresso SDK on GitHub

The Github repository not only hosts the sources, but as well the release(s):

GitHub Release of the SDK

GitHub Release of the SDK

The previous ‘zip approach’ does not go away according to the information provided by NXP:


github_release_introduction (Source: https://github.com/NXPmicro/mcux-sdk)

The ‘classic’ Zip file releases (MCUX_* on the bottom of the image) are still there, and they seem to get pulled into the GitHub main branch. I suspect that the engineering development not really happens on GitHub but on another (NXP internal?) repository and the changes get pulled in into the GitHub branch and from time to time released as MCUX_* zip file deliverable. The mainline might not include everything, but it is still massive improvement from seeing just the MCUX_* releases.

Now I have more transparency what gets changed or improved, and I can see and use changes and I don’t have to wait for the next release.

I can fork the repository and add my own changes and then do a pull-request to get my changes integrated. As of today, there are already 9 forks and I expect to be many more in the next weeks:



The big advantage of a fork is that you get your own copy, you can do changes under version control and decide if you want to contribute things back via PR (Pull Request). There are already some PR’s open:

Pull Requests

Pull Requests

But the Readme.md for now has this:

Currently we are not ready to accept contribution, you could create an issue to suggest a new idea or track a bug. Contribution will be open soon.

So I expect that PR’s will be handled soon too.

Using with NXP MCUXpresso IDE

The SDK includes cmake make files. But it is easier to start with an Eclipse managed make project. The process is basically:

  1. Clone the git repository
  2. Create a new ’empty’ project and assign the MCU to be used in the project settings
  3. Create a CDT Build variable (e.g. GITHUB_SDK) and use it to point to the header file directories

    SDK includes

    SDK includes

  4. Link to the needed source and driver files in the SDK (I prefer to link, but copy is fine too)
  5. Create a main.c and call the needed driver initialization

Within a few minutes, I was able to get a basic SDK project created from an empty project and able to debug it with the MCUXpresso IDE 11.3.0:

Debugging fresh GitHub SDK Project with MCUXpresso IDE

Debugging fresh GitHub SDK Project with MCUXpresso IDE

It is for sure not as straightforward as using the SDK wizard which uses the ‘zip’ version of the SDK, but for a medium or advanced user the above steps are pretty easy. And maybe NXP comes up with a simple wizard to do the above steps soon too. So I believe things will get even easier over time.


These days developers use version control systems, and having the NXP MCUXpresso SDK hosted on a GitHub repository by NXP makes a lot of sense. I think that step has been long overdue and is a good one to make the SDK better over time. Not sure why usually vendors are reluctant to do this step? Of course distributing things as a zip package or similar is easier, because it is just a one-way distribution way. But to have a successful open source project, you need to consider user collaboration with PR’s and a good ticketing system which GitHub provides. Of course this requires governance and engineering efforts from a vendor, but on the long term this makes software projects successful with a large community.

Happy Githubing 🙂


5 thoughts on “NXP published MCUXpresso SDK 2.9.0 on GitHub

  1. Can you cover how to properly pull in the missing middleware components when using the github hosted SDK? I assume there are specific versions/tags for each middleware component. Specifically, FreeRTOS and fatfs

    Were none of them modified for the NXP SDK?


    • My thinking is that probably the middlware shall be pulled in from their own respective sub-directories. As for FreeRTOS and FatFS I did not use already with the current/previous SDK and pulled it in from the official sites because at the time the SDK was released they were already outdated.


What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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