STM32WB fus not starting

[gprgprgpr]

Hi.

I have nucleo board with STM32WB55RGV6 mcu. Trying to start FUS using StCubeProgrammer (swd mode), and unable to start it and even get its version. I do what is described in wiki: connect in normal mode + hardware reset, start fus, disconnect, start in hotplug mode. Tryed many combination but nothing works. What can be the reason?

      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.14.0                  
      -------------------------------------------------------------------

ST-LINK SN  : 066FFF545057717867055039
ST-LINK FW  : V2J43M28
Board       : P-NUCLEO-WB55
Voltage     : 3.21V
SWD freq    : 4000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID   : 0x495
Revision ID : Rev B
Device name : STM32WB5x/35xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : 0xD2
Debug in Low Power mode enabled


UPLOADING OPTION BYTES DATA ...

  Bank          : 0x00
  Address       : 0x58004020
  Size          : 96 Bytes

[==================================================] 100% 

  Bank          : 0x01
  Address       : 0x58004080
  Size          : 8 Bytes

[==================================================] 100% 


OPTION BYTES BANK: 0

   Read Out Protection:

     RDP          : 0xAA (Level 0, no protection) 

   BOR Level:

     BOR_LEV      : 0x0 (BOR Level 0 reset level threshold is around 1.7 V) 

   User Configuration:

     nBOOT0       : 0x1 (nBOOT0=1 Boot from main Flash) 
     nBOOT1       : 0x1 (Boot from code area if BOOT0=0 otherwise system Flash) 
     nSWBOOT0     : 0x0 (BOOT0 taken from the option bit nBOOT0) 
     SRAM2RST     : 0x0 (SRAM2 erased when a system reset occurs) 
     SRAM2PE      : 0x1 (SRAM2 parity check disable) 
     nRST_STOP    : 0x1 (No reset generated when entering the Stop mode) 
     nRST_STDBY   : 0x1 (No reset generated when entering the Standby mode) 
     nRSTSHDW     : 0x1 (No reset generated when entering the Shutdown mode) 
     WWDGSW       : 0x1 (Software window watchdog) 
     IWDGSTDBY    : 0x1 (Independent watchdog counter running in Standby mode) 
     IWDGSTOP     : 0x1 (Independent watchdog counter running in Stop mode) 
     IWDGSW       : 0x1 (Software independent watchdog) 
     IPCCDBA      : 0x0  (0x0) 

   Security Configuration Option bytes - 1:

     ESE          : 0x0 (Security disabled) 

   PCROP Protection:

     PCROP1A_STRT : 0x1FF  (0x80FF800) 
     PCROP1A_END  : 0x0  (0x8000800) 
     PCROP_RDP    : 0x1 (PCROP zone is erased when RDP is decreased) 
     PCROP1B_STRT : 0x1FF  (0x80FF800) 
     PCROP1B_END  : 0x0  (0x8000800) 

   Write Protection:

     WRP1A_STRT   : 0xFF  (0x80FF000) 
     WRP1A_END    : 0x0  (0x8000000) 
     WRP1B_STRT   : 0xFF  (0x80FF000) 
     WRP1B_END    : 0x0  (0x8000000) 
OPTION BYTES BANK: 1

   Security Configuration Option bytes - 2:

     SFSA         : 0xD4  (0x80D4000) 
     FSD          : 0x1 (System and Flash non-secure) 
     DDS          : 0x1 (CPU2 debug access disabled) 
     C2OPT        : 0x1 (SBRV will address Flash) 
     NBRSD        : 0x1 (SRAM2b is non-secure) 
     SNBRSA       : 0x14  (0x2003D000) 
     BRSD         : 0x1 (SRAM2a is non-secure) 
     SBRSA        : 0xA  (0x20032800) 
     SBRV         : 0x35000  (0x20000000) 

[AScha.3]

what is "FUS" ?

and did you flash it ?

[Issamos]

Hello @gprgprgpr 

I suggest you to use this tutorial to FUS update. This should do the job.

Best regards.

II

[gprgprgpr]

All those tutorials show "happy path" when everything works, I wouldn't have asked the question in that case. I tried all combination with dfu, uart, and I suspect bootloader might be damaged somehow, I can connect to board only using st-link.

This board is from ebay and I suspect it might be damaged. Just wanted to ensure I'm not missing something obvious before returning it.

[detakm]

From what I can see your device's ESE, FSD, NBRSD and BRSD option bytes look incorrect. I am not certain how your device ended up in that situation but a common cause (from what I've learned) is disrupting power to the device when FUS is working with flash or writing option bytes.