ESP32 memory changes - 3.4.0 vs 3.7.0

[real-tintin]

Hi!

We are running Zephyr 3.4.0 on a ESP32-WROOM-32E-N8R and want to bump it to 3.7.0. However, I run into some issues due to changes in the linker scripts and how memory is used/defined (I get a dram0_0_seg overflow in 3.7.0). I also noticed that the region sizes are different between the two version.

Below I have included the compile output of the memories when compiling the hello_world sample for esp32_devkitc_wroom.

3.4.0
west build -p -b esp32 ./zephyr_os/zephyr/samples/hello_world

Memory region         Used Size  Region Size  %age Used
     mcuboot_hdr:          32 B         32 B    100.00%
        metadata:          28 B         32 B     87.50%
             ROM:       29692 B    4194240 B      0.71%
     iram0_0_seg:       11028 B       128 KB      8.41%
     irom0_0_seg:       14240 B    4194272 B      0.34%
     dram0_0_seg:        5456 B     180736 B      3.02%
     dram0_1_seg:         53 KB     110032 B     49.32%
     drom0_0_seg:        3680 B    4194240 B      0.09%
    rtc_iram_seg:          0 GB         8 KB      0.00%
    rtc_slow_seg:          0 GB         4 KB      0.00%
        IDT_LIST:          0 GB         8 KB      0.00%

3.7.0
west build -p -b esp32_devkitc_wroom/esp32/procpu ./zephyr_os/zephyr/samples/hello_world

Memory region         Used Size  Region Size  %age Used
           FLASH:      142704 B    4194048 B      3.40%
     iram0_0_seg:       32256 B       235 KB     13.40%
     dram0_0_seg:       16128 B       192 KB      8.20%
  dram0_shm0_seg:          0 GB         2 KB      0.00%
  dram0_sem0_seg:          0 GB          8 B      0.00%
     dram0_1_seg:          0 GB         0 GB
     irom0_0_seg:       11632 B      4092 KB      0.28%
     drom0_0_seg:         64 KB      4092 KB      1.56%
    rtc_iram_seg:          0 GB         8 KB      0.00%
    rtc_slow_seg:          0 GB         4 KB      0.00%
        IDT_LIST:          0 GB         8 KB      0.00%

Both the size of the iram0_0_seg and dram0_0_seg have increased while dram0_1_seg now reports as zero (used by the APPCPU?). The dram0_shm0_seg and dram0_sem0_seg are new. The total sum is actually larget: 427 (235+192) > 418 (128+180+110) KB. I can see that a lot of changes have been made to the linker scripts. Also the APPCPU is now new.

I have read https://blog.espressif.com/esp32-programmers-memory-model-259444d89387 where they illustrate the ESP32 memory model:

192KB IRAM and 328KB DRAM

and

The SRAM is used in two ways — one for instruction memory — IRAM(used for code execution — text data) and data memory — DRAM (used for BSS, data, heap). SRAM0 and SRAM1 can be used as a contiguous IRAM whereas SRAM1 and SRAM2 can be used as a contiguous DRAM address space.

So I guess there is room for flexibility here?

I will try utilize IRAM more as my overflow occurs on DRAM0.

Anyways. Could someone explain the differences between 3.4.0 vs 3.7.0 in terms of the memory model? And is it feasible to utilize the dram0_1_seg by the PROCPU?

[real-tintin]

I solved this by not selecting CONFIG_SOC_ESP32_PROCPU this in turn will free about 100 KB which otherwise is allocated for the APP CPU, which our application does not use.

I found the naming of the config somewhat confusing. Maybe there could be a "single core" config which entirely disables the intention to use the APP CPU. Furthermore, we have created our own board (based on the ESP32) but it seems like the SOC for ESP32 requires a PRO and APP CPU, even if for single core i.e., I need to still build for esp32_devkitc_wroom/esp32/procpu.

[aaNSG]

Thanks to your post about CONFIG_SOC_ESP32_PROCPU, it helped me free up more space. But there is also another problem: I increased the network buffers (CONFIG_NET_BUF_DATA_SIZE=1024) and I use external SPI RAM. In 3.4 it worked pretty well, but now I can't compile it because ```dram0_1_seg' area is 176376 bytes full''. It turns out that net_buf_data_tx_bufs and `net_buf_data_rx_bufs` in the nm output for the zephyr v3.4 compilation had addresses of 0x3f8*_**** which correspond to external RAM, while for zephyr 3.7 they appeared in a different memory space ( don't be surprised, I just fake increased SRAM1_USER_SIZE to more than 0x4000_0000 to compile):

3fffcd4c 00010000 b net_buf_data_tx_bufs
4000d44c 00010000 b net_buf_data_rx_bufs