ELF file size discrepancy

[peter-h]

This is the Cube Build Analyser



but the resulting binary file is 463k (473092 bytes).

The ELF is 5.2MB

My post build batch file is

Code: [Select]

arm-none-eabi-objcopy -S --strip-all -R .bss -R .main_heap -R .ccmram -O binary xxx.elf bin.dat

Probably I am not quite "stripping all" but what can I do to narrow it down?

The bin.dat is the file which is actually programmed into the CPU FLASH. I know this because I wrote all that code; the boot loader and all. That file is loaded from a FAT12 file system (FatFS) and its actual size in bytes is programmed. So if there is some excess in bin.dat, it doesn't do anything, or there is no excess and the Build Analyser display is BS.

The only reason this actually matters is because I have a code size ceiling of 510k in this version of the project, due to unrelated factors (the CPU is 1MB FLASH).

Of the total code size, about 300k is MBEDTLS The "MBED" is a bit of a joke... Next year they will be calling a PC with 24GB RAM "embedded".

[hans]

A bin file cannot "jump" memory sections. Your BL uses 12.39kB, but reserves 32kB. So around 19.6kB of space will be filled with 0s to get to the memory address of the main program.

32kB+429.8kB=461.8kB = 472883b

Pretty close to your 473092b .bin file.

If you want a program file that can write memory at any arbritrary location, you need .hex.

Concerning usage.. your main program last memory address is at 462kB out 510kB. So it is the actual usage. Perhaps a bit more than expected because the BL is healthily proportioned at 32kB, even though 16kB at this point would fit, but not sure about the FLASH pages on that chip.

[eutectique]

Do objdump of your elf file. You will find hefty .debug* sections.

Also, consider "fill=0xff' option for objcopy. Otherwise unused areas are filled with zeros.

Or consider .hex or .srec format, as already suggested.

[eutectique]

Next year they will be calling a PC with 24GB RAM "embedded".

Inside a tomograph, it is embedded.

[SiliconWizard]

What was the original question?

[SiliconWizard]

Yep if the OP wants to know what is really inside the ELF file, he can run objdump on it. Probably 'objdump -x' is the best bet here.

arm-none-eabi-objdump should be part of the compiler's binaries.

[peter-h]

Thank you - the boot loader / boot block pretty well explains it.

I am keeping the 32k reserved for that, for future use. Also the bottom FLASH block is 32k which is handy because reflashing that block (takes ~300ms) is the only bricking time window.

I could go to hex format if this was a problem, but also I could recompile the code with -Os which on past tests should save about 40k.