WB55 FUS upgrade fails, keep getting "security extension not instantiated" error message
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-14 04:10 AM
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!
- Labels:
-
STM32WB series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-15 08:16 AM
BOOT0 is grounded with a 10k as it supposed to be. I debug it through SWD using ST-Link. The application runs well, I can blink LEDs and stuff, but it seems, the sequencer doesn't initializes the BLE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-16 12:47 AM
@Remi QUINTIN​
And here are the option bytes, I assume these are default values.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-16 01:13 AM
​In fact I would like to see the secure option bytes: ESE, SFSA, SBRV, C2OPT, ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-16 01:17 AM
@Remi QUINTIN​
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-16 02:13 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-16 08:07 AM
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-22 08:56 AM
​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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-25 05:58 AM
@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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-25 06:45 AM
​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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-10-25 07:28 AM
@Remi QUINTIN​
The -fwdelete was succesful with the new CubeProgrammer, Thanks, but sadly still get 0s from the second command: