Working with MCUXpresso SDK - nxp-mcuxpresso/vscode-for-mcux GitHub Wiki

NXP provides a large series of open source drivers, middleware, and reference example applications to speed your software development. These come in different flavors:

  • GitHub repository

  • Zip package SDK built upon preferred HW target, host OS, toolchain at MCUXpresso SDK

  • Open-CMSIS-Pack standard for software delivery. Packs can be browsed/selected within supported IDEs and then downloaded locally from a dedicated NXP server.

MCUXpresso for VS Code offers the possibility to install and use these sources with this extension.

Import remote Git repository

A special tab option on the Import repository view will allow the user to specify the details about the remote repository.

Install remote SDK

Once this process is finished, INSTALLED REPOSITORIES will display all downloaded SDKs from that repository.

Installed remote SDK

By default, "main" revision is set. If other revision is needed, check the expanded list.

Install revision SDK

Note: In order to speed up the import process, the default operation does not clone entire examples content but only names in order to offer to the user the possibility to select them. The example sources are then downloaded only when a specific example template is used to create a project. Still, if you want a full download from the beginning (keep in mind that this will take an increased amount of time) just select Clone all examples checkbox.

Clone examples

Import standalone MCUXpresso SDK zip archive

Another possibility is to install an MCUXpresso SDK from a zip archive (Downloaded from MCUXpresso.NXP.com).

Install archive SDK

The extension will check for compatibility issues, then extract the archive at the specified location. If the user chooses to use the "Create Git repository" option a git repository will be initialized at the SDK location, with the branch name SDK_<version>.<name>. Afterwards, a git commit will be performed with all of the files present in the SDK.

Archive SDKs also have an update branch which will be created after these steps. The branch is tagged from the main SDK branch.

Having a Git repository that contains the SDK source code allows the users to keep track of the changes they made in the SDK source code and to switch between SDK versions, however the option of handling the git repository on their own is also available.

Import MCUXpresso SDK using SDK Builder

It is also possible to import an MCUXpresso SDK archive directly from the extension, using the SDK Builder.

SDK Builder

After selecting a package (which can be either a board or a device) and a version, information regarding the SDK package will be displayed.

SDK Builder Package Information

The view will display the related boards and devices of the selected package, along with a description and an image, if available. Additional information can be obtained by visiting the "View on NXP.com" hyperlink, present under the package description.

Similar to a local MCUXpresso SDK archive, the option to create a Git repository is also available.

The license of the package can be inspected by clicking on the license hyperlink. A new window with a preview will be opened on the side.

SDK Builder License Preview

After agreeing to the license, the selected package will be downloaded and will undergo the same import process as the local archive.

Create, build and debug the project

For creating, building and debugging the project, the standard steps described in create project, build and debug documentation sections should be followed.

Component management

Each project has a "Manage Components" option for viewing and managing all MCUXpresso SDK available components. "Manage Components" option can be accessed from the icon next to the project or from the projects context menu under the "Configure" group options.

Manage components

Manage components menu

A view with the list of all the available components will become open, just select the needed component(s) and press "OK" to add them to your application.

Select components

The component will be added in the component list inside CMakeLists.txt file.

Component management (Modern CMake)

The support for Modern CMake is available starting with MCUXpresso SDK version 2.14.

When a component is selected for a project, its dependencies are also added. This can be checked in "config.cmake" file.

Select component

Config cmake

If one of the selected components is not compatible with the other used components, an error message is displayed.

Dependencies error

When this happens, the user can investigate the issue by checking the dependencies of the selected components in the manifest file. The manifest file is located in the MCUXpresso SDK repository.

Example: project "lpcxpresso55s69_hello_world", component "middleware_sdmmc_host_sdif_interrupt" and component "middleware_sdmmc_host_sdif_freertos".

Manifest file: Dependencies manifest file

If "middleware_sdmmc_host_sdif_interrupt" component was already added, then "middleware_sdmmc_host_sdif_freertos" component cannot be added.

Changing floating point type

Project configuration options offers possibility to change the floating point ABI for MCUXpresso SDK based projects. If needed to do so, go to the build configuration used by the project, select Edit -> Go to the Floating Point option and select from the available list displayed. Press the Save button to finish.

Floating point

This change will be saved in the CMakePresets.json file as FPU_TYPE and FPU_ABI cacheVariables. Simply remove these settings in order to revert to the default project options (if needed to identify this, search for set_floating_point function in ./repo/tools/cmake_toolchain_files/mcux_config.cmake file).

Changing library type

Configuration options provide option to switch C/C++ library type. Select Configure -> Set Library Type from project context menu. This will allow selecting from the available library types.

Newlib and Newlib-nano are available by default as they are embedded into the Arm GNU Toolchain distribution.

