STM32WB55 BLE extended advertising wrong TX power settings

[piotrParf]

Describe the bug
We are using the STM32WB55 platform and extended advertising API for starting legacy advertising. We are using Zephyr 3.4.0.
Before starting any advertising we issue the ST-specific ACI command (application note AN5270 - ACI_HAL_SET_TX_POWER_LEVEL) to set TX power and we are setting it to a low value for example -20dbm(value 0x01 in mentioned command description).
When starting advertising using extended advertising API we observe that there is no difference of observed RSSI at sniffer if the power is set to 0dbm or -20dbm.
What was observed is that STM32WB55 is reacting wrong in le_ext_adv_param_set(file: zephyr/subsys/bluetooth/host/adv.c ) function to:

cp->tx_power = BT_HCI_LE_ADV_TX_POWER_NO_PREF;

The BLE controller should take preference from "global" power but it returns in this part of the code:

struct bt_hci_rp_le_set_ext_adv_param *rp = (void *)rsp->data;

adv->tx_power = rp->tx_power;

value of rp->tx_power=0x06.

When we manually changed the value like below:

cp->tx_power = -20;

the returned power is 0xeb = -21. So it is close to the demanded value. And the observed RSSI changes accordingly.
The first problem is that there are no means to change the cp->tx_power by API while it should be possible as in structure "struct bt_le_ext_adv" there is field tx_power and it seems unused at this moment. At this moment this value is hardcoded to BT_HCI_LE_ADV_TX_POWER_NO_PREF;
The second problem is that the ST BLE controller is reacting wrong to the BT_HCI_LE_ADV_TX_POWER_NO_PREF value while according to BLE standard it should not care for this value and use the "global" setting

Expected behavior
Advertising should start with globally set TX power.

Impact
It is impossible to change TX power using extended advertising API with STM32WB55. Higher power usage during advertising. Issues on algorithms relying on RSSI.

Environment (please complete the following information):

• OS: Linux
• Zephyr SDK 0.16.1, Zephyr 3.4.0,
• STM32WB55 BLE controller stm32wb5x_BLE_HCILayer_extended_fw.bin, version 1.17.0

Additional context
We have changed /modules/hal/stm32/lib/stm32wb/hci/app_conf.h and zephyr/drivers/bluetooth/hci/ipm_stm32wb.c files to turn on the Extended Advertising in Zephyr 3.4.0

[erwango]

@piotrParf In order to ease support, can you provide the changes you've made to /modules/hal/stm32/lib/stm32wb/hci/app_conf.h and zephyr/drivers/bluetooth/hci/ipm_stm32wb.c. ?

[piotrParf]

Hi @erwango,
We are using the below patches among others to enable Extended Advertising API with STM32WB55:

diff --git a/lib/stm32wb/hci/app_conf.h b/lib/stm32wb/hci/app_conf.h
index c3b16f51..0147b3a6 100644
--- a/lib/stm32wb/hci/app_conf.h
+++ b/lib/stm32wb/hci/app_conf.h
@@ -153,7 +153,7 @@
  * Maximum number of simultaneous connections that the device will support.
  * Valid values are from 1 to 8
  */
-#define CFG_BLE_NUM_LINK            2
+#define CFG_BLE_NUM_LINK            4
 
 /**
  * Maximum number of Services that can be stored in the GATT database.
@@ -283,7 +283,7 @@
  * other bits: reserved (shall be set to 0)
  */
 /* Z-WB-3 */
-#define CFG_BLE_OPTIONS  (SHCI_C2_BLE_INIT_OPTIONS_LL_ONLY | SHCI_C2_BLE_INIT_OPTIONS_WITH_SVC_CHANGE_DESC | SHCI_C2_BLE_INIT_OPTIONS_DEVICE_NAME_RW | SHCI_C2_BLE_INIT_OPTIONS_NO_EXT_ADV | SHCI_C2_BLE_INIT_OPTIONS_NO_CS_ALGO2 | SHCI_C2_BLE_INIT_OPTIONS_POWER_CLASS_2_3)
+#define CFG_BLE_OPTIONS  (SHCI_C2_BLE_INIT_OPTIONS_LL_ONLY | SHCI_C2_BLE_INIT_OPTIONS_WITH_SVC_CHANGE_DESC | SHCI_C2_BLE_INIT_OPTIONS_DEVICE_NAME_RW | SHCI_C2_BLE_INIT_OPTIONS_EXT_ADV | SHCI_C2_BLE_INIT_OPTIONS_NO_CS_ALGO2 | SHCI_C2_BLE_INIT_OPTIONS_POWER_CLASS_2_3)
 
 #define CFG_BLE_MAX_COC_INITIATOR_NBR   (32)
 
