Available memory on ESP32 S3 and C6. Why these differences?

[mdughera]

I discovered that memory available after boot of ESP32 S3 is much lower than ESP32 C6.
As per the documentation, since gc_mem_free() may not tell the whole picture, I (er. AI...) wrote a script that allocates memory until exaustion to check the effective memory available.

According to my experiments:
ESP32 S3
gc free: 229856
allocated effectively: 265408

ESP32 C6
gc free: 328224
allocated effectively: 342976

On paper, it seems to me that hardware-wise the two boards should be comparable for this feature.
How is it possible that C6 has 80K more memory available in Micropython?
What are the use cases for ESP32 S3 for running Micropython programs given that they are more expensive boards?

Below the script I used to do this check and the results obtained in 1.29.

I am M5Stack AtomS3 Lite with ESP32-S3
Starting allocation test
Initial GC free: 229856
Block size: 16384 Allocated: 212992
Block size: 4096 Allocated: 36864
Block size: 1024 Allocated: 11264
Block size: 256 Allocated: 3072
Block size: 64 Allocated: 1216

========== RESULTS ==========
Total bytearray payload: 265408 bytes
Total bytearray payload: 259 KiB
GC allocated: 268896
GC free: 5536

stack: 688 out of 15360
GC: total: 273280, used: 268896, free: 4384, max new split: 1152
No. of 1-blocks: 92, 2-blocks: 9, max blk sz: 1024, max free sz: 256

I am M5Stack NanoC6 with ESP32-C6
Starting allocation test
Initial GC free: 328224
Block size: 16384 Allocated: 278528
Block size: 4096 Allocated: 49152
Block size: 1024 Allocated: 11264
Block size: 256 Allocated: 3328
Block size: 64 Allocated: 704

========== RESULTS ==========
Total bytearray payload: 342976 bytes
Total bytearray payload: 334 KiB
GC allocated: 346400
GC free: 5752

stack: 516 out of 15360
GC: total: 351936, used: 346400, free: 5536, max new split: 216
No. of 1-blocks: 88, 2-blocks: 9, max blk sz: 1024, max free sz: 267

import os

print("I am ", os.uname().machine)

import gc
import micropython

Keep allocated objects alive; reserve a little memory for reporting.

blocks = []
report_reserve = bytearray(4096)

gc.collect()
total = 0

print("Starting allocation test")
print("Initial GC free:", gc.mem_free())

for size in (16384, 4096, 1024, 256, 64):
count = 0

while True:
    try:
        blocks.append(bytearray(size))
        total += size
        count += 1
    except MemoryError:
        break

print("Block size:", size, "Allocated:", count * size)

Release the reserve so reporting has some memory available.

del report_reserve
gc.collect()

print()
print("========== RESULTS ==========")
print("Total bytearray payload:", total, "bytes")
print("Total bytearray payload:", total // 1024, "KiB")
print("GC allocated:", gc.mem_alloc())
print("GC free:", gc.mem_free())

print()
micropython.mem_info()

[g4lb]

The S3 most likely loses SRAM to its CPU caches: ESP-IDF gives it 480 KB of data RAM, and the C6 512 KB. Use an S3 board with PSRAM (for example N8R8) for a much bigger heap.

[mdughera]

Looking at m5stack products purely as an example, an ESP32 S3 with 8MB PSRAM is almost 3 timest the price of an ESP32 C6.
If I use directly ESP-IDF I have access to both cores of S3 and this would justify the price difference.
If I use Micropython only (and there are many reasons for that...) I wonder why I would choose an S3 over the C6.

[scruss]

If I use Micropython only (and there are many reasons for that...) I wonder why I would choose an S3 over the C6.

Performance. The S3 is a much more powerful chip. A couple of results pulled from shaoziyang/micropython_benchmarks:

Platform	Frequency / MHz	Memory	Float multiplication 1000000 times / ms	Pi Calculation 10000 bits / ms
esp32-c6	160	334336	7837	39502
esp32-s3	240	8321536	5554	26830

The S3 is also three years older than the C6, so we've had time to develop mature designs with it. Plus, the C6 has very few peripherals compared to the S3 (see ESP Product Selector).

[Ramonspe]

Hi!

Both chips have 512 KB of internal SRAM on paper, but on the ESP32-S3 part of it is used as the flash cache, while on the ESP32-C6 the cache does not come out of that 512 KB. That alone accounts for about 64 KB of the gap you measured. The rest comes from what ESP-IDF itself uses on each chip.

Where the S3 RAM goes

Looking at the ESP-IDF heap layout for the S3 (components/heap/port/esp32s3/memory_layout.c, soc_memory_regions[]), the 512 KB is split like this:

• 32 KB block at 0x40370000: with the default 16 KB instruction cache, 16 KB is cache and the other 16 KB is IRAM only (executable, 32-bit access). It is not usable for data, so it can never become Python heap.
• 416 KB of shared D/IRAM (0x3FC88000 to 0x3FCF0000): static data, IRAM code and the IDF heap live here.
• 64 KB block at 0x3FCF0000: with the default 32 KB data cache, only the other 32 KB is available as DRAM.

So the S3 has roughly 448 KB of data-capable SRAM before anything else is loaded. MicroPython's S3 builds keep the ESP-IDF defaults (ESP32S3_INSTRUCTION_CACHE_16KB and ESP32S3_DATA_CACHE_32KB in components/esp_system/port/soc/esp32s3/Kconfig.cache).

On the C6 (components/heap/port/esp32c6/memory_layout.c), the whole 0x40800000 to 0x40880000 range (512 KB) is listed as general RAM. Code placed in RAM, static data and the ESP-IDF tasks come out of that pool on both chips, and the S3 being dual core means ESP-IDF runs some tasks per core (idle, IPC), each with its own stack. That explains the remaining few KB.

Why your test allocates more than gc.mem_free() reports

On the esp32 port the Python heap starts small and grows on demand (MICROPY_GC_SPLIT_HEAP and MICROPY_GC_SPLIT_HEAP_AUTO in ports/esp32/mpconfigport.h, initial size 64 KB on S3 and C6). gc.mem_free() returns the current free GC memory plus the largest single free block in the ESP-IDF heap (gc_get_max_new_split() in ports/esp32/gccollect.c). When you keep allocating, the heap grows several times from different free IDF regions, so the total you can actually allocate is higher than that single value. This is also described in the esp32.idf_heap_info() docs.

To see the regions on each board:

import esp32
for total, free, largest, min_free in esp32.idf_heap_info(esp32.HEAP_DATA):
    print(total, free, largest, min_free)

When the S3 makes sense

The main reason is PSRAM. Many S3 modules come with 2 to 8 MB of PSRAM, and MicroPython's S3 builds enable it with CONFIG_SPIRAM_USE_MALLOC=y (boards/sdkconfig.spiram_quad, plus the SPIRAM_OCT variant of ESP32_GENERIC_S3 for octal PSRAM). The Python heap can then grow into megabytes, which the C6 cannot match. The AtomS3 Lite is a special case here: its board definition explicitly removes PSRAM support because the board has none (boards/M5STACK_ATOMS3_LITE/mpconfigboard.cmake).

Other differences: the S3 has two Xtensa cores at up to 240 MHz (the C6 has one high-performance RISC-V core at up to 160 MHz), and native USB OTG, which MicroPython supports through machine.USBDevice. If you need neither PSRAM nor native USB and RAM is the priority, the C6 is a good fit, as your numbers show.

Hope this helps!

[mdughera]

thanks ramonspe!!!