ST Nucleo WB55RG - Can't enter DFU anymore

[Quentin Morlet]

Hello,

After playing around with the Nucleo board and wanting to try the simple BLE Beacon example, I believe I somehow got the bootloader stuck.

I could enter DFU mode the first time and flash accordingly to the instruction given. However, trying to flash another binary gave the STCubeProgrammer a segfault, and now the device is not recognised anymore and can't seem to be flashed through USB.

Is there any way to recover? Possible to rewrite bootloader / FUS through the STLink?

Thanks a lot

[Uwe Bonnes]

Did you have a look at AN5185.

However I miss a step by step procedure to restore the ST Nucleo WB55RG firmware.

[Quentin Morlet]

I did quickly, haven't seen anything anything related to restoring the firmware yes..

[Uwe Bonnes]

Look more closely. After some fiddling I could restore the ST Nucleo WB55RG based on AN5185.

[Quentin Morlet]

Could you tell me which part in specific? That'd be great.

I'm reading it more thoroughly now.

[Remi QUINTIN]

​Do you use CubeProgrammer tool in USB DFU mode?

Could you download all the options bytes?

Is the FUS still OK? have a look at 0x20030020 and check the value.

Note that you can also connect via the ST LINK port still using the CubeProgrammer tool. Just set the jumpers proprely. BOOT0 pin HIGH: CN7-5 to CN7-7 and use the ST_LINK connection on the board (not the USER_USB one).

[Quentin Morlet]

Hello

> ​Do you use CubeProgrammer tool in USB DFU mode?

Yes, but CubeProgrammer can't connect to it through USB

> Could you download all the options bytes?

Through the ST-Link port yes, and looks like I can program them too.

> Is the FUS still OK? have a look at 0x20030020 and check the value.

Looks to be kaput :

$ ST-LINK_CLI.exe -c UR -r32 0x20030030 1
STM32 ST-LINK CLI v3.2.0.0
STM32 ST-LINK Command Line Interface
 
ST-LINK SN : 0671FF393132534E43042927
ST-LINK Firmware version : V2J33M25
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V.
Connection mode : Connect Under Reset.
Device ID:0x495
Device flash Size : 1024 Kbytes
Device family :STM32WBxx
 
 
0x20030030 : 00000000

I imagine I should udpate the FUS through the ST-Link interface?

Also: Every time time I connect through the CubeProgrammer GUI, I get "Error: Data read failed", even though successfully connects and reads Option Bytes.

[Quentin Morlet]

To add the option bytes here :

Option bytes:
RDP             : Level 0
BOR             : Level 0
IWDG_SW         : 0
WWDG_SW         : 1
IWDG_STOP       : 1
IWDG_STDBY      : 1
nRST_STOP       : 1
nRST_STDBY      : 1
nRST_SHDW       : 1
PCROP_RDP       : 0
nBOOT0          : 1
SRAM2_PE        : 1
SRAM2_RST       : 0
nSWBOOT0        : 1
ESE             : 1
FSD             : 0
DDS             : 1
SFSA            : 0x00
C2OPT           : 1
NBRSD           : 0
BRSD            : 0
SNBRSA          : 0x0
SBRSA           : 0x0
SBRV            : 0x3FC00
WRP1A_STRT      : 0xFF
WRP1A_END       : 0x00
WRP1B_STRT      : 0xFF
WRP1B_END       : 0x00
PCROPA_STRT     : 0x01FF
PCROPA_END      : 0x0000
PCROPB_STRT     : 0x01FF
PCROPB_END      : 0x0000

[Remi QUINTIN · Accepted solution]

​I am affraid I can't do much to help you recover from this situation.

What I can see from your option bytes is that

ESE        : 0x1 (Security enabled)

FSD        : 0x0 (System and Flash secure)

FSA        : 0x0  (0x0) 

C2OPT   : 0x1 (SBRV will address Flash)

This means that the complete Flash memory is secure.

Worse the FSA =0, so the complete Flash memory is secure and become inaccessible. This is why you can’t get access to the values located in Flash either through USB DFU mode or ST LINK. Worse you can even not load a code in Flash!!!

These option bytes can only modified by the CPU2 (M0+). Unfortunately C2OPT being set to 1, the CPU2 must boot from Flash. As there is no way to load a code in Flash, there is no way to load a code to revert to a situation where these options bytes would be set to operational values like SFSA set to 0xCB.

In one word, your chip is blocked!!!

I don’t know how I can help you now.

One very important point to clarify: Can you explain what did you do (command sequence) to get into such deadlock?

Normally only the M0+ code can modify those option bytes and only the wireless FW (not modifiable by the user as loaded as a binary) can be executed from CPU2 (M0+). So we would like to understand the sequence of actions you did to get stuck with such configuration.

[Quentin Morlet]

Oh wow alright...

I don't have the full log of actions but, I was trying to run the BLE_Beacon example, followed the guide to flash the BLE STack on the copro somewhat sucessfully, then tried to run the application. The application did not seem to work so I think I tried to either reflash the FUS or the stack and had a segfault at some point where then the device was not able to be seen in DFU anymore.