Chapter 4. API Guides
(continued from previous page)
Used static DRAM: 30308 bytes ( 150428 available, 16.8% used) ␣
,→30764 -456 ( +456 available, +0 total)
Used static IRAM: 78498 bytes ( 52574 available, 59.9% used) ␣
,→83918 -5420 ( +5420 available, +0 total)
Flash code: 509183 bytes ␣
,→559943 -50760
Flash rodata: 170592 bytes ␣
,→176736 -6144
Total image size:~ 772789 bytes (.bin may be padded larger) ␣
,→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 If too much static memory is used, then the linker will fail with an error such
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 1448
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General