cancel
Showing results for 
Search instead for 
Did you mean: 

Problems starting BLE stack with NUCLEO-STM32WB55-Nucleo board - Confusing observations

MDaub.1
Associate III

I am a beginner with STM32 and the NUCLEO-STM32WB55 board.

The preflashed demo application worked without problems. When I installed the STM32WB55 MCU package, a couple of examples were available like the BLE HRS service.

I managed to import the project, compile and flash it, but nothing 'happened'. Couldn't see any advertisements, no UART debug messages, etc.

Tried another one, still the same behavior. Started reading about the whole eco-system and saw that there were firmware binaries in the MCU package. Despite that the first pre-flashed project worked, I wanted to give it a try and flashed according to the release-notes:

How to flash the Wireless Coprocessor Binary via USB (STM32CubeProgrammer GUI)
 
Inside the below procedure, the references to binaries name and install address are provided in the section Main Changes of this file.
 
STEP 1: Use STM32CubeProgrammer GUI
 
Version 2.4.0 or higher.
 
It gives access to Firmware Upgrade Service (FUS) (AN5185 : ST firmware upgrade services for STM32WB Series.) through Bootloader.
 
It is currently available as Graphical User Interface (GUI) mode (or Command Line Interface (CLI) mode).
 
STEP 2: Access to Bootloader USB Interface (system flash)
 
Boot mode selected by Boot0 pin set to VDD
For P-NUCLEO-WB55.Nucleo :
Jumper between CN7.5(VDD) and CN7.7(Boot0)
Power ON via USB_USER and Jumper JP1(USB_MCU)
For P-NUCLEO-WB55.USBDongle :
Move switch SW2 to Boot0
Connect P-NUCLEO-WB55.USBDongle
open STM32CubeProgrammer GUI and select “USB�?
in USB configuration: (Port: USB1) then select “Connect�?
STEP 3 : Delete current wireless stack
 
in Firmware Upgrade Services: select “Delete Firmware�?
STEP 4 : Read and upgrade FUS Version
 
in Firmware Upgrade Services: select “Read FUS state�?
0x20030030 : 00050300 : FUSv0.5.3 => Must be updated using STEP 5.
0x20030030 : 01000100 or 01000200 : FUSv1.0.x => Must be updated using STEP 6.
0x20030030 : 01010000 : FUSv1.1.0 => Up to date, you can download the new wireless stack using STEP 7.
STEP 5 : Download FUS v1.0.2 :
 
in Firmware Upgrade Service: (File Path: [stm32wb5x_FUS_fw_1_0_2.bin], Start Adress: [Install@])
then select “Firmware Upgrade�? Please check Firmware Upgrade Services Binary Table for Install@ parameter depending of the binary.
STEP 6 :Download latest FUS v1.1.0 :
 
in Firmware Upgrade Service: (File Path: [FUS_Binary], Start Adress: [Install@])
then select “Firmware Upgrade�? Please check Firmware Upgrade Services Binary Table for Install@ parameter depending of the binary.
STEP 7 : Download new wireless stack :
 
in Firmware Upgrade Service: (File Path: [Wireless_Coprocessor_Binary], Start Adress: [Install@])
then select “Firmware Upgrade�? with “Verify download�? and “Start stack after upgrade�? Please check Firmware Upgrade Services Binary Table for Install@ parameter depending of the binary.
STEP 8 : Revert STEP 2 procedure to put back device in normal mode.

Everything worked fine and I saw the expected version when reading "FUS state".

Once I clicked "Start stack" and reconnected the debugger, everything worked like a charm. OK, odd, probably the new projects needed that updated firmwar. Ok, maybe.

Then I spent the next day, trying to figure out how to build my own BLE peripheral (There is another post open from me concerning include-path settings which kept me occupied most of the time). Now that that was cleared I wanted to retry my project and flashed it again. No advertisements, nothing. Then tried to reflash the provided HRS example once more.... and it didn't work either? I traced the calls and saw that my code just hung at two calls:

1st) app_ble.c: Ble_Tl_Init() in APP_BLE_Init().

Revisiting the CubeProgrammer tool and inspecting FUS_state I got FUS_ERROR/FUS_not_running (MCU was connected in DFU mode).

I then tried reflashing the firmware (stm32wb5x_BLE_Stack_full_fw.bin to 0x080CB000), which worked successfully.

Restarting the debugger, I now got past that 1st call, but the code hung again at the call to Ble_Hci_Gap_Gatt_Init() in the same routine APP_BLE_Init().

Revisiting the CubeProgrammer and clicking "Start stack" the example started to work again and I saw the advertised service and could use it.

So I come to the conclusion that something/somehow I overwrote the BLE firmware or "stopped" it, and I wonder how this is even possible. I didn't do anything but trying to compile my own example (which didn't work due to the compile errors with the include-paths, so no reflashing happened) and/or flashing the provided examples by STM. Why should the firmware suddenly not work anymore or the stack be stopped?

What other reasons could lead to that result? What am I overlooking? It probably is not the intended way to just reflash the firmware every other day?

I have very little "tangible" here to provide (attached my progger.log though), but I am happy to redo some steps based on some guidance and provide the results.

tl; dr:

Playing around with the provided examples and doing some first steps, somehow the BLE firmware seemed to got stopped and/or corrupted and none of the examples worked anymore after some tries. Reflashing solved the issue, but should not be necessary. What was the root cause to avoid doing that required the reflashing?

2 REPLIES 2
MDaub.1
Associate III

I was now able to reproduce the problem clearly.

Start state: C:\Users\xxxx\STM32Cube\Repository\STM32Cube_FW_WB_V1.9.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\BLE_HeartRate was flashed on the board and working.

I created a new project "TestForSTM" based on the CubeMX templates in order to try to implement my own service. According to what I configured and my perception it "should" work - or at least give me some pointers what's wrong. Anyway... didn't work.

Now REFLASHED the previous existing project BLE_Heartrate and started it: Code hangs at SHCI_C2_BLE_Init( &ble_init_cmd_packet ) in APP_BLE_Init()!

The project that worked previously flawless, now no longer runs past the BLE initialization. What has the "TestForSTM" project changed? What's wrong?

MDaub.1
Associate III

Small but IMPORTANT finding... Whenever the BLE Stack seems to hang and no longer reacts.. Just disconnect/reconnect the board and it starts working again! It's not fixed by reflashing/restarting the debugger or even pressing the reset button! A full disconnect/reconnect is needed but reliably fixes it... Why is this? What could have gone wrong by starting one of the auto-generated project templates?