All esp32 models reported internal memory

[chegewara]

I maybe missing something and i am trying to learn. Is there something new in S2 and S3 or memory handling, because in empty sketch (C++) i am getting pretty strange values.
I am using 3 simple functions:

Code: Select all

esp_get_free_heap_size();
esp_get_free_internal_heap_size();
esp_get_minimum_free_heap_size();

Exactly the same code is running on esp32, esp32 C3, esp32 S2 and esp32 S3 and i have 2 questions:
- why old esp32 is reporting about 96kB less memory than S3; again, its almost empty C++ sketch, with the same sdkconfig file
- why on C3, S2 and S3 free heap and internal free heap are not the same values,
- how is it possible that minimum free heap is reported bigger than internal memory

Code: Select all

Heap info on esp32:
         free: 295164
         internal: 295164
         minimum: 294172

Heap info on S3:
         free: 389740
         internal: 383304
         minimum: 388616

Heap info on S2:
         free: 255052
         internal: 254964
         minimum: 255052
         
Heap info on C3:
         free: 330092
         internal: 323672
         minimum: 330092

[chegewara]

I think i can answer question about missing 96kB. Here is log:

Code: Select all

I (248) heap_init: Initializing. RAM available for dynamic allocation:
I (255) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (261) heap_init: At 3FFB2CA0 len 0002D360 (180 KiB): DRAM
I (267) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (274) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (280) heap_init: At 4008B0E0 len 00014F20 (83 KiB): IRAM
I (287) spi_flash: detected chip: gd
I (291) spi_flash: flash io: dio
W (295) spi_flash: Detected size(16384k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (309) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Heap info:
         free: 295164
         internal: 295164
         minimum: 294172

I think that IRAM is not added to free heap on old esp32, which is a bug i believe, and maybe D/IRAM too (just educated guessing):

Code: Select all

I (280) heap_init: At 4008B0E0 len 00014F20 (83 KiB): IRAM
I (267) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM

[boarchuz]

I think that IRAM is not added to free heap on old esp32, which is a bug i believe, and maybe D/IRAM too (just educated guessing)

There's a good post here that explains why: https://blog.espressif.com/esp32-progra ... 9444d89387

The IRAM can also be used for data, but with two important limitations.
- The address used for access to the data in IRAM has to be 32-bit aligned.
- The size of data accessed too has to be 32-bit aligned.

Starting with ESP-IDF release 4.2, we have added an ability to use IRAM for data. As mentioned above, IRAM has access limitations in terms of alignment of address and size. If an unaligned access is made, it results into an exception. The ESP-IDF, after release 4.2, handles these exceptions transparently to provide load/store as desired by the caller. As these unaligned accesses result in exception, the access is slower than the DRAM access. Typically each exception handling requires approximately 167 CPU cycles (i.e. 0.7 usec per access at 240 MHz or 1 usec per access at 160 MHz). The application or SDK components can use the IRAM for data either for BSS at link time or through heap allocator at run time. There are two limitations in using IRAM for data:
- The IRAM accesses are not multi-core safe. Hence it should be used in single-core mode of operation or when the system or application knows that the accesses are made only from one core (e.g. from a task pinned to a core).
- The memory allocations used for DMA should not be allocated from IRAM.

I think the default capability flags used for esp_get_free_heap_size() and related functions exclude memory with these constraints, however you should be able to allocate memory from that block with the correct MALLOC_CAP_x flags.