Default value of global variables is not set

Question

I am tracking a bug in the Marlin source code.

Background

Just for those who is not familiar with Reprap 3D printer and G-code: Marlin is firmware that controls a RepRap 3D printer. It receives G-code from a host computer (or read from SD card). Here the important thing is that if you send the "M114" command, it would report information about axis positions. Here, I extended this command to make it print some internal variable as well.

The Problem

In Marlin.ino file there is a line that says:

volatile int extrudemultiply=100; //100->1 200->2

However my RepRap keeps extruding (and worse, ejecting back) a huge amount of filament. So I added some debug output for M114 command to output this value. It turns out this value is not the default value, 100, but something like 12374.

I thought somewhere inside the setup() function this value might be changed. So I defined another variable,

volatile int orig_extrudemultiply = 100;

And then at the first line of setup() function, I added the following line.

orig_extrudemultiply = extrudemultiply;

Finally, I output this value for the M114 command. Still, it is not 100. So it looks like the default value is not effective.

The Question

Although I have experience in C programming, I am new to Arduino development. How is a global variable being initialized in Arduino? In my case, what is the proper way to initialize this value?

Versioning

I originally posted the official Marlin link for the reference. However, the version I actually use is this fork from the RepRap Pro team. I was just following the Melzi entry of the RepRap wiki, because my board is Melzi. I am not sure whether the latest version of Marlin works for my board.

Further details

As the commenter said, the first thing I thought of was memory corruption. So I wanted to narrow the problem down. Since that value is configurable through M302 SXXX command, I tested this command, and it works without difficulty. This means there is nothing in the loop function or the ISRs can affect this value when it is running stably. So I consider the problem must be in the setup function or earlier.

Further tests shows that setting this value at the end of setup or even at the beginning of setup still works fine. This means the setup function may not be the problematic one. The test in "The Problem" session was the last step, which, in my opinion, means the course of the problem must being run before entering setup.

UPDATE

Further examination shows that although it looks like it works when I set the default value in the first line of setup(), but that it is just luckily being 100. So once I add more padding variables it stops working until I move the default setting after the following line in setup():

EEPROM_RetrieveSettings(); // Loads data from EEPROM if available

However, since I greped for extrudemultiply before any test, and I didn't figure out this function, this function should not change this value. I guess there is some data overflow inside this function, so the value was changed expectationally.

I got to figure out what is wrong in this function.

Answer 1

This variable is declared volatile which is generally meaning that it can be modified by an Interrupt Service Routine (ISR).

So it is perfectly possible that this ISR gets called before your setup() function gets called and then it may modify this variable.

In C and C++, variables defined as type variable = xxx; are guaranteed to be initialized before any of your code starts to run.

So this means you must look for the root of the problem somewhere else.

Don't forget that it is perfectly possible that some code gets run before setup() is called.

You may try to search for the code that runs before setup(); unfortunately it can be hard to find out this code:

Indeed, in C++, there are a lot of possibilities for code to execute even before the main() function gets called; for instance, declaring an instance of a class as a global variable, will call the class constructor before main().

So you would have to find out all class instances declared as global variables in all source files, and then check the class constructor that gets called for each instance.

Another way could be to check the assembly produced for your program and find all calls occurring be fore main(), but it can be harder if you can't read assembly.

Answer 2

The problem of this version of Marlin can be shown in the following piece of code (which is inside EEPROM_RetrieveSettings function):

  for (short i=0;i<4;i++) 
  {
    axis_steps_per_unit[i]=tmp1[i];  
    max_feedrate[i]=tmp2[i];
    max_acceleration_units_per_sq_second[i]=tmp3[i];
    max_length[i]=tmp4[i];
  }

Here max_length is an array of 3 elements, not 4 (the X,Y and Z axes have a max length to avoid hitting the edge, but the extrude axis does not have such a limit - you should be able to extrude as many filament as you can supply), so the last statement in the loop overrides other variable(s).

The solution is

  for (short i=0;i<4;i++) 
  {
    axis_steps_per_unit[i]=tmp1[i];  
    max_feedrate[i]=tmp2[i];
    max_acceleration_units_per_sq_second[i]=tmp3[i];
    if(i<3)
        max_length[i]=tmp4[i];
  }

Or

  for (short i=0;i<4;i++) 
  {
    axis_steps_per_unit[i]=tmp1[i];  
    max_feedrate[i]=tmp2[i];
    max_acceleration_units_per_sq_second[i]=tmp3[i];
    if(i < sizeof(tmp4)/sizeof(tmp4[0]))
        max_length[i]=tmp4[i];
  }

Greate thanks to the answer writer and commenter. Without your help I couldn't follow the right track.