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]

If you are confident enough that you managed to update your board with the latest FUS V1.10 version and the Full BLE stack from the CubeWB FW package V1.5.0, the quickest thing to do would be to load the hex file located under STM32Cube_FW_WB_V1.5.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\BLE_p2pServer\Binary at address 0x08000000.

And it should work after reset and removal of the connector setting the BOOT0 value (pin 5 and 7 of CN7)

You can use the USB port in DFU mode or the SWD port.

Please also check the option bytes so that the boot is launched from the main flash memory.

[AClif]

Hi Remi,

Thank you for the detailed answer. I have downloaded the hex file in the location you gave into the board and it still doesn't work I'm afraid. The green LED (LD2) comes on, but it just stays on. I have used STM32CubeProgrammer and tried downloading it with both the on-board ST-LINK (with and without BOOT0 tied high), and the USB_USER connector, and they all give the same result. I also had a friend who has the same board upload the memory content from his board (which works correctly, LD2 flashing on startup), and while the uploaded binary is different from the binaries i have looked at, it does the exact same thing. Have I put the right BLE firmware in? Should I try different ones? I notice the documentation doesn't mention the full and light versions, so I assume this is a recent thing?

Thanks again

[AClif]

Oh, I forgot to say, I check the Option bytes, and it is set to boot from main flash

[Remi QUINTIN]

Could you provide the sequence of commands you use to update your board?

A log of the results of these commands would help to understand if there is something wrong.

Could you also provide a dump of all the option bytes?

Could you tell me what is the value at address 0x20030030? use the USB port for that.

One trick before upgrading the board is to start from a clean user area. this can be achieved by setting the RDP option byte to 0xBB (level 1) and then back to 0xAA (level 0). This will trigger a mass erase of the user area of the main flash memory. Then download the hex file again at address 0x08000000.

[AClif]

Hi Remi,

In trying to update the firmware, I am using the STM32CubeProgrammer GUI, rather than the CLI commands in the command prompt (I am in Windows 10).

For the FUS and BLE update I used the sequence from the Release_Notes.htm, but with the read protection enabled then disabled as per forum and reddit posts:

STM32_Programmer_CLI.exe -c port=usb1 -ob RDP=0xBB
STM32_Programmer_CLI.exe -c port=usb1 -ob RDP=0xAA
   POWER CYCLE HERE
STM32_Programmer_CLI.exe -c port=usb1 -rdu
STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1
STM32_Programmer_CLI.exe -c port=usb1 -fwdelete
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade stm32wb5x_FUS_fw_1_0_2.bin 0x080EC000 firstinstall=0
STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1   (TO CHECK!)
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade stm32wb5x_FUS_fw.bin 0x080EC000 firstinstall=0
STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1 (TO CHECK AGAIN!)
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade stm32wb5x_BLE_Stack_full_fw.bin 0x080CB000 firstinstall=1

After the trick with the RDP, all of the above commands seemed to work successfully.

The option bytes are as follows:

Read Out Protection		
RDP		AA	
 
BOR Level		
BOR_LEV	0	
 
User Configuration		
nBOOT0		Checked	
nBOOT1		Checked	
nSWBOOT0	Checked	
SRAM2RST	Unchecked	
SRAM2PE	Checked	
nRST_STOP	Checked	
nRST_STDBY	Checked	
nRSTSHDW	Checked	
WWDGSW	Checked	
IWGDSTDBY	Checked	
IWDGSTOP	Checked	
IWDGSW	Checked	
IPCCDBA	0x0	
 
Security Configuration Option Bytes		
ESE			Checked	
SFSA		0xcb	
FSD			Unchecked	
DDS		Checked	
C2OPT		Checked	
NBRSD		Unchecked	
SNBRSA		0xf	
BRSD		Unchecked	
SBRSA		0xa	
SBRV		0x3d000	
 
PCROP Protection	Value	Address
PCROP1A_STRT		0x1ff	0x8000ff8
PCROP1A_END		0x0		0x8000008
PCROP_RDP			Unchecked	
PCROP1B_STRT		0x1ff	0x8000ff8
PCROP1B_END		0x0		0x8000008
 
Write Protection	Value	Address
WRP1A_STRT			0xff		0x80ff000
WRP1A_END			0x0		0x8000000
WRP1B_STRT			0xff		0x80ff000
WRP1B_END			0x0		0x8000000

In terms of changing the RDP option, I had to do this in order to the get the FUS and BLE FW update to work, otherwise I got "firmware is not authentic" errors, and the FUS version never changed. from the 0.5.0.2. One thing I did notice was that in order to set the RDP back to 0xAA, I had to power cycle the board. Is this correct?

