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