How to calculate maximum application size from .bin/.hex/.elf?

[Harsh_Shakya]

Hello,
I am using a custom bootloader for firmware updates on an STM32F7 series MCU.
For my process, I need to check the maximum possible application size.
Could you please guide me on how I can calculate the application size from the generated .bin, .hex, or .elf files?
Also, how can I choose the slots to store the firmware.

Thanks in advance!

[Andrew Neil]

Welcome to the forum.

Please see How to write your question to maximize your chances to find a solution for best results.

---

@Harsh_Shakya wrote:

For my process, I need to check the maximum possible application size.

---

What, exactly, do you mean by that?

The size is fixed when the project is built.

You haven't said what tools you're using, but any decent IDE will tell you the memory usage when it's built the project.

STM32CubeIDE gives a summary at the end of every build, and you can get further details using the Build Analyser:

https://community.st.com/t5/stm32-mcus-motor-control/how-to-optimize-code-and-reduce-firmware-size-in-stm32-project/m-p/814005#M12885

[TDK]

The BIN size is the same as the application size. Using that one would be the most straightforward.

[Radosław]

Only If only ONE memory region is used.

But in my opinion Harsh_Shakya  is overthink this,   On bootlader side you only manage  FLASH from MCU that is left for aplication,   If in hex/elf/bin will exist data ouside of this  memory range programming should fail.  JUST IT.  

[franklinn]

You can get the application size directly from the generated files. For .bin, check its file size in bytes—that’s your app size. For .elf or .hex, most IDEs or tools like arm-none-eabi-size will show you text/data/bss sizes.
For choosing firmware slots, decide based on your flash memory layout—leave space for the bootloader, then divide the remaining space into slots that are large enough for your biggest possible app.

[Tesla DeLorean]

.ELF files have headers and sections you can walk.Ignore NOBITS sections, account for ones with BITS, and the address and sizes physical / virtual.

The format is well documented, and dumping tools like OBJDUMP, FROMELF, etc.

You can embedded data structures using linker, linker script, and startup.s

.HEX files you have to parse all the lines to determine all the areas and scope of addresses it writes into.

If staging, say on a MicroSD, you can use the file size, and seek through the image to parse or decrypt, etc.

[Andrew Neil]

---

@franklinn wrote:

You can get the application size directly from the generated files. 

---

Not directly - it will, in general, require some processing.

---

@franklinn wrote:

For .bin, check its file size in bytes—that’s your app size. 

---

---

@TDK wrote:

The BIN size is the same as the application size. 

---

As @Radosław said, that's not necessarily the case: only if the content is entirely contiguous - no padding!

[Andrew Neil]

---

@Tesla DeLorean wrote:

dumping tools like OBJDUMP, FROMELF, etc.

---

@Harsh_Shakya also nm - see, for example: https://linux.die.net/man/1/arm-linux-gnu-nm

[Pavel A.]

Fortunately we don't need to know the elf format. Just use the well known command to produce bin or hex. IAR has a more clever tool that can automatically extract several regions (internal and external flash, for example) instead of producing a huge file.

[Andrew Neil]

---

@Pavel A. wrote:

IAR has a more clever tool that can automatically extract several regions (internal and external flash, for example) instead of producing a huge file.

---

Probably the objdump, objcopy, and/or fromelf tools can do this - given appropriate options...