Skip to main content
Serge Lopez
Serge Lopez
Associate
December 21, 2017
Question

STM32CubeMx size of generated code problem

  • December 21, 2017
  • 5 replies
  • 7087 views
Posted on December 21, 2017 at 14:44

I am wroking on a project  using two microcontrollers a STM32F412 and a STM32L011 (8K flash, 2k RAM) .The STM32L011 is used as RTC to manage the power comsumption of the STM32F412. 

I used STM32CubeMx to generate the code to set the peripherics  that I use within the L011 (I2C, RTC, RCC). The problem is the size of the generated code once compiled is bigger than the 8k available inside the flash of the L011.

I only compile the genretaded code without writting a line of code.!

How could be possible to get a bigger code than the place to stored it for a defined STM32?

I think I did something wrong but I can find what is wrong.

Someone could provide me any ideas to resolve this situation. (i can not change the micro)

You will find in attachment the .ioc file. The genrated code from STM32Cube Mx is trasnfered on  a Eclipse platform 

and is used GNU ARM tools.

.Thanks in advance for your help

Best regards

Serge LOPEZ

#stm32cubemx #stm32l0xx #program-size
This topic has been closed for replies.

5 replies

Rosiney Silva
Rosiney Silva
Associate
December 22, 2017
Posted on December 22, 2017 at 18:03

Try the following gcc options:

-Os -ffunction-sections -fdata-sections -Wl, - gc-sections

Rosiney Silva
Rosiney Silva
Associate
December 22, 2017
Posted on December 22, 2017 at 18:15

My code

Without the above options:

text 51500  data 1140  bss 2640

flash  :    56736 ( 86.57 %)

ram    :     3780 ( 46.14 %)

With the above options:

text 14236  data 1124  bss 2568

flash  :    19456 ( 29.69 %)

ram    :     3692 ( 45.07 %)

With the above options plus -flto:

text 11136  data 1128  bss 2700

flash  :    16360 ( 24.96 %)

ram    :     3828 ( 46.73 %)
Serge Lopez
Serge LopezAuthor
Associate
January 8, 2018
Posted on January 08, 2018 at 14:33

Hello Rosiney,

Thanks for answering me.

I checked the compile commande that I used and these options are already declared.

FY, the compile cmd used is :

'

arm-none-eabi-g++ -mcpu=cortex-m0plus -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wpadded -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -g -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L../ldscripts -Wl,-Map,L011.map --specs=nano.specs -o L011.elf 'src\\_write.o' 'src\\main.o' 'src\\stm32l0xx_hal_msp.o' 'src\\stm32l0xx_it.o' 'system\\src\\clib\\_cxx.o' 'system\\src\\clib\\_exit.o' 'system\\src\\clib\\_sbrk.o' 'system\\src\\clib\\_startup.o' 'system\\src\\clib\\_syscalls.o' 'system\\src\\clib\\assert.o' 'system\\src\\cmsis\\startup_stm32l011xx.o' 'system\\src\\cmsis\\system_stm32l0xx.o' 'system\\src\\cortexm\\_initialize_hardware.o' 'system\\src\\cortexm\\_reset_hardware.o' 'system\\src\\cortexm\\exception_handlers.o' 'system\\src\\diag\\Trace.o' 'system\\src\\diag\\trace_impl.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_cortex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_dma.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_flash.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_flash_ex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_flash_ramfunc.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_gpio.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_i2c.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_i2c_ex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_pwr.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_pwr_ex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_rcc.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_rcc_ex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_rtc.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_rtc_ex.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_tim.o' 'system\\src\\stm32l0xx\\stm32l0xx_hal_tim_ex.o'

'

I

Kind regards

p.s.: All the best for 2018 !

Rosiney Silva
Rosiney Silva
Associate
January 8, 2018
Posted on January 08, 2018 at 19:59

I compiled with makefile but had to change 'STM32L011D3Px_FLASH.ld':

_Min_Heap_Size = 0x100; /* required amount of heap */

_Min_Stack_Size = 0x200; /* required amount of stack */

Make: 4.2.1

GCC: (arm-none-eabi) 6.3.1

Size after:

text data bss dec hex filename

5440 1088 948 7476 1d34 build/release/bin/test_l0/test_l0.elf

________________

Attachments :

L011.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy0r&d=%2Fa%2F0X0000000b4g%2Flj4NueqALk2QW74e9EZTjK2eGdimhpXeOwpc5HTys0E&asPdf=false
Serge Lopez
Serge LopezAuthor
Associate
January 11, 2018
Posted on January 11, 2018 at 09:07

I did not find the file STM32L011D3Px_FLASH.ld

What I found is the fololowing file mem.ld. Heap size and stack size are defined through equation with other parameters. So I was no confident to change them. I just was able to upgrade _Minn_Heap_Size that 's it.

