MCUXpresso SDK Documentation
Open on Repo Open an Issue
Source (.md/.rst) Page PDF (.pdf)

MCUXpresso SDK Release Notes

MCUXpresso SDK Release Notes#

Overview#

The MCUXpresso SDK is a comprehensive software enablement package designed to simplify and accelerate application development with Arm Cortex-M-based devices from NXP, including its general purpose, crossover and Bluetooth-enabled MCUs. MCUXpresso SW and Tools for DSC further extends the SDK support to current 32-bit Digital Signal Controllers. The MCUXpresso SDK includes production-grade software with integrated RTOS (optional), integrated enabling software technologies (stacks and middleware), reference software, and more.

In addition to working seamlessly with the MCUXpresso IDE, the MCUXpresso SDK also supports and provides example projects for various toolchains. The Development tools chapter in the associated Release Notes provides details about toolchain support for your board. Support for the MCUXpresso Config Tools allows easy cloning of existing SDK examples and demos, allowing users to leverage the existing software examples provided by the SDK for their own projects.

Underscoring our commitment to high quality, the MCUXpresso SDK is MISRA compliant and checked with Coverity static analysis tools. For details on MCUXpresso SDK, see MCUXpresso-SDK: Software Development Kit for MCUXpresso.

MCUXpresso SDK#

As part of the MCUXpresso software and tools, MCUXpresso SDK is the evolution of Kinetis SDK, includes support for LPC, DSC,PN76, and i.MX System-on-Chip (SoC). The same drivers, APIs, and middleware are still available with support for Kinetis, LPC, DSC, and i.MX silicon. The MCUXpresso SDK adds support for the MCUXpresso IDE, an Eclipse-based toolchain that works with all MCUXpresso SDKs. Easily import your SDK into the new toolchain to access to all of the available components, examples, and demos for your target silicon. In addition to the MCUXpresso IDE, support for the MCUXpresso Config Tools allows easy cloning of existing SDK examples and demos, allowing users to leverage the existing software examples provided by the SDK for their own projects.

In order to maintain compatibility with legacy Freescale code, the filenames and source code in MCUXpresso SDK containing the legacy Freescale prefix FSL has been left as is. The FSL prefix has been redefined as the NXP Foundation Software Library.

Development tools#

The MCUXpresso SDK was tested with following development tools. Same versions or above are recommended.

SDK 25.12.00 is the final release that includes MCUXpresso IDE support for MCX W7x devices. Beginning with SDK 26.x.x, MCUXpresso IDE will no longer be supported for MCX W7x development, and MCUXpresso for Visual Studio Code will become the recommended integrated development environment.

  • IAR Embedded Workbench for Arm, version is 9.60.4

  • MCUXpresso IDE, Rev. 25.06.xx

  • MCUXpresso for VS Code v25.09

  • GCC Arm Embedded Toolchain 14.2.x

Supported development systems#

This release supports board and devices listed in following table. The board and devices in bold were tested in this release.

Development boards

MCU devices

MCX-W71-EVK

MCXW716CMFPA, MCXW716CMFTA

MCUXpresso SDK release package#

The MCUXpresso SDK release package content is aligned with the silicon subfamily it supports. This includes the boards, CMSIS, devices, middleware, and RTOS support.

Device support#

The device folder contains the whole software enablement available for the specific System-on-Chip (SoC) subfamily. This folder includes clock-specific implementation, device register header files, device register feature header files, and the system configuration source files. Included with the standard SoC support are folders containing peripheral drivers, toolchain support, and a standard debug console. The device-specific header files provide a direct access to the microcontroller peripheral registers. The device header file provides an overall SoC memory mapped register definition. The folder also includes the feature header file for each peripheral on the microcontroller. The toolchain folder contains the startup code and linker files for each supported toolchain. The startup code efficiently transfers the code execution to the main() function.

Board support#

The boards folder provides the board-specific demo applications, driver examples, and middleware examples.

Demo application and other examples#

The demo applications demonstrate the usage of the peripheral drivers to achieve a system level solution. Each demo application contains a readme file that describes the operation of the demo and required setup steps. The driver examples demonstrate the capabilities of the peripheral drivers. Each example implements a common use case to help demonstrate the driver functionality.

RTOS#

FreeRTOS#

Real-time operating system for microcontrollers from Amazon

Middleware#

Wireless zigbee stack#

