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?

[TDK]

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

[Valerio3]

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

[Ozone]

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

[Valerio3]

---

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

[Ozone]

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.

[RobK1]

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]

---

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

[Valerio3]

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

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