使用idf.py build size 之后IRAM大小只有16K，怀疑只读到了RTC RAM的大小 (IDFGH-14598)

[ZhkuWuMingyang]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2.1

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

What is the expected behavior?

IRAM应该显示有300+KB大小

What is the actual behavior?

IRAM显示只有16KB

Steps to reproduce.

1. 使用idf.py create-project ttttt创建一个空白工程
2. 使用idf.py set-target esp32s3切换目标芯片
3. 使用idf.py build size

Build or installation Logs.

wmy@wmy:~/esp/work/ttttt$ idf.py build size
Executing action: all (aliases: build)
Running ninja in directory /home/wmy/esp/work/ttttt/build
Executing "ninja all"...
[1/4] cd /home/wmy/esp/work/ttttt/buil...ome/wmy/esp/work/ttttt/build/ttttt.bin
ttttt.bin binary size 0x357b0 bytes. Smallest app partition is 0x100000 bytes. 0xca850 bytes (79%) free.
[1/1] cd /home/wmy/esp/work/ttttt/buil.../ttttt/build/bootloader/bootloader.bin
Bootloader binary size 0x5250 bytes. 0x2db0 bytes (36%) free.
Executing action: size
Running ninja in directory /home/wmy/esp/work/ttttt/build
Executing "ninja all"...
[1/4] cd /home/wmy/esp/work/ttttt/buil...ome/wmy/esp/work/ttttt/build/ttttt.bin
ttttt.bin binary size 0x357b0 bytes. Smallest app partition is 0x100000 bytes. 0xca850 bytes (79%) free.
[1/1] cd /home/wmy/esp/work/ttttt/buil.../ttttt/build/bootloader/bootloader.bin
Bootloader binary size 0x5250 bytes. 0x2db0 bytes (36%) free.
Running ninja in directory /home/wmy/esp/work/ttttt/build
Executing "ninja size"...
[0/1] cd /home/wmy/esp/work/ttttt/build && /usr/bin/cmake -D "IDF_SIZE_TOOL=/home/wmy/.espressif/python_env/idf5.2_py3.8_env/bin/python;-m;esp_idf_size" -D MAP_FILE=/home/wmy/esp/work/ttttt/build/ttttt.map -D OUTPUT_JSON= -P /home/wmy/esp/esp-idf/tools/cmake/run_size_tool.cmake
Total sizes:
Used static IRAM:   16383 bytes (      1 remain, 100.0% used)
      .text size:   15356 bytes
   .vectors size:    1027 bytes
Used stat D/IRAM:   52831 bytes ( 293025 remain, 15.3% used)
      .data size:   10432 bytes
      .bss  size:    2256 bytes
      .text size:   40143 bytes
Used Flash size :  151987 bytes
           .text:   99567 bytes
         .rodata:   52164 bytes
Total image size:  218945 bytes (.bin may be padded larger)

Project build complete. To flash, run:
 idf.py flash
or
 idf.py -p PORT flash
or
 python -m esptool --chip esp32s3 -b 460800 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_size 2MB --flash_freq 80m 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/ttttt.bin
or from the "/home/wmy/esp/work/ttttt/build" directory
 python -m esptool --chip esp32s3 -b 460800 --before default_reset --after hard_reset write_flash "@flash_args"

More Information.

1.idf.py 版本为v5.2.1，尝试把版本升级到v5.2.3，问题都没有解决
2.尝试重新装esp-idf，也没有解决
3.目前问题只出现在esp32s3这个target，其他target正常
4.更换其他s3芯片也是一样的情况
5.尝试过新建一个空白工程，设置为esp32s3，IRAM大小也只显示16K
6.系统是在VM运行的：Ubuntu 20.04.6 LTS

[fhrbata]

Hello @ZhkuWuMingyang ,

https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf

4.3.2 Internal Memory

3. Internal SRAM 0
   Internal SRAM 0 is a 32 KB, read-and-write memory space, addressed by the CPU through the instruction bus,
   as shown in Table 4.3-1.
   A 16 KB or the total 32 KB of this memory space can be configured as instruction cache (ICache) to store
   instructions or read-only data of the external memory. In this case, the occupied memory space cannot be
   accessed by the CPU, while the remaining can still can be accessed by the CPU.

4. Internal SRAM 1
   Internal SRAM 1 is a 416 KB, read-and-write memory space, addressed by the CPU through the data bus or
   instruction bus in the same order, as shown in Table 4.3-1.

SRAM0 is mapped at 0x4037_0000 - 0x4037_7FFF via instruction bus. It has a total size of 32KB, but by default, 16KB is allocated for the instruction cache, as determined by CONFIG_ESP32S3_INSTRUCTION_CACHE_SIZE. This leaves 16KB of IRAM available in SRAM0. You can find this information at https://github.com/espressif/esp-idf/blob/master/components/esp_system/ld/esp32s3/memory.ld.in#L40. The section labeled as Used static IRAM: in the output refers to SRAM0.

SRAM1 is mapped at 0x4037_8000 - 0x403D_FFFF via instruction bus and directly follows the SRAM0 mapping. Additionally, SRAM1 can be accessed through the data bus at 0x3FC8_8000 - 0x3FCE_FFFF, indicating that it is not just IRAM but DIRAM. This is reflected in the Used stat D/IRAM: section in the output, where (293025 remain, 15.3% used) signifies that 293KB is still available for code or data. Please be aware that the Used stat D/IRAM section includes both the .data and .text sections, whereas the Used static IRAM section contains only the .text section.

The code is first placed into SRAM0 (IRAM) and may extend into SRAM1 (DIRAM) if needed. This explains the full SRAM0 (IRAM) usage shown as (1 remain, 100.0% used). The data is positioned after the code in SRAM1 (DIRAM), and its starting address depends on how much code is already in SRAM1 (DIRAM). This means there is no fixed starting address for the data in SRAM1 (DIRAM) and this is expressed by a dummy output section, which represent the part of SRAM1 (DIRAM) used for code (IRAM). It can be seen here https://github.com/espressif/esp-idf/blob/master/components/esp_system/ld/esp32s3/sections.ld.in#L206.

Because SRAM1 (DIRAM) is utilized for both code and data, it's not possible to determine the exact amount of space left as IRAM and DRAM. Therefore, esp-idf-size reports it together as D/IRAM. This division, based on how SRAM can be accessed, aims to provide accurate remaining values.

For a reference, I'm including a commit that resolved the outstanding DIRAM calculation issue: espressif/esp-idf-size@88a8b13
Before this commit the remaining DIRAM was accounted twice, once as remaining IRAM and second time for remaining DRAM, providing a misleading information about how much memory remains available.

I hope this clarifies how the DIRAM is represented in the esp-idf-size output for the esp32s3.

Apologies for the lengthy post and thank you.