Persistent ~2 mA Power Draw After BLE → Wi-Fi → BLE Cycle (ESP-IDF v5.3.1) (IDFGH-15222)

[michaelboeding]

Answers checklist.

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

General issue report

Persistent ~2 mA Power Draw After BLE → Wi-Fi → BLE Cycle (ESP-IDF v5.3.1)

Summary

Cycling from an always-on BLE stack to Wi-Fi and back on ESP-IDF v5.3.1 yields an extra ~2 mA of light-sleep current compared to BLE-only operation. Full Wi-Fi teardown via esp_wifi_disconnect(), esp_wifi_stop(), and esp_wifi_deinit() does not recover the expected µA-level sleep current, indicating residual RF coexistence resources remain powered.

Environment

• ESP-IDF version: 5.3.1
• Power measurement tool: Nordic Power Profiler
• ** 32 Khz crystal and DFS and auto light sleep running at 80 MAX / 40 min

Reproduction Steps

1. BLE baseline
   • Enable BLE advertising (no Wi-Fi).
   • Enter light-sleep → record baseline current.
2. Wi-Fi cycle
   • Initialize and connect Wi-Fi:

     esp_wifi_init(&cfg);
     esp_wifi_set_mode(WIFI_MODE_STA);
     esp_wifi_start();
     esp_wifi_connect();

   • Fully tear down Wi-Fi:

     esp_wifi_disconnect();
     esp_wifi_stop();
     esp_wifi_deinit();

3. Return to BLE
   • Continue BLE advertising.
   • Enter light-sleep → observe ~2 mA higher draw.

Expected Behavior

After full Wi-Fi deinitialization, BLE-only light-sleep current should return to the initial baseline (tens to hundreds of µA).

Actual Behavior

A persistent ~2 mA increase in light-sleep current remains after the BLE→Wi-Fi→BLE sequence.

Investigation & Findings

• Heap tracing uncovered ~19 KB of unfreed internal RAM in the RF coexistence adapter (esp_coex_adapter), allocated on Wi-Fi init and never freed by public APIs.
• Coexistence subsystem lacks a public deinit call; buffers remain resident even after esp_wifi_deinit().
• Bluetooth always on means coexistence arbitration remains active, preventing full power-down of RF resources.

[boarchuz]

Possibly ADC is still powered up. As a diagnostic step, do you see any change if you call sar_periph_ctrl_power_disable() immediately before sleep?

esp-idf/components/esp_hw_support/port/esp32/sar_periph_ctrl.c

Line 42 in 38628f9

void sar_periph_ctrl_power_disable(void)

[michaelboeding]

Thanks for the suggestion — I went ahead and tried calling sar_periph_ctrl_power_disable() after tearing down Wi-Fi and switching back to BLE.

It seems to help a bit — the current draw is now fluctuating and might be slightly lower overall. That said, I'm still seeing a floor of about 0.00068 A on the USB power monitor. Before Wi-Fi was ever brought up, the device would occasionally dip to 0.00000 A, which doesn't happen anymore.

For the most part, the device now sits between 0.00150 A and 0.00200 A, even with Wi-Fi fully deinitialized and BLE running. So while it's maybe a partial improvement, there's still something lingering that's preventing us from hitting the lowest power state we saw earlier.

[michaelboeding]

Also here's a video of both cases

BLE Only Enabled

trim.C8C0C4EC-F560-4708-9A1F-81B8840C9BEF.MOV

After WIFI connected and switched back to BLE (which remained running)

trim.CE6F9FCC-94C8-4931-8679-2FB697C273D8.MOV

[esp-lis]

@michaelboeding Can you tell me which chip model you're using? I need it to reproduce the issue locally. thank you!

[michaelboeding]

Hey @esp-lis I am using an ESP32-S3

[esp-lis]

@michaelboeding I tried to reproduce it locally, but everything seems fine.