Error when updating FUS firmware

Sorry to hear that, here the list of option bytes taken from CLI:

OPTION BYTES BANK: 0
 
 Read Out Protection:
 
 RDP : 0xAA (Level 0, no protection)
 
 BOR Level:
 
 BOR_LEV : 0x0 (BOR Level 0 reset level threshold is around 1.7 V)
 
 User Configuration:
 
 nBOOT0 : 0x1 (nBOOT0=1)
 nBOOT1 : 0x1 (Boot from code area if BOOT0=0 otherwise embedded SRAM)
 nSWBOOT0 : 0x1 (BOOT0 taken from PH3/BOOT0 pin)
 SRAM2RST : 0x0 (SRAM2 erased when a system reset occurs)
 SRAM2PE : 0x1 (SRAM2 parity check disable)
 nRST_STOP : 0x1 (No reset generated when entering the Stop mode)
 nRST_STDBY : 0x1 (No reset generated when entering the Standby mode)
 nRSTSHDW : 0x1 (No reset generated when entering the Shutdown mode)
 WWDGSW : 0x1 (Software window watchdog)
 IWGDSTDBY : 0x1 (Independent watchdog counter running in Standby mode)
 IWDGSTOP : 0x1 (Independent watchdog counter running in Stop mode)
 IWDGSW : 0x1 (Software independent watchdog)
 IPCCDBA : 0x0 (0x0)
 
 Security Configuration Option bytes:
 
 ESE : 0x1 (Security enabled)
 SFSA : 0xF6 (0xF6)
 FSD : 0x0 (System and Flash secure)
 DDS : 0x1 (CPU2 debug access disabled)
 C2OPT : 0x1 (SBRV will address Flash)
 NBRSD : 0x0 (SRAM2b is secure)
 SNBRSA : 0x10 (0x10)
 BRSD : 0x1 (SRAM2a is non-secure)
 SBRSA : 0x0 (0x0)
 SBRV : 0x3D800 (0x3D800)
 
 PCROP Protection:
 
 PCROP1A_STRT : 0x1FF (0x8000FF8)
 PCROP1A_END : 0x0 (0x8000008)
 PCROP_RDP : 0x0 (PCROP zone is kept when RDP is decreased)
 PCROP1B_STRT : 0x1FF (0x8000FF8)
 PCROP1B_END : 0x0 (0x8000008)
 
 Write Protection:
 
 WRP1A_STRT : 0xFF (0x807F800)
 WRP1A_END : 0x0 (0x8000000)
 WRP1B_STRT : 0xFF (0x807F800)
 WRP1B_END : 0x0 (0x8000000)

What is curious is that I am able to flash ble stack from version 1.0.0, which event generates the "firmware not authentic" error?

​Great!!!!

Indeed I will have a look at this strange influence of the RDP option byte on the ability to upgrade the FUS.

The fact that this action is erasing all data from the start of the flash up to the SFSA pointer may lead to the possibility of an incomplete erasure done by the CLI command "STM32_Programmer_CLI.exe -c port=usb1 -fwdelete".

I will check this.

thanks

​So let's resume this topic

Be sure to use the latest CuveWB FW package v1.5.0.

Then could you tell me which port you are using?

What is the CubeWB FW package version you are using?

What is the FUS version?

I Just saw that the SFSA pointer is set to 0. This is not a good news.

Did you never manage to upgrade the FUS on this Nucleo board?

Which port did you use?

Were you able to load FUS v1.1.0, I would be able to recover from this situation.

Now there is nothing obvious to do.

I was getting such as error. But after typing STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1 it showed that the firmware has been updated. I was seeing 0x20030030 00000000 but now I see 01000200. Anyway it doesn't work.

So the FUS had indeed been upgraded. Unfortunately, this is not enough to get your board back to work as the SFSA pointer = 0.

This is a quite weird situation as this sequence should not failed , leading to this blocked board.