Simplicity SDK 2024.6 to Simplicity SDK 2024.12: what needs attention

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.

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.

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.

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.

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.

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/.

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.

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.