How to disable write protection on STM32WB dongle?

[NGama]

Here is the log of the error:

13:22:22 : Memory Programming ...

13:22:22 : Opening and parsing file: P-NUCLEO-WB55.Nucleo_Thread_Coap_DataTransfer.elf

13:22:22 : File : P-NUCLEO-WB55.Nucleo_Thread_Coap_DataTransfer.elf

13:22:22 : Size : 114550 Bytes

13:22:22 : Address : 0x08000000 

13:22:22 : Erasing memory corresponding to segment 0:

13:22:22 : Erasing internal memory sectors [0 27]

13:22:22 : erasing sector 0000 @: 0x08000000 failed

13:22:22 : erasing sector 0001 @: 0x08001000 failed

13:22:22 : erasing sector 0002 @: 0x08002000 failed

13:22:22 : erasing sector 0003 @: 0x08003000 failed

13:22:22 : erasing sector 0004 @: 0x08004000 failed

13:22:22 : erasing sector 0005 @: 0x08005000 failed

13:22:22 : erasing sector 0006 @: 0x08006000 failed

13:22:22 : erasing sector 0007 @: 0x08007000 failed

13:22:22 : erasing sector 0008 @: 0x08008000 failed

13:22:22 : erasing sector 0009 @: 0x08009000 failed

13:22:22 : erasing sector 0010 @: 0x0800a000 failed

13:22:22 : erasing sector 0011 @: 0x0800b000 failed

13:22:22 : erasing sector 0012 @: 0x0800c000 failed

13:22:22 : erasing sector 0013 @: 0x0800d000 failed

13:22:22 : erasing sector 0014 @: 0x0800e000 failed

13:22:22 : erasing sector 0015 @: 0x0800f000 failed

13:22:22 : erasing sector 0016 @: 0x08010000 failed

13:22:22 : erasing sector 0017 @: 0x08011000 failed

13:22:22 : erasing sector 0018 @: 0x08012000 failed

13:22:22 : erasing sector 0019 @: 0x08013000 failed

13:22:22 : erasing sector 0020 @: 0x08014000 failed

13:22:22 : erasing sector 0021 @: 0x08015000 failed

13:22:22 : erasing sector 0022 @: 0x08016000 failed

13:22:22 : erasing sector 0023 @: 0x08017000 failed

13:22:22 : erasing sector 0024 @: 0x08018000 failed

13:22:22 : erasing sector 0025 @: 0x08019000 failed

13:22:22 : erasing sector 0026 @: 0x0801a000 failed

13:22:22 : erasing sector 0027 @: 0x0801b000 failed

13:22:22 : Erasing memory corresponding to segment 1:

13:22:22 : Not flash Memory : No erase done

13:22:22 : Download in Progress:

13:22:23 : File download complete

13:22:23 : Time elapsed during download operation: 00:00:00.618

13:22:23 : RUNNING Program ... 

13:22:23 : Address: : 0x08000000

13:22:23 : Error: Start operation failed

[Remi QUINTIN]

​Could you download the all option  bytes, both the secure one and those related to the memory protection.

You could also try to write OxBB to the RDP option byte and then back to 0xAA. This should clean all the non-secure area of the flash memory where the application is usually loaded.

[NGama]

I have tried the option of writing 0xAA to RDP and now I cant even establish a connection or change back the RDP.

09:56:08 : USB speed : Full Speed (12MBit/s)

09:56:08 : Manuf. ID : STMicroelectronics

09:56:08 : Product ID : DFU in FS Mode

09:56:08 : SN : 206A387A3036

09:56:08 : FW version : 0x011a

09:56:08 : Device ID : 0x0495

09:56:13 : Warning: Device is under Read Out Protection

09:56:24 : Disabling memory Read Protection...

09:56:35 : Error: Disabling memory Read Protection failed

09:56:35 : Disconnected from device.

[Remi QUINTIN]

Could you download the all option bytes, both the secure one and those related to the memory protection.

