STM32WB Radio Startup: Dispatch the CPU2 Ready Event Before Issuing Stack Commands

Starting CPU2 on STM32WB55 does not immediately make the wireless stack ready for application commands. CPU1 must receive and dispatch the system ready event, then perform the stack-specific initialization. A missing background dispatch can look like a radio boot failure even when CPU2 has already signaled readiness.

AN5289 Rev 18 describes the system transport, interrupt notification and event-buffer lifecycle. The useful debugging boundary is the handoff between those stages, rather than a fixed delay inserted after CPU2 activation.

Establish the transport before starting the peer

AN5289 annex 14.1 shows initialization of the shared reference table, system transport and memory channel before TL_Enable starts CPU2. These structures let CPU2 deliver the notification on which later initialization depends.

A port that moves CPU2 activation earlier can undermine its own readiness observation. Inspect the actual sequence: TL_Init, system-channel setup through shci_init and its lower layer, TL_MM_Init, and the transport enable. The application note's sequence supplies the dependency; a function with a similar name in another package is not proof of equivalent initialization.

While waiting, CPU1 may perform application initialization that does not depend on the radio. The wait should gate radio-dependent work, rather than unnecessarily stopping every unrelated sensor or configuration task.

The official FUS guide also describes shared tables and activation requirements for CPU2 service operation. Distinguish the installed CPU2 firmware and intended operating state from the M4 application's own version. A transport that can communicate with a service is not, by itself, an initialized BLE application.

Trace notification and dispatch separately

The ready event reaches CPU1 through the IPCC interrupt path. AN5289 shows shci_notify_asynch_evt notifying the application that work is pending. The application then calls shci_user_evt_proc from background context so the system transport can deliver the event to APPE_SysUserEvtRx.

That creates three useful observation points: the IPCC notification, the scheduled background processing, and the application callback receiving the system event. If the first occurs but the second never runs, increasing a startup timeout does not repair the missing dispatch path.

A sequencer or RTOS port must preserve the event-to-background-work connection. Check whether an initialization wait blocks the same execution context responsible for draining that event. A synchronous-looking “wait until ready” wrapper can deadlock its own readiness processing if it never lets the background consumer run.

Do not confuse system readiness with BLE initialization

After the system event, AN5289 shows the BLE transport initialization and SHCI_C2_BLE_Init sequence. Its HCI-only configuration has a different host integration from the full BLE host running on CPU2. Preserve the path for the selected stack rather than initializing both alternatives indiscriminately.

Label the milestones accordingly: CPU2 started, system ready event processed, selected wireless stack initialized, and product role started. An advertising or scanning operation belongs after the relevant stack setup, not merely after an interrupt proves that CPU2 is alive.

A proposed startup fixture can deliberately delay background event processing while allowing the interrupt notification. It should expose the system-ready stage as pending and avoid submitting radio commands prematurely. This is a diagnostic design, not a claim that such a fixture was executed.

Respect the event buffer's completion rule

The ordinary UserEvtRx return path releases the event buffer back to CPU2 memory management. Saving its pointer for a later application task while returning with the normal processed status can therefore leave that task referencing storage it no longer owns.

AN5289 also documents an explicit exception. If the application cannot process the event, it can return SHCI_TL_UserEventFlow_Disable. The transport retains and requeues the event, stops reporting further events, and resumes reporting after shci_resume_flow. This is coordinated transport backpressure, not an unlimited right to keep arbitrary event pointers.

Choose one supported policy. Process the required information within the callback, copy the bounded data needed later before returning normally, or deliberately use the documented pause/resume mechanism. With the last option, account for the fact that further system-event reporting stops until the flow resumes.

The startup result should show how CPU2's notification becomes application-visible readiness without losing the event or blocking its dispatcher. No firmware build or board startup was tested here. The documented stages are sufficient to replace an unexplained delay with a precise place to inspect the failed handoff.