FAQ
Why is my flash total different from esptool or size?
Different tools count different things. memprobe reports the flash total as the sum of allocated sections that occupy space in the file, the same bytes that get programmed into flash. arm-none-eabi-size groups bytes into its own text/data/bss buckets, and esptool reports the size of the final flashable image after the bootloader, partition table, and padding are added. The image on the part is usually larger than the ELF's allocated sections. memprobe measures your code and data; the flashing tools measure the packaged image around it.
Why can't I see source files or lines for my symbols?
Source attribution comes from DWARF debug info in the ELF. If a symbol has no file, the binary was likely built without -g, or the debug sections were stripped. Build with debug info (it stays in the ELF, not in the flashed image) to get per-symbol source mapping. memprobe also reads STT_FILE markers as a fallback, which covers many local symbols even without full DWARF.
Can I analyze a stripped binary?
Yes, with less detail. Section sizes and flash/RAM totals always work because they come from the section headers. The symbol table and source attribution need symbols to be present, so a fully stripped binary gives you the size breakdown but not the per-symbol view.
The call graph or insights say no DWARF info. Why?
The call graph and several insights need DWARF call-site and debug information, which only exists when you build with -g. Release builds often omit it. Add -g to the build that you analyze; it does not change the flashed image, since debug sections are not loaded onto the device.
What files can I analyze?
ELF executables (.elf) and Arm's .axf, from any toolchain: GCC, Clang, IAR, Keil, ESP-IDF, Zephyr, PlatformIO, Rust. Raw .bin and .hex images and linker .map files are not supported, because they do not carry the section and symbol data the analysis reads. To set part capacity from a linker script, use memprobe init --from-ld <script.ld>.
Is my firmware uploaded?
The web app processes the file on the server for the duration of the request and does not store it afterward. The CLI and GitHub Action are stricter: they read only the section and symbol table on your machine and send just that metadata, so the compiled binary never leaves your runner. The metadata is the same information readelf -S and nm print. See the privacy policy.
What counts as RAM?
RAM is the bytes your program occupies in memory at runtime: initialized data, zero-initialized .bss, and similar writable sections. It does not include dynamic heap or stack growth, which are runtime behavior rather than static size. For stack figures, use the stack-usage analysis.
Does a CI run use my monthly quota?
Yes. Every analyze counts against the monthly analysis limit and saves a build to history. check and diff run the gate without saving a build. A failed analysis is refunded.
Can I run it on-prem or point the CLI at my own server?
The CLI honors MEMPROBE_SERVER (or config set --server) so it can target a different backend. Self-hosting the analysis backend is a Teams conversation: contact us.
Something else?
Email [email protected]. If a flash or RAM number looks wrong for a specific build, include the toolchain and target and we will take a look.