I hope the RDP option byte was not set to 0xCC => This would fully protect the device with no way to exit from this situation.

[NGama]

OPTION BYTES BANK: 0

  Read Out Protection:

   RDP     : 0xAA (Level 0, no protection) 

  BOR Level:

   BOR_LEV   : 0x0 (BOR Level 0 reset level threshold is around 1.7 V) 

  User Configuration:

   nBOOT0    : 0x1 (nBOOT0=1) 

   nBOOT1    : 0x1 (Boot from code area if BOOT0=0 otherwise embedded SRAM) 

   nSWBOOT0   : 0x1 (BOOT0 taken from PH3/BOOT0 pin) 

   SRAM2RST   : 0x0 (SRAM2 erased when a system reset occurs) 

   SRAM2PE   : 0x1 (SRAM2 parity check disable) 

   nRST_STOP  : 0x1 (No reset generated when entering the Stop mode) 

   nRST_STDBY  : 0x1 (No reset generated when entering the Standby mode) 

   nRSTSHDW   : 0x1 (No reset generated when entering the Shutdown mode) 

   WWDGSW    : 0x1 (Software window watchdog) 

   IWGDSTDBY  : 0x1 (Independent watchdog counter running in Standby mode) 

   IWDGSTOP   : 0x1 (Independent watchdog counter running in Stop mode) 

   IWDGSW    : 0x1 (Software independent watchdog) 

   IPCCDBA   : 0x0 (0x0) 

  Security Configuration Option bytes:

   ESE     : 0x1 (Security enabled) 

   SFSA     : 0xCB (0xCB) 

   FSD     : 0x0 (System and Flash secure) 

   DDS     : 0x1 (CPU2 debug access disabled) 

   C2OPT    : 0x1 (SBRV will address Flash) 

   NBRSD    : 0x0 (SRAM2b is secure) 

   SNBRSA    : 0x14 (0x14) 

   BRSD     : 0x0 (SRAM2a is secure) 

   SBRSA    : 0xA (0xA) 

   SBRV     : 0x32C00 (0x32C00) 

  PCROP Protection:

   PCROP1A_STRT : 0x1FF (0x8000FF8) 

   PCROP1A_END : 0x0 (0x8000008) 

   PCROP_RDP  : 0x0 (PCROP zone is kept when RDP is decreased) 

   PCROP1B_STRT : 0x1FF (0x8000FF8) 

   PCROP1B_END : 0x0 (0x8000008) 

  Write Protection:

   WRP1A_STRT  : 0xFF (0x807F800) 

   WRP1A_END  : 0x0 (0x8000000) 

   WRP1B_STRT  : 0xFF (0x807F800) 

   WRP1B_END  : 0x0 (0x8000000) 

[Remi QUINTIN]

​I don’t see anything wrong in these values. ALL the protection options bytes (PCROPxx_STRT and _END, WRPxx_STRT and _END) are not defining any protected areas.

If you really apply the sequence 0xB and then 0xAA to the RDP option byte, the 27 first sectors from 0x08000000 should be ready (all clear)  to be overwritten by the programming.

I am assuming you’re using the last CubeWB FW V1.3.0 package and the new CubeProgrammer V2.2  programing the dongle in USB-DFU mode (CLI mode) with the switch set to the far side from the USB connector.

What is puzzling me is this “File download complete�? message. You should compare the content of the Flash memory with the .elf file. It should be the same. So this would mean the issue is not this download.

One more point to check: did you update the FUS on this dongle? Read the value at 0X20030030.

Did you load the correct RF stack? I see the SFSA being set to 0xCB which is OK for a BLE stack but not for a Thread full feature (FTD) stack which is bigger. According to the release notes the stm32wb5x_Thread_FTD_fw.bin  should be loaded at 0x0809F000. And so the SFSA option byte should be set to 0x9F (not CB).

 This could explain why your application is not starting correctly.

[NGama]

Yes, this was the solution to the problem. I had to update the firmware. Thank you very much for your time.