[feature] Free a little memory used by bluetooth if wifi is enabled or bluetooth is disabled#10398
Merged
thebentern merged 9 commits intoJun 25, 2026
Conversation
Release ESP-IDF BTDM memory after config load when Bluetooth is disabled or WiFi is enabled, recovering heap on ESP32 targets where BLE won’t be used for this boot.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces an ESP32-only runtime SRAM optimization by releasing ESP-IDF Bluetooth (BTDM) memory early in boot when Bluetooth will not be used, aiming to improve heap availability on constrained targets (notably ESP32-S3 without PSRAM).
Changes:
- Add
esp32ReleaseBluetoothMemoryIfUnused()and callesp_bt_mem_release(ESP_BT_MODE_BTDM)before NimBLE initialization when Bluetooth is disabled and/or WiFi is enabled. - Prevent attempts to re-enable Bluetooth in the same boot after Bluetooth memory has been released (warn + require reboot).
- Invoke the release path both after config load (boot) and after runtime Bluetooth deinit via admin flows.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/platform/esp32/main-esp32.cpp | Adds BT memory release logic + re-enable guard and logging. |
| src/main.cpp | Calls BT memory release right after NodeDB loads config, before NimBLE setup. |
| src/modules/AdminModule.cpp | Releases BT memory after ESP32 Bluetooth deinit in disableBluetooth(). |
| src/main.h | Updates ESP32 NimBLE include guard and adds esp32ReleaseBluetoothMemoryIfUnused() declaration. |
Contributor
Author
|
These bytes are hard fought for these days. |
fifieldt
approved these changes
May 29, 2026
…32-runtime-bt-memory-release
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ESP32 SRAM Memory Savings by Releasing Bluetooth Memory.
Scope
Testing focused on Heltec V3 / ESP32-S3 targets without PSRAM. The goal for this branch is runtime SRAM savings with the same firmware image: if Bluetooth will not be active for this boot, release the ESP-IDF Bluetooth memory pool.
Clanker warning
This was developed with the help of Codex 5.5, but reviewed and tested by a fallible human.
Runtime change in this branch
After
NodeDBloads config, but before NimBLE is initialized, ESP32 firmware now callsesp_bt_mem_release(ESP_BT_MODE_BTDM)when either:config.bluetooth.enabled == falseconfig.network.wifi_enabled == trueThe WiFi case is included because ESP32 Bluetooth is not started when WiFi is enabled for the boot. Releasing
ESP_BT_MODE_BTDMis intentionally irreversible until reboot, which matches the existing runtime behavior where re-enabling Bluetooth already requires a reboot.ESP_BT_MODE_BTDMis the ESP-IDF "all Bluetooth" release mode. Meshtastic uses BLE, but this mode returns the whole Bluetooth controller/host memory pool that ESP-IDF allows to be released for the rest of the boot.The release path logs the measured heap delta. The first line below is from the Bluetooth-disabled test; the WiFi-enabled path uses
the same release call and is expected to have the same size profile.
The exact log reason depends on the config state. The WiFi-enabled path uses the same release API and timing, so it is expected to recover the same amount of memory as the Bluetooth-disabled path.
Runtime measurements
Measurements were taken from Heltec V3 boot logs during this investigation.
heap +1652,free +1580bytes afteresp_bt_mem_release(ESP_BT_MODE_BTDM)heap +1652,free +1580bytesMoving the release earlier than config load did not increase savings. The useful point is after config is loaded and before NimBLE setup.
Compile-time comparison
A separate no-Bluetooth firmware saves much more memory, but it is a different firmware image and cannot re-enable Bluetooth without rebuilding/flashing. That experiment disabled Bluetooth and the BLE-dependent paxcounter code:
MESHTASTIC_EXCLUDE_BLUETOOTH=1HAS_BLUETOOTH=0src/nimble/NimBLE-ArduinoMESHTASTIC_EXCLUDE_PAXCOUNTER=1libpaxCONFIG_BT_NIMBLE_ENABLEDandLIBPAX_BLE-15812RAM,-195012flashBoot-log heap impact was larger than the static RAM report:
+30720+34184PowerFSMfree heap+34180+94140free bytes compared with normal after NimBLE initOther module reductions explored
These are not part of this branch, but were useful for sizing possible SRAM reductions:
MESHTASTIC_EXCLUDE_WIFI,MESHTASTIC_EXCLUDE_WEBSERVER, andMESHTASTIC_EXCLUDE_MQTT, but removing those paths requires additional OTA/admin dependency cleanup. For this branch, WiFi enabled at runtime now triggers BTDM release because WiFi already prevents Bluetooth from starting.118228static RAM bytes and1711349flash bytes, but that was a broad feature cut and is not committed here.Interpretation
Runtime
esp_bt_mem_release(ESP_BT_MODE_BTDM)saves about 1.5 KiB of free heap in the same firmware image. That is small, but it is available whenever Bluetooth will not be active for the boot, including the WiFi-enabled case.Compile-time Bluetooth removal is the larger SRAM win: roughly 15.8 KiB static RAM, roughly 34 KiB boot free heap, and roughly 92 KiB free heap compared with a normal build after NimBLE initialization. The cost is a separate no-Bluetooth firmware image.
🤝 Attestations
Heltec V4