P-NUCLEO-WB55 does not working on DFU mode

>>Before this destructive action SFSA was 0xF6, so I should have been able to perform -fwupgrade at 0x080EC000 as it is 24 Kb.

>Totally correct!

But in fact I wasn't able, as I said

I've managed to make everything work today. In case anybody is interested.

Any update on this? I did everything as described in this thread but I do not see my NUCLEO board. I can see dongle though.

Does it mean my NUCLEO board is fried?

​Could you explain your context? Are you using the USB port in DFU mode or the JTAG/SWD port?

Did you set the jumper as described in the Application note?

Can you download all the option bytes?

​First could you explain your context?

Are you using the USB port in DFU mode or the JTAG/SWD port?

Can you download the option bytes?

Can you show the log file to see the error messages?

I managed to make it work. To connect in boot mode I had to plug in 2 USB cables into Nucleo board. move power jumper to usb mcu and add jumper from pin 5 to 7.

Also needed to run STM32_Programmer_CLI.exe -c port=swd mode=UR -ob nSWboot0=1

after this i updated fus which was old and after multiple tries it got updated to latest version.

then i updated firmware now i can see my device

Hi @Community member​,

I have faced the same issue while updating FUS version V1.0.2 to V1.1 and in return I was getting the same error as in your original problem -

 Error: Could not execute fwupgrade command, Wrong address

I changed the FUS directory in my local system to a shorten path ( you may copy the same to Desktop), and it really helped me to get rid of the error.

Currently I'm using STM32programmer Version2.3, and I think ST need to check STM32Programmer bugs, plenty of things are there to improve.

I'm having the exactly same issue as @Community member​  and I'm not able to recover my STM32WB55 Nucleo board. Any attempt to read/write results in a failure. Does anyone has a clue?

My SFSA is also at 0x0 after I executed the procedure to update the M0+ BLE stack firmware.

If SFSA was set to 0x00, it means safeboot has been triggered because option bytes corruption occured.

This may occur during FUS upgrade operation or during any user application operation dealing with option bytes.

When safeboot is triggered it locks the device by setting SFSA=0x00 (all FLASH memory secure) and so no user application/debugger can access the user FLASH memory

anymore. This operation is not reversible.

Starting from FUS V1.1.0 the safeboot is modified to perform a factory reset instead of locking the device.

If your device was already upgraded with FUS v1.1.0, then you can only revert to the manufactory state and this is automatically managed by the FUS. After reboot, the board is completely reset of any data.

Hello Remi, comment ça va?

Thanks for the quick reply. So, I guess that what you described is exactly what happened to me. However, I did managed to update FUS to V1.1.0 before getting this issue. Actually, the problem raised while I was trying to update the Wireless stack, right after successfully update the FUS.

I've tried to reboot the board many times and still CubeProgrammer can't read or write in the Flash.