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 is compiled and tested with these development tools:
IAR Embedded Workbench for Arm, version is 9.60.3
MCUXpresso IDE, Rev. 24.12
MCUXpresso for VS Code v24.12
GCC Arm Embedded Toolchain 13.2.1
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 |
MCXW716AMFPA, MCXW716AMFTA, MCXW716CMFPA, |
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 Bluetooth LE host stack and applications
The Bluetooth LE Host Stack component provides an implementation for a Bluetooth LE mandatory and some optional, proprietary, and experimental features. The Bluetooth LE Host Stack component provides application examples, services, and profiles.
Main features supported:
Automotive Compliance
MISRA Compliance
HIS CCM <= 20
Advanced Secure Mode
Enhanced ATT
GATT Caching
Bluetooth LE Host GCC Libraries
Bluetooth LE Host IAR Libraries
Bluetooth LE Host Peripheral Libraries
Bluetooth LE Central Libraries
Bluetooth LE Host Full Host Features Libraries
Bluetooth LE Host Optional Features Libraries
Bluetooth LE Host Mandatory Features Libraries
Bare-metal and FreeRTOS Support
Bluetooth LE Privacy Support
CCC Sample Applications
Enhanced Notifications
Dynamic Database
OTA Support - Sample Applications
Decision based Advertising Filtering (DBAF) - Experimental feature
Advertising Coding Selection (ACS) - Experimental feature
Channel Sounding - Experimental feature with controlled access (contact your NXP representative for access)
Bluetooth LE Controller main and experimental features and capabilities described below are supported by the Bluetooth LE Host.
Note: For evaluating DBAF and ACS experimental features, replace the Bluetooth LE Host default example projects libraries with the libraries from the SDK folder ..\middleware\wireless\bluetooth\host\lib_exp and enable the features in the application. The Radio Subsystem (NBU) Firmware with experimental features is required.
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
26 Accept List entries
36 Resolvable Private Address (RPA) entries
Up to six 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) - Experimental feature. See Note below.
Advertising Coding Selection (ACS) - Experimental feature. See Note below.
Periodic Advertising with Responses (PAwR) - Experimental feature. See Note below. Additional features supported for KW47 and MCX W72 devices:
Channel Sounding - Experimental feature
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.
GenFSK link layer
The Generic FSK protocol enables radio operation using a custom GFSK/GMSK or MSK modulation format.
Main Features supported:
Highly configurable packet structure
Optimized Sequence Command Set
High-precision timebase to maintain network timing
Two timer-compare mechanisms for Interrupt Generation and Sequence Launching
Hardware automation for packet transmit and receive, CRC and Whitening
Up to four network addresses to synchronize to, can be 8-bit, 16-bit or 32-bit
Packet Lengths up to 2047 Bytes
Support complex auto-sequence, like CCA before TX, Auto-ACK, TR.
Many operating modes can support the sending and receiving of multiple protocol packets, such as Bluetooth LE.
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.
Wireless 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, such as, Low power, Over the Air (OTA) Firmware update, File System, Security, Sensors, Serial Connectivity Interface (FSCI), and others. The Connectivity Framework modules are located in the middleware\wireless\framework SDK folder.
Wireless Low-power reference design applications (central and peripheral)
The Low-Power Reference Design Applications provide reference design source code and projects showcasing how to implement optimized low power functionality based on a Bluetooth LE application. For additional details, see the readme.md.
CMSIS DSP Library
The MCUXpresso SDK is shipped with the standard CMSIS development pack, including the prebuilt libraries.
memfault-firmware-sdk
memfault-firmware-sdk
NXP PSA CRYPTO DRIVER
PSA crypto driver for crypto library integration via driver wrappers
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.03.00-pvw2).
Bluetooth LE host stack and applications
Added
L2CAP support for Channel Sounding IQ Sample Transfer in CCC CS sample applications.
Bluetooth LE Sample applications for MCX-W71-EVK board.
Changed
Updated FSCI XML file.
Updated Bluetooth LE Host Documentation.
Fixed
Cleared the mpRemoteCachedCaps entry when the peer disconnects (CS sample applications).
EAD - Updated advertising data length check to ensure encrypted data fits inside one AD.
Details can be found in CHANGELOG.md.
Bluetooth LE controller
Minor fixes and stability improvements
Transceiver Drivers (XCVR)
Added API to control PA ramp type and duration
Connectivity framework
Minor Changes (no impact on application)
General
[General] Various MISRA/Coverity fixes in framework: NVM, RNG, LowPower, SecLib and platform files
Services
[SecLib_RNG] fix return status from RNG_GetTrueRandomNumber() function: return correctly gRngSuccess_d when RNG_entropy_func() function is successful
[SFC] Allow the application to override the trig sample number parameter
[Settings] Re-define the framework settings API name to avoid double definition when gSettingsRedefineApiName_c flag is defined
Platform specific
[wireless_mcu] fwk_platform_sensors update :
Enable temperature measurement over ADC ISR
Enable temperature handling requested by NBU
[wireless_mcu] fwk_platform_lcl coex config update for KW45
Note
[HwParameter] By default, hardware parameters are located in both main flash and IFR. Main flash and IFR needs to be erased if you want to erase the actual hardware parameters.
Details can be found in CHANGELOG.md
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.
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:
Max number of connections supported : 8
Potential instabilities particularly with short Connection Intervals
Channel Sounding (CS) not supported:
RTT with Random sequence
RTT Random sequence NADM
TX SNR
LE 2M 2BT PHY
More than one CS procedure in parallel
Potential instabilities with small CS offset or small subevent interval
TQI not accurate
Periodic Advertising with Responses (PAwR):
Incorrect data in Periodic Advertising Response is reported if AUX_SYNC_SUBEVENT_RSP contained an extended header.
Sync device cannot synchronize on more than 32 subevents.
Connection establishment using PAwR in LE Coded PHY can potentially fail.
Data report can potentially be truncated on the first AUX_ADV_IND of an extended advertising train containing an ACAD field.
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.
XTAL32K less board with FRO32K support.
FRO32K notifications callback is for debug only. Application shall not execute long processing (such as PRINTF) as it is executed in ISR context.
A hardfault can be encountered when using fsl_component_mem_manager_light.c memory allocator and shutting down some unused RAM banks in low power. It is due to a wrong reinitialization of ECC RAM banks. To be sure not to reproduce the issue,
gPlatformShutdownEccRamInLowPower
should be set to 0.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 versionsIf 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).
Low power reference design applications are not supported for the armgcc toolchain from zip archives. Please use MCUXpresso IDE or IAR toolchains for development using these applications.
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
Annexure: Zigbee PRO 2023 dynamic link key negotiation
There are two types of DLK negotiations. When the requester of a new TCLK is not yet authorized in the network (does not have the network key), the process is called off-network DLK negotiation. This occurs after the parent replies with the Network Commissioning Response. Once a node is fully joined and authorized, it can request a new TCLK from the trust center. If both nodes, the TC and the requester, supports DLK, they shall use the on-network DLK Negotiation method instead of the Zigbee 3.0 Request Key method. The on-network DLK can be triggered using the Node Descriptor request from the initiator to the trust center. The stack appends the Supported Key Negotiation method TLV to the request and the response contains the Selected Key Negotiation method TLV. If the Trust Center approved the DLK, the stack of the initiator initiates the key negotiation process.
The coordinator R23 and Router R23 examples contain code which activates the DLK, off- and on-network. The code is provided for experimentation as the DLK feature set is not fully implemented nor tested. It is enabled by changing the following macro:
**\#ifdef** R23_UPDATES
/* Uncomment this to enable DLK with AES-128 */
//#define R23_DLK_AES128_ENABLE 1
**\#endif**
AIB attributes
The AIB attribute apsSupportedKeyNegotiationMethods
is a bit mask, which indicates the set of supported key negotiation methods by the local device. The set of valid values corresponds to the Supported Key Negotiation Methods Global TLV, which can be found in the ZigbeeCommon/Include/tlv.h
file. Only the Hash AES-MMO-128 method is supported in this experimental preview.
**\#define** ZPS_TLV_G_SUPPKEYNEGMETH_STATKEYREQ (1) /* Zigbee 3.0 Mechanism */
**\#define** ZPS_TLV_G_SUPPKEYNEGMETH_SPEKEAES128 (2) /* SPEKE using Curve25519 with Hash AES-MMO-128 */
**\#define** ZPS_TLV_G_SUPPKEYNEGMETH_SPEKESHA256 (4) /* SPEKE using Curve25519 with Hash SHA-256 */
At a minimum the device SHALL support one method, the key request method.
The AIB attribute u8SharedSecretsMask
is a bit mask which indicates the set of supported shared secrets by the local device. The set of valid values corresponds to the supported key negotiation methods global TLV, which can be found in the ZigbeeCommon/Include/tlv.h
file. Only the values (1) and (4) are supported, together with the default apscWellknownPSK
.
**\#define** ZPS_TLV_G_PSK_SYMMETRIC (1) /* Symmetric authentication token */
**\#define** ZPS_TLV_G_PSK_INSTALLCODE (2) /* Pre-configured link-ley derived from installation code */
**\#define** ZPS_TLV_G_PSK_PASSCODE (4) /* Variable-length pass code (for PAKE protocols) */
**\#define** ZPS_TLV_G_PSK_BASICAUTH (8) /* Basic Authorization Key */
**\#define** ZPS_TLV_G_PSK_ADMINAUTH (16) /* Administrative Authorization Key */
Setting these attributes in the AIB is done using the API ZPS_teStatus ZPS_eAplAibSetKeyNegotiationOptions(uint8 u8Methods, uint8 u8SharedSecrets)
. The return value is always ZPS_E_SUCCESS
.
Joiner TLVs
The device wanting to join an R23 network shall send the Network Commissioning Request command communicates information to the parent device with the Joiner TLVs directly in the message. The device shall include the Joiner Encapsulation Global TLV. In a multi-hop joining scenario the Trust Center and parent device will not be the same entity. Information about the sending device is communicated to the Trust Center through the Joiner Encapsulation Global TLV, which will be relayed in its entirety in the Update Device message. When a device creates the Joiner Encapsulation Global TLV it shall contain the following TLVs inside it:
Fragmentation Parameters Global TLV
If the device is not rejoining: Supported Key Negotiation Methods Global TLV
The Router R23 example contains the following code to set the Joiner TLVs before calling the stack initialization. These TLVs will be used by the stack as additional payload in the joining command. Their content is configured independently from the AIB attributes configuring the local node’s key negotiation options.
TLV_ENCAPS(g_sJoinerTlvs,
APP_SIZE_JOINREQ_TLV,
m_, tuTlvTestSpecific1,
m_, tuFragParams,
m_, tuSupportedKeyNegotiationMethods,
m_, tuTlvTestSpecific2) =
{
.u8Tag = ZPS_TLV_G_JOINERENCAPS, .u8Len = APP_SIZE_JOINREQ_TLV - 1,
/* This TLV is sent inside the Joiner Encapsulation */
{ .u16ZigbeeManufId = 0x1234, .au8Extra[0] = 0xAA, .au8Extra[1] = 0xBB,
.u8Tag = ZPS_TLV_G_MANUFSPEC, .u8Len = sizeof(tuTlvTestSpecific1) - 1 - ZPS_TLV_HDR_SIZE
},
{ .u16NodeId = 1, .u8FragOpt = 2, .u16InMaxLen = 10,
.u8Tag = ZPS_TLV_G_FRAGPARAMS, .u8Len = sizeof(tuFragParams) - 1 - ZPS_TLV_HDR_SIZE
},
{ .u8KeyNegotProtMask = ZPS_TLV_G_SUPPKEYNEGMETH_STATKEYREQ
| R23_DLK_KEY_PROTO_NEGOTIATION_MASK,
.u8SharedSecretsMask = R23_DLK_SHARED_SECRETS_MASK,
),