Build Analyzer underestimates by 30% Flash memory usage

[Valerio3]

Hello everybody,

I have this project for the STM32F103C8 where the build analyzer of STM32CubeIDE says that only ~57% of flash is used:

but while I'm flashing, it shows that the erased sectors are 0 to 56 (out of 63):

and also using the STM32Programmer I see that the empty region starts at 0x800E048

Now 56/63 ≈ 0xE048/0xFFFF ≈ 87% which is 30% higher than the stated 57% of build analyzer. This is kind of a bummer because now I will have to upgrade MCU since some other features must still be added to the project.

How is it possible such a difference?

[Valerio3 · Accepted solution]

I have finally found what is happening here.

When running the code from the CubeIDE via EITHER these buttons   it always loads to the MCU the debug version (regardless of the active configuration). While I thought that the rightmost one would have loaded the current active configuration (which is always set to "release").

The build analyzer on the other hand shows the size of the active configuration (i.e. "release").

Therefore to load the "small" version of the firmware I have to start the build all, and load the hex from the release folder using the STM32CubeProgrammer (or probably I will use an STM32_Programmer_CLI.exe command placed in the post-build, but I also think that there is a possibility to change the run configuration).

To me this is good on one side (i.e. I don't need to switch to a bigger mcu because the remaining 43% is enough to complete the project) but it also means that from a certain point onward I won't be able to debug the code, but only run it.

Thanks to all the contributors to this issue, I hope that this may help someone else.

[AScha.3]

> that from a certain point onward I won't be able to debug the code, but only run it.

NO !!!

This ARM cpu's have a debug unit in the core, so its always "debug version" , because there is allways the normal code from the compiler. What makes a difference : is only the optimizer setting, (i use always -O2 ) , because for nice debug , every instruction is on the next line, as written, the real speed and smaller code size is not generated, its only really optimized on the - O fast,or size 2,3, levels. (more for size or speed)

So all that happens, if setting always the mode for the final code, -O2 , or so, you still can debug, just dont be surprised, if it jumps to some line forward and then back, or leaves out some lines...thats what the cpu will do finally.

Nothing wrong or difficult to understand. :)

[TDK]

You were quick to assert it was using Release during flashing when I asked. Should have been trivial to spot in the Console when it flashed.

[Valerio3]

Thanks! This wipes out all my worries.

Sorry but this is my first design using this IDE. Before I have been using only the Keil uVision with a single target (i.e. no release/debug distinction) and just two buttons: load code and debug code.

Many kudos.

[Andrew Neil]

---

@Valerio3 wrote:

When running the code from the CubeIDE via EITHER these buttons   it always loads to the MCU the debug version (regardless of the active configuration). .

---

That's not true.

It runs whatever Debug Configuration is currently the default on those buttons.

You could create a Debug Configuration which loads the Release build.

If you click the little down arrows, you will get a list of what Debug Configurations are available, and the option to configure them or create a new one.

[Valerio3]

Yes of course, now I have understood it.

But apparently by default (since I started the project from scratch and I did not customize either debug or release configuration and always used the release one) those two buttons are mapped one to "debug the debug configuration" and the other to "run the debug configuration". That was my mistake, thinking that the green arrow button would have loaded and run the release configuration. Now thanks to AScha.3  I also have a better understanding on how to customize and change optimization levels for both configurations.

Thanks.