STM32WB Memory Budget: Reserve the Next CPU2 Stack, Not Only Today’s Application

The unused memory below an STM32WB55 wireless stack is not automatically permanent application capacity. FUS can change CPU2's protected flash and SRAM boundaries when it installs another stack version. A layout that fits today's application can therefore prevent the next supported wireless update or leave insufficient application RAM afterward.

Budget the currently accessible region, the update staging region and future CPU2 growth separately. The concrete rules below come from AN5289 Rev 18 and AN5185 Rev 15. The example intervals are illustrative; no option bytes, linker files or hardware were changed.

Read the three boundaries as ownership limits

AN5289 section 4.2 names SFSA for secure flash, SBRSA for SRAM2a and SNBRSA for SRAM2b. CPU1 cannot read or write the secure portions. FUS running on CPU2 is the owner that writes those boundary settings during CPU2 updates.

The boundaries are not simply linker preferences. A linker script can restrict the application to less memory than hardware permits, but enlarging the script cannot make CPU2-secure memory accessible. Conversely, a region omitted by a conservative example linker file may be usable only after the actual stack's requirements are understood.

AN5289 gives 4 KB flash and 1 KB SRAM boundary granularity for this model. Record the actual boundary addresses and the selected stack release notes before calculating available space. Do not use the installed application size as a substitute for the ownership limit.

Separate steady-state capacity from update capacity

The application note permits extending application flash up to SFSA, but adds an important condition for CPU2 updates: enough free memory must remain immediately below secure flash to hold the new encrypted CPU2 firmware image. Required space depends on the stack being updated, such as BLE, Thread or a concurrent solution.

For a hypothetical layout, let S be the present secure-flash start and E the exclusive end of all application-owned flash allocations. The interval from E to S is merely the available gap. It is not proof of update feasibility. The selected incoming image, its required placement and the FUS version's installation rules determine whether that gap can actually stage the update.

AN5185 describes version-dependent image installation behavior. Its historical limitations also show why a single generic formula should not replace the package's placement requirements. Preserve the exact FUS and wireless-image release conditions in the layout review.

Leave RAM margin for the next stack

SRAM2a and SRAM2b need a different reserve from flash staging. AN5289 advises leaving space below their secure boundaries for future CPU2 firmware that requires additional secure sectors. This is a future ownership margin, not a temporary encrypted-image buffer.

Suppose an application claims every currently nonsecure SRAM2a sector. A later supported stack needs two more secure sectors. Under the documented 1 KB granularity, that hypothetical growth consumes 2 KB from the old CPU1-accessible interval. The old linker allocation is then incompatible even if the updated application's own variables have not grown.

Do not present that example as a forecast of ST's next release. Its purpose is to expose the decision: either reserve a defensible margin for the supported update envelope or require a coordinated application layout change when the stack changes. The product must choose which contract it can maintain.

BLE-only reclamation is not a Thread guarantee

AN5289 says SRAM2b is entirely secure for CPU2 firmware supporting Thread. For BLE-only applications, it describes reclaiming a nonsecure SRAM2b interval up to SNBRSA, with margin for future secure growth.

That difference makes a future protocol roadmap relevant to today's memory optimization. A BLE product that uses reclaimed SRAM2b for essential application data cannot assume the same placement remains valid when changing to a Thread-capable stack. This is a hardware ownership conflict, not something an allocator can fix at runtime after the linker has placed static objects there.

The note also describes conservative linker files shared across several examples and exceptions for particular applications. Copying a linker file from a smaller demo is therefore not evidence that its memory choices match the chosen production stack and update strategy.

Deliver a layout that states its update envelope

The useful release artifact is a memory map with distinct ownership annotations: application flash, persistent data, encrypted CPU2 staging space, secure flash, application SRAM, and reserved secure-growth margin. Include the present stack and the set of future stack packages actually qualified with that map.

Before accepting an update, compare its required boundaries with the application allocations and staging region. If they collide, resolve the coordinated application and stack transition before programming. A successful link only proves that one image fits its declared regions; it does not prove that FUS can install the next CPU2 image or that the application remains valid afterward.

No future stack size or successful update is promised here. The engineering result is a memory budget that exposes those assumptions early enough to influence product capacity and serviceability.