search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.18k stars 6.23k forks source link

NUCLEO-WB55 BLE doesn't work with HCILayer_fw firmware #60951

Open ungverd opened 12 months ago

ungverd commented 12 months ago

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):

github-actions[bot] commented 12 months ago

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 commented 10 months ago

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 2f05af891 (current main).

sense-Jo commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

Playing with same board and sample. Same issues..

erwango commented 10 months ago

Same issues..

Hopefully same solution ?

erwango commented 10 months ago

Well, it would be good if the STM32 drivers would check if the co-processor is available and running a supported stack.

Ok, I'll investigate.

Oleh-Kravchenko commented 10 months ago

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

pekkanikander commented 10 months ago

Works for me now as well, also with stm32wb5x_BLE_HCILayer_extended_fw.bin. However, I'm pretty sure that it did not work with my first try. I'm not sure what was the issue at that phase.

Is stm32wb5x_BLE_HCILayer_extended_fw.bin supposed to really support extended advertising?

With samples/bluetooth/periodic_adv I get the following result:

*** Booting Zephyr OS build zephyr-v3.4.0-1-gd45a325e4975 ***
Starting Periodic Advertising 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 5.3 (0x0c) revision 0x8075, 0
[00:00:00.022,000] <inf> bt_hci_core: LMP: version 5.3 (0x0c) subver 0x2175
[00:00:00.026,000] <wrn> bt_hci_core: opcode 0x2036 status 0x01
Failed to create advertising set (err -5)

The opcode code 0x2036 seems to be BT_HCI_OP_LE_SET_EXT_ADV_PARAM and -5 is EIO, returned from hci_core.c:L343. The the meaning of the status code 0x01 I don't know.

erwango commented 10 months ago

Is stm32wb5x_BLE_HCILayer_extended_fw.bin supposed to really support extended advertising?

In theory no, we're missing some HCI driver adaptation. This is in the pipe, though. See https://github.com/zephyrproject-rtos/zephyr/discussions/62001

arcini commented 4 months ago

I'd like to add that I'm experiencing the exact same issue as reported by others above, however I am not able to resolve it by reflashing the stm32 wb copro binaries (attempted 5+ times now).

erwango commented 4 months ago

I'd like to add that I'm experiencing the exact same issue as reported by others above, however I am not able to resolve it by reflashing the stm32 wb copro binaries (attempted 5+ times now).

What versions are you using ? Are you able to get a Cube application working?

arcini commented 4 months ago

I was using V1.18.0 of _stm32wb5x_BLE_HCILayer_extendedfw.bin flashed at <0x080DA000> as specified in the blob's release notes

I'll note, that previously I had tried various previous versions of the same binary (including v1.17.3, v1.17.0, and v1.13.3). I have also reflashed v1.2.0 of the FUS binary at least a couple times now.

I am able to get ST's "BLE_p2pserver" application working, although it required flashing _stm32wb5x_BLE_Stack_fullfw.bin v1.18.0 first. Before flashing it, the app printed "Start Fast Advertising Failed , result: 1" and wasn't working (due to having the HCI only binary flashed). I flashed the BLE_Stack_full_fw binary one time, the same way as I had for the previous times I flashed the others. And, I am able to connect to my board and control LED1 using the "ST BLE Sensor" mobile app.

The kernel oops output I was getting when trying to run my zephyr application is exactly the same as some others above, with the ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:331 command opcode 0xfc0c timeout with err -11

Not sure how I should proceed here. Any ideas?

arcini commented 4 months ago

I was hoping if I simply flash back to the correct BLE firmware and try again, my app would magically work now. But that did not happen, here's what I did:

Here's my output:

*** Booting Zephyr OS build v3.6.0-1239-g7ffafd9b6473 ***
[00:00:00.001,000] <inf> foo: Initializing bluetooth

ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:331
        command opcode 0xfc0c timeout with err -11
[00:00:10.002,000] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:10.002,000] <err> os: r3/a4:  0x20000678 r12/ip:  0x00002712 r14/lr:  0x08003a23
[00:00:10.002,000] <err> os:  xpsr:  0x41000000
[00:00:10.002,000] <err> os: Faulting instruction address (r15/pc): 0x08003a2e
[00:00:10.002,000] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:10.002,000] <err> os: Current thread: 0x200010b8 (unknown)

I am using the nucleo_wb55rg board for my development, if that matters.

lopsided98 commented 4 months ago

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