AI SDK for Zephyr#

Prerequisites#

This guide assumes that all dependencies from Getting Started with Simplicity SDK for Zephyr are already installed.

Important: Skip the west workspace creation steps (specifically west init and west update) from the Getting Started with Simplicity SDK for Zephyr guide. Follow the workspace setup included in this guide instead.

AI SDK for Zephyr Installation#

Install the Simplicity AI SDK for Zephyr before you create or validate a Zephyr application with the AI SDK tools.

Follow the instructions on the Simplicity Installer page.

Workspace Creation#

Create a T2 west workspace so the Zephyr application, manifest, and imported modules are available under one workspace root.

T2 Workspace Topology#

T2 refers to a star topology in which the application is the manifest repository.

A T2 west workspace is recommended for application development with the AI SDK for Zephyr.

The following example shows the structure of a T2 west workspace:

workspace/
│
├── app/                 # .git/
│   ├── CMakeLists.txt
│   ├── prj.conf
│   ├── src/
│   │   └── main.c
│   └── west.yml         # main manifest with optional imports and overrides
│
├── modules/
│   ├── hal/
│   │   ├── silabs/
│   │   └── silabs_extra/
│   └── ...
│
├── zephyr/               # imported by application/west.yml
│   └── west.yml
│
└── zephyr-silabs/        # imported by application/west.yml
    └── west.yml

Place the main manifest in the app directory as west.yml.

The manifest defines the workspace, including required imports and overrides. It should import the preferred release or latest version of the zephyr-silabs repository as a west project.

The following example shows a simple main manifest:

# app/west.yml

manifest:
  remotes:
    - name: silabs
      url-base: https://github.com/SiliconLabsSoftware

  projects:
    - name: zephyr-silabs
      remote: silabs
      revision: v2026.6.0   # Preferred release tag
      import: true

  self:
    path: app

To create a T2 workspace:

  1. Create the workspace directory.

  2. Create the app directory inside the workspace.

  3. Create west.yml in the app directory and use it as the main manifest.

  4. From the workspace directory, initialize the west workspace by running west init -l app.

  5. Update the west workspace by running west update.

  6. Fetch the required HAL blobs by running west blobs fetch hal_silabs.

  7. If the Zephyr SDK toolchain is not already installed, run west sdk install from the workspace directory.

The T2 topology is recommended instead of developing a freestanding application outside a west workspace.

In a freestanding application, zephyr-silabs is initialized in one directory while the application resides in an unrelated directory. The build locates Zephyr through the ZEPHYR_BASE environment variable (set by sourcing zephyr-env.sh/ zephyr-env.cmd) or a CMake package registry entry (registered by running west zephyr-export).

This approach works, but it distributes the application and its dependencies across unrelated paths. The relationship between these paths exists only through environment state.

With the T2 topology, the application is the manifest repository. Its west.yml is both the entry point for the code and the single source of truth for every imported module. West resolves the modules under one workspace root.

This structure gives AI agents a predictable, self-contained context. Starting from the application directory, an agent can discover and index the build configuration and dependencies directly from the filesystem. It does not need to rely on environment variables or external registries that are not visible through static inspection.

As a result, AI agents can locate relevant files, analyze changes across modules, and run builds more reliably.

Usage#

Use the Simplicity AI SDK for Zephyr to create, validate, and iterate on Zephyr applications for Silicon Labs hardware.

Example Usage#

The best way to introduce the AI SDK is to use it to develop a simple application.

The following example creates a Bluetooth Low Energy (BLE) relative humidity and temperature (RHT) sensor application.

Hardware#

This example uses the xg24_rb4186c board, but you can use any supported Series 2 radio board with an RHT sensor, such as the Si7021, to follow this example.

Starting Point#

Start with an existing sample application from zephyr or zephyr-silabs. This lets you verify basic build, flash, and runtime behavior before adding functionality with the AI SDK.

Prompt

