Vendors · 43 pages
- STM32 (ST) — overview
- STM32 F / G / H mainstream
- STM32 L / U low-power
- STM32 WB / WL wireless
- NXP Kinetis & i.MX RT
- NXP LPC family
- Nordic nRF
- Nordic nRF53 dual-core
- Nordic nRF91 cellular
- Raspberry Pi RP2040 / RP2350
- Renesas RA / RX
- TI Tiva / MSP432
- TI Sitara (Cortex-A + R)
- Microchip SAM
- Silicon Labs EFM32 / EFR32
- Infineon XMC / PSoC
- Infineon AURIX
- GigaDevice GD32 — overview
- GD32F mainstream (M3/M4)
- GD32L low-power (M23)
- GD32W wireless (M33)
- Artery AT32 — overview
- AT32F4 mainstream (M4)
- AT32M motor / power
- Nuvoton NuMicro — overview
- NuMicro M0 entry-level
- NuMicro M4 mainstream
- NuMicro M23 secure
- Ambiq Apollo — overview
- Apollo4 sub-µA M4F
- Apollo510 / Apollo5 (Helium M55)Helium
- Maxim / ADI MAX32 — overview
- MAX32 general-purpose M4
- MAX78000 ML acceleratorAI
- NVIDIA Jetson — overview
- Jetson Orin Nano / NX
- Jetson AGX Orin / Thor
- MediaTek — overview
- MediaTek Genio (IoT A-series)
- MediaTek Filogic Wi-Fi router
- Rockchip — overview
- Rockchip RK3566 / RK3568
- Rockchip RK3588 / RK3582
STM32 wireless — WB and WL
STM32WB dual-core BLE/Thread/Zigbee with a dedicated Cortex-M0+ radio core, STM32WL sub-GHz LoRa with M4 application and M0+ Sub-GHz radio. How the application/network split works, IPC, and coexistence.
STM's STM32WB and STM32WL are the wireless-integrated members of the STM32 family — instead of pairing an external radio (Semtech SX1262, Nordic nRF52840, TI CC2640) with a host MCU over SPI, the radio is on-die, controlled by a dedicated Cortex-M0+ core, leaving the application Cortex-M4 free for everything else. WB is BLE / Thread / Zigbee / 802.15.4 / proprietary 2.4 GHz; WL is Sub-GHz with LoRa, (G)FSK, BPSK modulations. The split-core architecture and the IPC that glues them together are the defining features.
This page covers the silicon, the role of each core, the IPC mailbox, the wireless stacks that ship in the M0+ ROM, and the design considerations when you build product on these parts.
- STM32WB55
- Cortex-M4F @ 64 MHz (app) + Cortex-M0+ @ 32 MHz (radio); BLE 5.4, Thread, Zigbee 3.0, 802.15.4, proprietary 2.4 GHz
- STM32WBA52
- Single Cortex-M33 + integrated 2.4 GHz radio; BLE 5.4 only; TrustZone; lower cost, newer architecture
- STM32WL55
- Cortex-M4F + Cortex-M0+ + Semtech SX126x radio core; LoRa, (G)FSK, MSK, BPSK; 150 MHz to 960 MHz
- STM32WLE5
- Cortex-M4F single-core with the same integrated radio (no M0+); for simpler designs
- TX power
- WB: +6 dBm; WL: +22 dBm high-power output, +14 dBm boost mode
- RX sensitivity (LoRa SF12)
- -148 dBm on STM32WL — competitive with discrete SX1262
- Stack location
- M0+ runs the radio stack from system ROM (WB) or shared flash region (WL); upgradeable over the air
- IPC mechanism
- Mailbox in SRAM2 with shared memory channels; HW semaphore + IPCC interrupt block
- Certifications
- BLE SIG QDID, Zigbee certified, Thread certified, LoRaWAN-CertifiedCM, FCC/CE/IC pre-certified modules
Architecture — why two cores
A wireless protocol stack has hard real-time requirements that interact poorly with an application that wants to do other work. BLE link-layer interrupts fire at precise 1.25 ms intervals; LoRa receive windows open within microsecond tolerance of an expected packet. Missing one is at best a dropped packet; at worst it breaks the connection or the certified-radio behaviour.
The traditional answer is to give the radio its own MCU and talk to it over SPI. That works but costs another chip, board area, BOM, and CPU cycles on the host for the protocol-level translation (HCI for BLE, AT commands for cellular, custom for proprietary).
STM's answer is to put both MCUs on the same die, with shared RAM and Flash, and give one of them exclusive ownership of the radio block. The application MCU runs whatever — sensor loops, UI, BLE GATT server logic — and exchanges messages with the radio MCU via an IPC mailbox. From the app's perspective, sending a BLE notification is aci_gatt_update_char_value(...), the same library call you'd use against an external BlueNRG chip; under the hood that call writes a command to the mailbox, the radio core picks it up, runs the link layer, and writes the result back.
STM32WB block diagram
The IPC mailbox
The IPCC (IPC Controller) is a 6-channel mailbox: each channel has a "set bit" interrupt for one direction and "clear bit" for ack. The shared SRAM2 region is partitioned into command, event, and ACL data tables; the channels point at table heads. ST provides a thin C library (shci.h, tl_*.h) that abstracts the tables as command/response queues.
A BLE notification from the app's perspective:
// M4 application code
tBleStatus status = aci_gatt_update_char_value(
service_handle,
char_handle,
0, payload_len, payload
);What happens under the hood:
aci_gatt_update_char_valueformats an HCI command in the shared command buffer.- Sets IPCC channel 2 (HCI command available).
- M0+ wakes, reads the command from SRAM2, runs the BLE link layer's outgoing-notification logic, schedules a TX slot.
- M0+ posts an event to the response queue, sets IPCC channel 3.
- M4 wakes, reads the event ("command complete"), returns from the function call.
Total round-trip on STM32WB at 64 MHz: ~50 µs for a simple command, ~200 µs if a TX has to be scheduled. That's much faster than an SPI-tethered radio because there's no serial bus in the middle.
The radio stack — what comes preloaded
For STM32WB, ST provides several "Coprocessor Binary" releases — each is a precompiled image of a different protocol stack for the M0+:
| Image | Stack | Size | Notes |
|---|---|---|---|
stm32wb5x_BLE_Stack_full_extended_fw.bin | BLE 5.4 full | ~210 KB | Central + Peripheral, GAP/GATT, security, DLE, LE Audio |
stm32wb5x_BLE_Stack_light_fw.bin | BLE 5.4 minimal | ~130 KB | Peripheral-only, no security manager |
stm32wb5x_BLE_Thread_dynamic_concurrent_fw.bin | BLE + Thread | ~330 KB | Concurrent both stacks |
stm32wb5x_Zigbee_FFD_fw.bin | Zigbee 3.0 FFD | ~280 KB | Full-Function Device, can be router |
stm32wb5x_BLE_Zigbee_FFD_fw.bin | BLE + Zigbee | ~360 KB | Dual stack |
stm32wb5x_Mac_802_15_4_fw.bin | 802.15.4 MAC | ~160 KB | Raw MAC, build your own profile |
stm32wb5x_Phy_802_15_4_fw.bin | 802.15.4 PHY | ~100 KB | Lowest layer, full custom |
The image is flashed to a reserved high-Flash region by a bootloader called FUS (Firmware Upgrade Service). The app's flash sits in the lower region. Updating the radio stack OTA means delivering the new binary to the app, then asking FUS to verify and install it — the app is not running during the install (FUS takes over briefly).
For STM32WL, the radio stack is simpler — the Semtech SX126x driver lives in the app domain on STM32WLE5 (no M0+), or runs on the M0+ on STM32WL55. LoRaWAN MAC sits in the app on both variants; ST provides the LoRaWAN stack as source.
STM32WL — Sub-GHz integration
STM32WL is the Sub-GHz variant — integrates a Semtech SX1262-equivalent radio for 150–960 MHz LoRa, (G)FSK, MSK, BPSK. The combination of M4F + integrated radio replaces the two-chip STM32L4 + SX1262 design that was standard before WL shipped.
Notable LoRa-specific characteristics:
- +22 dBm high-power output with appropriate matching network. This is at the regulatory limit for 868 MHz EU duty-cycle bands and the standard for US 915 MHz.
- -148 dBm sensitivity at SF12 BW=125 kHz. With +22 dBm TX, this gives ~170 dB link budget — practical range of 10–15 km in suburban, >40 km line-of-sight.
- PA selection: the chip has two PAs — Low-Power (up to +14 dBm, more efficient) and High-Power (up to +22 dBm). External RF switching between them is required; ST provides reference designs.
- TCXO requirement at high SF: LoRa SF11/SF12 demand frequency stability of ±20 ppm; a standard 32 MHz crystal at ±10 ppm is borderline. Most production designs add a TCXO.
The WL55 dual-core option exists for cases where you need to run a non-trivial app stack (LoRaWAN class C with continuous RX, Bluetooth Mesh proxy, plus business logic) without missing radio deadlines. For most LoRaWAN-only end-nodes, WLE5 single-core is sufficient and cheaper.
STM32WBA — the M33 successor
WBA52 (launched 2023) is the next-generation wireless STM32 — single Cortex-M33 with TrustZone, integrated 2.4 GHz radio, BLE 5.4 only (no Zigbee/Thread yet). The single-core design simplifies the model: no IPC, no separate flash region, the BLE stack runs in non-secure mode on the same core as the app. Trade-off: the M33 must arbitrate between application code and link-layer ISRs in real time. The link layer is high-priority interrupts; if your app keeps interrupts off too long, packets are missed.
WBA suits new BLE-only designs that want TrustZone (for secure boot and key storage) and a lower BOM than WB55. For multi-protocol (BLE + Zigbee, BLE + Thread, Matter) WB55 remains the choice until WBA's stack catalogue catches up.
Designing a WB/WL product — practical notes
- Antenna design. Both parts come with reference matching networks in the datasheet. Deviating requires antenna-port impedance characterisation (network analyser) and re-certification.
- Radio coexistence. WB has a PTA (Packet Traffic Arbitration) pin for coexistence with an external Wi-Fi; without it, simultaneous BLE + 2.4 GHz Wi-Fi on the same product is risky.
- FCC/CE certification. ST publishes modular pre-certifications for reference layouts. Using a different layout requires intentional-radiator certification; budget $20–60k and 6–8 weeks.
- Low-power. WB Stop 2 with BLE advertising at 1 s interval: ~3 µA average. WL Stop 2 with LoRa class A and one TX/hour: ~1.5 µA average. Both competitive with the STM32L low-power line.
- OTA. ST's BLE OTA library uses the FUS region to stage and verify new app images. New app slot, verify CRC + signature, swap pointers, reset.
Cross-references
- STM32 mainstream F, G, H — non-wireless STM32 line.
- STM32 low-power L, U — battery-oriented family.
- Nordic nRF53 — dual M33 wireless competitor.
- IoT sensor node — full system design built on WL or WB.
- ST RM0434 (WB), RM0453 (WL) — reference manuals.
- ST AN5289 (WB BLE) and AN5406 (WL LoRa) — application notes for stack integration.