My Feedback on STM32WB Series Flash Architecture
Dear STMicroelectronics Team,
As an experienced developer working with the STM32WB series, I must voice a critical concern about its current flash memory architecture.
By placing both the Cortex‑M4 application and the Cortex‑M0+ wireless stack into a single shared internal flash, divided only by secure boundaries, you have created avoidable complexity and limitations for developers and end‑users alike. This design forces us to contend with:
Hard‑coded secure boundaries (SFSA/SBRV) and OB flags (DDS, C2OPT) that can only be altered via FUS or System Memory, making recovery unnecessarily difficult.
Loss of usable program space for the M4 when the wireless stack is present, even if the reserved region is unused.
Risk of total application downtime when the secure portion becomes corrupted or blocked, as both cores depend on the same physical array.
Debug and update processes that are far more fragile than they should be, especially in production environments.
For a platform intended to be versatile and developer‑friendly, these constraints create needless technical and operational overhead.
I strongly urge STMicroelectronics to consider, in future revisions of the STM32WB family, a dual‑flash architecture:
One physically independent flash array for the M4 application.
One dedicated, protected array for the M0+ wireless stack and secure services.
This separation would:
Eliminate cross‑core interference in flash access.
Simplify option byte logic and recovery scenarios.
Allow developers to fully utilize available program memory without jeopardizing wireless functionality.
Greatly improve the robustness and maintainability of deployed products.
