cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 with small flash + HAL + DEBUG + no Optimization...

LCE
Principal II

... leads to "funny" results:

STM32L011 with 16 kB of flash, HAL inits and LED toggle in main, DEBUG, no optimization:

93% of flash used

I had not expected it to be that bad! :grinning_face_with_sweat:

Okay, I will probably not use too much HAL, will use Release version with optimization,
but I better select an L01 in the next bigger QFN package (4x4) to get 32 kB of flash.

STM32L011_HAL_DEBUG_noOpt.png

24 REPLIES 24
MM..1
Chief III

Your screenshot show many peripherals , then maybe your LED toggle count bitcoins too ...

 

Show the results with "Optimise for Debug" (-Og).

You should also take a look at the map file - is it actually HAL that's using all that space ... ?

:thinking_face:

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.
KnarfB
Principal III

The Memory Details tab gives you more insights.

hth

KnarfB

LCE
Principal II

Yes, luckily I know all that - it was just a bad surprise and might deter some complete STM32 beginners.

So, this wasn't actually a call for help, just ... being "amazed" at how things are. Until now I only worked with "bigger" STM32 (G4, F7, H7), and occasionally using HAL or at project start wasn't a problem.

 

The list file showed mostly the "bloated" HAL inits - I actually forgot about the "Memory Details", thanks @KnarfB .

With release / optimization to size, it drops to 56%.

Record holder is HAL_RCC_Config with 1.15 kB, together with HAL_RCC_ClockConfig and HAL_RCCEx_PeriphCLKConfig taking up even more than 10% of the 16 kB.
These are the HAL setup functions I always use - I guess I have to overcome my laziness in that area.

 

image.png

 

BTW - RAM: the default CubeMx settings for heap and stack also took up ~90% :D

 

In MX you can very easy switch some parts to LL

LCE
Principal II

If this MCU will be used in a product, I will probably throw out the HAL stuff anyway (I don't like the LL either, so direct register settings for me).

I was just really shocked that a basically empty project - except for the inits - with all defaults from CubeMX leads to this memory usage: > 90% for flash and RAM.


@LCE wrote:

I was just really shocked that a basically empty project - except for the inits.


Probably, the inits are where 90% of the code lies!

So what do you get if you don't init any peripherals?

And then there's the C runtime support - how much did that amount to?

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.
LCE
Principal II

@Andrew Neil 

Probably, the inits are where 90% of the code lies!

Definitely!

I just switched to its next big brother with 32 kB SRAM, switched all to LL instead of HAL.

Release with no Opt: 9.57 kB flash

Release with Opt for size: 4.14 kB flash  <- I hadn't expected that with LL

 

And then there's the C runtime support - how much did that amount to?

Erm... where's that? Isn't that for memory allocation and stuff like that - which I don't use?


@LCE wrote:

@Andrew Neil 

Erm... where's that? Isn't that for memory allocation and stuff like that - which I don't use?


There's a lot more to it than that!

 

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.