STM32WBA as a Coprocessor: Choose Host Ownership and Transport Before Wiring
Using STM32WBA55 as a Bluetooth coprocessor requires two decisions before the board interface is fixed: where the BLE host runs, and which transport the selected framework uses. “Put Bluetooth on the second MCU” is too vague to determine software ownership, pin routing or sleep behavior.
ST's NCP/RCP guide and UM3529 Rev 2 describe the alternatives. This article concerns that documented framework, with WBA55 as the wireless device. It does not assume that every UART-based Bluetooth controller has the same power limitation.
Decide which processor owns the host stack
The NCP/RCP guide separates a radio coprocessor from a host-and-controller network coprocessor. In the RCP arrangement, the external MCU runs the BLE host and the WBA device runs the controller. The external host communicates through HCI.
In the NCP arrangement, the WBA device contains both host and controller. The external MCU runs the user application and uses the provided application-control interface. Moving between these arrangements changes which image owns higher-layer BLE behavior; it is not simply a different baud-rate setting.
A product that already has a qualified host integration may prefer to retain that owner and evaluate the RCP interface. A product that wants the WBA software to own host behavior should evaluate the NCP API and its application requirements. These are engineering choices, not claims that either architecture universally uses less memory or power.
Trace one required operation across the boundary
Before selecting an image, choose a concrete product operation such as configuring its GATT service or initiating the required connection role. Identify which processor owns the relevant stack layer and which supported command or API crosses the interface.
This exercise exposes mismatches early. An external application written for an NCP interface cannot assume the RCP controller alone implements the same host-level service. Conversely, adding a second host implementation while selecting a host-and-controller image can create overlapping ownership rather than useful redundancy.
Keep HCI command transport distinct from the product's data model. Sending a command successfully does not establish that the intended service, security state or application interaction is ready. The chosen stack owner must supply that lifecycle.
Include the framework's transport power behavior
The guide states that its UART interface does not allow the WBA device to enter Sleep, while the SPI interface supports Sleep using the dedicated IRQ and chip-select behavior. This is a property of the documented implementation, not a physical law about UART peripherals.
UART uses the documented transmit and receive signals. SPI requires clock, MOSI, MISO, chip select and IRQ. Chip select also participates in waking the WBA device, and IRQ communicates readiness or pending work according to the protocol phase.
A design that chooses UART to save signal pins should therefore include the framework's sleep limitation in its power analysis. A design that chooses SPI for the supported sleep behavior must budget the extra signals and implement the handshake, rather than treating the device as an ordinary memory with a fixed command-to-data delay.
No current figures are predicted here. Qualify the complete external-MCU and WBA operating cycle, because moving work or adding wake handshakes can affect both processors.
Check the exact WBA55 routing
UM3529 Rev 2 covers the X-CUBE-WBA expansion and describes the supported coprocessor interface. The framework documentation gives different pin mappings for WBA25 and WBA55/65. A WBA25 expansion-board wiring example is not automatically the wiring for a WBA55 product.
The guide also notes the absence of dedicated WBA55/65 Nucleo expansion boards in that setup. Resolve the actual device pins, voltage compatibility, reset and recovery access from the chosen boards and images before drawing a connection diagram for manufacturing.
Record the external MCU firmware, WBA coprocessor image, host ownership and physical transport together. If a service team changes the coprocessor image from NCP to RCP, the external firmware's assumptions must be reviewed as part of the same change.
Close the architecture decision before debugging bytes
A useful design review should answer three questions: which processor owns the required host behavior, whether the external software uses the matching interface, and whether the transport supports the intended power strategy on the exact board.
Only then does it make sense to qualify command framing, event handling and recovery. A perfect SPI waveform cannot repair a missing BLE host, and a working desktop demonstration cannot prove a product's sleep target. No coprocessor firmware or hardware was run here; the result is a defined interface boundary that can be implemented and tested coherently.