@@ -310,7 +310,7 @@
  * This parameter is considered by the CPU2 when CFG_BLE_OPTIONS has SHCI_C2_BLE_INIT_OPTIONS_EXT_ADV flag set
  */
 
-#define CFG_BLE_MAX_ADV_SET_NBR     (3)
+#define CFG_BLE_MAX_ADV_SET_NBR     (4)
 
  /* Maximum advertising data length (in bytes)
  * Range: 31 .. 1650 with limitation:
@@ -319,7 +319,7 @@
  * This parameter is considered by the CPU2 when CFG_BLE_OPTIONS has SHCI_C2_BLE_INIT_OPTIONS_EXT_ADV flag set
  */
 
-#define CFG_BLE_MAX_ADV_DATA_LEN    (1650)
+#define CFG_BLE_MAX_ADV_DATA_LEN    (1035)
 
  /* RF TX Path Compensation Value (16-bit signed integer). Units: 0.1 dB.
   * Range: -1280 .. 1280

and for ipm

diff --git a/drivers/bluetooth/hci/ipm_stm32wb.c b/drivers/bluetooth/hci/ipm_stm32wb.c
index 8b694af3e2..23be94b43c 100644
--- a/drivers/bluetooth/hci/ipm_stm32wb.c
+++ b/drivers/bluetooth/hci/ipm_stm32wb.c
@@ -100,7 +100,16 @@ static void stm32wb_start_ble(void)
 	    CFG_BLE_HSE_STARTUP_TIME,
 	    CFG_BLE_VITERBI_MODE,
 	    CFG_BLE_OPTIONS,
-	    0 }
+	   	0,
+		CFG_BLE_MAX_COC_INITIATOR_NBR,
+     	CFG_BLE_MIN_TX_POWER,
+     	CFG_BLE_MAX_TX_POWER,
+    	CFG_BLE_RX_MODEL_CONFIG,
+     	CFG_BLE_MAX_ADV_SET_NBR,
+     	CFG_BLE_MAX_ADV_DATA_LEN,
+     	CFG_BLE_TX_PATH_COMPENS,
+     	CFG_BLE_RX_PATH_COMPENS
+		}
 	};
 
 	/**

[erwango]

@piotrParf I'm converting this point to a discussion as the feature isn't available in upstream, so that isn't actually bug but we'll try to follow up on support

[joehatier]

Hello @piotrParf :) !
I have just looked at your problem, did you start from a zephyr sample? Or do you have a custom app?
Are you able to reproduce the problem with the Multiple Broadcaster sample, for example?

[piotrParf]

We are using our specific code. I will check if i can easily reproduce this issue in Multiple Broadcaster.
Also, it would be nice to have in the future the possibility to change parameters during the creation of advertising set - tx power should be possible to do. For myself i did a small patch that works (with stm32wb55 - not checked elsewhere) - but needs to get tx_power from the advertising set and then commit the update function.
I attach the patch I made.

diff --git a/subsys/bluetooth/host/adv.c b/subsys/bluetooth/host/adv.c
index 614220ae5af..db1c88d56c0 100644
--- a/subsys/bluetooth/host/adv.c
+++ b/subsys/bluetooth/host/adv.c
@@ -1151,7 +1151,12 @@ static int le_ext_adv_param_set(struct bt_le_ext_adv *adv,
 	sys_put_le24(param->interval_max, cp->prim_max_interval);
 	cp->prim_channel_map = get_adv_channel_map(param->options);
 	cp->filter_policy = get_filter_policy(param->options);
-	cp->tx_power = BT_HCI_LE_ADV_TX_POWER_NO_PREF;
+	
+	if (((adv->tx_power) >= -127) && ((adv->tx_power) <= 20)) {
+		cp->tx_power = adv->tx_power;
+	} else {
+		cp->tx_power = BT_HCI_LE_ADV_TX_POWER_NO_PREF;
+	}
 
 	adv->options = param->options;
 

And the usecase is something like this(we are using userspace syscalls etc. - so I present simplified code):

err = bt_le_ext_adv_create_um(&adv_param, &ext_adv_cb, &advertiser_data_ptr->ext_adv_set);
((struct bt_le_ext_adv *)(ext_adv_set))->tx_power = power;
bt_le_ext_adv_update_param(adv, param);
and then:
bt_le_ext_adv_start(advertiser_data_ptr->ext_adv_set, &ext_adv_start_param);

[piotrParf]

I got a response from ST engineers that the BT_HCI_LE_ADV_TX_POWER_NO_PREF parameter set in the extended advertising setup will handle the default tx power value set by ACI_HAL_SET_TX_POWER_LEVEL in the upcoming release of radio firmware for STM32WB55

[asm5878]

Hello @piotrParf,
Cleaning up the open discussions... it's fine for you ?

[piotrParf]

Hello,
yes I am fine with closing this discussion and I think it should be fixed in ST radio now.