I am developing a BLE-based relative humidity and temperature (RHT) sensor. Which existing Zephyr sample would be the most suitable starting point?

The agent loads the slab-zephyr-workflow skill, which is the root skill for AI SDK development on Zephyr. This skill describes the available tools and skills and when to use them.

The agent checks the local west workspace or uses the silabs_ai_sdk_search_docs tool from the silabs-knowledge-base MCP server to find a suitable sample application.

Agent response

Use samples/bluetooth/peripheral_esp (zephyr/samples/bluetooth/peripheral_esp).
That is the closest match for a BLE RHT device.
...
Values are simulated today (ess_simulate()).

The peripheral_esp sample is a good match because it implements a BLE peripheral with the Environmental Sensing Service (ESS), which is the standard BLE service for RHT sensors.

Prompt

Use the Zephyr peripheral_esp sample application to populate the app directory. Then build and flash the application to the connected board. Inspect the boot logs and verify that the application starts successfully and behaves as expected.

The agent inspects the workspace and verifies that the zephyr and zephyr-silabs west projects are available and valid and that the required blobs are present. The agent finds the peripheral_esp sample application and copies it to the app directory.

The agent uses the Simplicity Device Manager (SDM) tool to list the connected boards. It selects the only available board and determines the Zephyr board name (xg24_rb4186c) and the serial port to monitor.

The agent builds the application by running the regular west build command.

The agent uses the SDM tool to start serial port monitoring so the boot logs can be inspected after flashing.

The agent then flashes the application to the board by running the west flash command or using the SDM tool.

Finally, the agent stops serial port monitoring and inspects the boot logs.

Agent response

The peripheral_esp sample is in app, built for the connected kit, flashed, and the boot log shows a clean start.

App directory. Copied the sample into app/ and left app/west.yml in place:

app/CMakeLists.txt, app/prj.conf, app/README.rst, app/src/main.c
Target. One adapter (wpk_01, serial 440248217): BRD4186C on a BRD4002A WPK.
Zephyr board: xg24_rb4186c. Workspace release: v2026.6.0.

Build. Pristine build to app/build:

Image: app/build/zephyr/zephyr.hex
Flash 208 KB / 1536 KB, RAM 25 KB / 256 KB
Flash. Programmed that hex onto wpk_01. Commander reported success.

Boot log (VCOM serial1):

*** Booting Zephyr OS build v4.4.1-109-gf60fcfc44b27 ***
Bluetooth initialized
Advertising successfully started

New Functionality#

The current BLE app implements the Environmental Sensing Service (ESS), but it does not yet provide real sensor data. The next step is to read the RHT sensor and provide real data to the ESS service.

Prompt

Use the RHT sensor available on the xg24_rb4186c board to provide real temperature and humidity measurements to the Environmental Sensing Service (ESS) in the BLE peripheral_esp application.

Build and flash the application, then verify the functionality by checking the reported temperature and humidity values in the application logs.

The agent uses the silabs_ai_sdk_search_docs tool and inspects the workspace to find the RHT sensor in the devicetree and the corresponding driver.

It identifies the RHT sensor and the dedicated sensor enable line. The agent then updates prj.conf and src/main.c to enable the sensor and read values from it.

The agent builds and flashes the application and inspects the logs.

Agent response

The ESS app now uses the on-board Si7021 (dht0) instead of simulated values.

Changes

Enabled CONFIG_SENSOR, CONFIG_I2C, and CONFIG_REGULATOR (Si7021 via sensor_enable on PD03)
Sample Si7021 every 5 s and write temperature/humidity into the ESS GATT characteristics
Log each reading on the console
Verification (flashed to wpk_01 / xg24_rb4186c):

*** Booting Zephyr OS build v4.4.1-109-gf60fcfc44b27 ***
Using RHT sensor: si7021@40
Bluetooth initialized
Advertising successfully started
RHT: temperature = 29.45 C, humidity = 48.82 %RH
RHT: temperature = 29.48 C, humidity = 48.83 %RH
Those are live ambient readings updating periodically and feeding the Environmental Sensing Service.

