How can I reset the P-Nucleo-WB55 to original demo firmware?

[AClif]

TLDR: Is there a simple way (or at least clear step-by-step instructions) to reset the P-NUCLE-WB55 back to the firmware it was delivered with?

Full:

I have a P-Nucleo-WB55 and am trying to develop a project with it. I ran the "Getting Started" demo on the back of the pack and it worked brilliantly, so I got in with my project development. This started with a simple project to run a sensor using the SPI interface which worked fine. I then went to try some BLE development which is why I got this board.

Unfortunately, this is where my problems start. I was trying the BLE HeartRate demo and no matter what i did I couldn't get it to work. I followed the instructions for the FUS and BLE stack update and spent the next 24 hours thinking I had bricked the board as it would no longer do anything (I followed the ST instructions verbatim). I finally managed to get the update to work by using a mix of instructions from here and reddit on top of the ST release notes.

Anyway, I now have the most rect FUS from STM32Cube_FW_WB_V1.5.0 installed, as well as the full BLE stack, but still I can not get anything bluetoothy to work. At this point I decided the most sensible thing would be to try and get it back into its delivery state. I believe the firmware that should be in the main board (I haven't touched the dongle) is the BLE_p2pServer_ota, correct? I have opened this in STM32CubeIDE and itseems to program correctly if I tie the boot0 pin high (pins 5 & 7 or CN7), but it still doesn't seem to work at all. It also won't let me debug it, but I gather that is because the project doesn't enable the debug pins or something.

I am not too familiar with the STM32CubeIDE and have a had a lot of trouble getting anything going. The various application and release notes for the WB 55 seem to be inconsistent with each other and out of date.

Is there a clear set of instructions somewhere (assume I have no idea what I am doing) that can show me how to reprogram the P-NUCLEO-WB55 main board back to how it was when I got it?

Thanks in advance to anyone who can help!

[Remi QUINTIN]

​Yes!

In fact fwupgrade command is a secure function triggering action from the FUS to handle FW inside the secure area.

You don’t need this to download an application in the user area. -d just downloads the code as a simple write access.

[AClif]

SUCCESS!!!

I used the command

STM32_Programmer_CLI.exe -c port=usb1 -d BLE_p2pServer_reference.hex 0x08000000

which worked (I realise that I didn't need the address for a HEX file)

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 20703173554D
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WB55xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
Warning: Write address is ignored for hex, Srec and elf files
 
Memory Programming ...
Opening and parsing file: BLE_p2pServer_reference.hex
  File          : BLE_p2pServer_reference.hex
  Size          : 34192 Bytes
  Address       : 0x08000000
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 8]
erasing sector 0000 @: 0x08000000 done
erasing sector 0001 @: 0x08001000 done
erasing sector 0002 @: 0x08002000 done
erasing sector 0003 @: 0x08003000 done
erasing sector 0004 @: 0x08004000 done
erasing sector 0005 @: 0x08005000 done
erasing sector 0006 @: 0x08006000 done
erasing sector 0007 @: 0x08007000 done
erasing sector 0008 @: 0x08008000 done
Download in Progress:
██████████████████████████████████████████████████ 100%
 
File download complete
Time elapsed during download operation: 00:00:00.857

At this point, I removed the BOOT0 jumper and reset the board, and it did the same as it had before. Looking through the argument list for STM32_Programmer_CLI.exe, I came across the -startwirelessstack argument and it got me wondering.

I ran the following function:

STM32_Programmer_CLI.exe -c port=usb1 -startwirelessstack

I had removed the BOOT0 jumper and had to replace it and reset the processor to get the command to be accepted, but then got this:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 20703173554D
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WB55xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
FUS state is FUS_IDLE
 
FUS status is FUS_NO_ERROR
Starting wireless stack ...
Starting wireless stack finished
startwirelessStack command execution finished

I wasn't sure whether this remains through reset, but I removed the BOOT0 jumper again and pressed the reset button and it sprang to life!

It now seems to be working and is doing what is was when i first got it!

As an aside, should I need to run the -startwirelessstack command? In normal operation (e.g. in my final application), how is the wireless stack started? Apologies for my ignorance, I don't really understand the wireless side of things!

Thank you so so much for your help, like I say, this is the reason I like ST!

Thanks,

Andrew

[AClif]

Hi Remi, SUCCESS!!!

I downloaded the firmware using the following command:

STM32_Programmer_CLI.exe -c port=usb1 -d BLE_p2pServer_reference.hex 0x08000000

Giving the following successful response:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 20703173554D
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WB55xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
Warning: Write address is ignored for hex, Srec and elf files
 
Memory Programming ...
Opening and parsing file: BLE_p2pServer_reference.hex
  File          : BLE_p2pServer_reference.hex
  Size          : 34192 Bytes
  Address       : 0x08000000
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 8]
erasing sector 0000 @: 0x08000000 done
erasing sector 0001 @: 0x08001000 done
erasing sector 0002 @: 0x08002000 done
erasing sector 0003 @: 0x08003000 done
erasing sector 0004 @: 0x08004000 done
erasing sector 0005 @: 0x08005000 done
erasing sector 0006 @: 0x08006000 done
erasing sector 0007 @: 0x08007000 done
erasing sector 0008 @: 0x08008000 done
Download in Progress:
██████████████████████████████████████████████████ 100%
 
