We get this question a lot from product teams: "Can we use Bluetooth for setup and Zigbee for operation — on the same chip?" The short answer is yes. The STM32WB does exactly this. The longer answer involves understanding a dual-core architecture, time-division multiplexing on a shared radio, and some tricky memory trade-offs. Here's what we've learned from shipping products on this platform.

The problem every connected product faces

Picture this. Your customer unboxes a smart light bulb, opens the app, and expects the device to show up. That's BLE — fast discovery, works with every phone. But once it's set up, the bulb needs to join a Zigbee mesh so it can talk to other bulbs, switches, and the gateway reliably, across rooms, with low power.

The obvious approach? BLE for setup, then switch to Zigbee. Most products do this. But it falls apart when you need to re-commission the device, push a firmware update over BLE, or run diagnostics — because the device is now on Zigbee and can't hear BLE anymore.

We needed both protocols running together. Not taking turns. Actually coexisting.

What's actually inside the STM32WB

The STM32WB isn't one processor — it's two. A Cortex-M4 runs your application. A Cortex-M0+ runs the wireless stack. They share SRAM and communicate through a hardware mailbox called IPCC (Inter-Processor Communication Controller).

Think of it as two people sharing a desk. The M4 writes a note: "start advertising on BLE." The M0+ picks it up, handles the radio, and writes back: "done, here's the connection handle." Your application code never touches the radio directly.

ST ships pre-built, pre-certified wireless firmware binaries for the M0+. There's a BLE-only binary, a Zigbee-only binary, and — the one we care about — a concurrent BLE+Zigbee binary. That's where the magic happens.

Concurrent mode: how it actually works

There's one radio. One antenna. One 2.4 GHz transceiver. BLE and Zigbee both live in the 2.4 GHz band. So the M0+ core does time-division multiplexing — it schedules BLE and Zigbee operations in non-overlapping time slots.

During commissioning, the sequence looks like this: the device advertises on BLE, the phone connects, credentials are transferred, the device joins the Zigbee mesh, and it confirms back to the phone over BLE that everything worked. No reboot. No firmware swap. Smooth.

After commissioning, we keep BLE in a low-duty background mode — advertising every few seconds with minimal power. This lets us push firmware updates over BLE and run diagnostic reads without pulling the device off the Zigbee mesh. For us, this was the real win.

The trade-offs nobody talks about

Memory. The concurrent BLE+Zigbee stack eats roughly 256 KB of flash on the M0+ side. On a chip with 1 MB total flash, that's a quarter of your space gone before you write a single line of application code. For simple sensor nodes, that's fine. For feature-rich devices, it gets tight.

We've shipped both ways. For a commercial lighting product that gets re-commissioned whenever a tenant changes, we use concurrent mode — the convenience is worth the memory cost. For a low-cost environmental sensor that's set up once and forgotten, we use the switched approach: BLE for setup, then we flash the Zigbee-only binary onto the M0+. Takes about 2-3 seconds. The user sees a brief "configuring..." message. Done.

One more thing: security. During BLE commissioning, you're transferring Zigbee network keys. We always use BLE Secure Connections with ECDH pairing, plus application-layer encryption on the credential payload. Belt and suspenders. Those network keys are the keys to the kingdom.

What we'd tell you before you start

Start with the concurrent stack even if you think you don't need it. It's much easier to drop down to switched mode later than to retrofit concurrent support into a codebase that assumed single-protocol operation.

Budget your flash early. Write down every byte: M0+ stack, bootloader, application, file system, OTA staging area. If the numbers don't work, you'll find out at the worst possible time.

Test commissioning with real phones, not just Nordic's nRF Connect app. iPhones and Android devices have subtly different BLE behaviors — connection interval negotiation, MTU handling, background mode restrictions. We've been burned by this more than once.

And finally: the STM32WB ecosystem is good but the documentation is scattered. The CubeMX examples work, but they're minimal. Budget time for reading ST's AN5289 application note and the actual M0+ firmware release notes. That's where the real information lives.

Key Takeaways

• The STM32WB runs BLE and Zigbee concurrently on one chip using time-division multiplexing on a shared radio
• Concurrent mode costs ~256 KB flash — worth it for products needing frequent re-commissioning
• Always encrypt credential transfer during commissioning. BLE pairing alone isn't enough
• Start with the concurrent stack and budget flash early — retrofitting is painful