DFU HELP - .MAP file to find Application size in Flash

[Dave_couling]

Enlight of the increase in 8.0 SD size, I am concerned that my application size may soon grow too large to utilize Dual Bank DFU. I know the actual size of the .Hex files are not indicative of the actual FLASH size the Application will take up.

Using the .Map,
.text 0x00016000 0xdeb7 *(.Vectors)

Does this indicate that the Application size is 57, 015B in size? What part of the .Map file indicates the Application size? I need to know how much room I have for Dual Bank. Especially when I transition to SD 8.0. Please Help. Thank you Nordic Community

[Hung Bui]

@Dave: If you use KEIL to compile, you can scrool all the way down, and can find the ROM size at the bottom of the .map file: Total ROM Size = Code + RO Data + RW Data

You can also convert your hex/asf file to .bin binary file. The size of the binary file tells the size of actual code on flash.

[Dave_couling]

I am using Eclipse with GNU. Could I used the *.bin file size as a guide for the size? I can't seem to find a way to analyze the data in the *.MAP file for indication.

[Hung Bui]

@Dave: Correct, the .bin file tell the size of the code. If you use gcc, you can also use arm-none-eabi-size.exe [.out file ] to find the size of the code (text+data). Have a look here.

[Clem Taylor]

If you are using gcc, then you use the size utility:

arm-none-eabi-size xxxboot.elf
   text	   data	    bss	    dec	    hex	filename
  24862	   1760	  15016	  41638	   a2a6	xxxboot.elf

In my case I just use objcopy to extract the data from the elf and get the size from that (mostly because I already need to extract the data to compute the embedded CRCs).

$ arm-none-eabi-objcopy -Obinary --gap-fill=0xFF xxxboot.elf xxxboot.bin
$ stat -c %s xxxboot.bin 
26624

I use the linker file to pad the data out to the maximum section size. So the size is always 26624, but if I extract just the filler section I can figure out how much space is 'free'.

$ arm-none-eabi-objcopy -Obinary -j .fill xxxboot.elf xxxfill.bin
$ stat -c %s xxxfill.bin 
1660

The final step in my .elf compile rule prints:

xxxboot.elf: 1660 free of 26620 CRC: fcb4576c

I generate a map file but parsing it is a bit of a pain, so instead I use a combination of 'nm' and 'readelf' to pull out interesting data.

I have a script 'elfFlash' which will find out where all your flash is going:

#!/bin/sh
# print all non-empty symbols in flash (addresses beginning in 0x00??????)
ME="${0##*/}" # my name
elf=$1

if [ $# -ne 1 -o ! -x "$1" ]; then
    echo "Usage: $ME <elf file>"
    exit
fi

arm-none-eabi-readelf --wide --symbols $elf | \
    awk '$2 ~/^00/ && $3 != 0' | \
    sed 's/^[ 0-9]\+:\s\+//' | \
    sort | uniq -w 8

exit 0  

This just pulls all the symbols in the elf file, picks out symbols whose address starts with 0x00 and whose size is non-zero. Then it sorts by address and strips out duplicate (overlapping) symbols.

You can also sort by size with 'sort -k2nr' to find the big size offenders.

FWI, if you are using '-Os -flto' the size of various functions can be a bit miss-leading because gcc will recursively collapse leaf functions, so things like main() and your BLE event handlers can be end up being fairly large.

If you are interested in symbols that end up in SRAM you can do something like:

arm-none-eabi-readelf --wide --symbols $elf | \
    awk '$2 ~/^20/ && $3 != 0 && $4 ~/OBJECT/' | \
    sed 's/^[ 0-9]\+:\s\+//' | \
    sort | uniq -w 8