[BLE][IDF v5.3.x/5.4.0] Unable to Keep Periodic Advertising Running After Stopping Extended Advertising / Cannot Set Large Extended Adv Intervals (IDFGH-14466) #15240
Comments
github-actions
bot
changed the title
espressif-bot
added
Status: In Progress
|
Hi @iamcalledusman , thanks for you feedback! We noticed that you mentioned two issues:
The first one is a known issue and we're fixing it, the fix would be merged to IDF as soon as possible. :) For the second one, we tried to reproduce the issue locally with ESP32C6 on release/v5.3 and release/v5.4. In our modification to https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedroid/ble_50/periodic_adv, we called Related codes (on release/v5.4): void app_main(void)
{
...
// create static random address
esp_bd_addr_t rand_addr;
esp_ble_gap_addr_create_static(rand_addr);
test_sem = xSemaphoreCreateBinary();
// 2M phy extend adv, Non-Connectable and Non-Scannable Undirected advertising
ESP_LOG_BUFFER_HEX(LOG_TAG, rand_addr, ESP_BD_ADDR_LEN);
FUNC_SEND_WAIT_SEM(esp_ble_gap_ext_adv_set_params(EXT_ADV_HANDLE, &ext_adv_params_2M), test_sem);
FUNC_SEND_WAIT_SEM(esp_ble_gap_ext_adv_set_rand_addr(EXT_ADV_HANDLE, rand_addr), test_sem);
FUNC_SEND_WAIT_SEM(esp_ble_gap_config_ext_adv_data_raw(EXT_ADV_HANDLE, sizeof(raw_ext_adv_data_2m), &raw_ext_adv_data_2m[0]), test_sem);
// start all adv
FUNC_SEND_WAIT_SEM(esp_ble_gap_ext_adv_start(NUM_EXT_ADV, &ext_adv[0]), test_sem);
// set periodic adv param
FUNC_SEND_WAIT_SEM(esp_ble_gap_periodic_adv_set_params(EXT_ADV_HANDLE, &periodic_adv_params), test_sem);
#if (CONFIG_BT_BLE_FEAT_PERIODIC_ADV_ENH)
// set periodic adv raw data
FUNC_SEND_WAIT_SEM(esp_ble_gap_config_periodic_adv_data_raw(EXT_ADV_HANDLE, sizeof(periodic_adv_raw_data), &periodic_adv_raw_data[0], false), test_sem);
// start periodic adv, include the ADI field in AUX_SYNC_IND PDUs
FUNC_SEND_WAIT_SEM(esp_ble_gap_periodic_adv_start(EXT_ADV_HANDLE, true), test_sem);
while (1) {
vTaskDelay(2000 / portTICK_PERIOD_MS);
// just update the Advertising DID of the periodic advertising, unchanged data
FUNC_SEND_WAIT_SEM(esp_ble_gap_config_periodic_adv_data_raw(EXT_ADV_HANDLE, 0, NULL, true), test_sem);
}
#else
// set periodic adv raw data
FUNC_SEND_WAIT_SEM(esp_ble_gap_config_periodic_adv_data_raw(EXT_ADV_HANDLE, sizeof(periodic_adv_raw_data), &periodic_adv_raw_data[0]), test_sem);
FUNC_SEND_WAIT_SEM(esp_ble_gap_periodic_adv_start(EXT_ADV_HANDLE), test_sem);
#endif
// Stop extended advertising right after starting periodic advertising
FUNC_SEND_WAIT_SEM(esp_ble_gap_ext_adv_stop(NUM_EXT_ADV, &ext_adv[0].instance), test_sem);
return;
}Related logs: Checking your log, we found that periodic advertising didn't even start, could you please share your codes so we can help you debug the issue? PS: We noticed that you tried to stop extended advertising by calling We hope it would help. Looking forward to your reply. |
|
Hi @ZhouXiao616! Thank you so much for your time and assistance!
Periodic Advertisement LOG FILE Periodic Sync LOG FILE I attached both the project periodic_adv as well as the periodic_sync I enabled the following but still got the same response after disabling it. I noticed the same response, after calling esp_ble_gap_ext_adv_stop(NUM_EXT_ADV, &ext_adv[0].instance); both the periodic and ext adv pdu stopped. Thank you again for your response! Looking forward to your reply. |
|
Hi @ZhouXiao616! Thank you so much for your time and assistance! After a small change , now periodic adv is working fine Added the delay and stop the function Again thank You! |
Hello Espressif Team,
I am facing an issue with Extended Advertising and Periodic Advertising in ESP-IDF, specifically:
Stopping Extended Advertising Also Stops Periodic Advertising
According to the Bluetooth 5.0 spec, it should be possible to continue periodic advertising even after stopping extended advertising on the same handle. However, in my testing with ESP-IDF, once I call esp_ble_gap_ext_adv_stop(...), the periodic advertising also stops.
Large Extended Advertising Intervals Appear Clamped at ~40 s
When I set .interval_min and .interval_max to larger 24-bit values (e.g., 0x1FFFF for ~81 s), I still observe an actual advertising interval closer to 40 s. This suggests the controller might be falling back to the 16-bit legacy limit, even though I am using a non-legacy extended advertising property (NONCONN_NONSCANNABLE_UNDIRECTED).
My requirement is to have a short burst of extended advertising to establish periodic sync, and then either:
Stop extended advertising entirely while keeping periodic advertising on the same handle, or
Use a truly large extended advertising interval (e.g., ~81 s or more, up to the 24-bit limit of ~2.9 hours) to minimize power consumption.
However, neither approach seems possible in practice with the current ESP-IDF
Environment
Module or Chip: ESP32-C6
ESP-IDF Version: v5.3.2/v5.4.0(tried both)
Compiler: riscv32-esp-elf-gcc
Operating System: Windows
Power Supply: USB
Example code : https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedroid/ble_50/periodic_adv
LOG FILE :
Observed Behavior
Stopping Extended Advertising
esp_ble_gap_ext_adv_stop(1, &ext_adv[EXT_ADV_HANDLE]);
This also kills periodic advertising on the same handle. The logs confirm both advertisements stop.
Large Interval Clamped
If I do not stop extended advertising, I set .interval_min = 0x1FFFF (aiming for ~81 s). In practice, using a BLE sniffer or a scanning device, I see the device advertising at ~40 s intervals, indicating a fallback to the legacy 16-bit maximum.
Expected Behavior
According to the BLE Specification: We can keep periodic advertising running even if we stop sending extended advertising PDUs, or we can set an extended interval up to 0xFFFFFF (~2.9 hours) for truly extended advertising.
In either case, we would see either zero extended adv overhead (only periodic PDUs) or a very infrequent extended adv interval.
Question / Request
Is this a known limitation or bug in the ESP-IDF BLE controller stack?
Are there workarounds to achieve “periodic only” without extended PDUs or to set the interval larger than ~40 s?
Is there any plan to support stopping extended advertising while keeping periodic advertising active on the same handle, in line with the BLE spec?
Any guidance or solutions would be greatly appreciated.
Wireshark Logs
You can see that I set the interval of 0x1FFFF but getting PDU almost every 41 seconds, Tried with coded phy as well but still the same behavior.
Thank you!
The text was updated successfully, but these errors were encountered: