SDK upgrade guide
Simplicity SDK 2025.6 to Simplicity SDK 2025.12: what needs attention
Migratorisk's knowledge base lists 14 documented changes between Simplicity SDK 2025.6 and Simplicity SDK 2025.12 across 3 releases. 5 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.
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-2025.12.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 insteadWhere the changes are
What changes between Simplicity SDK 2025.6 and Simplicity SDK 2025.12
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.
Zigbee 9.0: Zigbee 4.0 / R23 stack and a new EZSP version
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.
Bluetooth LE 11.0 removes deprecated APIs
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.
Component sl_rail_sdk_simple_cpc removed in Simplicity SDK 2025.6.2
Simple RAIL CPC for NCP projects component has been modified, removed not needed requires.
Component sl_rail_sdk_simple_cpc_spi removed in Simplicity SDK 2025.6.2
Simple RAIL CPC for NCP projects (SPI) component has been modified, removed not needed requires.
Simplicity SDK 2025.12 moves to Conan packages and Simplicity Studio 6
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.
Bluetooth controller power amplifier settings move to SL_RAIL_UTIL_PA
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.
Micrium OS restricted to Series 2 devices
Micrium OS 6.0 (Simplicity SDK 2025.12) is restricted to Series 2 devices.
RAIL 3.0
Simplicity SDK 2025.12 updates RAIL to 3.0, with changes to initialization, FIFOs and TX power management.
Studio 5 IAR IDE projects do not open in Studio 6
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.
Configuration option APP_BUTTON_PRESS_WAKEUP_DELAY renamed to APP_BUTTON_PRESS_WAKEUP_DELAY_MS in Simplicity SDK 2025.6.1
APP_BUTTON_PRESS_WAKEUP_DELAY was renamed to APP_BUTTON_PRESS_WAKEUP_DELAY_MS.
Configuration option LONG_BUTTON_PRESS_DURATION renamed to LONG_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1
LONG_BUTTON_PRESS_DURATION was renamed to LONG_BUTTON_PRESS_DURATION_MS.
Configuration option MEDIUM_BUTTON_PRESS_DURATION renamed to MEDIUM_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1
MEDIUM_BUTTON_PRESS_DURATION was renamed to MEDIUM_BUTTON_PRESS_DURATION_MS.
Configuration option MIN_VALID_BUTTON_PRESS_DURATION renamed to MIN_VALID_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1
MIN_VALID_BUTTON_PRESS_DURATION was renamed to MIN_VALID_BUTTON_PRESS_DURATION_MS.
Configuration option SHORT_BUTTON_PRESS_DURATION renamed to SHORT_BUTTON_PRESS_DURATION_MS in Simplicity SDK 2025.6.1
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.
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 callThe initial discussion is free. Implementation is quoted separately.
Related upgrade paths
- Gecko SDK 4.4 to Simplicity SDK 2025.6
- Simplicity SDK 2024.12 to Simplicity SDK 2025.6
- Simplicity SDK 2025.6 to Simplicity SDK 2026.6
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.