This release of the NXP Zigbee stack supports the following generic Zigbee protocol features:

  • Zigbee Pro R22

  • Zigbee 3.0

  • Zigbee Green Power – Proxy and Combo

  • Base Device Behavior (BDB) 3.1

  • Zigbee Cluster Library (ZCL) 8

The SDK includes the following sample Zigbee 3.0 applications that allow the end user to get quickly up to speed with the development of Zigbee applications on NXP platforms:

  • Zigbee Coordinator

  • Zigbee Router

  • Zigbee End Device

IEEE 802.15.4 MACPHY Software#

The IEEE 802.15.4 software includes:

  • The IEEE 802.15.4 PHY supporting Thread 1.3.x and Thread 1.4.0 with OpenThread, and Matter over Thread

  • IEEE 802.15.4 MAC supporting Zigbee

  • Simple MAC (SMAC)

  • Low-level IEEE 802.15.4 radio mode test software

  • Multiprotocol support (Bluetooth LE and IEEE 802.15.4)

  • Experimental support for dual PAN mode (two IEEE 802.15.4 networks on a single channel or two channels)

The IEEE 802.15.4 PHY and MAC software implementation is based on IEEE Standard 802.15.4-2015.

Wireless XCVR#

The XCVR component provides a base Transceiver Driver for the 2.4 GHz narrowband radio.

Bluetooth LE Controller#

  • Main features supported:

    • Peripheral Role

    • Central Role

    • Multiple PHYs (1 Mbps, 2 Mbps, Coded PHY)

    • Asymmetric Connections

    • Public/Random/Static Addresses

    • Network/Device Privacy Modes

    • Extended Advertising

    • Extended Scanning

    • Passive/Active Scanning

    • LE Encryption

    • LE Ping Procedure

    • HCI Test Interface

    • UART Test Interface

    • Randomized Advertising Channel Indexing

    • Sleep Clock Accuracy Update - Mechanism

    • ADI Field in Scan Response Data

    • HCI Support for Debug Keys in LE - Secure Connections

  • Main capabilities supported:

    • Simultaneous scanning 1 Mbps and Long Range

    • Scanning and advertising in parallel

    • 24 connections as a central role

    • 24 connections as a peripheral role

    • Any combination of central and peripheral roles (24 connections maximum)

    • 8 connections with a 7.5 ms connection interval

    • Two advertising sets in parallel (\Four adv set as Early Access Release).

    • 26 Accept List entries

    • 36 Resolvable Private Address (RPA) entries

    • Up to two Chain Packets per Extended Advertising set

    • Enhanced Notification on end of - Scanning/Advertising/Connection events

    • Connection event counters associated to Bluetooth LE packet reception

    • Timestamp associated to Bluetooth LE packet reception

    • RF channel info associated to Bluetooth LE packet reception

    • NXP proprietary Bluetooth LE Handover feature

    • Decision Based Advertising Filtering (DBAF)

    • Advertising Coding Selection (ACS)

    • Periodic Advertising with Responses (PAwR) Additional features supported for KW47 and MCX W72 devices:

    • Channel Sounding Additional features supported as EAR (\Early Access Release) in the KW47 experimental build:

    • Channel Sounding TX/SNR. Additional features supported as EAR (\Early Access Release) in the KW45/KW47 experimental builds:

    • LE Test Mode Enhancement (\UTP/OTA).

    • LL Extended Feature Set.

    • Monitoring Advertisers.

    • Randomized Resolvable Private Address (\RPA).

      Note: Project configuration enabling Experimental features on KW45 and MCX W71 requires the Radio Subsystem (NBU) Firmware to be reprogrammed with the firmware provided in the SDK under \middleware\wireless\ble_controller\bin\experimental\. For NBU programming steps, see the EVK Quick Start Guide and Secure Provisioning SDK (SPSDK) documentation.

      Project configurations that require usage of the Bluetooth LE controller including all Bluetooth LE examples require the Radio Subsystem (NBU) Firmware to be re-programmed with the firmware provided in the SDK under middleware\wireless\ble_controller\bin.

Connectivity framework#

The Connectivity Framework is a software component that provides hardware abstraction modules to the upper layer connectivity stacks and components. It also provides a list of services and APIs (see Supported services). The Connectivity Framework modules are located in the middleware\wireless\framework SDK folder.

