With our default menuconfig (plus memory debugging enabled), I get: I (0) cpu_start: App cpu up. I (2206) heap_alloc_caps: Initializing. RAM available for dynamic allocation: I (2229) heap_alloc_caps: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (2249) heap_alloc_caps: At 3FFCA290 len 00015D70 (87 KiB): DRAM I (2270) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (2291) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2313) heap_alloc_caps: At 400955AC len 0000AA54 (42 KiB): IRAM OVMS > module memory ============================ Free 8-bit 77696/218088, 32-bit 18608/43580, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 20192 24444 0 change= +20192 +24444 +0 task=mai total= 9488 26948 0 change= +9488 +26948 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41440 0 0 change= +41440 +0 +0 If I turn off bluetooth in menuconfig, I get: OVMS > module memory ============================ Free 8-bit 150548/290912, 32-bit 18628/43600, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 44592 0 0 change= +44592 +0 +0 task=mai total= 36436 0 0 change= +36436 +0 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41468 0 0 change= +41468 +0 +0 72KB RAM seems a bit ridiculous for a bluetooth stack. I really hope this is not Espressif loading those binary blobs from libbtdm_app.a into RAM. If I configure a minimal (for our needs) bluetooth (BLE only), I get: --- Bluedroid Bluetooth stack enabled (3072) Bluetooth event (callback to application) task stack size (NEW) [ ] Bluedroid memory debug (NEW) [ ] Classic Bluetooth (NEW) [*] Release DRAM from Classic BT controller [*] Include GATT server module(GATTS) (NEW) [ ] Include GATT client module(GATTC) [*] Include BLE security module(SMP) (NEW) [*] Close the bluedroid bt stack log print (NEW) (2) BT/BLE MAX ACL CONNECTIONS(1~7) (NEW) OVMS > module memory ============================ Free 8-bit 106312/246720, 32-bit 18576/43548, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 21840 22776 0 change= +21840 +22776 +0 task=mai total= 36436 0 0 change= +36436 +0 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41476 0 0 change= +41476 +0 +0 With just classic bluetooth enabled: OVMS > module memory ============================ Free 8-bit 77696/218096, 32-bit 18608/43580, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 20200 24444 0 change= +20200 +24444 +0 task=mai total= 9488 26948 0 change= +9488 +26948 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41440 0 0 change= +41440 +0 +0 Turning off our memory and task debugging features, and enabling BLE GATT server + security (2 connections), gives me 122KB in metric m.freeram. That should include bluetooth requirements, but no wifi running yet. With wifi, it drops to 82KB. That should be what end-users of OVMS will see, and I’m happy with that, so have committed that as a default config for the moment. With memory and stack debugging enabled (as developers will most likely use), it drops 122KB-> 106KB. I did see some comments in the forums about this. For example: https://www.esp32.com/viewtopic.php?t=3139 <https://www.esp32.com/viewtopic.php?t=3139> It seems that IDF 3.0 changes the way this works (dynamic, rather than static as per menuconfig), and in the documentation for that they mention 70KB. It looks like a minimal bluetooth for us is going to cost 40KB RAM or so. Regards, Mark.