STM32WBA LE Audio NVM Migration: Restore the RAM Image Before Stack Initialization
An STM32WBA LE Audio application can compile after a package upgrade while its persistence integration still follows the previous library contract. The important change is not merely the name of a storage callback. The newer interface gives the audio stack an application-owned RAM image at initialization, so restoring existing information becomes a prerequisite of that initialization call.
ST identifies the transition at STM32CubeWBA 1.7.0, which includes Bluetooth LE Audio Library 1.11. This article examines the public integration contract, not the internals of a licensed library binary or an executed migration.
Locate the version boundary in the adapter
The LE Audio architecture and integration guide, section 2.7, describes two interfaces. Through CubeWBA 1.6.1, application implementations provide the audio library's add, get, compare and discard NVM hooks. From CubeWBA 1.7.0, the initialization structure supplies an NVM RAM buffer, with a store hook for persistence.
For the newer contract, BleAudioInit_t carries bleAudioStartRamAddress_NVM and total_buffer_size_NVM. If persistent audio information exists at startup, the supplied RAM buffer must already contain it when BLE_AUDIO_STACK_Init() is called. The application must also implement BLE_AUDIO_PLAT_NvmStore().
This creates a specific dependency in startup. Storage initialization and restoration must finish before audio-stack initialization consumes the buffer. Leaving restoration in a later application task is not equivalent to supplying the saved state at initialization, even if the task runs shortly afterward.
Rewrite the startup dependency, not just the callback names
Audit the point where the application constructs BleAudioInit_t. Trace the allocated buffer back to its owner and identify the operation that loads persistent audio information into it. Then inspect the control flow: can BLE_AUDIO_STACK_Init() run before that operation succeeds or reports that no prior state exists?
For a synchronous storage implementation, restoration can be an explicit preceding step. An asynchronous implementation needs a completion dependency before audio initialization. The relevant condition is completion of the required restoration, not submission of a read request. The application's empty-storage path also needs to follow the selected package's initialization requirements rather than accidentally consuming an uninitialized buffer.
Keep the buffer alive for the integration lifetime required by the library. The guide describes application-allocated working storage, so a temporary local array used only while assembling the initialization structure is an unsuitable ownership model. Confirm the allocation size and alignment from the actual package headers and example configuration; the two structure members alone do not document every requirement.
A useful diagnostic trace records restoration completion immediately before the initialization call, together with the selected buffer address and configured capacity. It does not need to log the stored audio information itself. That trace directly tests the new ordering obligation without exposing persisted contents.
The host NVM callback is a different interface
The similarly named host-storage hook is a migration trap. The BLE Stack Integration guide, NVM functions section, documents BLEPLAT_NvmStore with a uint64_t data pointer and a size expressed in 64-bit words. The audio guide shows BLE_AUDIO_PLAT_NvmStore with a const uint32_t pointer and a size argument, but its displayed signature does not specify that argument's unit.
Do not cast one callback into the other or copy a host-side multiplication factor into the audio adapter. A pointer's element type does not, by itself, define the unit of an accompanying integer. Resolve the audio callback's size semantics in the headers and implementation guidance distributed with the chosen audio package before converting it into the storage driver's length.
A shared low-level flash or file service can still sit underneath both adapters. Keep the adapters separate so each one translates its own documented address, length and lifetime contract. Similar function names do not authorize a shared interpretation of their arguments.
Existing data needs a separate compatibility decision
The new startup rule says when persistent information must be present. It does not establish that bytes written through the old per-record interface are directly compatible with the new RAM-image representation. Preserve that distinction in the upgrade plan.
Before accepting an existing device image, establish its producing library version and the supported conversion or initialization path for the destination package. If a conversion is required, perform it before presenting the destination buffer to the new stack. If no supported conversion is established, do not label a raw copy as a verified migration.
Qualification should exercise two different histories: an empty persistent store and a device carrying information from the supported predecessor. In both cases, observe the restore-before-init dependency and the later audio-store callback. Successful audio streaming alone does not demonstrate that saved profile information was recovered correctly.
The public documents establish a versioned API and startup-order change. They do not prove binary-format compatibility, storage atomicity or recovery behavior for a particular product. Those remain explicit integration questions rather than assumed benefits of a successful build.
