How to Optimize Code and Reduce Firmware Size in STM32 Project (Using STM32CubeIDE)

[Vats-ab]

Hello ST Community,

I am currently working on a motor control project using an STM32 microcontroller and STM32CubeIDE. I have noticed that the code size (firmware image size) is larger than expected, and I would like to reduce it as much as possible to fit within memory constraints and improve performance.

Are there recommended methods or best practices to optimize the firmware code and reduce its size?

 

At present, the firmware size is:

 

[Andrew Neil]

Not specific to STM32 - "best practices" would apply to any (microcontroller) software.

First, what compiler optimisation setting are you currently using?

The default is None:

As a first step, try 'Optimise for Debug (-Og)' - which is designed to give a decent compromise between optimisation and debuggability

GCC Optimisation levels are documented here:

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

 

If you're still needing further reductions, you'll need to investigate what's consuming all the space. 

CubeIDE's Build Analyser can help you with that:

Also look at the Linker's listing file (aka "Map" file).

[LCE]

Don't use HAL.

My latest STM32L031 project with 32 kB flash was about 95% "full" in the beginning only with the basic HAL startup code from CubeMX (without optimization).

Also reduce any flash-consuming printf messages. These are constants stored in flash.

[Andrew Neil]

---

@LCE wrote:

Don't use HAL.

---

@Vats-ab beware of jumping to that conclusion.

Use the Build Analyser and/or Map file to determine if this is really a significant problem in your particular case.

 

---

@LCE wrote:

Also reduce any flash-consuming printf messages. These are constants stored in flash.

---

and printf itself is pretty big - especially if you include float support.

Again, you need to check what's using up all the space in your particular case.

 

BTW: nm is another tool for seeing what's going on in your application's binary:

https://ftp.gnu.org/old-gnu/Manuals/binutils-2.12/html_node/binutils_4.html

[Andrew Neil]

Floating-point maths can use a fair bit of code space - especially on a chip with no hardware FPU.

Even on a chip with hardware FPU, you have to be careful:

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

[Ozone]

> At present, the firmware size is: ...

ELF is not a good representation of Flash usage, and can contain a lot of meta and debug information.

I don't use/know CubeIDE, but other IDEs create nice bar charts for Flash/RAM usage, with details for every section.
Alternatively, check the map file, or add a post-build step to convert it to a *.hex / *.s19 file.

[Andrew Neil]

---

@Ozone wrote:

> At present, the firmware size is: ...

ELF is not a good representation of Flash usage

---

That's true, but the figures  @Vats-ab showed do relate to the binary image size:

These figures don't include the ELF metadata.

 

---

@Ozone wrote:

other IDEs create nice bar charts for Flash/RAM usage, with details for every section.

---

CubeIDE provides that in the Build Analyser - mentioned earlier.

 

---

@Ozone wrote:

convert it to a *.hex / *.s19 file.

---

Both Intel Hex and Motorola S-Records add significant overhead - so they're also not a good indication of the actual memory usage.

[Ozone]

> CubeIDE provides that in the Build Analyser - mentioned earlier.

Perhaps you know Rowley Crossworks or Segger Embedded Studio, they display it by default in the GUI.
But this is a matter of taste.
I never liked Eclipse ... didn't I say that already ;)

> Both Intel Hex and Motorola S-Records add significant overhead - ...

Not really.
Their size is basically proportional to the program (Flash) size used, and the more experienced developer can quickly estimate end addresses and block usage.
Basically all programming utilities (meaning Flash erase/program tools) I know support this formats.
None of our hardware manufacturers accepts ELF files.

But back to the topic, I can't see what MCU type is used.
I suppose most motor control design tools spit out FPU-based code, at least by default.
As mentioned, floating point is always a performance and code size "hog".
And Cortex M FPUs have no trigonometric functions, which will require emulation.

In my experience, most free or inexpensive design tools are geared towards ease of use and quick results, but produce wasteful and ugly code that borders un-maintainability.

[htxy]

Well, of course you can always track down where maybe unnecessary code is allocated in the firmware, but the most memory saving way of doing things is to use LL instead of HAL. You sacrifice a lot of "comfort" but you will be able to reduce the code size.

[GMA]

Hello @Vats-ab,

By default, the Motor Control-generated IDE project uses the -Ofast optimization setting. Does using the -Os or -Oz optimization setting improve the size figure?

[GMA]

Hello all,

If the response does not meet your expectations, do not hesitate to open a new thread.