This is a continuation of the following ticket: Softdevice Controller: TX with 100% duty cycle scanning in v2.3
The resolution was logged as DRGN-19197, which was part of v2.4.0, but did not resolved the issue.
I have created a minimal reproduction based on the `zephyr/samples/bluetooth/scan_adv with the nRF52840DK.
The only additional Kconfig required is `CONFIG_BT_EXT_ADV=y`.
This reproduction starts scanning with 100% uptime and once a second attempts to create an Advertising set.
/* main.c - Application main entry point */
/*
* Copyright (c) 2015-2016 Intel Corporation
*
* SPDX-License-Identifier: Apache-2.0
*/
#include <zephyr/types.h>
#include <stddef.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/util.h>
#include <zephyr/bluetooth/bluetooth.h>
static uint8_t mfg_data[] = { 0xff, 0xff, 0x00 };
static const struct bt_data ad[] = {
BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 3),
};
static void scan_cb(const bt_addr_le_t *addr, int8_t rssi, uint8_t adv_type,
struct net_buf_simple *buf)
{
mfg_data[2]++;
}
static void adv_set_complete(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_sent_info *info)
{
printk("Advertising set complete after %d events\n", info->num_sent);
(void)bt_le_ext_adv_delete(adv);
}
static const struct bt_le_ext_adv_cb adv_cb = {
.sent = adv_set_complete,
};
static struct bt_le_ext_adv_start_param adv_start_param = {
.timeout = 0,
.num_events = 1,
};
int main(void)
{
struct bt_le_scan_param scan_param = {
.type = BT_LE_SCAN_TYPE_PASSIVE,
.options = BT_LE_SCAN_OPT_NONE,
.interval = 0x0010,
.window = 0x0010,
};
struct bt_le_adv_param adv_param = {
.id = BT_ID_DEFAULT,
.sid = 0U,
.secondary_max_skip = 0U,
.options = BT_LE_ADV_OPT_USE_IDENTITY | BT_LE_ADV_OPT_EXT_ADV,
.interval_min = BT_GAP_ADV_FAST_INT_MIN_1,
.interval_max = BT_GAP_ADV_FAST_INT_MAX_1,
.peer = NULL,
};
struct bt_le_ext_adv *adv;
int err;
printk("Starting Scanner/Advertiser Demo\n");
/* Initialize the Bluetooth Subsystem */
err = bt_enable(NULL);
if (err) {
printk("Bluetooth init failed (err %d)\n", err);
return 0;
}
printk("Bluetooth initialized\n");
err = bt_le_scan_start(&scan_param, scan_cb);
if (err) {
printk("Starting scanning failed (err %d)\n", err);
return 0;
}
do {
k_sleep(K_MSEC(1000));
/* Create advertising set */
err = bt_le_ext_adv_create(&adv_param, &adv_cb, &adv);
if (err < 0) {
printk("Failed to create advertising set (%d)\n", err);
continue;
}
/* Set extended advertising data */
err = bt_le_ext_adv_set_data(adv, ad, ARRAY_SIZE(ad), NULL, 0);
if (err != 0) {
printk("Failed to set advertising data (%d)\n", err);
(void)bt_le_ext_adv_delete(adv);
continue;
}
err = bt_le_ext_adv_start(adv, &adv_start_param);
if (err != 0) {
printk("Failed to start advertising set (%d)\n", err);
(void)bt_le_ext_adv_delete(adv);
continue;
}
printk("Advertising started...\n");
} while (1);
return 0;
}
When compiled as provided, the Bluetooth stack reports everything operating correctly, but Wireshark with the nRF Sniffer displays no packets.
*** Booting nRF Connect SDK v2.7.0-rc3-d5cd2f445522 ***
*** Using Zephyr OS v3.6.99-3e80418dd59f ***
Starting Scanner/Advertiser Demo
[00:00:00.000,488] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:
d6 da c7 ae 08 db 72 6f 2a a3 26 49 2a 4d a8 b3 |......ro *.&I*M..
98 0e 07 7f |....
[00:00:00.002,410] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.002,441] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.002,471] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 214.51162 Build 1926957230
[00:00:00.003,234] <inf> bt_hci_core: Identity: D9:0F:0E:72:66:EA (random)
[00:00:00.003,265] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x11fb, manufacturer 0x0059
[00:00:00.003,295] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x11fb
Bluetooth initialized
Advertising started...
Advertising set complete after 1 events
Advertising started...
Advertising set complete after 1 events
Advertising started...
Advertising set complete after 1 events
Changing the scan interval to be `0x0F` instead of `0x10` (95% scan duty cycle) restores the expected functionality and TX packets can be observed with Wireshark.
I am therefore confident that while the softdevice is reporting success under the 100% duty cycle case, no packets are actually being transmitted.
This appears to be a different failure mode to DRGN-19197 as the data payload is never changing length.
nRF Connect SDK: v2.7.0-rc3-d5cd2f445522
Softdevice: Version 214.51162 Build 1926957230
