Bluetooth on STM32WB55 board not working

[jkorte-dev]

This is my first question here and I hope it is not to specific.

I am trying to run micropython on a WeAct Studio STM32WB55CGU6 board:
https://github.com/WeActStudio/WeActStudio.STM32WB55CoreBoard

and started with the USBDONGLE_WB55 board definition. All I changed was pin definition for LED and removed user button. I flashed the custom firmware but could not start BLE. Therefore I tested

Micropython (v1.23.0) without any modifications but starting BLE failed again with "OSError: [Errno 110] ETIMEDOUT"

>>> import bluetooth
>>> ble = bluetooth.BLE()
>>> ble.active(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 110] ETIMEDOUT

WeAct Studio docu states that stm32wb5x_BLE_Stack_full_fw.bin / protocol stack,v1.19.0.2 is installed. My first idea was that maybe the WS does not match .
the stm module reports the following:

import stm
>>> stm.rfcore_status()
0
>>> stm.rfcore_fw_version(0)
(1, 1, 1, 0, 0)
>>> stm.rfcore_fw_version(1)
(1, 19, 0, 0, 2)
>>> stm.rfcore_sys_hci(0x3F, 0x52, b"", 0)

which corresponds to the WeAct docu. In the NUCLEO_WB55 directory I found the rfcore_debug.py
It's output is:

% mpremote run boards/NUCLEO_WB55/rfcore_debug.py 
SRAM2A @20030000
  0000  2003008c 2003007c 00000000 20030074 20030058 00000000 00000000 00000000
  0020  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0040  20030040 20030040 20030048 20030048 20038338 20038338 20038aa0 20038990
  0060  20038330 00000660 20030048 00000000 00000000 20038bb0 20030050 20038220
  0080  20038110 20030040 20038000 00000000 01010100 10000006 00000000 01130002
  00a0  11160026 00000001 00000000 00000000 00000000 00000000 00000000 00000000
  00c0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00e0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0100  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0120  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0140  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0160  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0180  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  01a0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  01c0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  01e0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0200  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0220  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0240  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0260  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0280  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  02a0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  02c0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  02e0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0300  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0320  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0340  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0360  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0380  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  03a0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  03c0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  03e0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  0400  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
IPCC initialised
SYS: 0x20038bb0 0x20030050
BLE: 0x20038220 0x20038110 0x20030040
IPCCDBA  : 0x00000000
DDS      : True
FSD      : False
SFSA     : 0x000000ce
C2OPT    : True
NBRSD    : False
SNBRSA   : 0x0000000f
BRSD     : False
SBRSA    : 0x0000000a
SBRV     : 0x00033800
Device information table @2003008c:
WS is active
safe boot version        : 0x00000000 (0.0.0.0.0)
FUS version              : 0x01010100 (1.1.1.0.0)
FUS memory size          : 0x10000006 (SRAM2b=16k SRAM2a=0k flash=24k)
FUS info                 : 0x00000000
wireless stack version   : 0x01130002 (1.19.0.0.2)
wireless stack mem size  : 0x11160026 (SRAM2b=17k SRAM2a=22k flash=152k)
wireless stack info      : 0x00000000
wireless reserved        : 0x00000000
IPCC:
  C1CR:     0x00000000  C2CR:     0x00010001
  C1MR:     0xfffffffe  C2MR:     0xfffffff5
  C1TOC2SR: 0x00000000  C2TOC1SR: 0x00000002

I verified that there is no hardware issue with the board by flashing the stm ble example from https://github.com/STMicroelectronics/STM32CubeWB/tree/master/Projects/P-NUCLEO-WB55.USBDongle/Applications/BLE/BLE_p2pServer/Binary

and it works (ble service P2PSRV1 shows up)

I have currently no idea what could be wrong. Timing problem? Any hints, ideas, suggestions for further investigations?

[jkorte-dev]

I have enabled HCI trace and debug output in rfcore.c ...
It looks to me like the expected response from the ble coprocessor cannot be found, which causes the timeout.

hci.log

[andrewleech]

