P-NUCLEO-WB55 does not working on DFU mode

[WWU.807]

Hi, All,

I want to use CubeMon-RF to monitor the USB dongle of the P-NUCLEO-WB55.

According to the Manual : STM32CubeMonitor-RF software tool for wireless performance measurements,

The USB dongle must be monitored using the VCP DEVICE link, and it need to update Firmware to use the example : ble_transparent_mode_vcp.

To update the USB dongle's firmware, I must use STM32CubeProg tool.

According to the manual : STM32CubeProgrammer software description,

USB dongle must use DFU mode for Firmware update, and I install DFU driver follow the Chapter 1.2.4.

And set the DFU mode according to this web page https://visualgdb.com/tools/STM32WBUpdater/connecting/.

However, when the device is plugged into the PC, the Window Device Manager does not detect any device, and the USB dongle is the same as STM32WB Nucleo.

And Win7 is the same as Win10.

May I ask how to solve this?

Thanks. ​

[Remi QUINTIN]

​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?

[Remi QUINTIN]

​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?

[Pavel Krupets]

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

[PS.2]

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.

[eriknayan]

Hello @Community member​ , I'm having the same issue around here, how did you manage to resolve this?

Thanks!

[eriknayan]

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.

[Remi QUINTIN]

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.

[eriknayan]

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.

[Remi QUINTIN]

Be sure to reconnect with the JTAG/SWD port and reset the RDP level from 1 to 0 (=0xAA). This may be the reason why you cannot get access to the protected flash.

[eriknayan]

I've done this but the flash is still protected. Even though RDP is at 0xAA, I still can't write or read from the flash. I think the Wireless stack update really bricked the MCU, which is unfortunate because I followed exactly the procedure described in the readme.