Associate

Solved

ST Nucleo WB55RG - Can't enter DFU anymore

Forum|Forum|6 years ago
August 16, 2019
6 replies
3315 views

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

This topic has been closed for replies.

Best answer by Remi QUINTIN

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.

Uwe Bonnes

Chief

Did you have a look at AN5185.

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

Quentin MorletAuthor

Associate

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

Uwe Bonnes

Chief

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

Remi QUINTIN

Technical Moderator

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 MorletAuthor

Associate

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 MorletAuthor

Associate

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 QUINTINAnswer

Technical Moderator

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 MorletAuthor

Associate

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.

NJian.1

Visitor II

Hey man,

i have the same issue with you, and i already fixed this problem, i'm come here to solve your problem.

if you want to into DFU mode that you need change the nBOOT0 = 0 in option bytes and apply program in MCU as below picture

, and when you run the application code that you needs change the nBOOT0 back to 1, hope this has solved your problem!

Remi QUINTIN

Technical Moderator

Indeed you have to check the option bytes when you move from the SWD port to the USB port and vice versa.

But this is of no use if the SFSA option byte = 0.

Note a very important point: If you are using CubeWB FW package V1.5.0 and update the FUS to the new version 1.1.0, then you will be able to revert to the manufactory configuration (even with SFSA = 0) if you perform the sequence below:

Write 0x00008000 at @0x5800040c
Set RDP level1 then Level0

This will prevent having a blocked board forever. After this sequence, the board is blank with only the last FUS V1.1.0 and the SFSA back to the value 0xF4.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded