cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB5MMG power removed while updating FUS

crwper
Senior

During testing to see what happens if power is interrupted during various parts of firmware update, I removed power from my test board while updating FUS. Now, when I connect via SWD using STM32CubeProgrammer, it shows the following:

0693W00000bh7sOQAQ.png 

When I try to update FUS in this state (writing FUS v1.2.0 to 0x080EC000), I get an error, "FUS_STATE_ERR_UNKNOWN".

Is it possible to recover from this state?

1 ACCEPTED SOLUTION

Accepted Solutions
Remi QUINTIN
ST Employee

SBRV cannot be changed by Cube programmer or any user operations as it is a security option byte that can only be accessed and modified by the FUS.

If the SBRV value is still the same, this means that your board became unusable as the FUS managing the secure updates has been damaged.

So, your board can run with the current wireless stack, but you won't be able to update it.

Note you can still update your application as this operation does not require a functional FUS.

This let you with a board with limited update capability regarding the wireless stack.

View solution in original post

9 REPLIES 9
Remi QUINTIN
ST Employee

I am afraid the board might become unusable.

Can you download the option bytes, especially those related to security configuration ones?

crwper
Senior

Sure thing! Here are the security configuration option bytes:

ESE: checked

SFSA: 0xf4

FSD: unchecked

DDS: checked

C2OPT: checked

NBRSD: unchecked

SNBRSA: 0xf

BRSD: unchecked

SBRSA: 0xa

SBRV: 0x33800

Anything else you can use?

So, maybe the lesson here is, in the field the FUS should not be updated unless absolutely necessary, and then only with a good power source, because there is an intermediate state in the update from which the device is unrecoverable?

Is this also the case for wireless stack update, or is that more robust?

Remi QUINTIN
ST Employee

The SBRV value is clearly pointing at the start of the stack (0x33800 equal to sector number 0xCE) and not at the start of the FUS (SBRV should be 33D00equal to sector 0xF4).

So, this can explain why you get this "FUS_STATE_ERR_UNKNOWN"" error message as it is impossible for CPU2 to guess the state of the FUS as it is currently executing the wireless stack.

So, use the CubePrgrammer tool to switch to the FUS by pressing the "START FUS" button.

As soon as the SVRB option byte gets the right value, you should be eble to load a new version wireless stack.

Note that if the FUS version is v1.2.0, then you won't be allowed to load a new version as this v1.2.0 version is the last FUS version. You would get an error message instead.

Remi QUINTIN
ST Employee

In all cases, any update of FUS or wireless stack should be done with a safe power supply to avoid unpredictable results.

I tried clicking "Start FUS", but got the error, "Error: Start FUS Operation Failure! Please, try again" followed by "Error: FUS_STATE_ERR_UNKNOWN". If I try again, I get the same pair of errors.

If I try to change SVRB directly, I get "Error: Option Byte Programming failed" then "Error: Expected value for Option Byte "SBRV": 0x33D00, found: 0x33800". Presumably this is because the option byte is read-only.

I've used FUS update (to the same version) to clear the CKS keys in the past, so I tried the following on a separate unit:

  1. Start FUS, then read FUS infos. FUS Version is v1.2.0.0.
  2. Use Firmware Upgrade to install FUS v1.2.0 from the STM32Cube FW WB v1.15.0 package.

This gives the messages "Firmware delete Success" then "Firmware Upgrade Success", and the next key installed in CKS goes in the first slot.

Is this unexpected behaviour, or something I can count on?

Re: connecting to a safe power supply before updating the stack, are you aware of any specific instances where cutting power while updating the stack can brick the unit? In my testing, I've always been able to recover from an interrupted stack update.

Thank you!

Remi QUINTIN
ST Employee

SBRV cannot be changed by Cube programmer or any user operations as it is a security option byte that can only be accessed and modified by the FUS.

If the SBRV value is still the same, this means that your board became unusable as the FUS managing the secure updates has been damaged.

So, your board can run with the current wireless stack, but you won't be able to update it.

Note you can still update your application as this operation does not require a functional FUS.

This let you with a board with limited update capability regarding the wireless stack.

Remi QUINTIN
ST Employee

Regarding the other comments, as I said earlier, you don't have to update the FUS if it is already version V1.2.0 as it is the last and definite official FUS version.

As you got the message "Firmware Upgrade Success", this means the FUS was not updated as the correct version was already installed.

The next key installed in CKS goes in the first slot if it is the first time you install a user key.

As long as the FUS is not damaged, you can always start a new FW update by the FUS. But this is not possible anymore if the FUS is damaged.

Thanks, Remi!

Follow-up question: If I "update" the FUS to the same version that's already installed, resetting the user keys, will this also reset the CKS master key? Thank you!