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.93k stars 6.65k forks source link

samples: hci_pwr_ctrl does not work on Silabs EFR32MG24 chip #81779

Open adri1mart1 opened 2 days ago

adri1mart1 commented 2 days ago

Hello Zephyr community

Describe the bug

When compiling the hci_pwr_ctrl samples for the Silicon Labs xg24_dk2601b board, the sample is compiling fine but not working.

Dynamic Tx power Beacon started
[00:00:00.014,892] <dbg> bt_hci_core: tx_processor: TX process start
Get Tx power level ->[00:00:00.014,953] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0xfc0f param_len 3
[00:00:00.014,984] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200080a8
[00:00:00.015,014] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x200080a8 opcode 0xfc0f len 6
[00:00:00.015,045] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:00.015,045] <dbg> bt_hci_core: tx_processor: TX process start
[00:00:00.015,075] <dbg> bt_hci_core: hci_core_send_cmd: fetch cmd
[00:00:00.015,106] <dbg> bt_hci_core: hci_core_send_cmd: Sending command 0xfc0f (buf 0x200080a8) to driver
[00:00:00.015,106] <dbg> bt_hci_core: bt_send: buf 0x200080a8 len 6 type 0
[00:00:00.015,136] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:00.015,197] <dbg> bt_hci_core: bt_recv_unsafe: buf 0x20007ffc len 6
[00:00:00.015,228] <dbg> bt_hci_core: hci_cmd_complete: opcode 0xfc0f
[00:00:00.015,258] <dbg> bt_hci_core: hci_cmd_done: opcode 0xfc0f status 0x01  buf 0x20007ffc
[00:00:00.015,289] <dbg> bt_hci_core: hci_cmd_done: sync cmd released
[00:00:00.015,289] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:00.015,411] <dbg> bt_hci_core: tx_processor: TX process start
[00:00:00.015,441] <wrn> bt_hci_core: opcode 0xfc0f status 0x01
Read Tx power err: -5
-> default TXP = -1
Set Tx power level to 4
[00:00:05.015,716] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0xfc0e param_len 4
[00:00:05.015,716] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200080a8
[00:00:05.015,747] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x200080a8 opcode 0xfc0e len 7
[00:00:05.015,747] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:05.015,777] <dbg> bt_hci_core: tx_processor: TX process start
[00:00:05.015,777] <dbg> bt_hci_core: hci_core_send_cmd: fetch cmd
[00:00:05.015,808] <dbg> bt_hci_core: hci_core_send_cmd: Sending command 0xfc0e (buf 0x200080a8) to driver
[00:00:05.015,808] <dbg> bt_hci_core: bt_send: buf 0x200080a8 len 7 type 0
[00:00:05.015,838] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:05.015,899] <dbg> bt_hci_core: bt_recv_unsafe: buf 0x20007ffc len 6
[00:00:05.015,930] <dbg> bt_hci_core: hci_cmd_complete: opcode 0xfc0e
[00:00:05.015,960] <dbg> bt_hci_core: hci_cmd_done: opcode 0xfc0e status 0x01  buf 0x20007ffc
[00:00:05.015,960] <dbg> bt_hci_core: hci_cmd_done: sync cmd released
[00:00:05.015,991] <dbg> bt_hci_core: bt_tx_irq_raise: kick TX
[00:00:05.016,021] <wrn> bt_hci_core: opcode 0xfc0e status 0x01
Set Tx power err: -5

I've requested some support from Silabs and they replied to me the HCI command may be wrong. The command that needs to be used is 0x3f/0x14 based on this document --> https://www.silabs.com/documents/public/application-notes/an1328-enabling-rcp-using-bt-hci.pdf (chapter 4.18).

I've quickly tried to update the command to test, changing the default macro from:

#define BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL   BT_OP(BT_OGF_VS, 0x000e)

to

#define BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL   BT_OP(BT_OGF_VS, 0x0014)

without any success.

Any hint on modification to bring, explanation on why this is not working would be very welcome.

To Reproduce

west blobs fetch hal_silabs
west build -b xg24_dk2601b samples/bluetooth/hci_pwr_ctrl -- -DCONFIG_BT_HCI_CORE_LOG_LEVEL_DBG=y
west flash

Check the log output, eventually check with NRF connect the device RSSI is not changing (at least not that much !)

Expected behavior

BLE power updating up & down like the example behavior

Environment (please complete the following information):

jhedberg commented 13 hours ago

Quoting the README from the sample app:

This sample application demonstrates the dynamic Tx power control over the LL of the Bluetooth LE controller via Zephyr HCI VS commands.

The "VS" in the opcode definition stands specifically for this, i.e. Vendor Specific, i.e. non-standard. Each vendor (if they support VS extensions), will have a different set of commands available with different opcodes. What's referred to by "Zephyr HCI VS commands" is what's documented here: https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/connectivity/bluetooth/api/hci.txt

Currently these are the only VS commands that Zephyr host stack knows about and supports, and there's no mechanism to support any other VS command set. Feel free to propose solution to allow having vendor-specific host-side support. One challenge is that it's not just the opcodes that will be different, but the general feature set of provided commands and their semantics will be different, since there is no standard specification for what should be there or how it should behave. Another challenge is that these are in no way runtime discoverable, i.e. there would need to be a build time mechanism to say "this controller implements the VS command/event set from vendor X".