Home › SDK migration

SDK upgrade guide

Simplicity SDK 2025.6 to Simplicity SDK 2026.6: what needs attention

Migratorisk's knowledge base lists 17 documented changes between Simplicity SDK 2025.6 and Simplicity SDK 2026.6 across 5 releases. 6 of them are rated likely to break code, configuration or builds that use them. Below is each change, what a scan also reviews on this path, and how to see which ones apply to your project.

17documented changes
6rated will or likely to break
9review checks on this path

Find which of these affect your firmware

Migratorisk scans your project on your own computer and reports only the changes your code, configuration and build actually touch. Your source code is not uploaded.

python -m pip install migratorisk
migratorisk scan --project ./your-firmware --from simplicity-sdk-2025.6.0 --to simplicity-sdk-2026.6.0 --out report.html

Requires Python 3.12 or newer. Results are free and complete without sign-up; sharing a report with us is optional.

Set up the local scanOr answer a few questions instead

Where the changes are

Component settings · 5Compiler and toolchain · 3Radio and RF · 3Bluetooth · 2SDK components · 2Zigbee stack · 1System services · 1

What changes between Simplicity SDK 2025.6 and Simplicity SDK 2026.6

Ordered by impact. Each item names the release that introduced it and links to the official source. A change only matters if your project uses what changed; the scan checks that.

Likely to break

Zigbee 9.0: Zigbee 4.0 / R23 stack and a new EZSP version

Zigbee stack · Simplicity SDK 2025.12.0 · Source

Zigbee 9.0 (Simplicity SDK 2025.12) is a Zigbee 4.0 (BDB 3.1, R23) stack using EZSP protocol version 0x12, so hosts and NCPs must be updated together, and IAR is not supported for Series 3 in this release. Covers 3 names.

Likely to break

Bluetooth LE 11.0 removes deprecated APIs

Bluetooth · Simplicity SDK 2025.12.0 · Source

Bluetooth LE 11.0 (Simplicity SDK 2025.12) removed the previously deprecated sl_bt_system_reset and sl_bt_sm_set_bonding_key, and NCP host applications must be rebuilt against 2025.12 because event payloads changed. Covers 2 names.

Likely to break

Component sl_rail_sdk_simple_cpc removed in Simplicity SDK 2025.6.2

SDK components · Simplicity SDK 2025.6.2 · Source

Simple RAIL CPC for NCP projects component has been modified, removed not needed requires.

Likely to break

Component sl_rail_sdk_simple_cpc_spi removed in Simplicity SDK 2025.6.2

SDK components · Simplicity SDK 2025.6.2 · Source

Simple RAIL CPC for NCP projects (SPI) component has been modified, removed not needed requires.

Likely to break

Simplicity SDK 2025.12 moves to Conan packages and Simplicity Studio 6

Compiler and toolchain · Simplicity SDK 2025.12.0 · Source

From 2025.12 the SDK is delivered as modular Conan packages through Silicon Labs Tools (SLT 1.1.0 or newer), with a new directory layout. The GitHub copy is for reference only, Studio 5 supports releases up to 2025.6, and SDK paths move from ~/SimplicityStudio/SDKs/simplicity_sdk to versioned SLT package folders.

Likely to break

sl_802154_radio_set_scheduler_priorities removed

Radio and RF · Simplicity SDK 2025.12.1 · Source

The 802.15.4 + BLE multiprotocol API sl_802154_radio_set_scheduler_priorities, deprecated in 2025.12.0, was removed in 2025.12.1.

Needs attention

Bluetooth controller power amplifier settings move to SL_RAIL_UTIL_PA

Radio and RF · Simplicity SDK 2025.12.0 · Source

In Bluetooth LE 11.0 all power amplifier configuration, including automatic PA selection, is done through the SL_RAIL_UTIL_PA component; the controller's own automatic PA mode was removed.

Needs attention

Compilers move to GCC 14.2 and IAR 9.70.4

Compiler and toolchain · Simplicity SDK 2026.6.0 · Source

Simplicity SDK 2026.6 is delivered with GCC 14.2.rel1 and IAR Embedded Workbench 9.70.4 (previous releases used GCC 12.2.1). Newer compilers add warnings, change optimisation and code size, and may reject code older ones accepted.

Needs attention

Micrium OS restricted to Series 2 devices

System services · Simplicity SDK 2025.12.0 · Source

Micrium OS 6.0 (Simplicity SDK 2025.12) is restricted to Series 2 devices.

Needs attention

RAIL 3.0

Radio and RF · Simplicity SDK 2025.12.0 · Source

Simplicity SDK 2025.12 updates RAIL to 3.0, with changes to initialization, FIFOs and TX power management.

Needs attention

Studio 5 IAR IDE projects do not open in Studio 6

Compiler and toolchain · Simplicity SDK 2025.12.0 · Source

Projects created in Simplicity Studio 5 with the Simplicity IDE and the IAR toolchain are not supported by Studio 6; the IAR EWARM or CMake generator must be enabled before or after migration.

Needs attention

bluetooth_ncp_transport_usart deprecated

Bluetooth · Simplicity SDK 2026.6.0 · Source

Bluetooth LE 11.1 (Simplicity SDK 2026.6) deprecates the bluetooth_ncp_transport_usart component in favour of bluetooth_ncp_transport_iostream, removes host adaptation IRQ priority settings, and deprecates older core/controller buffer and RF path gain configurations.

Worth checking

Configuration option APP_BUTTON_PRESS_WAKEUP_DELAY renamed to APP_BUTTON_PRESS_WAKEUP_DELAY_MS in Simplicity SDK 2025.6.1

Component settings · Simplicity SDK 2025.6.1 · Source

APP_BUTTON_PRESS_WAKEUP_DELAY was renamed to APP_BUTTON_PRESS_WAKEUP_DELAY_MS.

Worth checking

Configuration option LONG_BUTTON_PRESS_DURATION renamed to LONG_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1

Component settings · Simplicity SDK 2025.6.1 · Source

LONG_BUTTON_PRESS_DURATION was renamed to LONG_BUTTON_PRESS_DURATION_MS.

Worth checking

Configuration option MEDIUM_BUTTON_PRESS_DURATION renamed to MEDIUM_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1

Component settings · Simplicity SDK 2025.6.1 · Source

MEDIUM_BUTTON_PRESS_DURATION was renamed to MEDIUM_BUTTON_PRESS_DURATION_MS.

Worth checking

Configuration option MIN_VALID_BUTTON_PRESS_DURATION renamed to MIN_VALID_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1

Component settings · Simplicity SDK 2025.6.1 · Source

MIN_VALID_BUTTON_PRESS_DURATION was renamed to MIN_VALID_BUTTON_PRESS_DURATION_MS.

Worth checking

Configuration option SHORT_BUTTON_PRESS_DURATION renamed to SHORT_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1

Component settings · Simplicity SDK 2025.6.1 · Source

SHORT_BUTTON_PRESS_DURATION was renamed to SHORT_BUTTON_PRESS_DURATION_MS.

What a scan of this path also reviews

Beyond the documented changes, Migratorisk reviews these upgrade risks for Silicon Labs SDK projects on this path. Each one is reported only when the project shows the trigger.

Field updates must still be accepted by the bootloader on deployed devices

When it applies: The application updates itself in the field (OTA DFU, AppLoader, Zigbee OTA or Mesh DFU) through the Gecko Bootloader already on each device.

Why it matters: New releases change stack sizes and defaults, often growing the image; the new application must still fit the bootloader's download slot and use the same signing keys.

What to do: Keep the GBL signing and encryption keys, the storage slot layout and the application start address; check the new image size against the download slot; rehearse an update from the production firmware and bootloader.

RTOS start-up through sl_system is removed in Simplicity SDK 2026.6

