FUS running but not able to load Stack?

tester · ‎2023-08-04

I am trying to load the p2p server example and noticed my Nucleo-WB15CC doesn't do any bluetooth communication. I can run normal user code just fine (LEDs, GPIO etc.) but CPU2 doesn't seem to do anything.

When I try to start FUS, I get this:

When I try to read the FUS version, I just get this:

Here is the output of some STM32ProgrammerCLI commands:

.\STM32_Programmer_CLI.exe -c port=SWD -fusopgetversion

FUS Operator Version  : v3.1.0
fusopgetversion command execution finished

.\STM32_Programmer_CLI.exe -c port=SWD -fusgetstate

FUS_STATE_IDLE
getFUSstate command execution finished

.\STM32_Programmer_CLI.exe -c port=SWD -startfus

Reconnecting...
Reconnected !
Error: FUS_STATE_ERR_UNKNOWN: Unknown error

Error: Fus is not yet running, try again

.\STM32_Programmer_CLI.exe -c port=SWD -startwirelessstack

Error: FUS_STATE_ERR_UNKNOWN: Unknown error
Error: startwirelessStack Operation Failure! Please, try again

.\STM32_Programmer_CLI.exe -c port=SWD -fwdelete

Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 3]
failed to erase memory


failed to erase memory
Failed to download FUS operator!
Firmware delete n░1 failed after retrying!
fwdelete Operation Failure! Please, try again

.\STM32_Programmer_CLI.exe -c port=SWD -ob displ

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 system Flash)
     nSWBOOT0     : 0x0 (BOOT0 taken from the option bit nBOOT0)
     SRAM2RST     : 0x1 (SRAM2 is not 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)
     IWDGSTDBY    : 0x1 (Independent watchdog counter running in Standby mode)
     IWDGSTOP     : 0x1 (Independent watchdog counter running in Stop mode)
     IWDGSW       : 0x1 (Software independent watchdog)
     GPIO_MODE_PB11: 0x1 (If RESET_MODE_PB11 = 0: Standard GPIO pad functionality, Only internal RESET possible. If RESET_MODE_PB11 = 1: Bidirectional reset, NRST pin configured in reset input/output mode (default mode), GPIO functionality is not available on PB11.)
     RESET_MODE_PB11: 0x1 (If GPIO_MODE_PB11 = 0: Reset input only, a low level on the NRST pin generates system reset, internal RESET not propagated to the NSRT pin. If GPIO_MODE_PB11 = 1: Bidirectional reset, NRST pin configured in reset input/output mode (default mode).)
     IRH          : 0x1 (Internal resets drives NRST pin low until it is seen as low level.)

   ESE:

     ESE          : 0x1 (Security enabled)

   PCROP Protection:

     PCROP1A_STRT : 0x1FF  (0x807FC00)
     PCROP1A_END  : 0x0  (0x8000400)
     PCROP_RDP    : 0x0 (PCROP zone is kept when RDP is decreased)
     PCROP1B_STRT : 0x1FF  (0x807FC00)
     PCROP1B_END  : 0x0  (0x8000400)

   Write Protection:

     WRP1A_STRT   : 0xFF  (0x807F800)
     WRP1A_END    : 0x0  (0x8000000)
     WRP1B_STRT   : 0xFF  (0x807F800)
     WRP1B_END    : 0x0  (0x8000000)
OPTION BYTES BANK: 1

   IPCCDBA-AA:

     IPCCDBA      : 0x0  (0x20010000)
OPTION BYTES BANK: 2

   Security Configuration Option bytes:

     SFSA         : 0x8C  (0x8046000)
     FSD          : 0x0 (System and Flash secure)
     DDS          : 0x1 (CPU2 debug access disabled)
     C2OPT        : 0x1 (SBRV will address Flash)
     BRSD_B       : 0x0 (SRAM2b is secure)
     SBRSA_B      : 0x0  (0x20038000)
     BRSD_A       : 0x0 (SRAM2a is secure)
     SBRSA_A      : 0x0  (0x20030000)
     SBRV         : 0x11800  (0x8000000)

I really don't know what to do at this point. I've already looked at other similar issues here, tried different connection and reset modes, I tried the boot0 bootloader method, I did a "factory reset" with this command:

STM32_Programmer_CLI.exe -c port=SWD reset=HWrst -w32 0x5800040c 0x00008000

And nothing changed. At this point I'm clueless, have I locked my self out of the CPU2?

batuars · ‎2024-01-06

Hi. Is there any progress on this issue? Also in my topic, unfortunately, any STM engineers could not provide sufficient feedback for this issue.

Remi QUINTIN · ‎2024-01-08

Looking at the secure option bytes, SFSA is pointing to a previous version of the FUS.

Please use the startfus command and then read the FUS version using the fusgetversion command.

Let me know which version it is. If it is not higher than v1.2.x, then you have to upgrade the FUS with the latest version that you should find under \Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x.

In that case, depending on the current FUS version, I will tell you which FUS binary to use.

Once FUS is updated, the wireless stack will be correctly uploaded.

tester · ‎2024-01-12

I had a lot of back and forth with ST support over multiple tickets, but ultimately, they couldn't find a solution. Quote from the ticket: "yes, unfortunately your board CPU2 communication with CPU1 is locked without recovery option - not possible to run BLE application on this board." After that, they sent me a new board.

Remi QUINTIN · ‎2024-01-15

A few recommandations:

To know the FUS version, first do a StartFUS command and then issue a GetFUSversion command.

Looking at the secure option bytes SFSA and SBRV, you can guess whether the FUS or the Wireless stack is active.

If SBRV = 0x46000/4 = 0x18800, then FUS is active. 0xA000 is the space size reserved for the FUS in WB1x devices.

batuars · ‎2024-01-15

Hi,

You are lucky to use board, but I have custom design and I have at least 300 pieces of these problematic MCUs. I think, this explanation "yes, unfortunately your board CPU2 communication with CPU1 is locked without recovery option - not possible to run BLE application on this board." is not a valid explanation.

Remi QUINTIN · ‎2024-01-15

Is there a way you could download the secure option bytes on the blocked board to better understand this blocking situation?

batuars · ‎2024-01-15

Remi, can you also look my topic? There is also my secure option bytes and FUS version etc.

Remi QUINTIN · ‎2024-01-15

I had a look at the issue described in the other post.

To summarize, it looks like the SBRV value is the correct one. So, the FUS is active, and you should be able to send command like deleteFW or Program a wireless stack. despite the fact that the FUS version looked weird.

Does the SBRV value change after deleting and installing a new SW, whatever it is?