Build Analyzer underestimates by 30% Flash memory usage

Valerio3 · ‎2025-06-30

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 · ‎2025-07-04

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.

View solution in original post

TDK · ‎2025-06-30

Are you using the same (Release) configuration when flashing? No doubt Debug will be using more flash memory.

If you feel a post has answered your question, please click "Accept as Solution".

Valerio3 · ‎2025-06-30

Yes. All release. Also deleted release folder, build clean and rebuild, in various order. Same result.

Ozone · ‎2025-07-01

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

Check the datasheet. Not all sectors are of equal size.
I don't know the F103C8 in detail.

RobK1 · ‎2025-07-01

The last part of the programmed memory is all 0, what's with that?

Are there gaps in the code? Are you using EEPROM emulation?

Valerio3 · ‎2025-07-01

@Ozone wrote:
> ... but while I'm flashing, it shows that the erased sectors are 0 to 56 (out of 63):
Check the datasheet. Not all sectors are of equal size.
I don't know the F103C8 in detail.

That was the reason that made me suspicious but I knew it was not conclusive (also because it says "erased sectors" and maybe it erased more than needed), therefore I double checked by reading back the memory with the stm32programmer. According to Build Analyzer I should see a lot more FFFF's.

Valerio3 · ‎2025-07-01

@RobK1 wrote:
The last part of the programmed memory is all 0, what's with that?
Are there gaps in the code? Are you using EEPROM emulation?

Yes 1k of eeprom emulation (last k of flash memory, but it doesn't explain that big difference). No gaps in the code. Just above those zeros (they are about 30) there are non zero data (not shown in the picture).

Ozone · ‎2025-07-01

I am doubtful the "stm32programmer" and "Build Analyzer" are proper criteria.
The programmer software probably erased only sectors touched, and the latter evaluates bytes (or words) used vs. available.

I would check the map file, this should be unambiguous.
Which is, I strongly suspect, the main source of information for the "Build Analyzer".

> Yes 1k of eeprom emulation (last k of flash memory, but it doesn't explain that big difference).

That is only 1k if the actual size of the used Flash sector is 1k.
I suppose you know only whole Flash sectors can be erased, not single bytes or words.

Valerio3 · ‎2025-07-01

@Ozone wrote:
That is only 1k if the actual size of the used Flash sector is 1k.
I suppose you know only whole Flash sectors can be erased, not single bytes or words.

I checked, page size is 1k for the stm32f103 I'm using and yes I know how the eeprom emulation works.

I will check the map file, and I can also convert the generated .hex to .bin.

Ozone · ‎2025-07-01

... and yes I know how the eeprom emulation works.

That's ok, just saying. Although I think with 64k Flash, your MCU is probably a single-bank variant.

On a related note, you might need to consider the linker configuration as well.
Many embedded toolchains put code and initialized data in different sections, and some put the latter (data) section at the end of the Flash range, growing in a stack-like fashion downward.

Not sure what CubeIDE does, I don't use it.