Executable binary sizes

Troubleshooting and Support
1

I’m getting to the point in one of my projects where I’m starting to get close to the 128KB limit of the Flash memory. I can shave a bit off by optimising for size (-Os), but I was surprised how large the binary was. I took a look at the simplest Daisy project, Blink, and the binary size is 59KB, which is pretty huge for code that just blinks an LED.

Memory region         Used Size  Region Size  %age Used
           FLASH:       58964 B       128 KB     44.99%
         DTCMRAM:           0 B       128 KB      0.00%
            SRAM:       14224 B       512 KB      2.71%
          RAM_D2:         16 KB       288 KB      5.56%
          RAM_D3:           0 B        64 KB      0.00%
         ITCMRAM:           0 B        64 KB      0.00%
           SDRAM:           0 B        64 MB      0.00%
       QSPIFLASH:           0 B         8 MB      0.00%
arm-none-eabi-objcopy -O ihex build/Blink.elf build/Blink.hex
arm-none-eabi-objcopy -O binary -S build/Blink.elf build/Blink.bin

I imported the .elf into an online .elf viewer and can see symbols for lots of DaisyLib that I imagine isn’t used. I was assuming the linker would dead-strip most of this. Has anyone here spent much time looking at reducing binary size beyond just setting -Os?

2

Hi @Cutlasses!

Great question! This was brought up during today’s meeting actually, and we would love to provide more documentation about this topic of optimizing flash size. And (if I understood correctly) there will be a way to set up in a makefile to choose what’s not needed (for example like SPI) to save space for your project.

For the time being, -Os is the best approach. And if you need more space, then Daisy Bootloader is the way to go.

Thank you so much for bringing this up :slight_smile:

2 Likes
3

Same thing for me…i think i am at 99.56% of the Flash :frowning: . And yes i have use the -Os for my part but also i the DaisyLib part. And i agree the Daisy lib take a lot of place in the Flash.
Maybe Electrosmith should consider to use another STM32 with more flash for a new project or Maybe use a derivate of the actual ship.

4

Any more news here? I feel your suggestion @Takumi_Ogata may be too course for my needs, rather than broadly ruling out areas of the library (which I have a wide usage of) I would want the linker to include only the functions which are referenced. I thought Link Time Optimisation would do this. I’ve tried enabling this but I’m having issues because it’s not compatible with the assembly generation options in the core DaisyLib makefile and I’m a bit of a makefile noob. Has anyone got LTO working and did it help with executable size?

EDIT - with some hacking of the DaisySP core makefile I was able to get Blink to compile with LTO, but I did not see the executable size change (still a whopping 58k), so I assume the dead stripping isn’t happening correctly. This is what I’m adding to the Blink makefile

# Enable LTO
CFLAGS += -ffunction-sections -fdata-sections -flto
LDFLAGS += -Wl,--gc-sections -flto

I then had to remove all uses of -Wa and assembler-with-cpp from the core makefiles