Low-Power Mode#

Power management is not enabled in most Zephyr sample applications. It is usually more practical to prototype and verify the basic functionality first, and then add power management.

Prompt

Measure the board's current consumption and compare the measured values with the expected current consumption specified in the device datasheet.

The agent uses the silabs_ai_sdk_search_docs tool from the silabs-knowledge-base MCP server to query the current consumption of the EFR32MG24B210F1536IM48 device. The queried operating conditions include active mode (EM0), sleep mode (EM2), reception, and transmission.

The agent uses the commander aem command-line interface (CLI) tool to measure the board's current consumption.

Agent response

Average draw on the running peripheral_esp firmware is 2.95 mA (about 9.7 mW at 3.29 V).
That matches an always-on MCU plus BLE advertising, not the datasheet sleep figures.

Detailed plots and the datasheet comparison are in xg24 AEM current — a Canvas
you can open beside the chat.

Measured (AEM, 15.8 s, serial 440248217)

Current
- Average: 2.95 mA
- Idle floor: 2.23 mA (94.8% of time)
- Advertising peaks: ~7.2 mA every 34.6 ms
- Absolute max: 10.6 mA (<1 ms)


Datasheet typical (EFR32MG24, DCDC, 25 °C) vs this capture

- EM2 256 kB RAM: 2.9 µA — not applicable. CONFIG_PM is off, so the SoC never enters EM2.
- EM1 at 78 MHz, peripherals off: 1.76 mA — idle floor is 2.23 mA. Same ballpark;
  the extra ~0.5 mA  is USART, BLE host, Si7021 enable, and other board rails.
- EM0 Prime at 78 MHz: 2.60 mA — close to the 2.80 mA bin the board spends most
  of its time in. RX listen 1 Mbit/s, EM1P: 4.3 mA — adv peaks (~7 mA) sit above
  this because each event includes TX and an active MCU, not radio-only EM1P.
- TX CW 10 dBm: 19.1 mA — higher than the 10.6 mA AEM peak. Advertising packets
  are short, so the sample mixes TX with RX/idle.

Next, enable power management in the application and verify that current consumption decreases to the expected values.

Prompt

Enable power management to improve current consumption. Analyze the sleep current (µA range) in detail.

The agent uses the silabs_ai_sdk_search_docs tool from the silabs-knowledge-base MCP server to query information about power management for Series 2 devices in Zephyr.

The agent adds the required configuration options to prj.conf to enable power management:

CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y

The agent creates app/boards/xg24_rb4186c.overlay to:

  • Turn off unused devices, such as the ls0xx_ls013b7dh03 display.

  • Configure runtime power management for peripherals, such as i2c0, by setting zephyr,pm-device-runtime-auto;.

  • Configure pin sleep states.

The agent then builds and flashes the application, and uses the commander aem CLI tool to measure board current consumption.

Agent response

100 kHz AEM capture shows the device spends most of its time in the µA range.

Sleep floor
- 82% of samples are 0–20 µA (mean 5.7 µA, median 5.2 µA)
- 87% of samples are below 50 µA
- MG24 EM2 is ~2.9 µA; the measured values are consistent with EM2 plus AEM noise and board/sensor leakage

µA histogram
0–2 µA:   4%
2–4 µA:  19%
4–6 µA:  29%
6–8 µA:  17%
8–10 µA:  7%
10–20 µA: 5%

Why the average is still 0.37 mA
- Below 50 µA periods average 2.2 ms, max ~11 ms
- Above 1 mA accounts for only 9% of the time but 95% of the charge
- Sleep contributes only ~1.5% of total energy

The device reaches EM2-class sleep, but average current is dominated by BLE advertising rather than the sleep floor.

Network Trace Analysis#

Most Silicon Labs radio chips can emit transmitted and received packets through the Packet Trace Interface (PTI). You can capture and analyze these packets to inspect raw packet data, timing, and other RF and protocol details.

