Wireless Stack recovery for STM32WB

[Tim.N]

I've gotten my STM32WB55 into a state where CPU2 is booting into a "wireless firmware" area, but I think it's crashing when it starts. I can no longer talk to FUS inside CPU2:

-------------------------------------------------------------------
                        STM32CubeProgrammer v2.5.0                  
      -------------------------------------------------------------------
 
 
 
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 205434853236
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WBxx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
 
FUS state is FUS_ERROR
 
FUS status is FUS_NOT_RUNNING
getFUSstate command execution finished

stm32_programmer_cli -c port=usb1 -ob displ
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.5.0                  
      -------------------------------------------------------------------
 
 
 
USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in FS Mode
SN          : 205434853236
FW version  : 0x011a
Device ID   : 0x0495
Device name : STM32WBxx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M0+/M4
 
 
UPLOADING OPTION BYTES DATA ...
 
  Bank          : 0x00
  Address       : 0x1fff8000
  Size          : 128 Bytes
 
[==================================================] 100% 
 
 
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       : 0x0 (nBOOT0=0 Boot selected based on nBOOT1) 
     nBOOT1       : 0x1 (Boot from Flash if nBoot0=0 otherwise system memory) 
     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         : 0xB4  (0xB4) 
     FSD          : 0x0 (System and Flash secure) 
     DDS          : 0x1 (CPU2 debug access disabled) 
     C2OPT        : 0x1 (SBRV will address Flash) 
     NBRSD        : 0x0 (SRAM2b is secure) 
     SNBRSA       : 0xF  (0xF) 
     BRSD         : 0x0 (SRAM2a is secure) 
     SBRSA        : 0xA  (0xA) 
     SBRV         : 0x32800  (0x32800) 
 
   PCROP Protection:
 
     PCROP1A_STRT : 0x1FF  (0x80FF800) 
     PCROP1A_END  : 0x0  (0x8000800) 
     PCROP_RDP    : 0x0 (PCROP zone is kept when RDP is decreased) 
     PCROP1B_STRT : 0x1FF  (0x80FF800) 
     PCROP1B_END  : 0x0  (0x8000800) 
 
   Write Protection:
     WRP1A_STRT   : 0xFF  (0x80FF000) 
     WRP1A_END    : 0x0  (0x8000000) 
     WRP1B_STRT   : 0xFF  (0x80FF000) 
     WRP1B_END    : 0x0  (0x8000000)

I was modifying code in my application to use FUS to update the wireless firmware, and was playing with creating an update path that didn't require erasing the existing stack. In this case, I started with FUS v1.1.0, wireless stack v1.11.0 (stm32wb5x_BLE_HCILayer_fw.bin).

Sequence of events (run automatically inside my firmware)

• I uploaded a new firmware image into the internal filesystem of my firmware
• CPU1 switched CPU2 into FUS, wireless stack rebooted the part (via options application)
• Programmed in the new image to 0xb4000 since SFSA was 0xde, and gave the update process 2 extra pages of space to work with
• CPU1 asked CPU2's FUS to install it
• FUS went into the "state=16, err=0" mode for ~7 seconds
• FUS rebooted the part (via options application)
• FUS went into the "state=0, err=0" mode
• CPU1 asked CPU2's FUS to start the wireless stack
• FUS rebooted the part (via options application)
• CPU1 tried to start CPU2, but it didn't bootup correctly

Is there a way to recover this unit's CPU2 firmware state? CPU2 is no longer responding to FUS commands, like FUS_GetState(...).

[Tim.N]

Hi @TwisteR​ ,

No. I managed to recover a copy of the ST's unencrypted firmware blob only of one of the RF firmware images; it did not include the FUS or safeboot region.

Someone would need to figure out how to either dump out ST's AES encryption keys (presumably used for encoding the firmware images), and bypass the cryptographic signature check in order to get custom firmware on, or figure out a way to bypass the flash writing/erasure restrictions enforced in the hardware from the option bytes.

There are other products that have two Cortex M* CPUs, so if you need that feature, there are other products to consider. My guess is that ST's choice here was mainly due to not wanting to support that configuration and not driven by any other particular need.

- Tim

[TwisteR]

Hi Tim.N,

thank you for answer. Yes, there are other multi-core MCUs (like WL series), but their price is not so pleasant.

[Vyacheslav]

Hi, Tim.N.

Thank you so much for your post.

Thanks to him, I started restoring my chips.

Best regards,

Vyacheslv.