STM32WBA Flash Manager: Schedule Persistent Writes Inside Radio-Safe Windows

A successful STM32WBA Flash Manager request does not mean its data has reached flash. The module stores the accepted operation's parameters, asks the application to schedule background work, and coordinates access with radio timing. A missing scheduling hook can leave an otherwise valid request unable to progress.

The callback also has more than one meaning. A notification that the manager is available after an earlier busy result is different from completion of an accepted write. This distinction is visible in the public STM32CubeWBA v1.10.0 source, pinned at commit e455b860ceb52aaa0332a98f1e7a10bbd7014fc9.

Enter through the layer that coordinates RF activity

ST's Flash Management guide separates Flash Manager, RF Timing Synchro and the lower flash driver. The driver provides access controls, but it does not independently arrange RF-safe timing for an application that bypasses the manager.

RF Timing Synchro uses link-layer-granted windows to permit operations through the LL_RFTS control. The guide also describes LL_RFTS_BYPASS, which permits access despite that RF-window control, and a separate SYSTEM gate for other system restrictions.

A stalled request is not a reason to enable bypass indiscriminately. First determine whether the application scheduled the required background work, whether RF timing admitted an operation, and whether another gate remains closed. Those are different causes with different owners.

Connect request notification to background execution

The System Modules guide explains the request/callback model: a module validates and registers work, asks for its background function to run, and later reports the result. The application must register the background function with its scheduler and implement the corresponding ProcessRequest hook.

For Flash Manager, those names are FM_BackgroundProcess and FM_ProcessRequest. Porting the public API calls without this connection can produce a system in which requests are accepted but no consumer performs them.

The pinned FM_Write implementation saves source, destination and size when the state check returns FM_OK. It then calls FM_ProcessRequest. It does not copy the supplied payload into an independent durable queue before returning.

The guide consequently requires the source buffer to remain allocated until the write completes. Preserve its contents as well. Reusing a transmit or sensor buffer immediately after admission can change the bytes that the later flash operation reads.

Distinguish availability from operation completion

In the pinned source, a busy state can append the supplied callback node to a pending-notification list. FM_Write saves the new operation's parameters only on FM_OK. Thus, an FM_BUSY result plus a registered callback is not evidence that the requested payload was queued for automatic writing.

When an active operation finishes, the manager calls its active callback with FM_OPERATION_COMPLETE. It can then notify waiting requesters with FM_OPERATION_AVAILABLE. The latter tells the application that it can make another request; it does not complete the write that previously received busy.

For a hypothetical settings update, keep the desired data and request state in the application. If admission returns busy, wait for the appropriate availability path and submit the still-current request according to the integration contract. Mark the settings stored only after the accepted operation reaches its completion condition and any required application verification.

Do not treat every callback invocation as “save finished.” Also keep callback-node lifetime valid while the manager may retain it. Its presence in a notification list is a real object-lifetime requirement, even though the payload has not been accepted as a queued operation.

Let radio windows control progress

FM_BackgroundProcess contains a path that tries permitted operations and a path that requests a timing window when needed. The manager can advance an operation across available windows rather than requiring one application-owned critical section around the entire transfer.

A proposed diagnostic trace should distinguish request admission, ProcessRequest scheduling, background invocation, window availability and the callback status. If scheduling never occurs, investigate the port. If background processing runs but access remains blocked, investigate the documented gates and RF state. Do not infer the cause from the elapsed time alone.

This article does not claim a bounded write latency under every radio workload. It also does not turn Flash Manager into a transactional persistent store: erase preparation, record format and power-loss recovery require their own design.

The integration is complete when the scheduler, RF access controls, buffer ownership and callback meanings agree. Those concrete connections explain how a WBA flash request becomes completed work without bypassing the timing coordination it was intended to use.