Unable to successfully load BLE firmware because of FUS_IMAGE_NOT_AUTHENTIC so my code is failing in SHCI_C2_BLE_Init()

[DPars.2]

I have a custom board with an STM32WB55CEU (512K Flash) that is failing to start the BLE stack on CPU2 in the function SHCI_C2_BLE_Init(). I believe it's failing this function because it failed to load the BLE firmware (stm32wb5x_BLE_Stack_full_fw v1.13.0) correctly. Whenever I try to load the firmware I get an error at the end saying FUS_IMAGE_NOT_AUTHENTIC or FUS_STAE_IMG_NOT_AUTHENTIC depending on whether I try it from the command line over USB or through the GUI over SWD. I can delete the firmware image without error and my FUS appears to be up to date and running before I attempt the update.

I've also tried deleting the firmware by changing the RDP register from AA to BB and back. I still get the authentication error. This only happens on about half of the boards that I've loaded (13 out of 25). I feel like there is an address of setting somewhere that I'm not setting correctly and since all of the other posts I can find on this issue use the Nucleo with the 1MB flash part I'm not sure if my parts settings should be different. I am putting the FUS and BLE firmware at the correct address for my part according the v1.13 release notes.

Any help to get past this authentication issue would be appreciated. Thanks.

[DPars.2]

Out of curiosity I tried a different firmware file at a different address and still got the error. So is the signature it's looking for in the binary that's being loaded or is it already stored in flash somewhere? If it's stored somewhere already by the FUS (i have not stored a user key of any sort) then how do I erase it or restore it?

[Imen.D]

Hello @DPars.2​ ,

What STM32CubeProgrammer version are you using?

If it is not the latest version, so try updating it and using the latest one (v2.9).

Imen

[DPars.2]

Thank you for the response @Imen DAHMEN​  . I am using CubeProgrammer v2.9. I did notice that my command line programming was still using an earlier version so I updated that but it didn't change anything.

One thing I did notice during command line programming that I hadn't be before is that for the STM32WB5xxE (512K part I'm using) the FUS for 1.12.1 is supposed to be placed at 0x0807A000. I'm loading stm32wb5x_BLE_Stack_full_fw.bin which is 170804 bytes so it takes up 42 memory segments. If I place it at the recommended location of 0x08056000 it erases and programs through section 0x0807F000. Obviously this just writes over the FUS code. So I moved the BLE firmware to 0x0804F000 so that it ends before the FUS. It actually worked on one of the boards that I'm having an issue with but on a couple of others I'm not getting a flash write error (FUS_IMAGE_WRTERROR).

Here's the command line printout:

[DPars.2]

Well, I was able to successfully program the radio firmware on at least 3 boards. I changed to v1.13 so since the the BLE_full binary was slightly bigger I started writing it to 0x0804C000. This is still far below the 0x08053000 that the release notes suggest. I'm still having a lot of issues with the flash write error:

I can't really tell what causes it and there aren't really any other forum posts about it. It seems to be downloading and verifying fine but then failing in the last step when it writes the code to CPU2 flash.

[DPars.2]

I think I'm just confused about the memory addresses and code being written over. I'm using a 512K flash part which should go up to 0x08080000 which I guess is why all of the recommended ST address values make it so when you program a firmware binary the last sector written to is 0x0807F000. I still don't understand why moving the address so that it didn't end on 0x0807F000 worked in some cases and not in others.