NXP Matter Documentation
Source (.md/.rst) Page PDF (.pdf)

Known Issues v1.6.0.0.1

Known Issues v1.6.0.0.1#

OTA compatibility#

OTA update from v1.4.2 to v1.6.0 not supported#

Problem: OTA updates between versions v1.4.2 and v1.6.0 are not supported.

Root Cause: File system compatibility is not satisfied between the v1.4.2 and v1.6.0 releases due to the migration from Mbed TLS 2.x to Mbed TLS 3.x with PSA Crypto API and associated storage format changes.

Workaround: Perform a factory reset before upgrading from v1.4.2 to v1.6.0 or ask your NXP representative for further help.

Potential build issues#

CMake build failure with multiple MCUXpresso SDK versions#

Problem: If you have previously exported different versions of the MCUXpresso SDK, you may encounter a CMake build error similar to:

CMake Error: Cannot open file for write: /devices/Wireless/RW/RW612/cmake_install.cmake.tmpa2a74
CMake Error: : System Error: No such file or directory

Root Cause: This error occurs because CMake attempts to load an older cached MCUXpresso SDK package instead of the most recently exported version, leading to path conflicts and missing files.

Workaround:

  1. Delete all existing MCUX SDK CMake packages from your user environment:

    rm -rf ~/.cmake/packages/McuxSDK

  2. Re-export the updated SDK by running this command in your root sdk:

    west mcuxsdk-export

  3. Clean and rebuild your project.

Windows path length limitations causing build failures#

Problem: On Windows systems, compilation can fail with “file not found” errors or similar issues, even when the files exist. The issue is caused due to Windows’ limitation on maximum path length (260 characters by default).

Symptoms:

  • Build failures with missing file errors

  • Compilation stops unexpectedly during the build process

  • Files that exist in the file system are reported as not found

Root Cause: Windows has a default maximum path length limitation that can cause issues when building projects with deeply nested directory structures or long filenames.

Prevention: To avoid path length issues on Windows, follow these recommendations:

  1. Clone the SDK close to the root directory:

    • Clone the SDK as close as possible to the root C:/ drive

    • Choose a short name for the SDK directory. For example, C:/sdk instead of C:/Users/username/Documents/my-long-project-name/mcuxsdk.

  2. Use short paths for freestanding folders:

    • When creating a freestanding folder, prefer a location as close as possible to the SDK

    • Keep the folder name short and avoid deeply nested directory structures

  3. Shorten build directory names in the VS Code extension:

    • When using the MCUXpresso for VS Code Extension with build configurations other than “debug” and “release”, edit the configuration and change the build directory to a shorter name

    • This is especially important for repository applications, which tend to have longer build directory paths

Kconfig string values not preserved when passed via “CMake Extra Args” (MCUXpresso for VS Code Extension)#

Problem: When using the MCUXpresso for VS Code Extension, string values passed through “CMake Extra Args” in the build configuration are not preserved as expected. Specifically, when passing string Kconfig values like CONFIG_CHIP_DEVICE_SOFTWARE_VERSION_STRING="2.0", the quotes are stripped during the build process.

Symptoms:

  • String-type Kconfig overrides via “CMake Extra Args” are not reflected in the build

  • Configuration values appear without quotes or are not applied correctly

Workaround: Manually update the example’s prj.conf file when overriding string Kconfig values:

  1. Navigate to the “Project files” section in the VS Code extension

  2. Locate and open the prj.conf file for your project

  3. Add or modify the desired Kconfig string values directly in the file. For example, CONFIG_CHIP_DEVICE_SOFTWARE_VERSION_STRING="2.0".

  4. Save the file and rebuild your project

Bootstrap scripts require Python >= 3.11#

Problem: The Matter 1.6 environment now enforces a Python version >= 3.11. Using an older Python version results in an error during environment setup.

Workaround: Ensure Python 3.11 or later is installed and active in your environment before running bootstrap scripts.

Known functional issues#

The following functional issues are grouped by platform and build system.

RW612 (Zephyr)#

Transport

Test Case

Description

Wi-Fi

TC-SC-5-2

ViewGroup returns NOT_FOUND even after AddGroup is sent successfully.

Thread

BLE-Thread commissioning

The DUT may reset unexpectedly during BLE-Thread commissioning when using factory data.

Thread

TC-CNET-4.12

The DUT fails to connect on THREAD_1ST_OPERATIONALDATASET.

Thread

TC-IDM-4.2

The subscription report is not sent.

Wi-Fi

Shell command

The matter wifi disconnect shell command does not work.

Wi-Fi / Thread

TC-G-2.3

The Identify cluster is not correctly supported in the provided example, causing test failures such as TC-G-2.3.

Wi-Fi / Thread

TC-SU-2.6

The boot reason may be incorrect after rebooting following a software update.

MCX W72 (Zephyr)#

Transport

Test Case

Description

Thread

Stress scenario

Some packets may be dropped during high traffic scenarios.

i.MX RT1060 + IW610 (FreeRTOS)#

Transport

Test Case

Description

Thread

TC-DD-3.19

The DUT is not removed from the fabric after a remove-fabric command.

MCX W72 (FreeRTOS)#

Transport

Test Case

Description

Thread

Contact sensor (LIT)

A contact sensor LIT device may present instability in slow poll mode when logging is enabled. As a workaround, disable logging, or disable power-down if logging must remain enabled.

RW612 (FreeRTOS)#

Transport

Test Case

Description

Wi-Fi + OTBR

Secondary Thread interface

With a secondary Thread interface, commissioning may fail when commissioning over the secondary network interface (commissioning over Thread).

Known limitations#

MCX W72 limitations#

RAM bank retention management (FreeRTOS)#

If RAM usage or heap size increases, the link symbol lp_ram_upper_limit in the application’s nxp_sdk_reconfig.cmake must be updated manually. This ensures that all RAM banks up to this address are kept in retention during sleep.

Note: lp_ram_upper_limit is computed as the .heap start address (which can be found in the map file) plus the heap size.