STM32WBA SPI Coprocessor Link: Treat IRQ Transitions as Protocol Phases

The STM32WBA coprocessor SPI link has two readiness handshakes within one transaction. The host waits for IRQ high before the five-byte header, then waits for IRQ low before transferring payload. Sending the entire header and payload as one uninterrupted transfer can violate the protocol even when SPI mode and clock frequency are correct.

UM3529 Rev 2 section 4.5 defines the exchange and its incomplete-transaction behavior. This discussion targets the documented NCP/RCP framework, not a generic Bluetooth HCI transport. No bus trace or fault-injection test was executed.

Read IRQ in the current protocol phase

The NCP/RCP framework guide describes five SPI signals, including IRQ. Its role is more than a permanent “data available” Boolean.

UM3529 explains that asserting chip select can wake the WBA device. The interval before readiness depends on its state, including whether wake-up and preparation are needed. The external MCU must wait for IRQ high before clocking the header.

After the five header bytes, the device lowers IRQ when it has prepared the requested payload phase. That low level is the next readiness condition. A driver that only waits for high at the start and immediately continues clocking can outrun the device's second preparation step.

Represent these as distinct states in the host driver: selected and waiting for header readiness, exchanging header, waiting for payload readiness, transferring payload, and ending the transaction. A GPIO sample without the state that gives it meaning is an incomplete diagnostic record.

Decode both directions of the header

For a write, the MOSI header begins with control 0x0A and includes the command size in low-byte-first order, followed by the documented unused bytes. Control 0x0B selects a read. At the same time, the MISO header returns its start byte, a two-byte WBUF and a two-byte RBUF, also least-significant byte first.

WBUF describes how many bytes the external controller may write to the WBA device. RBUF describes how many bytes are waiting to be read. They are different directional capacities. Swapping them can make a plausible header drive the wrong transfer length.

Before a write payload, verify that WBUF can accommodate the command. If it cannot, the manual requires waiting; do not truncate the command to fit the currently reported capacity. Before a read payload, use the reported RBUF count and the required IRQ transition.

The manual identifies an unexpected read case where RBUF is zero despite the earlier event indication. Its specified response is to complete the transaction with zero data bytes, rather than inventing a minimum-length read.

Treat short writes differently from short headers

Table 4 is important when designing recovery. An incomplete header of zero to four bytes is ignored. An incomplete read misses the event. An incomplete write is different again: the WBA device stores the received bytes and uses bytes from the next write operation to try to complete the Bluetooth frame.

Therefore, a host cannot apply one blind “retry the full command” policy to every interrupted SPI exchange. After a short write, the device may retain a prefix. Repeating the whole command can be interpreted as continuation data instead of a clean new frame.

The article does not prescribe an undocumented reset or flush command for that condition. Establish the supported recovery behavior of the chosen coprocessor image and host integration. Preserve how many bytes were actually clocked and the protocol phase in which the interruption occurred, rather than reporting only a generic SPI error.

Make a proposed trace distinguish the transitions

For a normal write, a useful capture should show chip select asserted, IRQ becoming high, exactly five header bytes, IRQ becoming low, the admitted payload, and chip select released. The header fields and actual payload count should agree.

Separate proposed negative cases for a truncated header, clocks started before IRQ high, a short read and a short write. Table 4 assigns different outcomes, so one combined “communication disturbance” test cannot establish all of them.

Use the selected device's electrical timing requirements and the framework's specified SPI mode. The phase diagram here does not set numerical setup times or override ambiguous edge wording with an invented timing value.

A reliable host implementation records both the byte stream and the handshake state. That makes it possible to distinguish a device still waking, a payload not yet prepared, insufficient write capacity and an interrupted frame. Successful transfer of five header bytes alone establishes none of the later milestones.