Silicon Labs (EFM32 / EFR32)

Silicon Labs (SiLabs) built their brand on energy-friendly microcontrollers. The "Gecko" lineup of EFM32 chips have long led the low-power benchmarks, and the EFR32 wireless line is dominant in Zigbee, Thread, Matter, and now BLE — particularly in smart home and connected lighting.

EFM32 — pure MCU

The "Gecko" branding has multiple generations. Series 2 (newer) is the recommended path for new MCU designs.

EFR32 — wireless

This is where SiLabs really wins. EFR32 chips combine a Cortex-M33 with a 2.4 GHz radio supporting multiple protocols.

The EFR32xG24 is currently SiLabs's flagship — Cortex-M33 with Matter support, AI/ML accelerator, dual-bank flash for OTA. It ships in Amazon Sidewalk endpoints, Philips Hue lights, Aqara sensors, and a long list of similar consumer products.

Energy modes

SiLabs's defining feature: a granular set of low-power modes, going beyond ARM's standard sleep states.

A SiLabs design typically operates in EM2 (around 1.5 µA) the vast majority of the time, waking briefly to EM0 to handle events. Battery life of 5+ years on a CR2032 is routine.

Simplicity Studio

SiLabs's vendor IDE. Eclipse-based, integrates board management, energy profiler, network analyser (for the EFR32 lines), and an OTA flash debugger. Better than most vendor IDEs, particularly the energy profiler — it shows you per-µs current consumption correlated with your code, so you can see exactly which function call costs how many microcoulombs.

For non-wireless EFM32 work, command-line CMake + arm-none-eabi-gcc + their HAL works fine.

When you'd pick SiLabs

• You need Matter / Thread / Zigbee — the EFR32 family is arguably the most mature for these protocols.
• Energy budget is critical — SiLabs's deep-sleep modes are reliably class-leading.
• Smart home / connected lighting product — you'll find more relevant reference designs at SiLabs than anywhere else.

Series 1 versus Series 2 — what changed under the hood

The Series 1 / Series 2 split is the most important versioning fact for any new SiLabs design. Series 1 parts (EFR32xG12, xG13, xG14, MG12, BG13, etc.) are Cortex-M4F based, lack TrustZone, and use the older Peripheral Reflex System (PRS) v1. Series 2 (xG21, xG22, xG23, xG24, xG27, xG28) moves to Cortex-M33, adds TrustZone-M, a Secure Vault for key storage, an AI/ML accelerator (xG24 only — a CMSIS-NN-compatible matrix-vector engine), and an upgraded PRS v2 with deeper routing.

Series 2 also restructures the clock tree: the older HFXO/LFXO/HFRCO/LFRCO split is replaced by HFXO + HFRCODPLL + LFXO + LFRCO + ULFRCO, with the DPLL allowing the high-frequency RC to be calibrated against the 32 kHz crystal to within roughly 100 ppm — useful when you want to skip the 38.4 MHz radio crystal in cost-down designs. Cryptographic acceleration moves from the standalone CRYPTO peripheral to the integrated SE (Security Element) subsystem, which on xG21B/xG24 is a separate Cortex-M0+ running signed firmware.

For new designs in 2025+, default to Series 2. Series 1 is still in production for backwards compatibility, but xG24 is now the standard pick for Matter/Thread end-devices.

RAIL — the Radio Abstraction Interface Layer

Beneath every SiLabs wireless stack — BLE, OpenThread, Zigbee, Bluetooth Mesh, Wi-SUN, Z-Wave LR, proprietary — sits RAIL. RAIL exposes a uniform API for "configure the radio, transmit a packet, receive a packet, schedule a TX event, ACK, retry." Above RAIL, the stacks layer their protocol logic; below RAIL, the radio is a programmable engine with PHY parameters (modulation, data rate, channel filter, packet structure) loaded from a configuration blob generated by the Radio Configurator tool in Simplicity Studio.

This architecture has two important consequences. First, RAIL lets a single Series 2 chip switch protocols at runtime — an xG24 can act as a Zigbee coordinator in one second and as a BLE peripheral in the next, sharing the antenna. Second, RAIL is the right abstraction layer for proprietary protocols: if your product needs a custom 2.4 GHz link (long-range, low-rate, robust to interference), you write your MAC over RAIL rather than fighting the BLE / Zigbee stacks.

/* Minimal RAIL transmit pattern */
RAIL_Handle_t handle = RAIL_Init(&railCfg, NULL);
RAIL_ConfigChannels(handle, channelConfig, NULL);
RAIL_SetTxFifo(handle, txFifo, 0, sizeof(txFifo));
RAIL_WriteTxFifo(handle, payload, length, true);
RAIL_StartTx(handle, channel, RAIL_TX_OPTIONS_DEFAULT, NULL);

Inside the energy modes — what each one actually gates

The published numbers (1.4 microamps in EM2, 50 nanoamps in EM4H) only hold if you understand what each mode is gating. EM2 keeps the LFXO crystal running, the RTCC counting, all RAM retained, and any peripheral that opted into "EM2 capable" mode (BURTC, LEUART, LETIMER, I2C in master-pull mode, GPIO with async sense) operational. The CPU is clock-gated, the HF oscillator off, the radio off. Wake to EM0 from EM2 typically takes 5–10 microseconds — fast enough for sensor-polling profiles that wake hundreds of times per second.

EM3 drops the RTCC and most LF peripherals; only the BURTC (Backup RTC) and GPIO interrupts can wake you. EM4S retains RAM and a small set of registers; EM4H retains nothing and wakes via a dedicated pin or a programmable wake counter. The trick to ultra-low-power designs is to do as much as possible in EM2 with peripheral autonomy: a typical EFR32 design runs a state machine where the LDMA (Linked DMA), peripheral PRS chains, and CRYOTIMER trigger packet transmissions without the CPU ever waking.

Cross-references

• Cortex-M33 / M23 — EFR32 / EFM32 Series 2 core.
• Cortex-M0+ — older Gecko core.
• Cortex-M4 — Series 1 EFR32 core.
• TrustZone — used by the Series 2 Secure Vault.
• CMSIS — Gecko SDK layers on CMSIS-Core.
• Nordic — primary BLE competitor.
• NXP — alternative Matter/Thread option via K32W and MCX-W.
• QEMU & Renode — Renode has EFM32 Giant Gecko and partial EFR32 models.
• Interrupt latency tool — explore EM2-wake versus EM0 trade-offs.