2023-03-29 07:13 AM
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:
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?
Solved! Go to Solution.
2023-03-30 01:07 AM
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.
2023-03-29 08:47 AM
I am afraid the board might become unusable.
Can you download the option bytes, especially those related to security configuration ones?
2023-03-29 11:07 AM
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?
2023-03-29 12:14 PM
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.
2023-03-29 12:15 PM
In all cases, any update of FUS or wireless stack should be done with a safe power supply to avoid unpredictable results.
2023-03-29 02:28 PM
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:
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!
2023-03-30 01:07 AM
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.
2023-03-30 01:22 AM
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.
2023-03-30 10:31 AM
Thanks, Remi!
2023-05-07 10:04 PM
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!