STM342WB55 after load last BLE stack (1.8.0) I can`t erase fw with STM32CubeProgrammer

[Vyacheslav]

Hi.

Using STM32CubeProgrammer I load last stm32wb5x_BLE_Stack_light_fw.bin, but when after that I try to run command -fwdelete, I get an error : "FUS_NOT_RUNNING".

I attach log file becose Idont understand whot is this.

But me application work fine and I see that stack is a last version.

Please help whot may bee .

I send call:

STM32_Programmer_CLI.exe -c port=usb1 -fwdelete -vb 3

[Remi QUINTIN]

​Yes please check if this issue is occuring with other devices and let me know.

[Remi QUINTIN]

Reviewing the full thread, an idea came to my mind.

Fwdelete not completed with an error : "FUS_NOT_RUNNING" => This means the FUS is not active. This could be the case when the previous load of the RF stack was successful. In that case the wireless stack is active, not the FUS. To activate the FUS, you should issue a Fus get state command. and then try the fwdelete command again.

[Vyacheslav]

Hi, Remi.

We are tested one more chip with marking:

STM32WB55

RGV7

7B A7P 9R Y

PHL GQ 9 16

ARM 34

Its a same situation.

Our steps:

- we have a chip whith FUS 0.5.3

- we upgrade FUS to 1.0.1

- then upgrade FUS to 1.1.0

- then we load BLE stack light ver 1.6.0 - all ok. We can delete FW and reload FW.

- then we load BLE stack light ver 1.8.0 - process was ok, but now we can`t delete any FW and reload it (FUS or stack). But ESE bit now checked.

I can send you this chip to.

[Vyacheslav]

We are tested third chip with marking:

STM32WB55

RGV7

7B A7P 9R Y

PHL GQ 9 16

ARM 24

Its a same situation.

Our steps:

- we have a chip whith FUS 0.5.3

- we upgrade FUS to 1.0.1

- then upgrade FUS to 1.1.0

- then we immediately load last BLE stack light ver 1.8.0 - process was ok, but now we can`t delete any FW and reload it (FUS or stack). But ESE bit now checked.

Now we have 3 chips with which we can do nothing.

🙂

[Vyacheslav]

We are tested fourth chip with marking:

this chip is 512kB flash

STM32WB55

REV6

7B A6G 9R Y

PHL GQ 9 44

ARM 31

FUS and stack we was load on correct addresses. 

Its a same situation.

Our steps:

- we have a chip whith FUS 0.5.3

- we upgrade FUS to 1.0.2

- then upgrade FUS to 1.1.0

- then we immediately load last BLE stack light ver 1.8.0 - process was ok, but now we can`t delete any FW and reload it (FUS or stack). But ESE bit now checked.

Now we have 4 chips with which we can do nothing.

[Vyacheslav]

And in all tooday tested chips after that steps

calling command:

STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1

we have FUS version : 00000000.

[Vyacheslav]

I think the problem is in the BLE_stack_lignt of version 1.8.0.

For some reason he does not allow FUS to start.

[Vyacheslav]

And may be a starnge diffence of size between versions of stack:

- stm32wb5x_BLE_Stack_light_fw 1.5.0 have size 107696

- stm32wb5x_BLE_Stack_light_fw 1.6.0 have size 107096

- stm32wb5x_BLE_Stack_light_fw 1.7.0 have size 107096

- stm32wb5x_BLE_Stack_light_fw 1.8.0 have size 122596

Its a strange that the size of 1.8.0 is more than 15500 bytes.

[Remi QUINTIN]

I used my Nucleo board and load the stm32wb5x_BLE_Stack_light_fw.bin (from V1.8.0 package) at 0x080D6000 and then the BLE_p2pServeur application and I was able to detect the board advertising using the android ST BLE sensor application on my mobile.

Then I delete the RF FW using the CubeProgrammer tool in GUI mode and manage to program the stm32wb5x_BLE_Stack_full_fw.bin binary (from V1.8.0 package) at 0x080CB000 without any issue. I still detect the board on my mobile.

Regarding the increase of the light stack size, I will check that point.

[Vyacheslav]

The problem is not that the stack is working. 1.8.0 works for me too.

The problem is that after loading 1.8.0 the stack, I can no longer erase or load nothing.