STM32WBA55 Standby: Preserve the Reset-Handler Path That Resumes After WFI
An STM32WBA55 connectivity application can preserve Standby state yet fail to resume correctly if a custom startup file replaces the connectivity-specific reset handler. The WBA5 solution does more than retain a data record: it saves CPU execution context and uses a special reset path to return to the low-power continuation.
Audit that path when changing the startup code, linker integration or RTOS example. The evidence here combines ST's low-power guide with STM32CubeWBA v1.10.0 source pinned at commit e455b860ceb52aaa0332a98f1e7a10bbd7014fc9. No sleep transition was executed.
Distinguish retained memory from resumed execution
The WBA low-power guide distinguishes link-layer Standby from SoC Standby. The latter resets the CPU on exit. For connectivity operation with retention, the guide requires dedicated link-layer SRAM and at least application SRAM1, with SRAM2 retained when the application needs it.
Those retention choices preserve required bytes. They do not, by themselves, make a default cold-start handler resume the interrupted low-power path. Ordinary data initialization, zeroing and entry into main represent a different execution history from restoring the saved CPU context.
The guide describes saved stack-related registers, interruption priorities and general-purpose registers. The stack holding that context is therefore part of the retained-state contract. Retaining only an application variable that says “was asleep” is not sufficient.
Inspect the actual reset-handler branch
The pinned GCC reset handler calls is_boot_from_standby before the ordinary SystemInit, data-copy, BSS-clear and main path. A recognized Standby exit branches to CPUcontextRestore.
Its save routine pushes registers and the return context, stores the stack pointer and executes WFI. The restore routine reloads the saved stack pointer and returns through the preserved context. This establishes why selecting the correct startup object matters: the behavior is implemented in executable startup code, not implied by a retained linker section.
Inspect the final vector table and linked Reset_Handler definition. Finding the right assembly file in the project directory is insufficient if another startup object supplies the active handler or if the build never includes the connectivity-specific file.
Preserve the restore path's surrounding contracts
The RM0493 Rev 7 power description supplies the hardware Standby context. The software guide adds the configurations that must be reapplied: NVIC state, radio bus clock, SoC peripheral initialization and the RTC peripheral clock. RTC registers being retained does not imply that its bus clock is already restored.
A return to the saved code location is therefore not the final success condition. The low-power exit path must recreate the environment that continuation expects. A peripheral accessed immediately after return can expose a missing restoration that a retained-memory checksum would never detect.
The guide also describes backup_system_register and restore_system_register for additional CPU peripheral registers. Treat the actual backup list as part of the selected example and port, rather than copying a generic list without checking what the OS maintains elsewhere.
Compare the RTOS example, not only the generic description
The pinned NUCLEO-WBA55CG ThreadX example lists SCB CPACR and VTOR in its register_backup_table. That concrete table differs from the broader register examples discussed in the guide.
The difference is a reason to inspect the complete OS-specific save/restore integration, not proof that one table is defective. Do not append arbitrary register writes simply to make the lists look identical. Establish who owns each state item and whether its restoration belongs to this table, the CPU context path, the RTOS or peripheral initialization.
When changing the RTOS or toolchain, review stack selection and the corresponding startup implementation together. Mixing a save sequence from one integration with a restore sequence from another can invalidate the assumed stack contents and return context even when all source files compile.
Test the branch that the product intends to use
A proposed development fixture should distinguish cold reset from recognized Standby exit, record which reset-handler branch executes, and verify the first application and radio operations after continuation. Also include a normal cold boot so the retained-resume changes do not conceal an initialization regression.
This is not a general promise that every BLE connection survives Standby. The specific engineering result is confidence that the chosen WBA5 retention and startup mechanism remains intact through a custom port. Retained bytes, restored CPU context and a usable post-wake system are separate things to establish.