Redlib is NXP variant of (non-GNU) ISO C90 standard C library, with some C99 extensions. If you need a smaller application size and don't need the additional functionality of the C99 or C++ libraries, we recommend the use of Redlib, which can often produce much smaller applications.

Library type

This change will be saved in the CMakePresets.json file as LIBRARY_TYPE cacheVariables. If needed to identify details on how the library type option is used, follow set_library function in ./repo/tools/cmake_toolchain_files/mcux_config.cmake file.

Redlib extensions to C90

Note: Redlib is provided by the NXP Toolchain Add-on pack distributed by the MCUXpresso Installer and it comes installed on top of an Arm GNU Toolchain distribution. Be sure you have 12.3.2 or newer version of NXP Toolchain Add-on in order to have Redlib support added. Alternatively, the toolchain provided by MCUXpresso IDE (in case there is already an existing installation on the machine) can be used, which already contains Redlib support. Also, MCUXpresso SDK 2.15 or newer has to be used in order to provide integration support of Redlib.

Although Redlib is basically a C90 standard C library, it does implement a number of extensions, including some from the C99 specification. These include:

  • Single precision math functions
    • Single precision implementations of some of the math.h functions such as sinf() and cosf() are provided.
  • stdbool.h
    • An implementation of the C99 stdbool.h header is provided.
  • inttypes.h
    • An implementation of the C99 inttypes.h header is provided.
  • itoa
    • itoa() is a non-standard library function which is provided in many other toolchains to convert an integer to a string. To ease porting, an implementation of this function is provided, accessible via stdlib.h. More details can be found later in this chapter.

Library variants

Each C library family is provided in a number of different variants: None, Nohost and Semihost. These variants each provide a different set of 'stubs' that form the very bottom of the C library and include certain low-level functions used by other functions in the library.

Each variant has a differing set of these stubs, and hence provides differing levels of functionality:

  • Semihost(-mb)
    • This library variant provides an implementation of all functions, including file I/O. The file I/O is directed through the debugger and is performed on the host system (semihosting). For example, printf/scanf uses the debugger console window and fread/fwrite operates on files on the host system. Note: emulated I/O is relatively slow and can only be used when debugging. Note that mb library variants may optionally be selected for enhanced semihost performance with the penalty of slightly larger RAM usage.
  • Semihost(-mb)-nf (no files)
    • Redlib only. Similar to Semihost, but only provides support for the 3 standard built-in streams: stdin, stdout, stderr. This reduces the memory overhead required for the data structures used by streams, but means that the user application cannot open and use files, though generally this is not a problem for embedded applications.
  • Nohost and Nohost-nf
    • This library variant provides the string and memory handling functions and some file-based I/O functions. However, it assumes that you have no debugging host system, thus any file I/O does nothing. However, it is possible for the user to provide their own implementations of some of these I/O functions, for example, to redirect output to the UART.
  • None
    • This has literally no stub and has the smallest memory footprint. It excludes low-level functions for all file-based I/O and some string and memory handling functions.

In many embedded microcontroller applications it is possible to use the None variant by careful use of the C library, for instance avoiding calls to printf().

If you are using the wrong library variant, then you will see build errors in the form:

Linker error "Undefined reference to ‘xxx’ "

For example for a project linking against Redlib(None) but using printf() :

… libcr_c.a(fpprintf.o): In function `printf':
fpprintf.c:(.text.printf+0x38): undefined reference to `__sys_write'
fpprintf.c:(.text.printf+0x4c): undefined reference to `__Ciob'

Or if linking against NewlibNano(None):

… libc_nano.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x10): undefined reference to `_write'

In such cases, simply change the library hosting being used (as described below), or remove the call to the triggering C library function.

Changing toolchain for an existing project

When importing a project or an example from the repository you are required to choose a toolchain to be associated to the project, but you may also change the toolchain for an existing project. To do this go to the context menu of the project, select "Configure" and then "Associate Toolchain", you should now see the available toolchain options and select the desired value.

Associate toolchain

Changing the associated repository for an existing project

You can also change the repository associated to an existing project. To do this go to the context menu of the project, select "Configure" and then "Associate Repository", you should now see all the available MCUXpresso SDK repositories and select the desired value.

Associate repository

Changing the associated package for an existing project

MCUs are commonly available in a range of package types. Different packages may impact the options available on the MCU external pins, for example, the number of GPIO lines. MCUXpresso for VS Code makes no use of this package type however it is significant to MCUXpresso Config Tools. From the PROJECTS view, for "MCU" virtual node, select "Change Package".

Change package

A quick pick will open with the list of packages for the current device.

Select package

home

⚠️ **GitHub.com Fallback** ⚠️