NUCLEO-WB55 BLE doesn't work with HCILayer_fw firmware

[ungverd]

Describe the bug
When I'm trying to upload stm32wb5x_BLE_HCILayer_fw.bin (i tried STM32CubeWB versions 1.17.0 and 1.13.0) to NUCLEO-WB55 (Nucleo68) board using STM32CubeProgrammer v2.14.0 and then flash beacon sample, I observe errors in minicom console and can not detect the beacon.

With stm32wb5x_BLE_HCILayer_extended_fw.bin this sample works fine.

To Reproduce
Steps to reproduce the behavior:

1. upload to the board stm32wb5x_BLE_HCILayer_fw.bin from STM32CubeWB (from https://www.st.com/en/embedded-software/stm32cubewb.html#get-software ), instructions are in the file en.stm32cubewb-v1-17-0/STM32Cube_FW_WB_V1.17.0/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/Release_Notes.html
2. minicom -D /dev/ttyACM0
3. (in another tab) west build -p always -b nucleo_wb55rg samples/bluetooth/beacon/
4. west flash
5. observe error in minicom console

Expected behavior
Beacon working and detectable by smartphone

Impact
I needed to stop and try things until I tried extended HCI version

Logs and console output

Starting Beacon Demo                                                                                                 
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:331                                  
        command opcode 0xfc0c timeout with err -11                                                                   
[00:00:43.002,000] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:43.002,000] <err> os: r3/a4:  0x20000340 r12/ip:  0x0000a7fa r14/lr:  0x080038cb
[00:00:43.002,000] <err> os:  xpsr:  0x41000000
[00:00:43.002,000] <err> os: Faulting instruction address (r15/pc): 0x080038d6
[00:00:43.002,000] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:43.002,000] <err> os: Current thread: 0x20000b58 (unknown)
[00:00:43.058,000] <err> os: Halting system

Environment (please complete the following information):

• OS: Ubuntu 22.04.2 LTS
• Toolchain: Zephyr SDK
• Version used: 0.16.1

[github-actions]

Hi @ungverd! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[sense-Jo]

Hi, I came across the same error when trying to use Bluetooth on STM32WB with Zephyr v3.4.0. However, for me it is independent of whether I am using stm32wb5x_BLE_HCILayer_fw.bin or stm32wb5x_BLE_HCILayer_extended_fw.bin; I always get the assertion fail in hci_core.c and the kernel oops directly afterwards.
Another minor difference is that I get timeout and kernel oops after only 10 seconds:

*** Booting Zephyr OS build zephyr-v3.4.0 ***
Starting Beacon Demo
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:330
        command opcode 0xfc0c timeout with err -11
[00:00:10.001,000] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:10.001,000] <err> os: r3/a4:  0x20000340 r12/ip:  0x00002711 r14/lr:  0x080038e3
[00:00:10.001,000] <err> os:  xpsr:  0x41000000
[00:00:10.001,000] <err> os: Faulting instruction address (r15/pc): 0x080038ee
[00:00:10.001,000] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:10.001,000] <err> os: Current thread: 0x20000b58 (unknown)
[00:00:10.058,000] <err> os: Halting system

I tried this with the coprocessor binaries from STM32Cube_FW_WB_V1.16.0 on Zephyr v3.4.0, and STM32Cube_FW_WB_V1.17.0 on 2f05af8 (current main).

[sense-Jo]

Okay, I could solve the problem I described above. Unfortunately, I don't know what exactly made the difference, as I just reinstalled the latest FUS (V1.2.0) and the BLE HCILayer FW from STM32Cube_FW_WB_V1.17.0. Now, things work with both stm32wb5x_BLE_HCILayer_fw.bin and stm32wb5x_BLE_HCILayer_extended_fw.bin.

[erwango]

Unfortunately, I don't know what exactly made the difference, as I just reinstalled the latest FUS (V1.2.0) and the BLE HCILayer FW

This happen to me as well from time to time. So far, I haven't been able to identify FUS issue and assumed issue was coming from my side as I always end up to make it working.

Don't hesitate to close the issue if you're done.

[pekkanikander]

I came across this same problem, with Zephyr v3.4.0. At the moment, I cannot get my board working with either V1.17.0 or V1.17.3 of STM32Cube_FW_WB.

However, using STM32Cube_FW_WB_V1.17.3/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/stm32wb5x_BLE_HCILayer_fw.bin at 0x080E0000 seems to have fixed the problem. For some reason, I needed also to reflash this at some point. I don't know what I did to cause the corruption, but so it was.

Just in case that wasn't really the issue, I also installed STM32CubeIDE and tested with it that the board is still working in the first place.

[erwango]

I cannot get my board working with either V1.17.0 or V1.17.3 of STM32Cube_FW_WB.

Which f/w are you using ?
See note here, "Note that since STM32WB Cube package V1.13.2, "full stack" binaries are not compatible
anymore for a use in Zephyr and only "HCI Only" versions should be used on the M0
side."

[pekkanikander]

I ended up using stm32wb5x_BLE_HCILayer_fw.binfrom STM32Cube_FW_WB_V1.17.3. With that my board seems to work — at least most of the time. But it is too early determine how reliably this works.

In general, I have a feeling that the low level STM32 drivers should be improved here.

[erwango]

In general, I have a feeling that the low level STM32 drivers should be improved here

Sure, but can you clarify your exact expectations ?

[pekkanikander]

In general, I have a feeling that the low level STM32 drivers should be improved here

Sure, but can you clarify your exact expectations ?

Well, it would be good if the STM32 drivers would check if the co-processor is available and running a supported stack. I don't know if that is feasible, though. If implemented, it should also be behind a compile time option so that it can be turned off in a production version.

If such functionality had been there, it would have saved me maybe 2–3 hours of work that I needed to figure out what was wrong after having upgraded the co-processor firmware.

[Oleh-Kravchenko]

Playing with same board and sample.
Same issues..