STM32C031: Reducing Flash Usage Without Losing Debugging

[Ricko]

Hi,

I’m working with an STM32C031 and have written bare-metal firmware based on the CubeMX-generated framework. When I compile in Debug mode, the firmware uses about 79% of the available flash. Switching to Release mode reduces this to around 45%, which is a big improvement.

I’d like to further minimize code size while still retaining as much debugging capability as possible.

A couple of questions if someone could advise:

1. What techniques and/or compiler/linker options do you recommend?

2. where and how do I set any such settings? I assume in CMakeLists.txt? but not sure.

Thank you

[MM..1]

Your configs debug/release must differ in optimization level. Debug is always possible and no change in code size .

[AScha.3]

Hi,

there is no difference between debug and release, just two (preset) settings .

The arm core always has its debug unit working and there is no difference in code - using debug or not.

What IS different : the settings (you can set/change) for optimizer and download/flash :

- optimized code might not jump from line to line , as debug is expected to do

- flash and then : just run or start debug session  is also just a setting

I use always -O2 , best compromise between speed and code size, so i recommend this.

And just set it in C settings... ->

[mfgkw]

Using -O2 debugging might more diffult since the machine code differs from source code more or less.

So -Og is a good choice for debug builds where optimations are not as aggressive with debugging in mind.

[Cartu38 OpenDev]

@Ricko 
Consider ST ARM Clang (LLVM) toolchain usage too. Picolib mode is much more efficient than GCC but may require some tiny updates of your linker script file.

as extra optimization levels pointed previously

takes care to debug level which may help you experience too

[Andrew Neil]

---

@Ricko wrote:

When I compile in Debug mode, the firmware uses about 79% of the available flash. Switching to Release mode reduces this to around 45%, which is a big improvement.

---

As the others have said, this will be due to a different optimisation setting between your Debug and Release configurations.

The GCC optimisation settings are documented here:

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

In particular:

 -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable blend of optimization, fast compilation and debugging experience.

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

As others have said, the higher the level of optimisation, the harder it is to follow in the debugger.

A good starting point would be to examine the linker listing file (aka "map" file) to identify what is consuming the most code space in your application.

nm is another useful tool here.

Things like floating-point and printf can hog a lot of code space ...