STM32WB55: FUS_GET_STATE returns IDLE over SWD but ERROR over USB DFU; all real operations fail with FUS_STATE_ERR_UNKNOWN either way
Board: WeAct STM32WB55 Core Board (STM32WB55CGU6, 1MB flash)
STM32CubeProgrammer: v2.23.0
Connections tested: ST-LINK/V2 clone (SWD, mode=HOTPLUG) and native
USB DFU bootloader (port=usb1, H3/BOOT0 held
high to 3.3V)
SUMMARY
A wireless-stack upgrade (v1.20.0.2 -> v1.24.0 stack, which also
required a FUS upgrade from v1.1.1 to a newer FUS) was interrupted
partway through due to the target losing USB connection during the
reconnect phase. Since then, the FUS no longer completes any real
operation (fwdelete, fwupgrade all fail with FUS_STATE_ERR_UNKNOWN)
on either interface. FUS_GET_STATE itself gives a confirmed,
repeatable, interface-dependent result -- see point 10 -- which
doesn't correspond to operations actually working on either side.
STARTING STATE (before anything went wrong)
Read via USB bootloader, Read FUS infos:
FUS State : FUS_IDLE
FUS Status : FUS_NO_ERROR
FUS Version : v1.1.1.0
STACK Version: v1.20.0.2
STACK Address: 0x80CE000
WHAT WAS ATTEMPTED
1. A FUS upgrade was started (v1.1.1 -> v1.2.0, stm32wb5x_FUS_fw_1_2_0.bin
at 0x080EC000, Verify download ticked, automatic address
determination OFF, over USB bootloader port=usb1). Starting state
confirmed via Read FUS infos immediately before: FUS_IDLE /
FUS_NO_ERROR, FUS v1.1.1.0, STACK v1.20.0.2 at 0x80CE000.
The log shows the tool proceeding into the old-stack delete step,
which triggers an internal reset, and the target never returned
from it:
FUS state is FUS_IDLE
FUS status is FUS_NO_ERROR
Reconnecting...
Old Firmware delete ...
Deleting firmware ...
Reconnecting...
[stuck here indefinitely, 0% progress]
The new v1.2.0 FUS image was never opened/written at this point --
the failure is specifically in the delete-old-stack step, before
any new image transfer begins. BOOT0 was not held through this
internal reset (held momentarily via button rather than a
continuous jumper), which is suspected as the proximate cause of
the target not coming back on USB.
2. After this, every subsequent fusgetstate over USB returned:
FUS state is FUS_ERROR
FUS status is FUS_NOT_RUNNING
3. Connected via ST-LINK (SWD, mode=HOTPLUG). -ob displ shows a
stable, self-consistent option byte set (not SFSA=0x00, so
safeboot/lock does not appear to have triggered):
RDP : 0xAA (Level 0, no protection)
nBOOT0 : 0x1
nBOOT1 : 0x1
nSWBOOT0: 0x1 (later changed to 0x0 by repeated CLI FUS-operator
writes -- each fusgetstate/fwupgrade/fwdelete call sets
this itself as part of its internal routine)
ESE : 0x1 (Security enabled)
SFSA : 0xEC (0x80EC000)
FSD : 0x0
DDS : 0x1
C2OPT : 0x1
SBRV : 0x3D000 (matches AN5185's documented "FUS v1.x/v2.x
running" value, not the 0x3D800 v0.5.3 value)
This SBRV/SFSA combination persisted unchanged through every step
below.
4. Performed a full chip erase (unprotected user flash only, below
SFSA) and a full power cycle (ST-Link fully unplugged, H3/BOOT0
jumper to 3.3V to force bootloader, then USB plugged in). Flash at
0x08000000 confirmed erased (all FFFFFFFF). Device info table:
0x20030000 : 20030024 00000000 00000000 2003005C
0x20030010 : 2003017C 00000000 00000000 00000000
0x20030020 : 00000000 00000000 00000000 00000000
0x20030030 : 00000000 00000000 00000000 00000000
Table pointer (0x20030024) is present and correct per AN5185, but
the FUS version word at 0x20030030 is all zeros. fusgetstate still
returns FUS_ERROR / FUS_NOT_RUNNING at this point (over USB).
5. Tried stm32wb5x_FUS_fw.bin (latest, v2.2.0) via -fwupgrade over
SWD with automatic address determination. Tool computed
0x080E6000, erased/wrote/verified the image successfully
("Download verified successfully"), but the FUS itself then
rejected the actual upgrade:
Firmware Upgrade process started ...
...
Error: FUS_STATE_ERR_UNKNOWN: Unknown error
6. Tried an RDP 0xAA -> 0xBB -> 0xAA cycle via -ob over SWD (per
AN5185's FAQ recovery suggestion). Both transitions completed
cleanly and reversibly; SFSA/SBRV unchanged throughout. No effect
on FUS behavior.
7. Manually wrote PWR_CR4 to set C2BOOT and release CPU2, over SWD:
STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -w32 0x5800040C 0x00008000
This completed as a normal instant register write (no flash-style
"Downloading..." banner, unlike writes to the flash controller's
own registers e.g. 0x58004008 which the CLI routes through its
flash-programming engine and which fail with "Failed to download
data" on this chip in its current state).
Afterward, fusgetstate was run 3x in a row over SWD per AN5185's
FAQ recommendation ("ensures FUS is running and idle in most
cases"):
FUS_STATE_IDLE
FUS_STATE_IDLE
FUS_STATE_IDLE
-ob displ immediately after: RDP=0xAA, SFSA=0xEC, SBRV=0x3D000 --
unchanged.
HOWEVER, the device info table read right after this (0x20030000,
64 bytes, over SWD) still showed 0x20030030 = 00000000 (no FUS
version populated), despite the GET_STATE calls succeeding.
8. Given the IDLE responses, tested an actual operation rather than
just a status query, over SWD:
STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -fwdelete
Result:
Error: FUS_STATE_ERR_UNKNOWN: Unknown error
Firmware delete n°-17891602 failed after retrying!
(retried 3x automatically, same result each time)
9. Re-ran -fwupgrade with stm32wb5x_FUS_fw_1_2_0.bin at 0x080EC000,
firstinstall=0, over SWD, immediately after a fresh C2BOOT wake +
3x confirmed FUS_STATE_IDLE. Same failure:
Old wireless stack delete ...
...
Error: FUS_STATE_ERR_UNKNOWN: Unknown error
Error:
Old Firmware delete failed
10. INTERFACE DISCREPANCY (confirmed, not a timing artifact):
fusgetstate over SWD consistently returns FUS_STATE_IDLE,
including when run as the very first command of a session with
no prior C2BOOT write or any other command beforehand (tested
cold specifically to rule out session-timing/wake-proximity
effects). fusgetstate over native USB DFU (port=usb1, H3 held
high) consistently returns FUS_ERROR / FUS_NOT_RUNNING, likewise
as a cold first command, on the same chip, with no option byte
changes in between sessions. However, on both interfaces, every
actual operation (fwdelete, fwupgrade) still fails identically
with FUS_STATE_ERR_UNKNOWN -- GET_STATE succeeding over SWD has
not corresponded to operations actually working.
QUESTIONS
1. What does FUS_STATE_ERR_UNKNOWN actually mean in this specific
context -- GET_STATE succeeding (IDLE), but any real operation
(fwdelete, fwupgrade, regardless of binary/address) failing the
same way, on both SWD and USB DFU interfaces, both before and
after a manual C2BOOT wake? AN5185 Table 16 lists this as "0xFF:
Unknown error" with no further detail -- is there internal
diagnostic info (e.g. via a debug UART, trace channel, or a
specific register) that could narrow this down further?
2. The device info table at 0x20030030 stays at 0x00000000 even
immediately after 3 consecutive FUS_STATE_IDLE responses over SWD.
Per AN5185 Section 1.2, this table should be populated by FUS at
startup if FUS is genuinely running. Does this mean GET_STATE can
return IDLE from some other code path than the actual FUS, or is
there a timing/reset issue where the table gets cleared (e.g. via
SRAM2RST on each of the repeated internal resets the CLI performs
per command) before it can be read back?
3. The SWD-vs-USB-DFU GET_STATE discrepancy in point 10 is confirmed
and not explained by query timing (tested cold, no prior commands
in-session, on both sides). What would cause FUS_GET_STATE
specifically to answer differently depending on which bootloader
interface issues it, when AN5185 documents SWD and USB DFU as
equally valid paths to the same FUS?
4. Is this chip's CPU2/FUS region recoverable at this point through
any further procedure, or does the pattern above (stable,
self-consistent option bytes; no SFSA=0x00; GET_STATE sometimes
answering; every real operation failing identically regardless of
interface) match a known failure mode that's specifically
unrecoverable?
Happy to provide full verbose (level 3) logs for any of the above
steps, or try any specific diagnostic command.