Urgh yeah the WB55 can be just the worst sometimes. When it doesn't want to work it just gives you nothing to go by. That OSError: [Errno 110] ETIMEDOUT really just means "micropython is trying to talk to the rfcore firmware and it's simply not responding at all".

It's been some time since I've used the WB55 BLE, there's a chance that newer rfcore versions have broken the compatibility perhaps? I think 1.13 is the last one I've used personally.

The changes in this PR might have an effect too: #8452 your post here reminded me I needed to rework that one as @dpgeorge cleaned up the flash code significantly which should mean my changes there can be reduced dramatically.

[jkorte-dev]

Thanks for the reply I have increased debug logging and try to narrow the problem, but I have the feeling that this problem is too big for me. When I had a look at your PR I realized how complex the communication between cpu1 and cpu2 can be.

I'll check if it is possible to downgrade ws to 1.13 and try again

[jkorte-dev]

I had a terrible time trying to find the bug. At one point the timeout behavior suddenly changed and I realized that fus was active and ws was not. I was able to get back to active ws mode easily using STM32_Programmer_CLI, but soon after I gave up. Now I stumbled upon this {https://community.st.com/t5/stm32-mcus-wireless/bluetooth-application-on-nucleo-wb55rg-in-micropython/td-p/80091) thread on the STM forum where people were having the same timeout error on their official STM32WB55 boards, which leads me to believe that it may be an incompatibility with STM's latest wireless stack.

@andrewleech was 1.13 the version of the wireless stack or micropython? Could you please have a look which ws version is running on your board, I looks like I can do a ws firmware downgrade. Thank you.

[andrewleech]

Yeah this BLE diagnostics is crazy hard on these chips with the core 2 radio a big black box.

I was referring to stm ws 1.13 as the last version I've used with micropython.

[jkorte-dev]

It took some time to get the firmware installation working (STM32_Programmer_CLI crashed with segmentation fault) but it works now after downgrading to ws 1.13.0 !!

Device information table @20030058:
WS is active
safe boot version        : 0x00000000 (0.0.0.0.0)
FUS version              : 0x01010100 (1.1.1.0.0)
FUS memory size          : 0x10000006 (SRAM2b=16k SRAM2a=0k flash=24k)
FUS info                 : 0x00000000
wireless stack version   : 0x010d0005 (1.13.0.0.5)
wireless stack mem size  : 0x1116002a (SRAM2b=17k SRAM2a=22k flash=168k)
wireless stack info      : 0x00000000
wireless reserved        : 0x00000000
IPCC:
  C1CR:     0x00000000  C2CR:     0x00010001
  C1MR:     0xfffffffe  C2MR:     0xfffffff5
  C1TOC2SR: 0x00000000  C2TOC1SR: 0x00000002
>>> from bluetooth import  BLE
>>> BLE().active(True)
True

I used the stm32wb5x_BLE_Stack_full_fw.bin . Somewhere between v1.13.0 and 1.13.3 was the breaking change.

[andrewleech]

Congrats on getting a working unit!
That's good to know that there's a breaking change there, thanks for sharing your efforts.

We do intend to use the WB55 at work still for BLE projects so I might need to schedule in some time to investigate what's going on here!

[andrewleech]

I haven't looked into it any deeper yet however on my NUCLEO_WB55 I just installed the v1.21.0 stm32wb5x_BLE_HCILayer_extended_fw.bin stack from:

• https://github.com/STMicroelectronics/STM32CubeWB/blob/v1.21.0/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/stm32wb5x_BLE_HCILayer_extended_fw.bin

It was loaded at address 0x080DA000 for my STM32WB5xxG (1MB Flash) chip as per the release note.
The basic ble active call worked correctly without timeout

>>> from bluetooth import  BLE
>>> BLE().active(True)
True

[jkorte-dev]

Thank you for the update. WeAct, the vendor of my board has updated to ble stack to v1.21.0 as well. I haven't used the board for quite a while. But I will give it a try. Looks promising.

[andrewleech]

The variant of the stack might make a difference, I only tried on the minimal HCI build. The stm32wb5x_BLE_Stack_full_fw.bin one might be different / too big or something as well.