Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Hello every one,
I have got a problem and am unable to sort it out. I have a code on Arduino written for Arduino-ProMini. Code length is 30kb. As I moved my code from Arduino Pro-Mini to STM32 Maple-Mini my code size extended to around 100kb. I want to decrease the code size some what upto 64kb.
Can any one suggest me what should I do??

Find the functions that take the largest space:
arm-none-eabi-nm --print-size --size-sort --radix=d yourfile.elf

Thanx Deniel for ur reply, can u plz guide me where to write those lines
“arm-none-eabi-nm –print-size –size-sort –radix=d yourfile.elf”

umerocks wrote:Thanx Deniel for ur reply, can u plz guide me where to write those lines
“arm-none-eabi-nm –print-size –size-sort –radix=d yourfile.elf”

umerocks wrote:Thanx Deniel for ur reply, can u plz guide me where to write those lines
“arm-none-eabi-nm –print-size –size-sort –radix=d yourfile.elf”

Almost certainly the code you are compiling will have use the new operator, or something else that means the linker has had to pull in a massive amount of memory management code.

This will still probably fit into the bluepill as most of them are actually 128k flash devices, even though they are sold as 64k.

So the simple solution is to select generic stm32f103cB instead of c8

More complex solution is to change to code to use static instantiation of memory.

The reason the code is small on the AVR, is that it uses customised memory management libs.

I am not an expert in the ARM Gcc libraries, and there may be a smaller lib you could link instead of the one we normally use, but other people have already encountered this problem, and I don’t think the solution is to use a different lib ( though I cant remember why not)

Thanks every one for your suggestions and help. Finally I figured out the problem.
There were two static variables which were initialized with a “micros() and a Variable” that were causing an amazing increment in code size. By fixing their initialization, code size reduced to 38KB.
Hope this could help others facing the same problem

umerocks wrote:Thanks every one for your suggestions and help. Finally I figured out the problem.
There were two static variables which were initialized with a “micros() and a Variable” that were causing an amazing increment in code size. By fixing their initialization, code size reduced to 38KB.
Hope this could help others facing the same problem

Sample:
void ABC(void){
uint8_t Value_1 = 0;
static unsigned long Value_2 = micros(); // culprit
static unsigned long Value_3 = Value_1 ; // culprit

//replaced with
static unsigned long Value_2 =0;
static unsigned long Value_3 = 0;
.
.
.
}

When used danieleff’s method, only function’s code size was printed. As static variable initialization might have included some other internal libraries which didnt show the increased ABC() size. Then i commented out all of the functions being called and uncomment them one by one and compiled the code each time until i came to the fn consuming large memory. Then went thru the fn’s code and sorted out the problem

Please disregard my post (below), as as Rick has pointed out the code is not in global scope

Looking at the code again, perhaps the code is just an example rather than the real code, as the variable names seem strange.
i.e not real names of things.

Interesting, and also quite strange.

I didnt known it was possible to call functions to initialise variables in C.
Initialisation of variables in global scope is always problematic, because the order in which things are setup is not defined in the C specification.

The call to millis() would be a complete waste of time, as its bound to be zero
And its not valid to call millis() before main() as on most processors the hardware needs to be confugured to operate the millis() counter e.g. PLLs need to be setup unless your MCU happens to have a dedicated hardware millisecond counter register.

With the static vars, does the code size jump if you just fix the millis() problem?

It seems odd that just assigning a non static variable to a static variable would cause the linker to require a load of memory management code.

But perhaps the compiler is having to jump through hoops to technically do whats being asked pf the code.

IMHO. I would be a bit worried about the quality of the code you are using.

I would never assign a variable to another variable in global scope. If two variables need to contain the same value during initialisation, I would make a #define for that value ( assuming its not zero) and use the define to init both vars sepately.

Also naming things as “variable1” is bad practice.
And why is variable1 not static? ( relates back to bad naming of variables as there is no way to know by looking at the variable name, precisely what it is used for)

RogerClark wrote:
Initialisation of variables in global scope is always problematic, because the order in which things are setup is not defined in the C specification.

Rick

My mistake

I thought that code was in global scope

I’ll update my post.

I shouldnt post before my first cup of coffee in the morning

Rick

Any idea when the compiler would actually assign the variable that is calling millis() ?

Is this when the function is first called, or as part of global init.

If its global init, then calling millis() is going to be problematic – and probably pointless as its always going to be zero

It falls under the first use rule I posted above

Looking at the code again, perhaps the code is just an example rather than the real code, as the variable names seem strange.
i.e not real names of things.

Yes Roger, you are right, its just an example code that i mentioned and the variable names are for an example aswel.

Ok.

Thanks.