Supported services#

  • FSCI - Framework Serial Communication Interface

  • FunctionLib - Common function library utilities

  • HWParameter - Hardware parameter management

  • LowPower - Low power mode management

  • ModuleInfo - Module information and versioning

  • NVS - Non-Volatile Storage

  • NVM - Non-Volatile Memory management

  • OtaSupport - Over-The-Air update support

  • SecLib_RNG - Security library and Random Number Generator

  • Sensors - Sensor abstraction layer

  • SFC - Smart Frequency Calibration

  • WorkQ - Work queue management

Supported platform#

  • KW45_MCXW71

  • KW47_MCXW72

  • MCXW23

  • RW61X

  • RT1060 and RT1170

  • i.MX RT595s

Advanced features supported on platforms#

KW45_MCXW71#

  • FRO32K with smart frequency calibration (see SFC)

  • Power down mode support (for evaluation only)

KW47_MCXW72#

  • FRO32K with smart frequency calibration (see SFC)

  • Power down mode support (for evaluation only)

  • Crystal 32M trimming with temperature

  • Debug module for NBU

  • Extended NBU support with SecLib and pseudo RNG support

CMSIS DSP Library#

The MCUXpresso SDK is shipped with the standard CMSIS development pack, including the prebuilt libraries.

memfault-firmware-sdk#

memfault-firmware-sdk

TF-M#

Trusted Firmware - M Library

PSA Test Suite#

Arm Platform Security Architecture Test Suite

NXP PSA CRYPTO DRIVER#

PSA crypto driver for crypto library integration via driver wrappers

secure_storage#

secure_storage

EdgeLock SE050 Plug and Trust Middleware#

Secure subsystem library - SSS APIs

Multicore#

Multicore Software Development Kit

NXP IoT Agent#

NXP IoT Agent

mbedTLS#

mbedtls SSL/TLS library v3.x

mbedTLS#

mbedtls SSL/TLS library v2.x

LittleFS#

LittleFS filesystem stack

FreeMASTER#

FreeMASTER communication driver for 32-bit platforms.

Release contents#

Provides an overview of the MCUXpresso SDK release package contents and locations.

Deliverable

Location

Boards

INSTALL_DIR/boards

Demo Applications

INSTALL_DIR/boards/<board_name>/demo_apps

Driver Examples

INSTALL_DIR/boards/<board_name>/driver_examples

eIQ examples

INSTALL_DIR/boards/<board_name>/eiq_examples

Board Project Template for MCUXpresso IDE NPW

INSTALL_DIR/boards/<board_name>/project_template

Driver, SoC header files, extension header files and feature header files, utilities

INSTALL_DIR/devices/<device_name>

CMSIS drivers

INSTALL_DIR/devices/<device_name>/cmsis_drivers

Peripheral drivers

INSTALL_DIR/devices/<device_name>/drivers

Toolchain linker files and startup code

INSTALL_DIR/devices/<device_name>/<toolchain_name>

Utilities such as debug console

INSTALL_DIR/devices/<device_name>/utilities

Device Project Template for MCUXpresso IDE NPW

INSTALL_DIR/devices/<device_name>/project_template

CMSIS Arm Cortex-M header files, DSP library source

INSTALL_DIR/CMSIS

Components and board device drivers

INSTALL_DIR/components

RTOS

INSTALL_DIR/rtos

Release Notes, Getting Started Document and other documents

INSTALL_DIR/docs

Tools such as shared cmake files

INSTALL_DIR/tools

Middleware

INSTALL_DIR/middleware

What is new#

