same sdkconfig but different memory layouts

commarmi76
Posts: 7
Joined: Sun Apr 23, 2017 10:06 pm

same sdkconfig but different memory layouts

Postby commarmi76 » Thu Apr 27, 2017 9:18 pm

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

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: same sdkconfig but different memory layouts

Postby ESP_Angus » Thu Apr 27, 2017 11:51 pm

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?

ESP_Sprite
Posts: 9833
Joined: Thu Nov 26, 2015 4:08 am

Re: same sdkconfig but different memory layouts

Postby ESP_Sprite » Fri Apr 28, 2017 2:09 am

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.

commarmi76
Posts: 7
Joined: Sun Apr 23, 2017 10:06 pm

Re: same sdkconfig but different memory layouts

Postby commarmi76 » Sat Apr 29, 2017 4:12 pm

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.

ESP_Sprite
Posts: 9833
Joined: Thu Nov 26, 2015 4:08 am

Re: same sdkconfig but different memory layouts

Postby ESP_Sprite » Mon May 01, 2017 6:46 am

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: Google [Bot] and 84 guests