STM32CudeMX base code generates a larger program file

[philipagne]

Hi

I made a program for STM32F103RG using STM32CubeMX and STM32CubeIDE a few years ago. The program is using the USB Device Mass storage software pack. I thought that I should update it with the latest version of it and made a new project since the old config file was too old for the latest SMT32CubeMX version. I configured the MCU in the same way and added my own code.

When I build my code now the size of the program is now doubled in size, but still works the same. The old version was 17 kB and the new is 38 kB. Does anyone know why it has grown that much?

[AScha.3 · Accepted solution]

did you use same optimizer settings ?   -O2  is good in most case.

[Mahmoud Ben Romdhane]

Hello @philipagne ,

First let me thank you for posting and welcome to the ST Community.

Updating the STM32CubeMx introduces changes in code generation that impact the resulting program file size.
In fact, these updates include additional features, improvements in the way the code is generated or optimized.

It is essential to review the release notes accompanying the update to understand the changes made in the new version.
The updates include more libraries, additional functionalities, or different optimization settings, resulting in larger program files.

STM32CubeIDE includes optimization features. Select the project, Properties, C/C++Build, Settings, MCU GCC Compiler, Optimization. Then you can choose the optimization level.

Thanks.

Mahmoud.

[philipagne]

Thank you, now it is approximately the same size. I did not realise that I had that enabled in the previous version.

Do you know what the drawbacks of the optimization is?

[AScha.3]

the "ARM" cpu is/was designed to work optimized with the code a "compiler" generates;

but to use it as intended, the compiler rearranges the instructions to get best speed or minimum program size - or both, if possible.

only "drawback" is : debug might be curious, because things like "out of order" instruction flow or variables, you cannot "see" anymore, just message "optimized out" , can make debugging funny. :)

but there is a debug friendly -Od optimizer setting, better debug, but less speed etc. ; use just for debug.

other drawbacks come from optimizing the program flow, ie a simple delay loop --- is just away !

because optimizer thinks: this variable (end of delay loop) is not used in program any more, so its useless. and away it is. so in these cases you have to tell the optimizer, you want to keep this "useless" variable : the keyword here is "volatile". so a >> volatile uint16_t loopi <<  it will not "optimize out".

https://stackoverflow.com/questions/20080362/is-volatile-sufficient-to-prevent-c-compilers-from-optimizing-out-a-silent-w