2016-12-11 02:25 AM
Posted on December 11, 2016 at 11:25
HI All,
I am wondering why initial code size differs with a factor of 3 between the STM32F031K6 and the STM32L031K6 - just for making an LED blink.
I use CubeMx to generate the project and GCC (OpenSTM32 AC6 IDE) to compile it. In CubeMX I select the Nucleo-F031K6 and the Nucleo-L031K6 and click the 'Initialize all peripherals with their default mode'. Then I leave everything as default, just enough to make the LD3 blink (PB3).
Compiling the project without any modification gives me the following code size:
== STM32L031K6 ==
arm-none-eabi-size 'TEST-L0.elf'
text data bss dec hex filename
12504 12 1684 14200 3778 TEST-L0.elf
== STM32F031K6 ==
arm-none-eabi-size 'TEST-F0.elf'
text data bss dec hex filename
4536 12 1684 6232 1858 TEST-F0.elf
== Question ==
Why this huge difference in code size between the L0 (12,5 KB) and the F0 (4,5 KB) ?
Kind regards
Anders
Solved! Go to Solution.
2016-12-12 11:46 AM
Review .LD and .MAP files
The linker script might separate regions leaving holes, the .MAP file should break down what's where. A disassembly listing might also be instructive.
Review optimization setting, and libraries pulled in.
One complaint and possible cause is if one is pulling the floating point code library, vs one not. The code to compute the USART baud rate has some unnecessary floating point computation in one of the HAL releases.
#dogfooding
2016-12-11 02:56 AM
Most compiler toolchain can generate a MAP file which details for each *.o object file the used memory for constants, code and variables. It should help to analyse the resulting code size.
Good luck!
2016-12-12 11:46 AM
Review .LD and .MAP files
The linker script might separate regions leaving holes, the .MAP file should break down what's where. A disassembly listing might also be instructive.
Review optimization setting, and libraries pulled in.
One complaint and possible cause is if one is pulling the floating point code library, vs one not. The code to compute the USART baud rate has some unnecessary floating point computation in one of the HAL releases.
#dogfooding
2016-12-13 07:24 AM
Posted on December 13, 2016 at 16:24
Hi
Kofoed.Anders_Dam
I have moved this post to the
https://community.st.com/s/topic/0TO0X000000BSqSWAW/
where product related questions are posted.
Thanks
Oli
2016-12-13 08:33 AM
Thanks Cilve,
Yes, disabling the USART driver gave me this:
== STM32L031K6 ==
arm-none-eabi-size 'TEST-L0.elf'
text
data
bss
dec
hex filename
3608
12
1572
5192
1448 TEST-L0.elf
== STM32F031K6 ==
arm-none-eabi-size 'TEST-F0.elf'
text
data
bss
dec
hex filename
3296
12
1572
4880
1310 TEST-F0.elf
The L0 slightly bigger than the F0. Also you are right in that it seems to include code that does some multiplication or division...
Thanks
Kind regards
Anders
2016-12-14 12:46 PM
https://community.st.com/0D50X00009XkflfSAB
https://community.st.com/0D50X00009XkaFMSAZ