Problem loading stack on a nucleo STM32WB55

[OTOMA.2]

It's a board I've been using for a while, and I'm struggling loading a new stack onto it.

Here are the steps I've executed:

1/ powercycle

2/ start FUS

3/ delete image

4/ powercycle

5/ start FUS

6/ get FUS info: FUS_IDLE | FUD_NO_ERROR | Version=1.1.1.0 | stackversion=1.13.3.2 | FUS opeatorver = 3.1.0

7/ erase memory to load the stack (stack full basic v1.13.3.2, address @0x080D0000)

8/ firmware upgrade of the stack (with verify download enabled, and first install (tested without too))

9/ ERR_IMG_NOT_FOUND.

The weird part is that after a firmware delete and a powercycle, the fus still report the current stack version being v1.13.3.2. However, after checking with a getfwinfo, I get the stack_type == 0. And the SFSA is 0xF4, so only the FUS is protected, leaving the whole Flash writable for the image (which has been verified!)

Can you advise?

[MM..1]

Seems as you firmware files is placed on long path with spaces. Copy folder with bin files to for example C:\STWBFW

[OTOMA.2]

Actually I've checked, and I don't have any space in the path:

/home/user/STM32Cube/Repository/STM32Cube_FW_WB_V1.13.3/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/stm32wb5x_FUS_fw.bin

[MM..1]

First update LOG show ok upgrade for FUS, after this FUS report no image say BLE fw not loaded or using user keys.
Try use latest STMProgrammer version ... Check flash size and install addr table.

[OTOMA.2]

Good idea, i've checked, the STM32CubeProgrammer is version 2.10.0 and there does not seem to be any updated version on the ST website.

I've checked the STM32WB55 from the nucleo is a 1MB version, therefore the release_note of the copro binaries from the WB pack 1.13.3 are stating 0x080EC000 for FUS update, and 0x080D0000 for the stack I've choosen.

I'm quite stuck

[OTOMA.2]

For the record, that thing already happen twice. The first one on a nucleo WB55 with FUS 0.5.3. But I didn't clearly log the actions. So to reproduce, I've bought another nucleo WB55, and performed the test, carefully listing the steps to reproduce.

It occurs that I do have a systematic error here...

[Remy ISSALYS]

Hello,

The following wiki page describes how to update the FUS and the wireless stack:

https://wiki.st.com/stm32mcu/wiki/Connectivity:STM32WB_BLE_Hardware_Setup

Try to follow these steps in order to perform FUS and the wireless stack update. If you have the same issue, tell us which step didn't succeeded.

Best Regards

[OTOMA.2]

Dear Remy,

I've read the page, and while upgrading the FUS, it feils on step 3.1.2 Start FUS:

here is a capture of the error withint the STM32CubeProgrammer 2.10.0

(i've tried several times as specified with board reconnection)

Best regards,

[Remy ISSALYS]

Hello,

Find in attachment a readme and a binary which is a tool that allow to see FUS and Wireless FW versions and perform some actions like delete Wireless Stack, FUS and Wireless Stack update, switch between FUS and Wireless Stack.

Can you try to load this binary at 0x08000000 address ? If your FUS version is different of v1.2.0, update your FUS with the procedure describe in the readme file. And then update your Wireless Stack by following the same procedure.

Best Regards

[OTOMA.2]

Wrapping up on that problem, after realising the FUS1.1.1 faulted and delegated the boot below the secure flash limit, I've been able to disable ESE and reload a FUS to make the board work again.

After trying on a second virgin board, I succeeded in performing my IAP stack loading through FUS 1.2.0 without the flitch encountered with the FUS 1.1.1.

Cheers, and thanks everyone for your comments!