Hello,
I've two project with the same sdkconfig and created using esp-idf-template. When I flash and run monitor, the memory layout presented by the boot process are different.
Let me show:
I (1428) cpu_start: Pro cpu up.
I (1428) cpu_start: Single core mode
I (1429) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1442) heap_alloc_caps: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (1462) heap_alloc_caps: At 3FFC37C0 len 0001C840 (114 KiB): DRAM
I (1483) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1505) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1526) heap_alloc_caps: At 40086C04 len 000193FC (100 KiB): IRAM
I (1548) cpu_start: Pro cpu start user code
I (1607) cpu_start: Starting scheduler on PRO CPU.
ESP32 SDK version:v2.0-rc1-666-g0fe765a9, RAM left 212192
==================================================================================================================
I (1428) cpu_start: Pro cpu up.
I (1429) cpu_start: Single core mode
I (1430) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1443) heap_alloc_caps: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (1463) heap_alloc_caps: At 3FFB1B58 len 0002E4A8 (185 KiB): DRAM
I (1484) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1506) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1527) heap_alloc_caps: At 40086C04 len 000193FC (100 KiB): IRAM
I (1548) cpu_start: Pro cpu start user code
I (1607) cpu_start: Starting scheduler on PRO CPU.
ESP32 SDK version:v2.0-rc1-666-g0fe765a9, RAM left 285000
The first one was created 3 week ago and the second one today. I'm doing "make clean flash monitor" in both projects.
Could someone explain de difference ?
Thanks
same sdkconfig but different memory layouts
-
- Posts: 7
- Joined: Sun Apr 23, 2017 10:06 pm
Re: same sdkconfig but different memory layouts
The section of memory which is missing in one of the logs is memory which is used for Bluetooth (some BT functions are in ROM, so they use hardcoded memory regions which are reserved at app boot time).
https://github.com/espressif/esp-idf/bl ... aps.c#L195
If Bluetooth is disabled in sdkconfig, all of this memory should be available as heap.
I can't explain why you're only seeing it in one of the logs, if the sdkconfigs are identical. If you diff the 'sdkconfig' files are they 100% the same? Are you sure you've recompiled both apps and re-flashed them?
https://github.com/espressif/esp-idf/bl ... aps.c#L195
If Bluetooth is disabled in sdkconfig, all of this memory should be available as heap.
I can't explain why you're only seeing it in one of the logs, if the sdkconfigs are identical. If you diff the 'sdkconfig' files are they 100% the same? Are you sure you've recompiled both apps and re-flashed them?
-
- Posts: 9833
- Joined: Thu Nov 26, 2015 4:08 am
Re: same sdkconfig but different memory layouts
ESP-IDF gives back memory used for BT Classic to the heap pool when Classic is not needed, but only does this since pretty recent ESP-IDF versions. One of the reasons for what you're seeing is that one of the examples is compiled with an old esp-idf version. Run make clean && make flash in both projects, and I'm pretty sure the difference will disappear.
-
- Posts: 7
- Joined: Sun Apr 23, 2017 10:06 pm
Re: same sdkconfig but different memory layouts
Hello,
surprisingly it is something related to the code. If I put a "return 0" before the lame_init_params here: https://github.com/commarmi76/libmp3lam ... test.c#L63 the memory layout is correct.
I wonder what related to the code can change memory layout ?
Some kind of static array ?
I'm investigating, I will back..
br.
surprisingly it is something related to the code. If I put a "return 0" before the lame_init_params here: https://github.com/commarmi76/libmp3lam ... test.c#L63 the memory layout is correct.
I wonder what related to the code can change memory layout ?
Some kind of static array ?
I'm investigating, I will back..
br.
-
- Posts: 9833
- Joined: Thu Nov 26, 2015 4:08 am
Re: same sdkconfig but different memory layouts
I think it is. The bits you quoted above indicate the memory available for dynamic allocation; static (bss and data) memory is not shown there because it's, well, static. By adding a 'return 0', you're probably causing a lot of these static variables to be not used, causing the compiler to optimize them out; the memory can be claimed by the dynamic allocator then.
Who is online
Users browsing this forum: ok-home and 108 guests