Will resetting the RDP not wipe the FUS and BLE FW as well?

If I read the FUS State in the GUI, I get FUS version v1.1.0.0.

If I read it from the command prompt, I get the following (which I think shows the same version):

      -------------------------------------------------------------------
                       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
 
 
Reading 32-bit memory content
  Size          : 4 Bytes
  Address:      : 0x20030030
 
0x20030030 : 01010000

A random aside question: How does the software know which firmware I am writing (M4 or M0+)? Is is defined by the memory start location?

Thanks again!

[Remi QUINTIN]

​Perfect!

>One thing I did notice was that in order to set the RDP back to 0xAA, I had to power cycle the board. Is this correct?

Normally you should not have to power off and on your board... strange!

>Will resetting the RDP not wipe the FUS and BLE FW as well?

No as the FUS and BLE FW are protected by the secure area. This  area (starting at the location pointed by the SFSA option byte) is NOT impacted by the masse erase triggered by the change of RDP level. The mass erase only impacts the user (non-protected) area.

>I get FUS version v1.1.0.0.

So it is the most recent and correct FUS version

Now  your is correctly updated with the p2pserver application.

[AClif]

Hi Remi,

I just went to set and reset the write protection and the process reminded me of something I had to do last time. When I try and set the RDP back to 0xAA, i get a message telling me the RDP is set, so I should use the -rdu command to unprotect. This is what i had to do last time as well (I had forgotten). This time, I tried before unplugging and replugging the USB with no success. When I plugged the USB back in, it failed again, the first time, but the second time it worked. Command prompt dump below.

If I wanted to download the p2pserver application using the CLI executable, are there any special flags I should use? I am not really clear on the firstinstall flag. My guess at the correct command is:

STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade BLE_p2pServer_reference.hex 0x08000000 firstinstall=???

What should I use in firstinstall?

Thanks again for all your help, the amazing support is why I love the STM32!

C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -ob RDP=0xBB
      -------------------------------------------------------------------
                       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
 
UPLOADING OPTION BYTES DATA ...
  Bank          : 0x00
  Address       : 0x1fff8000
  Size          : 128 Bytes
██████████████████████████████████████████████████ 100%
 
PROGRAMMING OPTION BYTES AREA ...
  Bank          : 0x00
  Address       : 0x1fff8000
  Size          : 128 Bytes
██████████████████████████████████████████████████ 100%
Verifying Read Out Protection...
Read Out Protection has been set successfully.
Device will be disconnected
 
 
C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -ob RDP=0xAA
      -------------------------------------------------------------------
                       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
Warning: Device is under Read Out Protection
Error: RDP level is set to 1 (0xBB), try using Read UnProtect (-rdu) command in order to remove the Read Out Protection.
 
 
C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -rdu
      -------------------------------------------------------------------
                       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
Warning: Device is under Read Out Protection
 
Disabling memory Read Protection...
 
Error: Disabling memory Read Protection failed
 
C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -ob RDP=0xAA
      -------------------------------------------------------------------
                       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
Warning: Device is under Read Out Protection
Error: RDP level is set to 1 (0xBB), try using Read UnProtect (-rdu) command in order to remove the Read Out Protection.
 
 
C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -rdu
      -------------------------------------------------------------------
                       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
Warning: Device is under Read Out Protection
 
Disabling memory Read Protection...
 
Error: Disabling memory Read Protection failed
 
 
C:\ST\STM32Cube_FW_WB_V1.5.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x>STM32_Programmer_CLI.exe -c port=usb1 -rdu
      -------------------------------------------------------------------
                       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
 
Disabling memory Read Protection...
 
Memory Read Protection disabled successfully

[Remi QUINTIN · Accepted solution]

The -rdu command has normally the same effect as setting the RDP option byte to 0xAA, triggering the mass erase of the user area.

The non-detection of the USB port the first time is strange as it is finally recognized the second time.

firstinstall parameter is not key for the application.

Do not forget the -d argument before the application name.

You can use the GUI version of the Cube programmer tool to program the user area as it does not involve any secure SW (FUS).

The sequence of commands in the log looks weird.

I am afraid some error messages are in fact only warnings.

The best thing to check if the error is real is to read the RDP option byte to confirm whether the RDP really level is changed or not.

[AClif]

Hi Remi, Thanks for that. Just to check, does the -d argument replace the -fwupgrade argument?

Thanks,

Andrew