zephyr: NUCLEO-WB55 BLE doesn't work with HCILayer_fw firmware

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:

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
minicom -D /dev/ttyACM0
(in another tab) west build -p always -b nucleo_wb55rg samples/bluetooth/beacon/
west flash
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

About this issue

Original URL
State: open
Created a year ago
Comments: 20 (8 by maintainers)

Most upvoted comments

The thing that fixed it for me was a full chip erase. Afterward I reflashed Zephyr and it immediately started working.

lopsided98 on Mar 24, 2024

Works for me. I’ve flashed these files a few times from v1.17.3 and even did a full chip erase:

stm32wb5x_FUS_fw.bin (0x080EC000, 06dbb3c9a003796470cd339d58523827)
stm32wb5x_BLE_HCILayer_extended_fw.bin (0x080DA000, cde4a2147949bb0cb8603a1cb5e9a4db)

*** Booting Zephyr OS build zephyr-v3.4.0 ***
Starting Beacon Demo
[00:00:00.022,000] <inf> bt_hci_core: Identity: 02:80:E1:00:00:00 (public)
[00:00:00.022,000] <inf> bt_hci_core: HCI: version 1.0b (0x00) revision 0x8074, manufacturer 0x0030
[00:00:00.022,000] <inf> bt_hci_core: LMP: version 1.0b (0x00) subver 0x2174
Bluetooth initialized
Beacon started, advertising as 02:80:E1:00:00:00 (public)

Oleh-Kravchenko on Sep 22, 2023

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.

pekkanikander on Sep 20, 2023