cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WBCG after flashing new FUS and BLEStack is only able to run after flashing a demo application.

Alexander1
Associate II

I recently got my new prototypes based on the STM32WBCG. I selected boot1 mode and ran the FUS update and the BLE stack installer:

STM32_Programmer_CLI.exe -c port=usb1 -fwdelete
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade .\STM32WB_Copro_Wireless_Binaries\stm32wb5x_FUS_fw.bin 0x080EC000 firstinstall=0
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade .\STM32WB_Copro_Wireless_Binaries\stm32wb5x_BLE_Stack_fw.bin 0x080CB000 firstinstall=1

Afterwards, I connected the SWD debugger and installed my application. The application crashed after APPE_Init(); So I checked again the binaries and reinstalled them. It still didn't work.

So I tried to flash the BLE_TransparentMode_reference.hex from STM32Cube_FW_WB_V1.4.0 and reconnected it to my PC. Et voilà! It worked!

Afterwards I flased my application as I did before and suddently it worked. I had to flash the reference.hex to all my prototypes and then flash my application to make them able to run.

I saw some posts about having troubles flashing the BLE stacks to your devices. Maybe that fixes it. 🙂

Does anyone have an idea what happend? Or can explain that behaviour?

Yours

Alex

1 REPLY 1
Remi QUINTIN
ST Employee

​Moving from one programming interface (USB in DFU mode) to another (SWD) may lead to such unpredictable result due to the fact that the option bytes are not set in the same way for both interfaces. Now how this relates to the crash of the APPE_Init function, .... Hard to say!!

Writing the .hex file is not requiring any secure FW to run. So this is why it works in all cases.