Fail und FUS and Stack update

[mkrug]

Hi everybody,

I think I have the same problem as CTare (https://community.st.com/s/question/0D53W00000fo0kcSAA/unable-to-install-wireless-stack-on-stm32wb55?t=1628516513992) I coudn't reply to that post because it's already archived.

My setup: Nucleo WB55RG board. I tried to fully understand the FUS, Stack programming including all the options. After 6hours I end up with a board that I can communicate with using STM32Programmer (v2.8, 2.7 and 2.5, each of them in DFU or STlink mode) but I'm not able to reprogram FUS and RF-Stack (in my case BLE). I attached my batch file that is derived from Quintin and the response the board gives (because of the limitations in this forum as one pdf file :worried_face:). What makes me very suspicious is the FUS firmware version that is replied to be v0.0.0.00 (that's the same I can see in STM32Programmer. So it seems to me that there is no FUS at all - although the programming command don't show errors.

Similar to CTare I'm not sure if I hit the 'antirollback' push button accidentially. Following the previous post I tried to fix that with STM32Programmer v2.5 but with no sucess. Is there really no way to remove that antirollback flag somewhere in the STM32WB?

Anybody any idea what went wrong and how to fix this?

Best Regards

Markus

[Remi QUINTIN]

Is your Nucleo board older than 2 years? Some of the very first Nucleo boards that were distributed had some issues with the FUS and FW updates.

Can you download the option bytes to check?

Can you be sure to use the latest versions for the WB package v 1.12.1 and CubeProgrammer V2.8.

The anti-rollback is used to enable the possibility to update the FUS under certain circumstances: In order to upgrade from FUS V1.1.0 to FUS V1.1.2 , the Anti-rollback must first be activated.

It also prevents the installation of a FW stack version that is older than the current installed one. Before activating Anti-rollback, an installed wireless stack must be present.

In all case, this should not prevent the correct update of a new FUS version such as the v1.1.2.

[mkrug]

Dear Quintin,

thanks for answering.

The Nucleo Board I'm using is about 2 months old. So that can't be the case. I have one about 2 years old and manged to update it to v1.1.2.

Here are my option bytes. Maybe you can see a problem there.

Thanks in advance

Markus

C:\Program Files\ST\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD -ob displ

   -------------------------------------------------------------------

            STM32CubeProgrammer v2.8.0

   -------------------------------------------------------------------

ST-LINK SN : 0669FF555755846687081914

ST-LINK FW : V2J38M27

Board    : NUCLEO-WB55RG

Voltage   : 3.27V

SWD freq  : 4000 KHz

Connect mode: Normal

Reset mode : Software reset

Device ID  : 0x495

Revision ID : Rev Y

Device name : STM32WB5x

Flash size : 1 MBytes

Device type : MCU

Device CPU : Cortex-M4

BL Version : 0xd5

Debug in Low Power mode enabled

UPLOADING OPTION BYTES DATA ...

 Bank     : 0x00

 Address    : 0x58004020

 Size     : 96 Bytes

██████████████████████████████████████████████████ 100%

 Bank     : 0x01

 Address    : 0x58004080

 Size     : 8 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    : 0x1 (nBOOT0=1 Boot from main Flash)

   nBOOT1    : 0x1 (Boot from code area if BOOT0=0 otherwise system Flash)

   nSWBOOT0   : 0x0 (BOOT0 taken from the option bit nBOOT0)

   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 - 1:

   ESE     : 0x1 (Security enabled)

  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)

OPTION BYTES BANK: 1

  Security Configuration Option bytes - 2:

   SFSA     : 0xF4 (0x80F4000)

   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 (0x2003BC00)

   BRSD     : 0x0 (SRAM2a is secure)

   SBRSA    : 0xA (0x20032800)

   SBRV     : 0x32800 (0x20000000)

[Remi QUINTIN]

Your board is in a weird situation. According to SFSA value, there is no RF FW installed on your board while the SBRV value is pointing on the start address of a previous BLE RF stack. This SBRV value was not realigned with the SFSA value. It looks like a previous fwdelete command did not complete, letting the SBRV value to that strange value = start address of an old RF stack.

I would recommend you activate the FUS to realign those 2 values ... I hope.

Use the START FUS button of Cube Programmer v2.8 to do it. You may have to press it twice to have a proper answer.

The SBRV value should then be 0x3D000.

Then retry the FW install. Hope it works.

[Remi QUINTIN]

Good to see that you managed to update it to v1.1.2.

Next step is to upgrade it to FUS v1.2 which is part of WB FW package v1,12,

[mkrug]

Dear Quintin,

there is a misunterstanding. I have several STM32WB Nucleo boards and all of them - beside the broken one - are updated to the latest FUS Version without a problem.

However, the 'broken' board is still broken and the SBRV value is still set to 0x32800 even if I tried to change it with 'START FUS' several times. I get the following information in the log window:

 08:23:00 : Warning: Option Byte: nSWboot0, value: 0x0, was not modified.

 08:23:00 : Warning: Option Byte: nboot0, value: 0x1, was not modified.

 08:23:00 : Warning: Option Byte: nboot1, value: 0x1, was not modified.

 08:23:00 : Warning: Option Bytes are unchanged, Data won't be downloaded

 08:23:00 : Succeeded to set nSWboot0=0 nboot1=1 nboot0=1 

 08:23:00 : Memory Programming ...

 08:23:00 : Opening and parsing file: 0x495_FUS_Operator.bin

 08:23:00 :  File     : 0x495_FUS_Operator.bin

 08:23:00 :  Size     : 8 KBytes

 08:23:00 :  Address    : 0x08000000 

 08:23:00 : Erasing memory corresponding to segment 0:

 08:23:00 : Erasing internal memory sectors [0 1]

 08:23:00 : Download in Progress:

 08:23:00 : File download complete

 08:23:00 : Time elapsed during download operation: 00:00:00.264

 08:23:00 : Application is running, Please Hold on...

 08:23:00 : Reconnecting...

 08:23:00 : Reconnected !

 08:23:04 : Reconnecting...

 08:23:04 : Reconnected !

 08:23:04 : Error: FUS_STATE_ERR_UNKNOWN

 08:23:04 : Start FUS failed !

 08:23:04 : Error: Start FUS Operation Failure! Please, try again

[Remi QUINTIN]

I have no idea of what's going wrong with your board. It is really in a weird state.

In last resort, I would propose you to set it back to its manufacturing state.

For that you just have to write 0x00008000 at address 0x0x5800040C and then restart the board.

[mkrug]

Dear Quintin,

seems to me that this didn't help.

So I wrote the value to 0x5800040C and restart the board by power off->power on and still get the same values in the SBRV register entry. See the log below.

Any idea what else I can do?

C:\Program Files\ST\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD -w32 0x5800040C 0x00008000

   -------------------------------------------------------------------

            STM32CubeProgrammer v2.8.0

   -------------------------------------------------------------------

ST-LINK SN : 0669FF555755846687081914

ST-LINK FW : V2J38M27

Board    : NUCLEO-WB55RG

Voltage   : 3.27V

SWD freq  : 4000 KHz

Connect mode: Normal

Reset mode : Software reset

Device ID  : 0x495

Revision ID : Rev Y

Device name : STM32WB5x

Flash size : 1 MBytes

Device type : MCU

Device CPU : Cortex-M4

BL Version : 0xd5

Debug in Low Power mode enabled

Write 32-bit data

w @0x5800040c: 0x00008000

Downloading...

██████████████████████████████████████████████████ 100%

32-bit data download complete

C:\Program Files\ST\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD -ob displ

   -------------------------------------------------------------------

            STM32CubeProgrammer v2.8.0

   -------------------------------------------------------------------

ST-LINK SN : 0669FF555755846687081914

ST-LINK FW : V2J38M27

Board    : NUCLEO-WB55RG

Voltage   : 3.27V

SWD freq  : 4000 KHz

Connect mode: Normal

Reset mode : Software reset

Device ID  : 0x495

Revision ID : Rev Y

Device name : STM32WB5x

Flash size : 1 MBytes

Device type : MCU

Device CPU : Cortex-M4

BL Version : 0xd5

Debug in Low Power mode enabled

UPLOADING OPTION BYTES DATA ...

 Bank     : 0x00

 Address    : 0x58004020

 Size     : 96 Bytes

██████████████████████████████████████████████████ 100%

 Bank     : 0x01

 Address    : 0x58004080

 Size     : 8 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    : 0x1 (nBOOT0=1 Boot from main Flash)

   nBOOT1    : 0x1 (Boot from code area if BOOT0=0 otherwise system Flash)

   nSWBOOT0   : 0x0 (BOOT0 taken from the option bit nBOOT0)

   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 - 1:

   ESE     : 0x1 (Security enabled)

  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)

OPTION BYTES BANK: 1

  Security Configuration Option bytes - 2:

   SFSA     : 0xF4 (0x80F4000)

   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 (0x2003BC00)

   BRSD     : 0x0 (SRAM2a is secure)

   SBRSA    : 0xA (0x20032800)

   SBRV     : 0x32800 (0x20000000)

[Remi QUINTIN]

So let's consider this board as definitely broken.

[mkrug]

Hi Quintin,

really bad and sad that it is possible to 'kill' this device with the standard STM tools. Also it was very expensive for me because we tried to make it running for many hours.

Anyway, I appreciate your quick response and attempt to help us out of this situation.

Best Regards

Markus