Zephyr 3.7 RC2 BLE on STM32 Nucleo WB55 does not work

[piotrParf]

Describe the bug
I am using Zephyr 3.7 RC2 but the issue is vissible also with 3.7 RC1.
I am trying if everything still works for the STM32WB55 device. I am using STM32 Nucleo WB55.
I checked radio firmware stm32wb5x_BLE_HCILayer_fw.bin in version 1.18.0 from STM32WB Copro Wireless Binaries.
The issue is visible with the radio version 1.19.1 and also with the firmware file stm32wb5x_BLE_HCILayer_extended_fw.bin.
Demos with BLE do not work on STM32 Nucleo WB55. I have also my own application but also demo iBeacon does not work.

The issue seems coming from the bt_ipm_ble_init function.

It was working with Zephyr 3.4 when I last checked.

To Reproduce
Have radio firmware loaded with radio fw.
Build the "zephyr/samples/bluetooth/ibeacon" demo for -DBOARD=nucleo_wb55rg flash and run.

Expected behavior
Working demo and visible iBeacon node on BLE scanner.

Impact
BLE on STM32 Nucleo WB55 does not work.

Logs and console output
When I read the log I got the below report:

*** Booting Zephyr OS build v3.7.0-rc1-588-g40810983ead2 ***
Starting iBeacon Demo
E: ***** USAGE FAULT *****
E:   Illegal use of the EPSR
E: r0/a1:  0x080094f4  r1/a2:  0x20002ac8  r2/a3:  0x00080000
E: r3/a4:  0x00000000 r12/ip:  0x20000224 r14/lr:  0x080035b1
E:  xpsr:  0x20000000
E: Faulting instruction address (r15/pc): 0x00000000
E: >>> ZEPHYR FATAL ERROR 35: Unknown error on CPU 0
E: Current thread: 0x20000490 (unknown)
E: Halting system

Environment (please complete the following information):
Linux Debian 11
CMake version: 3.21.0
Zephyr version: 3.7.0-rc2
west 1.2.0
host-tools: zephyr 0.16.1
toolchain: zephyr 0.16.1

[ajarmouni-st]

Hi @piotrParf, have you seen?

zephyr/boards/st/nucleo_wb55rg/doc/nucleo_wb55rg.rst

Lines 194 to 196 in 6700a15

	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.

[piotrParf]

@ajarmouni-st
As I mentioned in bug description I tried stm32wb5x_BLE_HCILayer_fw.bin and stm32wb5x_BLE_HCILayer_extended_fw.bin from packages in version 1.18.0 and 1.19.1. Both firmwares are HCI only. Firmware 1.18.0 works with Zephyr 3.4 (our current base which we want to migrate to new version).

[erwango]

^^@asm5878

[asm5878]

^^@JoeGitST

[asm5878]

Thanks to @JoeGitST we have identified the commit causing the regression:
501e715

Investigation is on going

[asm5878]

^^ @jhedberg

[asm5878]

After the update of BLE HCI API drivers we have realized we have an issue in management of TX/RX HCI commands.
The first HCI cmd (any) is causing an usage fault.

Investigation will continue to clearly analyze the root cause.

[jhedberg]

@asm5878 I took a quick look at the driver code, and it seems like the core issue is likely that the driver attempts to send HCI commands inside bt_ipm_open(). No driver should do that, since from the perspective of the host (which owns the bt_hci_cmd_send*() APIs) the HCI transport is functional only after the drivers's open() callback has successfully returned. What the driver should instead do is to implement a setup() callback (which gets called by the host immediately after open()) and perform any HCI command sending from within that callback instead.

[jhedberg]

@asm5878 the exact failure is probably simply that the driver hasn't yet set its hci->recv callback pointer before it attempts to send HCI commands (recv() is needed to pass the command completion events to the host), however even if you fixed that it's not right for the driver to call any HCI command APIs from open() rather those should be moved into setup().

[jhedberg]

@asm5878 also, this is not the first HCI driver to have such a bug, take a look e.g. at #73711 for a recent similar fix.