When it applies: The project runs an RTOS and starts it through sl_system (sl_system_kernel_start).

Why it matters: Silicon Labs deprecated sl_system in 2025.6.0 and announced that sl_system support for RTOS applications is removed in 2026.6.0; RTOS projects must start through sl_main.

What to do: Move the start-up to sl_main (app_init and app_process_action hooks, tasks created from app_init) following Silicon Labs' sl_system to sl_main migration guide.

SDK extensions must move to versions built for the target SDK

When it applies: The project uses SDK extensions (for example Matter, WiSeConnect or AI/ML) on top of the Silicon Labs SDK.

Why it matters: Each extension release is built and tested against one SDK release. Mixing versions fails to generate or builds an untested combination.

What to do: Pick the extension release that names the target SDK in its release notes and upgrade it together with the SDK.

A copy of the SDK lives inside the project

When it applies: The project contains a copied Gecko or Simplicity SDK folder instead of linking to an installed SDK.

Why it matters: An upgrade does not touch the copy. Local patches to it are easily lost or silently kept, and the build may mix old and new SDK files.

What to do: List local changes to the copied SDK (diff it against the matching release), then replace the copy with the target SDK and re-apply only the changes still needed.

Zigbee host and NCP must be upgraded together

When it applies: The project is a Zigbee host application that talks to an NCP over EZSP.

Why it matters: EZSP versions change between SDK releases; a host only talks to an NCP built with a compatible stack.

What to do: Upgrade host and NCP firmware as one release, and make sure the host can still reflash an NCP that runs the old firmware.

Updating the Gecko Bootloader itself

When it applies: The repository builds a Gecko Bootloader with the SDK.

Why it matters: A new bootloader must keep the storage layout, keys and application interface of the one on deployed devices, and it can only be replaced in the field if the bootloader upgrade path was planned.

What to do: Decide whether deployed devices keep their current bootloader (usual) or receive a bootloader upgrade; if so, test the upgrade image on production devices before release.

The project must be upgraded and regenerated with SLC

When it applies: Silicon Labs projects are generated from the .slcp by SLC (Simplicity Studio or slc-cli).

Why it matters: New releases rename, split and remove components and configuration options (Silicon Labs' upgrade rules apply most of these automatically), and regenerate autogen/ and config headers.

What to do: Run the project upgrade (Simplicity Studio's Upgrade, or slc upgrade) on a clean branch, regenerate, then review the diff of config/ and the .slcp before touching application code. Never keep hand edits in autogen/.

Stored data must survive the update

When it applies: The firmware keeps data in NVM3 or tokens (network keys, bonding data, Mesh provisioning, application settings).

Why it matters: Stack releases occasionally change stored data formats (for example the Bluetooth Mesh model storage format in 2025.6); data written by the old firmware must still be read correctly.

What to do: Update a device that has real stored data (joined network, bonded phone, provisioned node) from the production firmware and check it keeps working without re-pairing or re-commissioning.

Check the Secure Engine firmware required by the target SDK

When it applies: The project targets a Series 2 device, whose Secure Engine runs its own firmware.

Why it matters: Newer SDKs are released with a matching Secure Engine firmware version; security features and some PSA Crypto behaviour depend on it, and devices in the field keep the SE firmware they shipped with unless it is updated.

What to do: Compare the SE firmware version on production devices with the one in the target SDK's platform release notes, and decide whether the update must include an SE firmware upgrade.

VelocityCreate

Want us to handle the upgrade?

VelocityCreate can review your assessment, agree on the migration scope, and carry out the firmware changes and agreed verification. Discuss your deadline, hardware, and requirements with an embedded engineer.

Discuss my migrationBook a technical call

The initial discussion is free. Implementation is quoted separately.

Related upgrade paths

Generated from the rule catalog of Migratorisk 0.3.0. This is an automated summary of published SDK changes, not a review of your project, and it does not replace builds and device tests. How the scanner is validated.