Mbed-os BLE stopped working on STM32WB55 after update FUS and BLE stack to version 1.14.1

Mbed OS Bugs
1

Hi community,

I have a device with STM32WB55 that has worked successfully with mbed-os for over two years (since the mbed-os 5 version). I decided to do an update of the FUS and STM BLE stack because I was using the old 1.2.0 versions and started having problems with the firmware update with the new application from ST and from own BLE Web API tool. I did an update of FUS and STM BLE stack to the current version 1.14.1.

[INFO][BLWB]: WIRELESS COPROCESSOR FW VERSION ID = 1.14.1
[INFO][BLWB]: WIRELESS COPROCESSOR FW STACK TYPE = 1 (ROM size 0xc3000)

After this action, BLE stopped working with mbed-os, when other functionalities of the firmware work fine. I have the following info from the HCI driver:

[INFO][BLWB]: Command Status event, status:1, opcode=0x2002

The problem occurs after calling _ble.init()
_ble.init(this, &BleProcess::onInitComplete);
onInitComplete() is obviously not executed.
Info on status 1 and opcode 0x2002 is reported in the method:
virtual void handle_reset_sequence(uint8_t *pMsg){}
In the file HCIDriver.cpp

I did tests with older versions of mbed-os from version 5 to mbed-os version 6.15.1. The problem is the same, BLE does not work. I also took another device and installed FUS and BLE stack versions 1.10.0 (older ones but younger than 1.2.0). With these versions mbed-os BLE also does not work. In the package from ST ‘STM32Cube_FW_WB’ there are now 3 firmwares: light, full, full_extended. I did tests on the light and full versions. So far on the full extended version nothing works for me. I’m trying to get even the BLE_Ota app working so I can upload firmware.

Is anyone perhaps familiar with this problem? What does opcode 0x2002 error from HCI driver means? How to solve this problem? Maybe someone from ST will comment?

Here is a little more info on how to get BLE working.

[INFO][BLCO]: WSF Cordio tracing enabled
[INFO][BLE ]: Allocated 2250 bytes for Cordio
[INFO][BLE ]: BLE features enabled: EXTENDED_ADVERTISING GATT_CLIENT GATT_SERVER PERIODIC_ADVERTISING PHY_MANAGEMENT PRIVACY SECURE_CONNECTIONS SECURITY SIGNING WHITELIST
[INFO][BLE ]: BLE roles enabled: PERIPHERAL CENTRAL
[INFO][BLE ]: Initialising Cordio host stack
[INFO][BLPR]: Initialize privacy PAL
[INFO][BLE ]: Initialising BLE instance
[INFO][BLHC]: CordioHCIDriver initializing
[INFO][BLWB]: init_debug ENABLED
[INFO][BLWB]: WIRELESS COPROCESSOR FW VERSION ID = 1.14.1
[INFO][BLWB]: WIRELESS COPROCESSOR FW STACK TYPE = 1 (ROM size 0xc3000)
[INFO][BLE]: Process started
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: WB Reset Received
[INFO][BLWB]: Found Unique Device Number: 1c6xxx
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: Setting Bdaddr: 5b:6b:1c:26:xx:xx
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: TX>> BLE CMD
[INFO][BLWB]: Command Status event, status:1, opcode=0x2002
2

Hi community,

It’s sad that no one has written anything back. I, however, have explored the issue a bit and can do a more extensive description of where the problem is.

As I wrote, I have 2 devices, one of which has the BLE stack from ST uploaded with version 1.2.0 and the other with 1.14.1. I ran the extended debug (trace) in mbed-os 6.14.1. Where are the differences, well, during BLE initialization, all responses to queries via HCI in the device with the 1.2.0 stack are of the type ‘Command Complete event’. Example below:

[DBG ][BLE_WB]: TX >> BLE CMD >> Type: 1 / Cmd: 202A / Len: 0
[DBG ][BLE_WB]: Payload:
[DBG ][BLE_WB]: Command complete event, cmd: 0e:05:01:2a:20:00:0f:00:94:26:00:20:00:00:00:00:00:00:00:00

and they are correctly handled by HCIDriver. On the other hand, for a device with stack 1.14.1, responses of type ‘Command Status event’ appear for the same queries.

[DBG ][BLE_WB]: TX >> BLE CMD >> Type: 1 / Cmd: 202A / Len: 0
[DBG ][BLE_WB]: Payload:
[DBG ][BLE_WB]: Command Status event, status:1, opcode=0x202A
0f:04:01:01:2a:20:00:00:94:26:00:20:00:00:00:00:00:00:00:00

Below are the BLE codes to which I get responses like ‘Command Status event’ instead of ‘Command Complete event’

[INFO][BLWB]: Command Status event, status:1, opcode=0x2002
[INFO][BLWB]: Command Status event, status:1, opcode=0x201C
[INFO][BLWB]: Command Status event, status:1, opcode=0x200F
[INFO][BLWB]: Command Status event, status:1, opcode=0x2003
[INFO][BLWB]: Command Status event, status:1, opcode=0x202A
[INFO][BLWB]: Command Status event, status:1, opcode=0x2005

At the very first response of this type, BLE initialization is stopped.
I went one step further and, having a debug from a properly working device, I myself call the appropriate functions as if the response was a ‘Command Complete event’ mode and configure with the correct data (from a device with an older stack) a device with a newer stack. It turns out that the BLE initializes. The GATT server is also initializing. All statuses are ok. However, as a consequence, BLE is not broadcasting. I need to solve this problem.

  1. Has anyone run the new stack from ST (1.14.1, or newer then 1.2.0) with mbed-os? Has it worked for anyone?
  2. Maybe it’s a problem on the ST side because the responses from the stack are not as they should be. The documentation from ST says that the responses should be of type ‘Command Complete event’ but all the examples that ST gave (from ‘STM32Cube_FW_WB’) are working fine. Why every response received by HCI Driver ‘Command Status event’ looks the same and is as below:

0f:04:01:01:2a:20:00:00:94:26:00:20:00:00:00:00:00:00:00:00

Moreover BLE stack 1.14.1 from ST is certified for BLE 5.2 and even works with BLE 5.3.

  1. Maybe it’s a problem with mbed-os that it can’t properly initialize the device with the newer stack?

Maybe someone has a solution to this issue?