Sending a notification causes STM32WB55 to go idle and becomes unresponsive to all further BLE requests

[mbedt]

Upon triggering a notify event calling the following function "Custom_STM_App_Update_Char()", the STM32 successfully sends data, which I receive on my iPhone using ST BLE Toolbox. However, after that, the STM32 becomes unresponsive to further BLE requests. I can see that the system hasn't crashed, as it is continusouly calling "UTIL_SEQ_Idle".

I am using a BLE application: server profile with a custom profile. I have already seen the other forum post titled "STM32WB55 Stops handling events after sending a notification" which sounds similar to this, but I am not deliberately pausing or stopping the sequencer at any point (as far as I'm aware).

Another unusual thing I've noticed, is that every other characteristic has been given a handle for the function "Custom_STM_Event_Handler(void *Event)" in "custom_stm.c", which I am able to use to call other functions to handle thos events, however, for my notify event, I can only see handles for NOTIFY_ENABLED_EVT / NOTIFY_DISABLED_EVT which aren't of much use to me.

[STTwo-32]

Hello @mbedt 

Are you able to reproduce this issue using the last version of the STM32CubeWB (V1.21.0). 

Best Regards.

STTwo-32

[mbedt]

I've just tried updating to v1.21 and it seems to have caused further issues.

It still functioned after changing to v1.2.1 but the BLE code wouldn't intialise, meaning I couldn't connect to it at all via BLE / ST BLE Toolbox, even though it was looping through MX_APPE_Process() and UTIL_SEQ_Idle(void) with the debugger.

Moving back to the previous version, v1.19.0, it still no longer works. Is there a way to factory reset or is the device bricked?

[STTwo-32]

Hello @mbedt 

First, are you using an ST Board or your own HW?

In both cases, could you please share your the FUS and stack that you are using (you may can perform a test using one of our examples).

Best Regards.

STTwo-32 

[mbedt]

The device I'm using is the NUCLEO-WB55RG.

I previously had the following on it from STM32Cube_FW_WB_V1.19.0, where I was having my original issue:

• stm32wb5x_FUS_fw.bin
• stm32wb5x_BLE_Stack_full_fw.bin

I have now just tried the same binaries, but from the latest version, STM32Cube_FW_WB_V1.21.0, as per your suggestion. I've attached a picture of what's read back from the device since I programmed it with v1.21.0.

[STTwo-32]

After updating your stack, have you clicked on the "Start Wireless Stack" button after updating the wireless stack to start it?

Best Regards.

STTwo-32

[mbedt]

What's the need for "Start Wireless Stack", since the device has to be disconnected to download the code from STM32CubeIDE?

This is my process:

• Connect NCULEO-WB55RG to STM32CubeProgrammer
• Full chip erase
• Using files from \en.stm32cubewb-v1-21-0\STM32Cube_FW_WB_V1.21.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x:
  • Flash with: stm32wb5x_FUS_fw.bin @ addr: 0x080EC000
  • Read FUS info to confirm: v1.2.0.0 read back successfully with FUS operator v3.1.0
  • Start FUS
  • Flash with: stm32wb5x_BLE_Stack_full_fw.bin @ addr: 0x080D0000
  • Read FUS info to confirm stack: v1.21.0.3 read back successfully
  • Start Wireless Stack

• Disconnect NCULEO-WB55RG from STM32CubeProgrammer
• Open STM32CubeIDE:
  • Download programme to device using green "Debug" icon
  • Programme downloads and debugger starts
  • Debugger connects and main loop runs:
  • Try to connect via BLE using ST BLE Toolbox. BLE connects then disconnects immediately (which I observe from the device end because of print statements)
  • ST BLE toolbox reports "An error occurred during connection"
  • Open .ioc file and prompted to migrate project to new FW_WB_V1.21.0.
  • Project migrated and code generated again.
  • Redownload code to device using debug button
  • Same issue as above occurs.

Thanks

[STTwo-32]

Does your board work fine with the STM32WB55 P2P server example?. Could you please upload your firmware using the upload button:

Best Regards.

STTwo-32 

[mbedt]

I tried the P2P example, which didn't work. So tried a 2nd NUCLEO board that I have (same model - NUCLEO-WB55RG) with the P2P example, wireless stack 1.13.2.2. Thisn worked fine, which suggested an issue with the first board. However, I've now gone to use the 2nd board again, and now that won't work, with same symptoms as the first board. The only common demominator I can think of is STM32CubeProgrammer, as I haven't touched the FUS or wireless stack on the second board. I only used STM32CubePorgrammer to check the versions on it.