The following changes have been implemented compared to the previous SDK release version (25.12.00-pvw2).

  • Bluetooth LE Host Stack and Applications

    Added

    • ‘Monitoring Advertisers’ support in the ‘fsci_black_box’ and ‘ble_shell’ applications

    Fixed

    • Missing handler for Version2 of the Set RPA Timeout command

    • Details can be found in github repository nxp-mcuxpresso/mcuxsdk-middleware-bluetooth-host/CHANGELOG.md.

  • Bluetooth LE controller

    • Periodic Advertising updates:

      • Fixed PerAdvSync skip scheduling.

      • Improved PAwR Responses (TX & RX) instant.

      • Fixed calculation of the count parameters in Periodic Advertising Subevent Data Request.

    • Fixed a corner case where LL_CONNECTION_PARAM_REQ is immediately followed by LL_TERMINATE_IND.

  • Transceiver Drivers (XCVR)

    • Added API to control PA ramp type and duration.

  • Connectivity framework

    Major Changes - [wireless_mcu][wireless_nbu] Replaced interrupt masking macros with static inline functions PLATFORM_SetInterruptMask() and PLATFORM_ClearInterruptMask() to ensure consistent BASEPRI value handling across all compilers. This addresses compiler-dependent behavior issues with the previous macro implementation. - [wireless_mcu] Added BASEPRI-based interrupt masking in PLATFORM_RemoteActiveRel() to allow high-priority IRQs while ensuring only IMU0 or thread context can call this function. - [wireless_mcu] Introduced gPlatformUseHwParameter_d compile flag to allow builds without HWParameter section. When undefined or set to 0, crystal trimming functions conditionally access HWParameters only when required. Minor Changes - [wireless_mcu] Set RL_BUFFER_PAYLOAD_SIZE to word-aligned value as expected by rpmsg-lite. - [wireless_mcu] Added system-generated HCI vendor events capability for debug and diagnostic purposes. - [Platform] Simplified enablement of reset features via pin detection - Automatically selects gUseResetByLvdForce_c when gAppForceLvdResetOnResetPinDet_d is enabled. - Automatically select gUseResetByDeepPowerDown_c when gAppForceDeepPowerDownResetOnResetPinDet_d is enabled. - [RNG] Replaced gRngHasSecLibDependency_d compilation switch with gRngUseSecLib_d. Bug fixes - [wireless_mcu] Fixed race condition in PLATFORM_RemoteActiveRel() by adding verification loop to confirm NBU core execution before releasing power domain. - [wireless_mcu] Added instruction synchronization barrier (__ISB()) after interrupt re-enable in PLATFORM_RemoteActiveRel() to ensure pending interrupts execute between critical sections. - [wireless_mcu] Fixed external IO voltage isolation issue during low-power initialization - isolation is now cleared at init to ensure proper behavior. - [wireless_mcu] Replaced spin-wait loops with event-based synchronization in NBU communication APIs. Added mutex protection to PLATFORM_NbuApiReq() and PLATFORM_GetNbuInfo() to prevent race conditions and deadlocks when multiple tasks call these APIs concurrently. - [wireless_mcu] Fixed OSA bare metal event race condition in ICS where auto-clear event feature could cause tasks to become permanently stuck. Disabled auto-clear feature in bare metal builds and manually clear event flags after OSA_EventWait() returns successfully. - [NVM] Fixed NvIdle() to prevent looping for more operations than the queue size. - [NVS] Fixed blank check procedure to return false (non-blank) when checking a 0 length area. - [NVS] Made external and internal flash ports consistent. - [MISRA] Various MISRA compliance fixes in NVM, HWParameter, LowPower, SecLib, Platform modules and IFR offset definitions.

  • IEEE 802.15.4

    • API cleanup: remove unmaintained slotted support

    • support for MAC split architecture

      • fix condition to enter low power

    • minor fixes and stability improvements for connectivity_test example application

  • Zigbee

    • NCP Host Updates and fixes

    • R23 fixes

      • Device can’t establish a new TCLK through ZDO Start Key Update procedure

      • Security Start Key Update Request is not relayed to joining ZED in multi hop key negotiation

    • propagate APS ACK to end-user application

    • documentation updates

Known issues#

This section lists the known issues, limitations, and/or workarounds.

FRO6M Clock Stability Issue#

According to ERRATA ERR052742, the FRO6M clock is not stable on some parts. FRO6M outputs lower frequency signal instead of 6MHz when device is reset or wakes up from low power. It can impact peripherals using it as a clock source.

Impact on TSTMR Module#

The TSTMR (Time Stamp Timer) module exclusively uses the FRO6M clock source. Due to the aforementioned stability issues, avoid using TSTMR-related APIs if your application requires high-precision timing.

Recommendation#

For applications requiring precise timing, consider using alternative timer modules that support more stable clock sources.

New project wizard compile failure#

The following components request the user to manually select other components that they depend upon in order to compile. These components depend on several other components and the New Project Wizard (NPW) is not able to decide which one is needed by the user.

Note: xxx means core variants, such as, cm0plus, cm33, cm4, cm33_nodsp.

Also for low-level adapter components, currently the different types of the same adapter cannot be selected at the same time. For example, if there are two types of timer adapters, gpt_adapter and pit_adapter, only one can be selected as timer adapter in one project at a time. Duplicate implementation of the function results in an error.

Only FreeRTOS is tested for RTOS support#

This release only supports the FreeRTOS kernel and a bare-metal non-preemptive task scheduler.

Bluetooth LE#

Most sensor applications have pairing and bonding disabled to allow a faster interaction with mobile applications. These two security features can be enabled in the app_preinclude.h header file.

Bluetooth LE controller:#

  • The maximum Advertising data length is limited to 800 bytes.

  • The scanner may sporadically miss some chained packets.

Periodic Advertising with Responses (PAwR):

  • Periodic Advertising with Response (PAwR) is not supported with the configuration “Subevent Interval = Number of Response Slots x Response Slot Spacing with Response Slot Spacing = 0x2”.

  • Periodic Advertising placement with connection events is unoptimized.

  • The feature is not functional with the Free-Running Oscillator (FRO32K); it requires a 32 KHz Crystal Oscillator with accuracy less than 50 ppm.

KW45/MCXW71: No specific issues.

KW47/MCXW72: Channel Sounding (CS): Limitations:

  • RTT with Sounding Sequence is not supported.

  • LE 2M 2BT PHY is not supported.

  • Maximum 6 Channel Sounding procedures are supported in parallel.

  • Scheduling of activities may be non optimal when multiple Channel Sounding procedures are running in parallel.

  • Phase measurement bias is within certification range (<1.7x2πns) with KW47 EVK board. However, if different PCB or antenna matching is used, some bias may appear due to increased delay. Known issues:

  • When CS Subevents are configured very close from each other (<700us), some Subevents may be aborted with reason 0x3.

  • When CS offset is configured too close from ACL anchor point, the anchor point may not be served (TX on central or RX on peripheral will not happen). Ideally, CS Offset should be configured greater than 1ms.

  • RTT bias compensation:

    • For parts not properly configured at production (IFR blank), RTT bias may not be compensated properly. Consequently, an inaccuracy of +/-2m may be observed.

Zigbee#

  • OTA interruption is not resuming correctly (for example, when using a reset in the middle of the transfer).

  • Zigbee ZED RX OFF example application on FreeRTOS fails sometime.

  • Minor fixes and stability improvements for connectivity_test example application.

LIN New Project Wizard (NPW) issue#

  • The lin (LIN Driver) and lin_stack (LIN Stack Driver) drivers components should not be enabled at the same time while creating the new projects in MCUXpresso. Otherwise there will be the compiling issue.

  • The lin_stack (LIN Stack Driver) is not actually a driver. It is an adapt layer for LIN Stack middleware to adapt to the low level lpuart driver and cannot be used in NPW alone. So, select the LIN Stack middleware and then the lin_stack is selected automatically since it is required by LIN Stack middleware. Besides, customer need to add the lin_cfg.c/h in application layer for user definition of frame data and add FSL_SDK_LIN_STACK_ENABLE=1 in MCUXpresso preprocessor, otherwise the compiling of LIN Stack will report error.

Flash ROMAPI#

Note that:

  • If using ROM API for internal flash or SPI NOR operation, reserve RAM location 0x200030A0 - 0x200032CF (0x300030A0 - 0x300032CF).

  • If using kb API, reserve 0x20002000 - 0x200032FF (0x30002000 - 0x300032FF).

Other limitations#

  • The following Connectivity Framework configurations are Experimental and not recommended for mass production:

    • Power down on application power domain.

  • GenFSK Connectivity_test application is not operational with Low Power enabled.

  • Serial manager is only supported on UART (not I2C nor SPI).

  • The --no-warn-rwx-segments cannot been recognized on legacy MCUXpresso IDE versions.

    The --no-warn-rwx-segments option in MCUXpresso projects should be manually removed from the project settings if someone needs to use legacy (< 11.8.0) MCUXpresso IDE versions

  • If the FRO32K is configured as the clock source of the CM33 Core then the debug session will block in both IAR, MCUX CMSIS-DAP while debugging. Use a lower debug wire speed, for example 1 MHz instead of the default one.

    In IAR, the option is in Runtime Checking -> Debugger -> CMSIS DAP -> Interface -> Interface speed.

    In MCUXpresso IDE, the option is in LinkServer Debugger -> Advanced Settings -> Wirespeed (Hz).

Implementation Status of el2go Examples#

El2go examples have been implemented but have not been verified on specified platforms. The only verification performed so far is through automation, where we check whether the application boots successfully. However, no el2go-specific verification has been conducted to confirm functionality beyond the boot process.

Examples: el2go_blob_test, el2go_import_blob

Affected toolchains: All

Contents