________________

Attachments :

mem.ld.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyCR&d=%2Fa%2F0X0000000b4V%2FTy7mx_vNCs7BhZ1SrDuvNBKQXQ_MUDlAkccbLAD5vwc&asPdf=false
Rosiney Silva
Rosiney Silva
Associate
January 12, 2018
Posted on January 12, 2018 at 20:55

Try changing the values using ''STM32CubeMx'':

0690X00000609MFQAY.png

The default setting is:

_Min_Heap_Size = 0x200;

_Min_Stack_Size = 0x400;

or 1536 bytes reserved. (75% of 2048).

reduce to:

_Min_Heap_Size = 0x100;

_Min_Stack_Size = 0x200;

or

_Min_Heap_Size = 0x000;

_Min_Stack_Size = 0x200;

AvaTar
AvaTar
Senior III
January 11, 2018
Posted on January 11, 2018 at 09:34

If your code optimization possibilities have been exhausted, I see two options.

  • 1. write your own code, without all the bloat of Cube
  • 2. accept that your initial MCU choice was sub-optimal, and use a variant with more flash

Problems like yours happen much more often than you might think ...

Andrew Neil
Andrew Neil
Super User
January 11, 2018
Posted on January 11, 2018 at 10:28

AvaTar wrote:

Problems like yours happen much more often than you might think ...

Indeed - 'sizing' the microcontroller for the task at hand is a key skill.

Premature optimisation is a root of many evils.

8K flash is very small!

You need to examine the Map file to see what is using all the space.

You can also use nm: 

https://sourceware.org/binutils/docs/binutils/nm.html

  

You're not using floating-point maths, are you ... ?

(and beware that Cube/HAL isn't sneaking it in through the back door)

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
AvaTar
AvaTar
Senior III
January 11, 2018
Posted on January 11, 2018 at 10:45

You're not using floating-point maths, are you ... ?

(and beware that Cube/HAL isn't sneaking it in through the back door)

Yes, definitely worth to check for that.

I don't use Cube, for this and other reasons (yes, and I repeat it ever time ...).

Another option is a better toolchain.

The Keil compiler, AFAIK, produces best results in regard to code size. IAR WB is not bad either.

But this might prove futile as well when you need to add another 'very important' feature - and you are again beyond the limits.

Versions of the STM32L011 with more Flash (16k instead of 8k) exist, so the swap would be rather painless.

Bogdan Golab
Bogdan Golab
Lead
January 11, 2018
Posted on January 11, 2018 at 11:05

Cube LL drivers is another way to go... I work with small flash a lot and switched to LL

Serge Lopez_2
Serge Lopez_2
Associate
January 22, 2018
Posted on January 22, 2018 at 15:26

Hello Bogdan,

Thanks for your suggestion 

I will go in this way

Kinds regards

Serge

Szymon PANECKI
Szymon PANECKI
Senior III
January 11, 2018
Posted on January 11, 2018 at 11:06

Hello,

Indeed using Cube HAL for STM32 MCUs with small size of Flash could be problematic, because most or all (like in this example) Flash can be consumed by generated code and there is small or no space for user code.

This limitation was a reason why ST introduced some time ago so called Low Layer (LL) libraries. This is an alternative solution to HAL libraries. Thanks to it developers can create applications based on working out of the box API for MCU's resources, but additionaly they benefit from significantly reduced code size. Both HAL and LL are supported by STM32CubeMX and user selects for each peripheral separately HAL or LL. In order to make such configuration inside STM32CubeMX please click in main menu Project -> Settings and in opened window select Advanced Settings tab.

0690X00000609KdQAI.png

I believe this solution will allow you to fit in MCU's Flash size and still you will be able to use STM32CubeMX and ST libraries (LL) for your application development.

Regards

Szymon
Bogdan Golab
Bogdan Golab
Lead
January 11, 2018
Posted on January 11, 2018 at 11:12

The only problem I see lack of good documentation for LL. If someone does not study datasheet carefully he/she may have a problem with using them. The HAL documentation at least shows how to use the drivers. Here, in case of LL, we can either study examples or staty datasheet. The latter is better but for requires some time.

Even such simple tick like starting SystTick (for HAL it's an easy task automated through CubeMX) in LL requires to debug the app to discover that IT is not enabled and you need to add extra function to enable it.

I would suggest adding better documentation how to use the LL drivers to avoid reverse engineering;)

Bogdan Golab
Bogdan Golab
Lead
January 11, 2018
Posted on January 11, 2018 at 11:15

I hope that someone with better experience/understanding of will correct my opinion about LL.

Besides I think the LL is good thing (it made me study the datasheet)

Terms & ConditionsAccessibility statement