Error upgrading wireless coprocessor firmware on Nucleo-68

[anddam]

I am experiencing an error while trying to upgrade a Nucleo-68 board from P-NUCLEO-WB55 wireless coprocessor to latest v1.7.0 firmware provided by STMicroelectronics/STM32CubeWB github repo.

I already reported the issue on the githb repo here is a copy of the issue:

**Describe the set-up**

Host OS: Linux glibc system

Board: P-NUCLEO-WB55 STM32WB55RG (Nucleo-68)

Tools:

 - STM32CubeProgrammer v2.4.0

 - SMT32CubeWB firmware images

**Describe the bug**

Trying to update the wireless coprocessor to latest v1.7.0 results in an error:

```

Error: failed to download Segment[0]

Error: failed to download the File

Error: Failed to download image!

```

**How To Reproduce**

1. clone `https://github.com/STMicroelectronics/STM32CubeWB`

2. enter the repository

3. checkout tag `v1.7.0`

4. cd `Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/`

5. follow instructions at `How to flash the Wireless Coprocessor Binary via USB (Command Line Interface)` in file `Release_Notes.html` using STM32CubeProgrammer v2.4.0

**Additional context**

The *Update History* section of `Release_Notes.html` shows 1.6.0 changes as latest entry even on tag `v.1.7.0`. However checking out the repo at `v1.6.0` yields the same error result as `v1.7.0`.

The full log provided in the issue is attached here as well.

[Remi QUINTIN]

yes -ob displ output is enough

[anddam]

Here it is:

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 Boot from main Flash) 
     nBOOT1       : 0x1 (Boot from Flash if nBoot0=0 otherwise system memory) 
     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         : 0xF4  (0xF4) 
     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         : 0x3D000  (0x3D000) 
 
   PCROP Protection:
 
     PCROP1A_STRT : 0x1FF  (0x8000FF8) 
     PCROP1A_END  : 0x0  (0x8000008) 
     PCROP_RDP    : 0x1 (PCROP zone is erased when RDP is decreased) 
     PCROP1B_STRT : 0x1FF  (0x8000FF8) 
     PCROP1B_END  : 0x0  (0x8000008) 
 
   Write Protection:
 
     WRP1A_STRT   : 0xFF  (0x80FF000) 
     WRP1A_END    : 0x0  (0x8000000) 
     WRP1B_STRT   : 0xFF  (0x80FF000) 
     WRP1B_END    : 0x0  (0x8000000)

I also get this output from `-fusgetstate`:

FUS state is WIRELESS_STACK_UPGRADE_ONGOING
 
FUS status is FUS_IMAGE_NOT_AUTHENTIC
getFUSstate command execution finished

 The not authentic par is what is worrying me, why is the FUS not considered authentic?

[anddam]

Did the log provide some useful insights on the failing firmware upgrades?

[Remi QUINTIN]

Not really. The FUS is correctly installed at the right address with the right version. But the RF stack is not.

This message FUS_IMAGE_NOT_AUTHENTIC is issued when the FUS is finding some data in the user space that is expected to be the RF stack but the integrity check failed. This happens when old data remains in the Flash memory. The FUS can be misled by fake checksum.

Therefore, erasing the user space is key to avoid such situation.

I don’t understand why the mass erase does not work. Or maybe it worked and there is another cause for this error message.

Did you check the content of the flash memory after the masse erase to see if the data is really erased?

[anddam]

No, I did not. Actually I would not know how to do that, can you please provide some more detailed instructions?

[Remi QUINTIN]

​You can use CubeProgrammer tool in GUI mode and read the sector you want to erase. Try to write some data and activate the masse erase. Then check if the data you wrote is indeed erased.

[Remi QUINTIN]

​No.  as long as nSWBOOT0 = 0x1  and the jumper is properly set, I dont see any reason for such error.

What is the voltage used to power your board?

[anddam]

The voltage is the 5 V from host USB via the USB_user port, the source is set via "USB MCU" jumper.

Sorry for the delayed reply.