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]

Maybe you need FUS update.

[OTOMA.2]

I'll try that !

[OTOMA.2]

Ok, just tested, trying to install the firmware update with the FUS_fw.bin @ 0x080EC000, and I get the same error IMG_NOT_FOUND.

Could any ST support reply with a procedure to recover the nucleo?

[Remi QUINTIN]

Indeed you should better used the FUS available in the FW package version of the new FW you want to update.

Note that FUS V1.2.0 is the latest and definite version. So once you updated this version, you should never have to load a new FUS. I see your FUS version is 1.1.1. So I would recommend to update it to FUS v1.2.0 which is available in WB FW package V1.13.x.

[OTOMA.2]

So, As the latest FUS fw from the WB_1.13.3 package is not loading (IMG_NOT_FOUND, as stated before), what should I do?

[OTOMA.2]

Here is the stm32cubeprogrammer log:

 15:49:56 : Firmware delete Success

 15:49:56 : Download Stack/FUS image at address 0x80ec000 ...

 15:49:56 : Memory Programming ...

 15:49:56 : Opening and parsing file: stm32wb5x_FUS_fw.bin

 15:49:56 :  File         : stm32wb5x_FUS_fw.bin

 15:49:56 :  Size         : 23,92 KB

 15:49:56 :  Address      : 0x080EC000

 15:49:56 : Erasing memory corresponding to segment 0:

 15:49:56 : Erasing internal memory sectors [236 241]

 15:49:56 : Download in Progress:

 15:49:57 : File download complete

 15:49:57 : Time elapsed during download operation: 00:00:00.634

 15:49:57 : Verifying ...

 15:49:57 : Read progress:

 15:49:57 : Download verified successfully

 15:49:57 : Firmware Upgrade process started ...

 15:49:57 : Application is running, Please Hold on...

 15:50:09 : Reconnecting...

 15:50:09 : Reconnected !

 15:50:09 : Error: FUS_STATE_IMG_NOT_FOUND

[OTOMA.2]

Could any ST member advise on why is the device stuck. I'm not sure if this is a serious issue, but from production reliability it clearly is not acceptable. I'm wondering what sequence could have led the chip to such a state.

[Remi QUINTIN]

Strange!

I assume your are using the ST LINK port to download the FUS.

Could you erase the user space by setting the RDP value to 0xBB and then back to 0xAA.

Then retry to upgrade the FUS.

[OTOMA.2]

Thanks Remi for your reply.

However, it didn't go well.

1/ I changed to BB,

2/ powercycle

3/ I changed to AA

4/ powercycle

5/ I loaded FUS upgrade to 0x080EC000

6/ IMG_NOT_FOUND

7/ I slipped onto Start wireless stack

8/ The chip FUS is unresponsive

9/ powercycle

10/ The chip FUS is unresponsive.

I guess this is a terminal state for the chip, I don't have much hope. However this is clearly a critical tearing condition. Ths chip is not functional anymore. If you have services who can investigate I can arrange a shipment for the board.

BR