BluetoothSerial / esp_bt_mem_release / memory consumption in arduino api

[ferbar]

Related area

BT, BluetoothSerial

Hardware specification

any

Is your feature request related to a problem?

Using BluetoothSerial is taking about 140kB ram of the ESP32. That could be reduced by recompiling the arduino esp idf with a reduced set of options or by using esp_bt_mem_release(BTLE) for example if bluetooth LE isn't required. Since recompiling takes a lot of time I would suggest some options in the ESP32 arduino sdk.

Describe the solution you'd like

When btInUse() is returning true about 70kB ram are in use since boot. When btStart() is called additional 70kB are required. If BluetoothSerial is used, I don't think that BTLE will be used in general, so I suggest an option to BluetoothSerial or BluetoothSerial::begin to disable BTLE and BluetoothSerial::end to disable BT in general (and call esp_bt_mem_release())

a) btStart() has to be changed because of
esp_bt_controller_config_t cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
.mode = ESP_BT_MODE_CLASSIC_BT,

b) esp_bt_mem_release() has to be called before esp_bt_controller_init() and after BluetoothSerial::end()

I already have those modifications and would file a PR when #6380 is merged.
@me-no-dev: what do you think about

• add a btStartMode(BT_classic / BTLE / DM) -> releases BTLE or BT_classic ram if not used
• add a btStop_memrelease() -> which frees every BT ram
• Is there any reason why esp32-hal-bt.c is a .c, not .cpp file (I'm asking because overloading those functions would be more convinient)
• everything could be done in BluetoothSerial.cpp, however I think esp32-hal-bt.h: btStart() / btStop is be the right place.

Thanks!

Describe alternatives you've considered

No response

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[antoinnneee]

I have the same issue. I need ~50Ko more memory for my project, and I'm lock due to bluetooth ram usage. I'm not using BLE in project.

For you're question : "Is there any reason why esp32-hal-bt.c is a .c, not .cpp file (I'm asking because overloading those functions would be more convinient)"
All the esp32 frameworks is built with C. And it's a better to keep C for performance and ram usage.
Almost all uC use C instead of C++. From my experience, Cpp in uC is rare. I just have 2 or 3 ref that use cpp against a ton of other that work with C. In addition, I much prefer C programming for embedded programs. I write code much faster. But that's just an opinion

Another possible optimization. Is to let the user choose what to use in the Bluetooth lib. For example, I only need Bluetooth spp, but bluedroid has Bluetooth HID, A2DP, HFP, ...

[VojtechBartoska]

@ferbar Thaks for contribution and your PR, let's wait till your proposed PR is reviewed.

[VojtechBartoska]

PR was merged.

Edit: I just closed it but I now see it was something else. So the question is, are there any updates on this?

[ferbar]

@VojtechBartoska: Yes, this is still open, do you have any ideas / wishes how to implement disabling BTLE if it is not needed to save some kB ram?
Maybe also disable HID, A2DP, HFP if it is not needed?

Thanks

[garageeks]

Hi to all,
I started using BT for an A2DP application, and was surprised to see how much heap memory is gone.
It appears to impossible to run BT and Wi-Fi concurrently, despite the excellent coexistence mode, because it runs out of heap memory quickly.
I have 230KB of free heap, once I add BT references it goes down to 167KB.
When I start BT, heap goes down to 58520 bytes.
When BT client is connected it drops further to 41508 bytes, and when playing audio stream it fluctuates between 34168 - 35704 bytes. Some web requests are processed despite the low available memory.
As soon as I disconnect the BT client and reconnect, then start playing an audio stream, it crashes always at the same function.

PC: 0x401290d7: reassemble_and_dispatch at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/host/bluedroid/hci/packet_fragmenter.c line 174
EXCVADDR: 0x00000002

Decoding stack results
0x401290d4: reassemble_and_dispatch at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/host/bluedroid/hci/packet_fragmenter.c line 174
0x401284ad: hal_says_packet_ready at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/host/bluedroid/hci/hci_layer.c line 415
0x40151385: hci_upstream_data_handler at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/host/bluedroid/hci/hci_hal_h4.c line 466
0x40143605: osi_thread_generic_event_handler at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/common/osi/thread.c line 425
0x4014359b: osi_thread_run at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/bt/common/osi/thread.c line 165

Interestingly, reassemble_and_dispatch function doesn't have a buffer overflow check in the 2014 Bluedroid version used by ESP-IDF.
Old version used by ESP-IDF: https://github.com/espressif/esp-idf/blob/1cb31e50943bb757966ca91ed7f4852692a5b0ed/components/bt/host/bluedroid/hci/packet_fragmenter.c

This appears to be a newer version: https://android.googlesource.com/platform/system/bt/+/ea7ab70a711e642653dd5922b83aa04a53af9e0e/hci/src/packet_fragmenter.cc

It appears to be significantly rewritten and with a comment "
// Check for buffer overflow and that the full packet size + BT_HDR size
// is less than the max buffer size"

Anyway the ability to choose between BT Classic OR BLE would already solve many issues.
Alternatively, could anyone provide instructions on how to compile a custom libbt.a through lib-builder?

Many thanks,
Nick

[ferbar]

With the patch above it is possible to save stunning 14kB free ram when BLE is not used. Unfortunately it seems that the current master takes 10kb more ram .....

-DCONFIG_BTDM_CONTROLLER_MODE_BR_EDR_ONLY=y
has to be defined in platformio.ini or changed in sdkconfig

[ferbar]

Related: espressif/esp32-arduino-lib-builder#108

[SimonPVS]

Hi @garageeks,

I have the same error as you have. (failing in the packet_fragmenter.c)
How did you solve this error?

Any help would be much appreciated, thanks!

[garageeks]

@SimonPVS sorry for late reply. I simply gave up sending web requests while using Bluetooth A2DP.
Web requests want at least 50KB free RAM to work reliably.
I'm still using 2.0.4 though, maybe the behaviour has been improved in later versions

[garageeks]

@VojtechBartoska I saw lots of changes with new 3.0.0 version, did you add a flag to disable BTLE and leave BT classic (or viceversa)?
This would enable BT and Wi-Fi transmission, which would otherwise RAM starved and crash.

According to @ferbar , it is a matter of
_Add the following lines to configs/defconfig.esp32

CONFIG_BTDM_CTRL_MODE_BR_EDR_ONLY=y
CONFIG_BT_HFP_ENABLE=n
CONFIG_BT_BLE_ENABLED=n
CONFIG_BT_MULTI_CONNECTION_ENBALE=n
CONFIG_BLE_MESH=n
and rebuild the esp32-arduino libraries. This will save some 300kB flash and 50kB ram_

Thank you

[Parsaabasi]

Hello,

Due to the overwhelming volume of issues currently being addressed, we have decided to close the previously received tickets. If you still require assistance or if the issue persists, please don't hesitate to reopen the ticket.

Thanks.