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

LCE · ‎2024-07-23

... 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.

BarryWhit · ‎2024-08-12

There's constant pressure from china driving cost down and capabilities up. JLCPCB recently made via-in-pad free for 6 layers and up, and have had a 6 layer deal going for months now that makes them cheaper than 4 layers. There's still the complexity of layout to consider, but if someone really needs to get small then switching from pins to balls ultimately makes sense.

I've been meaning to try hand-assembling some WLCSP chips (they are marvels of miniature). But I'd probably have to go through caffeine withdrawal first, before attempting it - so maybe not.

Whenever I see a WLCSP, I can't help but think (by way of contrast) of those old spy movies featuring "cutting-edge" east-german phone bugs - the size of a motorola brick phone.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

LCE · ‎2024-08-12

Interesting stuff from all of you! :thumbs_up:

Yeah, the size... We have relatively small lot numbers, and in most products we have enough space to avoid WLCSP, BGA, and most often - if the manufacturer allows - even QFN, our "go-to" SMD format for passives is still 0603, nothing smaller if possible.
This recent project with the L0 is very space limited, but our production manager still begged me to stay away from BGA and anything smaller than 0603 - while the sales manager side is asking for more features, you know the game... :grinning_face_with_sweat:

Andrew Neil · ‎2024-09-25

See also:

https://community.st.com/t5/stm32cubeide-mcus/stm32-cubeide-code-generator-uses-more-program-memory/m-p/724475#M31029

LCE · ‎2024-09-25

Interesting that the compiler automatically assumes double floating point calculations, these "__aeabi_dxxx" libs take some more space.

I found that I can suppress this with adding "-fsingle-precision-constant" to gcc in the compiler settings:

Gave me 4 kB flash back.

Is that the correct way? Feels somehow not so elegant...

Andrew Neil · ‎2024-09-26

@LCE wrote:
Interesting that the compiler automatically assumes double floating point calculations,

Indeed:

https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/