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

[AValt.1]

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

[AValt.1]

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

[Remi QUINTIN]

Once the new application is loaded on the device via OTA, a reset is done.

After reset the application core starts to execute from address 0x8000000. This is the area occupied by BLE_OTA application.

The first thing that the BLE-OTA application does is:

• To jump to the User app when no OTA request is set or a valid User app is present

• Or Implement a BLE service to download the new FW (User app or Encrypted wireless stack)

When a FW update via OTA is requested, a connection is started with the master device to download the code.

After download, the BLE_OTA application generates a reset and the OTA_BLE applicationl looks for a valid application to be present.

When a Wireless stack has been downloaded and needs to be updated, the BLE_OTA application send a command to the FUS to decrypt and install the new FW.

If the new RF stack is not correct, the former one is still valid as the new erroneous one did not overwrite the current one during the OTA download.

[AValt.1]

Hi Remi,

First of all thanks for your clear explanation, i still have some doubts, i will try to be clear.

My problem is that when updating Wireless Stack, with an invalid file the ota firmware doesnt jump to the valid aplication or ota aplication again, i still need to do a manual software reset to recover from that situation.

In order to be able to recover automatically from any situation, i add in the BLE OTA example(stCube1.5) 2 Software resets( lines 306 and 354 of app_entry.c.), to have an application that could recover after a Wireless Stack Update automatically without any user manual reset or something...

My question now is:

I know that i read FUS version 0x0000000, because and error during update process of the Wireless Stack, when i update it with a valid .bin file, (the 2 resets that i add in the code could be a problem i guess), but as in the beggining of the code there is a function: SHCI_C2_FUS_GetState, which after 2 calls (check page 3 in  https://www.st.com/resource/en/application_note/dm00513965-st-firmware-upgrade-services-for-stm32wb-series-stmicroelectronics.pdf  ) should activate FUS and recover the properly Wireless Stack behaviour, why is code execution blocked in that function?.

Finally, the only way to recover was:

Send 2 FUS_GET_STATE comands, i dit it via cli commands, connecting the board 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 SHCI_C2_FUS_GetState() commands at the beginning of code execution, 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.

To conclude i finally add in lines 303 and 353 of file app_entry.c a while( condition) befor NVIC_Reset(), where condition checks SHCI_C2_FUS_GetState()!=0, and everything is ok now, could you answer my question please, thanks a lot.

Regards

Alvaro