STM32WBxx FUS seems to be deleted

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?

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

​

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?

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.

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

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.

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

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.

Hi Remi,

it doesnt seem to be a solution for me, i need to be able to update via OTA wireless Stack, and if i send via OTA a pdf or other invalid file, i see 2 scenarios:

1. Sending an Invalid file with St Ble sensor App to update Wireless Stak: SBRV value is 0x3D000, and SFSA is 0xcb, while SBRV should be 0x32c00 (which is the value that i have read with st Cube Programmer whem it works properly), after update and receiving confirmation the 2 leds (blue and green remain turned on nothing happens, i need a solution to recover from that without making the final user do a Software reset....Any help?
2. If i try to add in the Ble_ota Fw from last package 1.5, 2 resets lines 339 and 294 of file app_entry.c, it recovers from sending an invalid file to update wireless stack automatically, without the need of making software resets, but in this scenario, when i try to update the Wireless stack with a correct file this happens:

When updating with correct BLE Wireless Stack, and after having received update confirmation, it stays blocked in function

SHCI_C2_FUS_GetState() (the proyect Ble_OTA app, file app_entry.c line 275 ) and doesnt return, in that situation, i have tried to reset the board (Software reset), but it doesnt work. When that happens i have to connect the board as follows:

1. Jumper between CN7.5(VDD) and CN7.7(Boot0)
2. Power ON via USB_USER and Jumper JP1(USB_MCU)

And then when i execute this command via cli --> STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1 i get:

USB speed  : Full Speed (12MBit/s)

Manuf. ID  : STMicroelectronics

Product ID : DFU in FS Mode

SN     : 20803176554D

FW version : 0x011a

Device ID  : 0x0495

Device name : STM32WBxx

Flash size : 1 MBytes

Device type : MCU

Device CPU : Cortex-M0+/M4

0x20030030 : 00000000

1. So i have to install the fus again, why is this due to?

Please i need a profesional solution for both scenarios, from my point of view, reprogramming the board, or making Software resets manually is not a solution.

Regards

Hi Remi,

I solved it, the reason why we are reading FUS version 0x0000000 is beacuse its not active, to activate it you have to send 2 FUS_GET_STATE comands, i dit it via cli commands, conected in usb BOOT mode interface, and then check FUS version wich is correct, then after that everything is ok, i wonder why if BLE_OTA firmware sends that commands at the beginning, it doesnt recover after 2 resets... it stays blocked there.. is it due to different behave when connected in usb Boot Mode?, i did not found documentation about it.

Regards

Alvaro