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

[Vyacheslav]

Value at 0x20030030 -- FCD91B10.

[Remi QUINTIN]

​ouch!!  quite weird value!!

In fact, the ESE option byte is not checked so this device is not secure. No FUS is loaded on your chip.

So you won't be able to use it to install new FUS or any RF encrypted RF stack.

It may be a very old device (very early version).

Where did you get it?

[Vyacheslav]

Sorry, Remi, but before download a new stack (1.8.0) everything worked fine and last stack was 1.7.0. and FUS is 1.1.0.

And now chip continue working fine and stack now 1.8.0.0.5 and FUS 1.1.0

This info I get in me application fw by "SHCI_GetWirelessFwInfo".

But now I cant delete or reload any stack - this is a problem.

As for the chip, this is a chip from the first lots of P-NUCLEO-WB55 when they first went on sale.

[Remi QUINTIN]

​Really? So you manage to upgrade your device with FUS 1.1.0 and then the BLE light RF stack from V1.8?

This is amazing as this can only happen on a secure chip => ESE = 1.

Now the ESE = 0 but normally no one (except CPU2) can reset it to 0.... I am quite puzzled by this situation.

Could you to perform a fwdelete again and read the FUS version?

Can you try then to set ESE back to 1 and retry to read the FUS version?

[Vyacheslav]

Yes!

"Could you to perform a fwdelete again and read the FUS version?" - problem in my topic 🙂 afyer loading last stak (1.8.0) I can`t delete.

Log on the zip - it is a dump of "fwdelete" command.

Ok, I try again and send you log.

[Remi QUINTIN]

>This info I get in me application fw by "SHCI_GetWirelessFwInfo".

OK so we can consider the FUS is V1.1.0. In last resort we could try a trick that would revert the chip to its manufactory state. But this would erase any data in flash memory except the FUS.

First let's wait for your trial.

[Vyacheslav]

First try to delete:

Log try to set ESE:

18:56:17:163 : Option byte command : -ob ESE=1 

18:56:17:178 : PROGRAMMING OPTION BYTES AREA ...

18:56:17:178 : Warning: Option Byte: ESE, is not programmable

18:56:17:203 : Warning: Option Byte: ESE, does not exist

18:56:17:222 : Warning: Option Bytes are unchanged, Data won't be downloaded

18:56:17:261 : sending an abort request

18:56:17:261 : setting the address pointer to address: 0x08000000

18:56:17:263 : UPLOADING OPTION BYTES DATA ...

18:56:17:263 :  Bank     : 0x00

18:56:17:264 :  Address    : 0x1fff8000

18:56:17:264 :  Size     : 128 Bytes

18:56:17:264 : setting the address pointer to address: 0x1fff8000

18:56:17:265 : receiving packet nbr: 0

18:56:17:265 : sending an abort request

18:56:17:265 : UpLoading data

:(

It is an and ?

[Vyacheslav]

I answer on your previous comment.

This is an extended result of try to set ESE:

19:02:09:760 : Option byte command : -ob ESE=1 

19:02:09:762 : PROGRAMMING OPTION BYTES AREA ...

19:02:09:763 : Warning: Option Byte: ESE, is not programmable

19:02:09:786 : Warning: Option Byte: ESE, does not exist

19:02:09:808 : Warning: Option Bytes are unchanged, Data won't be downloaded

19:02:09:839 : DFU status = 0

19:02:09:839 : DFU State = 9

19:02:09:839 : Status: 0, State: 9

19:02:09:840 : sending an abort request

19:02:09:840 : DFU status = 0

19:02:09:840 : DFU State = 2

19:02:09:840 : setting the address pointer to address: 0x08000000

19:02:09:840 : DFU status = 0

19:02:09:840 : DFU State = 4

19:02:09:841 : DFU status = 0

19:02:09:841 : DFU State = 5

19:02:09:841 : data: 2100000008

19:02:09:841 : UPLOADING OPTION BYTES DATA ...

19:02:09:841 : Bank : 0x00

19:02:09:841 : Address : 0x1fff8000

19:02:09:841 : Size : 128 Bytes

19:02:09:841 : DFU status = 0

19:02:09:842 : DFU State = 5

19:02:09:842 : Status: 0, State: 5

19:02:09:842 : setting the address pointer to address: 0x1fff8000

19:02:09:842 : DFU status = 0

19:02:09:842 : DFU State = 4

19:02:09:842 : DFU status = 0

19:02:09:842 : DFU State = 5

19:02:09:842 : data: 210080ff1f

19:02:09:842 : receiving packet nbr: 0

19:02:09:842 : DFU status = 0

19:02:09:842 : DFU State = 5

19:02:09:842 : sending an abort request

19:02:09:842 : DFU status = 0

19:02:09:842 : DFU State = 2

19:02:09:843 : UpLoading data

19:02:09:843 : DFU status = 0

19:02:09:843 : DFU State = 9

19:02:09:843 : data: aaf0ff3f550f00c0ff01000000feffff00000000ffffffffff00000000ffffffff00000000ffffffff01000000feffff00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00c0ffffff3f0000d610000029efffff00582b9effa7d461

[Vyacheslav]

and  FUS version is FCD91B10. 🙂

[Remi QUINTIN]

As you can see, it is not possible to modify the ESE bit. This is why I am quite puzzle by the fact you were able to load a new fus and run an application.

This can only be done with ESE = 1 and once set to 1 there is no way to revert it to 0.

I would say that this chip is too old from an early not secured version on which you can only run application but without any RF stack.

Are you really able to advertise and be detected by a mobile application like the STBLE sensor android application?

if calling SHCI_GetWirelessFwInfo function still gives you FUS v1.1.0, then you could try to revert to the manufactory state (no guarantee it would work with your case).

Write 0x00008000 at address 0x5800040C and then reset your chip.

Let me know if it allows you to program it again.