STM32WB Stack Maintenance over SWD: Restore the M4 Application After FUS Operator
An STM32WB wireless-stack maintenance operation can succeed while leaving the product's M4 application absent. With STM32CubeProgrammer over SWD, the FUS Operator application occupies the application processor's firmware space. Restoring the product application is consequently part of the maintenance sequence, rather than evidence that the wireless update failed.
ST documents this behavior in its staff-authored FAQ dated 28 April 2026. The distinction concerns the tool's FUS operation and transport, not every ordinary debugger connection or every possible flash programming workflow. No device was modified for this article.
Identify the code that performs the service operation
The ST FAQ explains that an SWD FUS operation installs an embedded FUS Operator on Cortex-M4. That program communicates with the FUS running on Cortex-M0+ and handles the requested service operations.
The existing M4 firmware is overwritten by this operator. A factory process that initially programs the final application, then performs its last FUS operation over SWD, must not assume the first application programming step still represents the final device contents.
This is particularly easy to overlook when a script separates tasks into independent stages called “application programming” and “radio setup.” The names suggest separate storage owners, but the radio-maintenance transport temporarily uses the application processor to do its work.
Even the meaning of a service check needs review
The FAQ includes reading the FUS state among operations handled by the operator. Therefore, a stage described as “check the FUS” is not automatically a passive observation of the installed M4 application. Determine which tool operation actually runs, rather than assuming that a status-oriented label makes it non-mutating.
This does not mean that attaching SWD always overwrites the application. The relevant boundary is invoking the documented CubeProgrammer FUS workflow that uses the operator. Keep ordinary debugger inspection, raw flash access and FUS service commands distinct in the manufacturing procedure.
A useful review begins with the last FUS-related operation in the actual station sequence. Ask which transport it uses, whether it loads the operator, and what application programming step follows it. If the answer ends at “FUS state is successful,” the product's application restoration remains unresolved.
Understand why DFU and USART differ
The FAQ describes USB DFU and USART FUS operations as using the system bootloader to communicate with CPU2. In that route, the operator does not replace the M4 product application in the same way.
AN5185 Rev 15 supplies the underlying architecture: FUS runs on Cortex-M0+ in protected flash, while communication can come from M4 user code or the system bootloader through the supported command model. Different communication owners explain the different application-side effect.
Do not turn this comparison into a blanket promise that a DFU maintenance job preserves every byte of user data. Image staging, requested deletion, memory boundaries and the particular operations in the job still have their own effects. The supported conclusion is narrower: the documented SWD operator-overwrite mechanism differs from the system-bootloader transport path.
Put the final application after the final operator use
For an SWD-based production flow, a practical order is to finish the required FUS and wireless-stack work, follow the applicable stack-start instructions, and then restore the intended M4 application artifact. This ordering is an integration consequence of the documented operator behavior, not a universal ready-to-run programming script.
Keep the application artifact associated with the selected stack and memory layout. Reflashing an arbitrary older M4 image merely to make the device boot can introduce a different compatibility problem. The restore step should identify the approved image bytes and the layout expected by that release.
ST's FAQ recommends starting the wireless stack and reflashing the application after FUS work regardless of transport. If a production process follows that recommendation, it should record the final application step explicitly rather than depending on an engineer remembering to perform it manually.
Verify the resulting product, not only the service tool
Consider a proposed service test on a recoverable development unit. Begin with an identifiable application build, perform the selected FUS workflow, and observe which application is present before restoration. Then restore the approved product image and verify its build identity and intended radio initialization. The stages distinguish the expected operator side effect from an unrelated programming failure.
A successful FUS response concerns the service operation. A successful final application programming result concerns a different artifact. A running product with the intended application and wireless configuration is the final integration outcome. Keeping those milestones separate prevents a normal SWD maintenance side effect from appearing later as an intermittent factory failure.