File download complete
Time elapsed during download operation: 00:00:00.857

Upon removing the BOOT0 jumper and resetting the STM32, I got the same response I have had before, with LED2 just staying on permanently.

Looking through the arguments for STM32_Programmer_CLI.exe, I noticed a -startwirelessstack argument. On a whim, I ran the following command:

STM32_Programmer_CLI.exe -c port=usb1 -startwirelessstack

This failed initially as the BOOT0 jumper wasn't fitted.

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
Error: Target device not found
Establishing connection with the device failed

I replaced the jumper and reset the board, at which point the same command was successful:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 20703173554D
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WB55xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
FUS state is FUS_IDLE
 
FUS status is FUS_NO_ERROR
Starting wireless stack ...
Starting wireless stack finished
startwirelessStack command execution finished

At this point, I removed the BOOT0 jumper again and reset the board (using the button) and it sprang to life!

It is now doing what it was when I first got the board, which is excellent!

In terms of the -startwirelessstack argument, will I need to do this every time I program it? How does this work in normal applications?

Thank you so so much for all your help, this is why I stick with STM32! :beaming_face_with_smiling_eyes: :thumbs_up:

Thanks,

Andrew

[AClif]

Oops, I posted the last thing twice, as I missed the "more answers" button so I thought it hadn't been uploaded! It won't let me delete the duplicate.

[Remi QUINTIN]

The startwirelessStack parameter only starts the RF stack located in the secure area and executed by the M0+ core. It does not launch the application running on the M4 core.​ So you may see some advertising phase but you won’t be able to communicate with the application via your mobile using the ST BLE sensor android app.

Normally, once the flash memory is updated, you just have to remove the BOOT0 connector (pin 5 -7 on CN7), reset the board and you should see the green light blinking for a while indicating the device is currently advertising. You should be able to connect to this device with your mobile.

What could have happen in your case is some wrong values for the option bytes defining the boot mode. To boot from the beginning of the main Flash memory (0x08000000), be sure that the option byte nSWBoot0 is set and no HW connector, or nSWBoot0 is reset but in this case the nBOOT0 option byte must be set to 1.

[Remi QUINTIN]

​By the way, regarding the error message from the -rdu command, there may be an issue with the Cube programmer interface.

Despite the error <<Error: Disabling memory Read Protection failed..>> , the RDP level is correctly set to the requested value. You can check this by reading the RDP value once the -RDU command completed.

[AClif]

That's great Remi, thank you. I have now imported and compiled the same project using STM32CubeIDE and it still works great!

Thank you for all of your help, I am now going to try a couple of other demos, and then have a go at my own application.

[Vleon.1]

I'm in your situation about having trouble with update firmware, sorry if i'm not pointing out the focus of your question, i followed the application note for ota update ble for stm32wb55 nucleo but i didn't succed, so i'm interested in the way you sorted out this problem, if you can share some C code or how to manage memory in CubeProgrammer to make it possible.

Thanks