WB55 FUS upgrade fails, keep getting "security extension not instantiated" error message

[MLeng.638]

I'm trying to flash the FUS and BLE_stack to the co-processor, but the CubeProgrammer drops me the error below. I could not even delete the previous FUS as the release note said. Same error message. The flash was erased by changing the protection byte to 0xBB and then back to 0xAA. Could that be my problem? The MCU is on a custom PCB, and the important parts are the same as on the WB55-Nucleo and I'm using a nucleo with s-link to program through SWD. The application runs perfectly on the M4 (except the bluetooth part).

So the error message is: "Error: Could not execute fwupgrade command, Security extension not instantiated".

Any help is appreciated.

Thanks in advance!

[Remi QUINTIN]

They look good. At least the SFSA is set at a level that can let us confirm that the RF stack is correctly installed. Are you using the new CubeProgrammer V2.2 with the SWD protocol?

Can you go up to the call to SET_BIT(PWR->CR4, PWR_CR4_C2BOOT) that launches the CP2?

Do you get the IPCCC IRQ?

Then, on the HW side, the LSE or HSE clocks are critical. There may be a need for a new calibration as it is a new board with a new oscillator and impedances. Can you check this. The deviation should be max +/- 20 ppm. The CPU2 clock must be at 32Mhz.

Please have a look at AN5042 on the HSE trimming.

[MLeng.638]

@Remi QUINTIN​ 

Mostly I'm using the STM32CubeIDE (1.1.0) software to program the device, and occasionally the CubeProgrammer V2.1.0.

The " SET_BIT(PWR->CR4, PWR_CR4_C2BOOT)" is called, and the value of the register is 0x8000, which is good, I assume.

Didn't get IPCC IRQ, yet they are set and enabled.

The HSE clock is set to 32'000'0xx Hz. That's the most precise value we can measure (on the A8 Pin), but it is inside the +-20ppm interval, so that should not be a problem.

[Remi QUINTIN]

​Please use the lasted version V2.2 of CubeProgrammer as some improvements were made when using the SWD interface for SW update.

OK for the HSE clock!

C2BOOT OK with SFSA OK!

Do you see some data existing  in SRAM2a  starting from 0x2003 0000 (IPCC data buffers)?

[MLeng.638]

@Remi QUINTIN​ 

Updated the CubeProgrammer to v2.2, but everíthing is the same.

From the addres 0x2003 0000, I only see a bunch of zeros, like this:

[Remi QUINTIN]

​Clearly the RF stacks is not working.

The fact that you do not see any data, especially on 0x20030030 shows that the FUS is not activated.

One way to do it is to perform a fw delete  . This will trigger the FUS and one of its first action is to write its version at 0x20030030.

·        FUS FW delete :  

        STM32_Programmer_CLI.exe -c port=swd -fwdelete

·        Read FUS version :  

        STM32_Programmer_CLI.exe -c port=swd -r32 0x20030030 1

Then if the 2 commands above are successful with a FUS version not being 0, you should be able to upgrade the FUS if the version is V0.5.3 (=0x00050003). If it is not ,for example if the version number is V1.0.2 (0x=01000200), then you don't have to update it. It is the most recent as of today.

·        FUS Upgrade :  

STM32_Programmer_CLI.exe -c port=swd mode=UR -ob nSWboot0=0 nboot1=1 nboot0=1 -fwupgrade stm32wb5x_FUS_fw.bin 0x080EC000 firstinstall=1  

Then try to update the RF stack

·        RF Stack install :

STM32_Programmer_CLI.exe -c port=swd mode=UR -ob nSWboot0=0 nboot1=1 nboot0=1 -fwupgrade stm32wb5x_BLE_Stack_fw.bin 0x080EC000

And finally the application

·        User application install :

STM32_Programmer_CLI.exe -c port=swd mode=UR -d UserApplication.bin 0x08000000 -v

 

[MLeng.638]

@Remi QUINTIN​ 

The -fwdelete was succesful with the new CubeProgrammer, Thanks, but sadly still get 0s from the second command:

[Remi QUINTIN]

​Yes it is normal. I forgot to mentionned that this command is not supported  via the SWD port.

So please go on with the RF stack update.

[MLeng.638]

@Remi QUINTIN​ 

After the the successful 'fwdelete' command, at the FUS upgrade I get errors (FUS_STATE_IMG_NOT_AUTHENTIC, fwupgrade command failure), but after that I tried to upload the BLE_stack to 0x080CC000, and it said it was successful. Yet, the RF stack still doesn't start.

Do I suppose to do someting with the boot0 pin during all that, or just left it as it is (down to ground with a10k)?

(Btw, this is the MCU we desoldered from a nucleo dongle and it was working on that PCB, so what could be the problem which cause all this? Our custom PCB is almost the same as the dongle PCB, there is a few I/O pin difference, that's all. The code which is running on the M4, is written with the help of the WB55 workshop, it's basically the HandsOn_2 code.)

[Remi QUINTIN]

​If the BLE RF stack is from the CubeWB FW package V1.3.0, the load address should be 0x080CB000 as it is one sector bigger.

Once all your pieces of SW are programmed in Flash memory, BOOT0 should be set to 0 to start execution from the main Flash memory.