STM32WBxx FUS seems to be deleted

[cyancali]

Hi,

I am currently working with the STM32WB Nucleo Boards. I wanted to flash a new FW on the Dongle. Therefore I enabled USB DFU Mode. I used the following command to write the new FW:

$ ./STM32_Programmer.sh -c port=usb1 -w ~/Tools/STM32CubeWB/Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Ota/SW4STM32/Production/Debug/Production.elf

Output:

Memory Programming ...
Opening and parsing file: Production.elf
  File          : Production.elf
  Size          : 20512 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
erasing sector 0000 @: 0x08000000 failed
erasing sector 0001 @: 0x08001000 failed
erasing sector 0002 @: 0x08002000 failed
erasing sector 0003 @: 0x08003000 failed
erasing sector 0004 @: 0x08004000 failed
Erasing memory corresponding to segment 1:
Not flash Memory : No erase done
Download in Progress:
[==================================================] 100% 
 
File download complete
Time elapsed during download operation: 00:00:00.069

After that I could no longer reach FUS. I wanted to check the version but it returned only 0s:

Reading 32-bit memory content
  Size          : 4 Bytes
  Address:      : 0x20030030
 
0x20030030 : 00000000

I tried to use -fwdelete but it only returned errors:

FUS state is FUS_ERROR
 
FUS status is FUS_NOT_RUNNING
Error: Could not start service since FUS is not in IDLE state

I can't do anything at all anymore with this device! What happened?

According to the help/docu this shouldn't lead to bricked device!?

Does anyone know a solution to that issue?

Until now i could not find any help.

Best Regards

Alex

[cyancali]

I tried it now a second time and now it did get detected but the log did look the same...

I am pretty much confused. Is there also a WB variant which is not locked and more debugable with an open source FUS?

[Remi QUINTIN]

When the RF FW is successfully installed, the FUS is not working anymore. So the last 2 messages FUS_ERROR and FUS_NOT_ RUNNING are expected messages.

Now you just have to load the application at 0x08000000 and it should work.

[cyancali]

This worked up to today, now I was working with two Nucleo boards to try and setup a connection between them. Today, I tried again to update the stack via the bootloader. This returned an error. After the upgrade I did -ob displ:

First board:

   Security Configuration Option bytes:
 
     ESE          : 0x1 (Security enabled) 
     SFSA         : 0x0  (0x0) 
     FSD          : 0x0 (System and Flash secure) 
     DDS          : 0x1 (CPU2 debug access disabled) 
     C2OPT        : 0x1 (SBRV will address Flash) 
     NBRSD        : 0x0 (SRAM2b is secure) 
     SNBRSA       : 0x0  (0x0) 
     BRSD         : 0x0 (SRAM2a is secure) 
     SBRSA        : 0x0  (0x0) 
     SBRV         : 0x3FC00  (0x3FC00) 

The SFSA is at 0x00? and also both SRAMs are locked?

For the second

   Security Configuration Option bytes:
 
     ESE          : 0x1 (Security enabled) 
     SFSA         : 0xCB  (0xCB) 
     FSD          : 0x0 (System and Flash secure) 
     DDS          : 0x1 (CPU2 debug access disabled) 
     C2OPT        : 0x1 (SBRV will address Flash) 
     NBRSD        : 0x0 (SRAM2b is secure) 
     SNBRSA       : 0xF  (0xF) 
     BRSD         : 0x0 (SRAM2a is secure) 
     SBRSA        : 0xA  (0xA) 
     SBRV         : 0x3D000  (0x3D000) 

It seems to lock fine, but I neither can start the bootloader anymore or do any update via SWD and only returns me errors and finish the operation with no success.

Is there any option to reset these boards?

[cyancali]

On the second board it seems like I can still upload an application via SWD, but as soon as I start it it runs into the NMI_Handler

[Remi QUINTIN]

SFSA = 0 => This is always a surprising effect I don’t understand. So you used the USB in DFU mode just to upload the RF stack only => fwdelete and then fwupgrade? same RF stack at the same address?

For the second board, I notice that the SBRV pointer is still pointing on the FUS code while the SFSA is correctly located at the beginning of the RF stack.

So this situation (SFSA pointing to address not in line with SBRV ) may occur when a wireless stack has been installed but then CPU2 has been switched to executing FUS.

This typically happens when, after installing the new wireless stack, too many -fusgetstate commands are sent (actually sending two times -fusgetstate makes the wireless stack switch CPU2 execution to FUS).

If you are reading the Device Info Table @0x20030890 and it's valid and presents the correct FUS version V1.0.2, it means that FUS is running correctly and communication with FUS shall be correct.

Now we need to make sure that communication with FUS is correct:

Let's just have a -fusgetstate command status through USB DFU.

Could you check the option bytes to verify the nBOOT0 and nSWBOOT0 are correctly set to enable the DFU mode?

[cyancali]

On the second board I could enable DFU and called -fusgetstate, but it seems to not start the FUS.

./STM32_Programmer.sh -c port=usb1 -fusgetstate      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.2.0                  
      -------------------------------------------------------------------
 
 
 
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 207E3171554D
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WBxx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
 
FUS state is FUS_ERROR
 
FUS status is FUS_NOT_RUNNING
getFUSstate command execution finished

Reading 0x20030030 returns only 0x00.

Regarding the SFSA at 0x00, can this be reseted? I did a -fwdelete and -fwupgrade via SWD.

[Remi QUINTIN]

​Could you call FWgetstate a second time and check the version again.

[cyancali]

Just did it a second time. First -fusgetstate and then read memory:

Reading 32-bit memory content
  Size          : 4 Bytes
  Address:      : 0x20030030
 
0x20030030 : 00000000

The error FUS_ERROR / FUS_NOT_RUNNING persists.

[AValt.1]

Hi, i have almost same problem, SBRV value in my case is 0X3D000, and SFSA is 0xcb, i get this situation by updating with st ble sensor App sending an invalid wireless stack file, such as a pdf or whatever... how could i protect it?

Regards

Alvaro

[Remi QUINTIN]

Please send a FWdelete command to the device to erase the erroneous RF stack.

From what I can see, the FW update is wrong but the SFSA has anyhow been kept to 0xcb while the SBRV (the location where the M0+ should start its code execution) remain to the start of the FUS code.

Then try to update the FUS using the last CubeWB FW package V1.5.0. It contains the last V1.10 FUS version. In the end you should see 0x01010000 at address 0x20030030 (via USB port) and the SFSA should become 0xF6.

Then upgrade the RF stack you want.