Hello,
I am trying to implement the update procedure for the wireless stack in our custom firmware.
The development is currently performed with the NUCLEO-WB55RG development board to avoid having to worry about the special features of our custom hardware.
We currently have 4 boards that are bricked so it is no longer possible to install or start the wireless stack in any way.
The cause of the failure of the first three boards is unknown, as it was first discovered that they were bricked after a lot of time was spent of time trying different things to try to understand why the commands kept failing.
On these boards, both FUS and the wireless stack report version v0.0.0.0 in STM32CubeProgrammer, SFSA is 0xf4 and SBRV is 0x17000, 0x17400 or similar values.
The fourth board failed while trying to update it: After calling FUS_FW_UPGRADE and receiving the response, the CPU was reset by mistake, the update continued, but got stuck later in the process.
After a couple of minutes, a manual reset was performed, and it reported the new version number with SHCI_GetWirelessFwInfo, but SFSA(0xf4), SBRV(0x3D000), and the image in flash was unchanged and the stack could not be started.
Trying to install the stack after this failed with FUS_STATE_IMG_NOT_AUTHENTIC, both from our code and from STM32CubeProgrammer. Deleting the stack and the chip did not work either, leaving the reported version number.
After trying pretty much everything else, I tried running the FUS_CLI example to delete the stack and erase the chip, but this made it fail in a new way: SBRV is now 0x33800 and FUS and wireless stack versions are v0.0.0.0 as with the first three boards.
Board 4 definitely used FUS 1.2.0, the others might have been running previous versions.
Is there any way to recover these boards over SWD? I have tried setting RDP to 0xBB and back to 0xAA, running full chip erase, etc., with no luck. PWR_CR4.C2BOOT is currently 1 and setting it to 0 and back to 1 does not appear to help.
It is understandable if a failed FUS update can cause the device to be bricked, and as we do not expect to need to update the FUS once the device is deployed, this should not be a problem.
We do expect that the wireless stack needs to be updated from time to time, so if there is even a small risk of a deployed device being permanently bricked with no way to recover it, this can turn into a big problem.
Is there a list of things that can cause these failures, so we can avoid them?
According to community.st.com/s/question/0D53W00002CPbM0SAL/stm32wb5mmg-power-removed-while-updating-fus, updates apparently needs “a safe power supply�?, but is there anything else that must be avoided, such as resetting CPU1 and watchdog resets?
I have experienced that the communication with the debugger fails while an update is running, so should debugging be avoided when updating, or should it be safe?