The following example shows how to validate the advertisement interval by enabling PTI and capturing and decoding a network trace.

Prompt

Enable PTI on the device, then record and analyze the network trace to check the advertisement interval.

The agent enables PTI in prj.conf and in app/boards/xg24_rb4186c.overlay, then builds and flashes the application to the board.

# prj.conf
CONFIG_DEBUG_DRIVER=y
CONFIG_DEBUG_SILABS_PTI=y
/* xg24_rb4186c.overlay */
&pti {
	pinctrl-0 = <&pti_default>;
	pinctrl-names = "default";
	status = "okay";
};

The agent uses the sdm ci CLI tool to capture the network trace and the network-intelligence-cli decode CLI tool to decode and analyze the captured data.

Agent response

Enabled Silicon Labs PTI on the DUT (&pti node + CONFIG_DEBUG_SILABS_PTI=y) so
the same wpk_01 adapter used to flash/debug could also stream TX/RX radio packets
— no second sniffer board needed. Rebuilt, flashed, then captured 27.3 s of
traffic via sdm ci and decoded it with Network Intelligence.

Result: 782 legacy advertising events (782 TX bursts on ch 37/38/39), start-to-start interval:

Metric - Value
Configured (BT_LE_ADV_CONN_FAST_1): 30–60 ms
Measured min / mean / max: 30 / 35 / 40 ms
Std. dev: 3.2 ms

The controller sticks to the 30 ms minimum plus the spec-mandated 0–10 ms
advDelay jitter — it never uses the 60 ms max. At ~35 ms average, the radio wakes
~29×/second, which lines up with why advertising dominates your energy budget
despite deep EM2 sleep otherwise. A slower fixed interval (e.g. 500 ms) would
cut that proportionally if you want to trade off reconnect latency for power —
let me know if you'd like me to implement and re-measure that.

Debugging#

The gdb-mcp MCP server provides a GDB server interface to the connected board. The agent can use it to perform debugging operations, such as setting breakpoints, inspecting variables, stepping through code, and inspecting threads and stacks.

The gdb-mcp tools can also help debug complex issues such as deadlocks, memory corruption, and other runtime issues.

In the following example, the agent is instructed to list the stack traces of all threads in the application.

Prompt

List the stack traces of all threads in the application.

The agent enables thread-aware debugging in the app by extending prj.conf:

CONFIG_THREAD_MONITOR=y
CONFIG_THREAD_NAME=y
CONFIG_DEBUG_THREAD_INFO=y

The agent launches a debugging session with the gdb-mcp server and retrieves the stack traces of all threads in the application.

Agent response

Here's the thread list:

The agent enabled CONFIG_THREAD_MONITOR, CONFIG_THREAD_NAME, and CONFIG_DEBUG_THREAD_INFO
in app/prj.conf and reflashed, which lets the debugger walk the real Zephyr thread
list (without them, only a single sentinel/raw-core entry is visible).
Attaching live via J-Link GDB (rtos=zephyr) showed 9 real Zephyr threads:

main — priority 0, blocked (sleeping)
idle — priority 15
logging — priority 14, pending
sysworkq — priority 255, pending
BT LW WQ — priority 10, pending
bt_tx_processor — priority 255, pending
BT RX WQ — priority 248, pending
EFR32 LL — priority 240, pending
EFR32 HCI RX — priority 246, pending

9 Zephyr threads total: 1 app thread (main), the kernel idle thread, and 7 subsystem threads
(logging + 3 Bluetooth host workqueues + 3 EFR32 HCI/link-layer driver threads).
All were idle/blocked at the time of the snapshot, consistent with the sleeping
BLE peripheral between advertising events.

Conclusion#

The Simplicity AI SDK for Zephyr provides AI agents with a powerful set of tools and skills to develop and validate Zephyr applications on Silicon Labs hardware. The validation tools enable the agent to run multiple iterations based on measured results and improve the application until it meets the requirements.