Page 1 of 2
Memory consumption of bluetooth is enormous
Posted: Mon Sep 25, 2017 9:01 pm
by jumjum123
Startet to add BLE support to an application.
Memory consumption in RAM(>64K) and in Flash(>500k) is enormous.
Size of Flash raised from 800kb to more than 1300kb only by adding a simple BLE_UART
Today this looks like being a showstopper for using BLE in my application.
Re: Memory consumption of bluetooth is enormous
Posted: Mon Sep 25, 2017 11:13 pm
by ESP_Angus
It is possible to release some of the RAM used by the Bluetooth stack if running with BLE only.
In IDF v2.1, this is done by setting "Release DRAM from Classic BT controller" under Component Config -> Bluetooth -> Bluedroid Bluetooth Stack.
In current master & IDF v3.0, this is done via esp_bt_controller_mem_release() function call:
https://esp-idf.readthedocs.io/en/lates ... _bt_mode_t
Re: Memory consumption of bluetooth is enormous
Posted: Tue Sep 26, 2017 3:14 am
by Lucas.Hutchinson
What is your log print level set to?
If it is set to verbose, you will find the bin size to be quite large. If you set this to info, warning or error, you will likely find the size will drop.
Also check the following options in your menuconfig:
- "Component config-> Bluetooth-> Bluedorid Bluetooth stack enabled-> Bluedriod memory debug" Set to disabled
- "Component config-> Bluetooth-> Bluedorid Bluetooth stack enabled->Close the bluedroid bt stack log print" Set to enabled
- "Component config-> Bluetooth-> Bluedorid Bluetooth stack enabled-> Classic Bluetooth" Set to disabled (if you are not suing classic bluetooth)
- "Component config-> Bluetooth-> Bluedorid Bluetooth stack enabled-> Include BLE Security module (SMP)" Set to disabled (only if you do not intend to use SMP)
Re: Memory consumption of bluetooth is enormous
Posted: Tue Sep 26, 2017 9:20 am
by BuddyCasino
Not sure I understood the documentation, is BT memory now completely dynamic? Is it possible to re-enable BT again after calling
Code: Select all
esp_bt_controller_mem_release(ESP_BT_MODE_BTDM)
, or is that a one-off thing where BT will be unavailable forever after?
Re: Memory consumption of bluetooth is enormous
Posted: Tue Sep 26, 2017 9:32 am
by ESP_igrr
It is not fully dynamic. The act of releasing BT memory adds this memory as new region(s) to the heap allocator. Once that is done, we can assume that some code can call 'malloc' and get a pointer allocated in that region of memory. Since there is no way of reversing this (unless one is using a VM with a moving garbage collector) we can never use this released region for BT again.
This change was mainly done to satisfy requirements of environments such as micropython and Arduino, which need to postpone the decision of enabling BT until runtime.
Re: Memory consumption of bluetooth is enormous
Posted: Tue Sep 26, 2017 10:50 am
by jumjum123
Thanks a lot for the feedback
@ESP_ANGUS this was the first I had to do, even to get an empty BLE, without any GAP/GATT starting.
Size of free heap during startup is less than after start. This made it impossible to start without this change.
@Lucas started to check your recommendations
Log Level and Classic Bluetooth have already been changed in my tests.
SInce a lot of changes have been done during testing, I prefer to start from zero again.
Therefore it will take some time before I can give feedback
BTW setting Compiler options --> Optimization level to Release also saves some bytes
Re: Memory consumption of bluetooth is enormous
Posted: Tue Oct 24, 2017 3:38 am
by chegewara
I would like to use it to recover some heap but this code:
Code: Select all
int app_main(void) {
// ESP_ERROR_CHECK( heap_trace_init_standalone(trace_record, NUM_RECORDS) );
esp_bt_controller_enable(ESP_BT_MODE_BLE);
esp_bt_controller_mem_release(ESP_BT_MODE_BTDM);
task_webserver(nullptr);
return 0;
}
causes this panic:
Code: Select all
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:4456
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:11756
entry 0x40078ce4
I (241) cpu_start: Pro cpu up.
I (241) cpu_start: Starting app cpu, entry point is 0x40080fc4
0x40080fc4: call_start_cpu1 at /home/esp32/esp/esp-idf/components/esp32/./cpu_start.c:220
I (0) cpu_start: App cpu up.
I (244) heap_init: Initializing. RAM available for dynamic allocation:
D (251) heap_init: New heap initialised at 0x3ffaff10
I (256) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
D (262) heap_init: New heap initialised at 0x3ffcc320
I (267) heap_init: At 3FFCC320 len 00013CE0 (79 KiB): DRAM
I (273) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (280) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
D (287) heap_init: New heap initialised at 0x40093f90
I (291) heap_init: At 40093F90 len 0000C070 (48 KiB): IRAM
I (297) cpu_start: Pro cpu start user code
D (309) clk: RTC_SLOW_CLK calibration value: 3228570
V (20) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (20) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (26) intr_alloc: Connected src 46 to int 2 (cpu 0)
V (31) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (37) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xC0E
D (45) intr_alloc: Connected src 57 to int 3 (cpu 0)
V (50) esp_pthread: pthread_once: call init_routine 0x3ffc1cd0
V (56) esp_pthread: pthread_once: call init_routine 0x3ffc1cc8
V (65) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (68) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (76) intr_alloc: Connected src 16 to int 9 (cpu 0)
V (81) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (87) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x40E
D (95) intr_alloc: Connected src 24 to int 12 (cpu 0)
I (101) cpu_start: Starting scheduler on PRO CPU.
V (0) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): checking args
V (5) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): Args okay. Resulting flags 0x40E
D (14) intr_alloc: Connected src 25 to int 2 (cpu 1)
I (18) cpu_start: Starting scheduler on APP CPU.
D (154) heap_init: New heap initialised at 0x3ffe0440
D (159) heap_init: New heap initialised at 0x3ffe4350
D (164) BTDM_INIT: Release DRAM [0x3ffae6e0] - [0x3ffaff10]
ESP_ERROR_CHECK failed: esp_err_t 0xffffffff at 0x4013ba55
0x4013ba55: esp_bt_controller_mem_release at /home/esp32/esp/esp-idf/components/bt/./bt.c:472
file: "/home/esp32/esp/esp-idf/components/bt/./bt.c" line 408
func: esp_bt_controller_mem_release
expression: heap_caps_add_region(mem_start, mem_end)
Backtrace: 0x4008adb8:0x3ffd46d0 0x4008b131:0x3ffd46f0 0x4013ba55:0x3ffd4710 0x401065e0:0x3ffd4740 0x400d1183:0x3ffd4760
0x4008adb8: invoke_abort at /home/esp32/esp/esp-idf/components/esp32/./panic.c:553
0x4008b131: _esp_error_check_failed at /home/esp32/esp/esp-idf/components/esp32/./panic.c:565
0x4013ba55: esp_bt_controller_mem_release at /home/esp32/esp/esp-idf/components/bt/./bt.c:472
0x401065e0: app_main at /home/esp32/ESP32_Explorer/main/./main.cpp:71
0x400d1183: main_task at /home/esp32/esp/esp-idf/components/esp32/./cpu_start.c:406
Re: Memory consumption of bluetooth is enormous
Posted: Tue Oct 31, 2017 6:34 pm
by chegewara
Code: Select all
esp_bt_controller_enable(ESP_BT_MODE_BLE);
esp_bt_controller_mem_release(ESP_BT_MODE_BTDM);
I can confirm it is working and release about 30kB RAM with one issue. esp_bt_controller_mem_release cant be used before initializing and enabling BT:
Code: Select all
esp_bt_controller_init(&bt_cfg)
esp_bt_controller_enable(ESP_BT_MODE_BLE)
Re: Memory consumption of bluetooth is enormous
Posted: Wed Nov 01, 2017 9:49 am
by jumjum123
Just tested mem release and got additional 30k heap
Re: Memory consumption of bluetooth is enormous
Posted: Thu Nov 02, 2017 6:39 am
by chegewara
My observations how to free RAM:
- if you are using wifi then in menuconfig->wifi start with the lowest settings, it gives another 30-ish kB (by default settings are setup very high)
- if you dont use SSL menuconfig->mbedTLS->TLS maximum message content length is set to 16kB, why? set it to lowest possible, another 15kB
- trick with BT about 30kB.
Looks nice? Works great