Chapter 4. API Guides
Used static DRAM:
30764
-456
→
Used static IRAM:
83918
-5420
→
Flash code:
509183
559943
-50760
→
Flash rodata:
170592
176736
-6144
→
Total image size:~
772789
835553
-62764
→
We can see from the "Difference"column that changing this one setting caused the whole binary to be over 60 KB
smaller and over 5 KB more RAM is available.
It's also possible to use the "diff"mode to output a table of component-level (static library archive) differences:
$IDF_PATH/tools/idf_size.py --archives --diff build_Og/https_request.map build_
Oshttps_request.map
→
Also at the individual source file level:
$IDF_PATH/tools/idf_size.py --files --diff build_Og/https_request.map build_
Oshttps_request.map
→
Other options (like writing the output to a file) are available, pass --help to see the full list.
Showing Size When Linker Fails
as DRAM segment data does not fit, region `iram0_0_seg' overflowed by 44 bytes,
or similar.
In these cases, idf.py size will not succeed either. However it is possible to run idf_size.py manually in
order to view the partial static memory usage (the memory usage will miss the variables which could not be linked,
so there still appears to be some free space.)
The map file argument is <projectname>.map in the build directory
$IDF_PATH/tools/idf_size.py build/project_name.map
It is also possible to view the equivalent of size-components or size-files output:
$IDF_PATH/tools/idf_size.py --archives build/project_name.map
$IDF_PATH/tools/idf_size.py --files build/project_name.map
Linker Map File
This is an advanced analysis method, but it can be very useful. Feel free to skip ahead to
:ref:`reducing-overall-size` and possibly come back to this later.
The idf.py size analysis tools all work by parsing the GNU binutils "linker map file", which is a summary of
everything the linker did when it created ("linked") the final firmware binary file
Linker map files themselves are plain text files, so it's possible to read them and find out exactly what the linker did.
However, they are also very complex and long - often 100,000 or more lines!
The map file itself is broken into parts and each part has a heading. The parts are:
• Archive member included to satisfy reference by file (symbol). This shows you:
for each object file included in the link, what symbol (function or variable) was the linker searching for when
it included that object file. If you're wondering why some object file in particular was included in the binary,
this part may give a clue. This part can be used in conjunction with the Cross Reference Table at the
end of the file. Note that not every object file shown in this list ends up included in the final binary, some end
up in the Discarded input sections list instead.
Espressif Systems
30308
bytes
(
150428
(
+456 available,
78498
bytes
(
52574
(
+5420 available,
bytes
bytes
bytes (.bin may be padded
If too much static memory is used, then the linker will fail with an error such
Submit Document Feedback
available, 16.8%
used)
+0
total)
available, 59.9%
used)
+0
total)
larger)
1448
(continued from previous page)
␣
␣
␣
␣
␣
Release v4.4
Need help?
Do you have a question about the ESP32-S2 and is the answer not in the manual?