cancel
Showing results for 
Search instead for 
Did you mean: 

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

Vyacheslav
Senior II

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

65 REPLIES 65

Value at 0x20030030 -- FCD91B10.

Remi QUINTIN
ST Employee

​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?

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
ST Employee

​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?

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
ST Employee

>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.

First try to delete:

0693W000002lGc8QAE.png

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 ?

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

and  FUS version is FCD91B10. :)

Remi QUINTIN
ST Employee

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.