STM32WB55 Radio Stalls Capture CPU2 Fault Evidence Before Reset

A BLE command that stops returning does not prove that the STM32WB55 wireless processor crashed. CPU1 may have stopped dispatching notifications, a response path may be blocked, or CPU2 may have entered a fault state. Capture the documented CPU2 evidence before a recovery reset removes the distinction.

The diagnostic format below comes from AN5289 Rev 18, section 4.8. The application-side debug configuration is pinned to the P-NUCLEO-WB55.Nucleo BLE_p2pServer example in STM32CubeWB v1.24.0, commit 7c5aa7dcd2c0abe787f922bb06a6213c724d08e4. Confirm applicability to the installed CPU2 binary. No fault was induced, target memory read or recovery executed.

Preserve the first useful observation

Before designing an automatic reset loop, decide what a stalled product can record safely. A compact report should identify the application build, installed wireless stack and service versions, last command submitted, last successful transport progress, reset cause and time since boot.

Avoid asking the already stalled BLE command path to produce all this information. Keep version metadata and recent progress in application-owned diagnostic state during normal operation, and use a reviewed non-blocking capture path when progress stops.

A watchdog reset can remain necessary for product availability, but the recovery policy should allow the bounded evidence capture that the system can safely support. A missing record is preferable to an unbounded fault handler that prevents recovery. Keep that tradeoff explicit in the product’s failure requirements.

Original diagnostic plan based on ST’s documented interface. It is not a captured crash or a guarantee that every failure writes a marker.

Decode the documented signatures without guessing

AN5289 Rev 18 documents 0x1170FD0F at SRAM2A_BASE for a CPU2 hard fault. The next three words contain the program counter, link register and stack pointer. It separately documents 0x3DE96F61 when mailbox buffers supplied to CPU2 are outside nonsecure SRAM.

Keep those classifications separate. The second signature directs attention to shared-buffer placement and the security boundary; it is not interchangeable with the hard-fault register record. Do not label either case merely “Bluetooth disconnected.”

Preserve the raw words before decoding. An original offline classification sketch is:

if marker equals 0x1170FD0F:
    classify as documented CPU2 hard-fault evidence
    preserve the next three raw words as PC, LR and SP
else if marker equals 0x3DE96F61:
    classify as documented mailbox-placement evidence
else:
    report that neither documented signature was observed

This outline does not read hardware. A production collector must use the correct target address definitions and a supported access path, with the application’s memory protection and failure-context restrictions respected.

Treat absence and age as explicit limitations

Neither marker being present does not establish that CPU2 is healthy. The processor may be waiting, the observed memory may already have been repurposed, or the failing binary may have a different applicable diagnostic contract. A previous reset can also make the sample irrelevant to the original stall.

Record when the words were captured and whether any reset, reinitialization or memory-clearing operation preceded that capture. Do not assume diagnostic SRAM contents are a durable crash log. Copy only the documented record into a separately designed persistent report if the product requires retention, using a safe storage path rather than initiating uncontrolled flash work in a fault context.

Likewise, an unexplained old marker should not automatically be attributed to the current operation. Establish capture freshness through the controlled test sequence and lifecycle evidence. Avoid writing over shared diagnostic memory merely to create a convenient “clear fault” operation without a documented ownership contract.

Use debug GPIOs as an additional observation

The pinned app_debug.c contains CPU2 software-signal configuration, including a hard-fault signal, and hardware radio-debug configuration. These can help correlate radio activity and fault timing in a development build. The pinned source marks CPU2 GPIO debug and nonzero BLE_DTB_CFG settings as intended only on request from ST Support. Follow that vendor-guided workflow when enabling this instrumentation.

Review the actual board schematic before enabling a signal. A spare pin in an example may drive a product output, share a peripheral or be unavailable in another package. Hardware debug signals also have mapping constraints; changing a table entry does not necessarily move the underlying hardware signal.

Keep the instrumentation configuration with the capture. Debug output can change pin use, power behavior and the build under test. It provides an observation channel, not permission to claim that an instrumented board represents every production operating condition.

Keep CPU1 and CPU2 evidence in their own domains

A CPU2 program counter belongs to the installed wireless image. Feeding it to the application’s M4 ELF can produce an unrelated or misleading result. Preserve the wireless binary identity and the raw address for the appropriate vendor-supported analysis route.

In parallel, inspect CPU1 progress: did the relevant IPCC interrupt occur, did its notification request background work, and did that work run? The HCI transport source provides concrete response and asynchronous-event boundaries. A captured interrupt without subsequent dispatch supports a different investigation from a fresh CPU2 fault record.

Proposed acceptance cases include a deliberately delayed CPU1 dispatcher in a software fixture, a simulated diagnostic record and ordinary recovery with capture enabled. Do not corrupt CPU2 memory to manufacture a field-like fault. The objective is a report that preserves the failed boundary, exact versions and uncertainty before recovery, allowing the next investigation to begin with evidence rather than a reset count.