ESP32C6 - BLE Power Save Connection Issue/Concurrent Tasks (IDFGH-13913)

rac146 commented 1 month ago

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3.1

Espressif SoC revision.

ESP32C6

Operating System used.

macOS

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

Seeed XIAO ESP32C6

Power Supply used.

USB

What is the expected behavior?

When using BLE power save with an external crystal, allow successful connection while running CPU tasks.

What is the actual behavior?

When using BLE power save with an external crystal, BLE will not connect successfully while running CPU tasks.

Steps to reproduce.

The easiest way to reproduce this issue is to run the BLE Power Save Example

Just set a while loop at the bottom of the example in main to simulate work:

while(true) {
        MODLOG_DFLT(INFO, "Running...");
 }

BLE will consistently fail to connect.

OR

If you build with CONFIG_PM_TRACE=y AND set light_sleep_enable = false in the PM config; then try to connect to BLE it will consistently fail to connect.

More Information.

I originally noticed this when trying to write to an OLED display - my BLE would disconnect immediately when the display was written to. Then I realized a similar behavior with CONFIG_PM_TRACE=y. It seems certain CPU operations will cause the BLE to disconnect with a 520 error when the power save configuration settings are used.

External crystal is running correctly.

If I disable switch from CONFIG_BT_LE_LP_CLK_SRC_DEFAULT=y back to CONFIG_BT_LE_LP_CLK_SRC_MAIN_XTAL=y it will connect successfully.

Does anyone know why this is happening when using the external 32 Khz crystal?

zhaoweiliang2021 commented 1 month ago

@rac146 Hi rac146, from your description, it seems that BLE connection will fail to establish if device does not enter light sleep mode. However, I didn't manage to reproduce the issue using the ESP32-C6-DevKitM-1 chip and external 32kHz xtal. There's are some aspects you can look into:

Is there another task present with higher priority that can suspend the BT controller task for as long as the supervision timeout? The BT controller task priority is set to ESP_TASK_BT_CONTROLLER_PRIO in default.
In the content of initialization log, do you find a log like this: BLE_INIT: Using external 32.768 kHz XTAL as clock source? This shows that Bluetooth is using the external XTAL as its clock source, for ESP32C6, using any clock source other than main xtal and external 32.768 kHz xtal will not be able to establish or maintain the BLE connection.
Another possible reason is that your external 32.768kHz XTAL clock accuracy does not meet expectation, maybe you can check if the clock accuracy is below 500 PPM, if so, try to change the CONFIG_BT_LE_LL_SCA config to a higher value, and see if the issue persists.

rac146 commented 1 month ago

BLE connection will establish, it just doesn't hold the connection correctly. After a brief amount of work out of light sleep mode, the BLE connection will drop with a 520 disconnect error.

In the power save example, I added the work simulation in the main thread. I have also tried to spawn FreeRTOS tasks with lower priorities than ESP_TASK_BT_CONTROLLER_PRIO and still experience the issue.
Yes - I can see the crystal calibrating upon startup (I have 5000 calibration cycles set). I also see BLE using the 32.768 Khz clock source:
This is possible - I'm using a cheap crystal I found on Amazon - I did have this briefly hooked up to a scope and saw the frequency output around 32.768 Khz, but the numbers were varying slightly. Unfortunately I tried setting CONFIG_BT_LE_LL_SCA to 500, but still experience the issue.

Looking a little further into it, I switched CONFIG_RTC_CLK_CAL_CYCLES from 5000 to 8000 but that didn't help either.

zhaoweiliang2021 commented 4 weeks ago

@rac146 Hi rac146,

From your response, It's possible that the frequency drift of your crystal is too large to maintain a connection given that same issue will not happen with main XTAL as clock source. Please measure the your crystal's accuracy and check this point.

espressif / esp-idf