next topic »

[on:]

Hi,
I've been fighting a problem where my code crashes and usually setup() gets called again and starts over (although a few builds just froze completely).  I'm using the Arduino 0021 IDE on a Macbook Pro, targeting  an Arduino Duemilanove.  I haven't figured out how to debug with the Arduino IDE yet aside from hammer-and-chissel Serial.println()'s.  However, the number of calls I have to Serial.println() in my code appear to directly effect this crashing behavior.  When this behavior begins,  I can make it go away by removing some of the Serial.println()s from the code. Note that I remove ones that wouldn't get called anyway, so they are not the problem themselves (the code is still calling Serial.printXX(), just not the ones that were removed).  I'm thinking it could be based on variable space needed for storing the strings, or maybe a bug in Serial.printXX() ?   The Arduino IDE shows “Binary sketch size: 16464 bytes (of a 30720 byte maximum)”, so it's not too big.  Another behavior seen, when it doesn't crash, is that strings printed by Serial.print() or Serial.println() will get garbled together (appears to be corrupted string data).  Could be a bug in Serial.printXX(), or linker's dealing with variable data, or compiler setup/usage of stack space, or ??
Note that I examined closely the code that was crashing and there was nothing recursive going on that could blow the stack (I have no recursive routines in this code), nor could I find any code that could overflow a local or global variable.
I also notice I can also “fix it” by changing global space allocation.  I have a 2x2 array of longs, and if I reduce the size of it by a few entries, that can make it go from 100% failure to 100% success.
Feels like it's blowing the stack somehow, but not sure how to really debug this without ability to add printf's or access to an actual debugger.  

I have a few questions I'm hoping someone can help me out on:
Q) Are there limits/rules on total stack space usage?  Global variable space size/usage?   Is there a FAQ on this stuff somewhere I should be looking at?
Q) Is there a debugger for the Arduino IDE / what's the best way to debug a sketch?
Q) I'm confused about the compiler's behavior when I increase the size of a global variable.  I would expect the Binary sketch size to INCREASE in size, not DECREASE.  Am I not understanding something here, or is this a bug in the compiler/linker?
Before Change:
unsigned long g_right_turn_weights[2][2];
Binary sketch size: 16464 bytes (of a 30720 byte maximum)

After Increasing Global Variable Array Size by 16 bytes (4 longs):
unsigned long g_right_turn_weights[2][4];
Binary sketch size: 16410 bytes (of a 30720 byte maximum)

Thanks in advance for the helpful pointers/tips.
-- Nick
P.S.  I've been programming for over 30 years, but I'm new to the Arduino world (very cool stuff), so please excuse the newbee questions - I'm learning as fast as I can, with your help  

[Reply #1 on:]

There are 3 kinds of memory on the Arduino - EEPROM, SRAM, and Flash. The code goes in flash. That is the size that the compiler reports.

Constants, including strings used in Serial.print() statements, go in SRAM, as does the stack that is used for passing variables to functions, along with global variables. Since SRAM usage is dynamic, there is no way for the compiler to know how much SRAM is being used.

Q) Are there limits/rules on total stack space usage?  Global variable space size/usage?

Limits, yes. You can't use more than there is.

Q) Is there a debugger for the Arduino IDE

No. Using (and removing, when some specific function works) Serial.print() is the best way, because it's the only way.

Q) I'm confused about the compiler's behavior when I increase the size of a global variable.  I would expect the Binary sketch size to INCREASE in size, not DECREASE.

Global variables go in SRAM, not flash. Changing the size of a global variable should have no impact on the size of a sketch.

[Reply #2 on:]

Thanks Paul, that's helpful, and made me laugh (re: Limits, yes.  You can't use more than there is).  

I was curious about your statement "Changing the size of a global variable should have no impact on the size of a sketch.".  

Q) If changing the size of a global variable should have no impact on the size of the binary, what do you think might be causing the change in "binary sketch size" after recompiling with the change - a bug in the IDE?

Q) Does it do this (avoid object file bloat when increasing global variable allocation) via a .bss section in the binary or something similar?

Q) Are there any docs available describing the binary object file format for the Arduino, and if so, can you point me to them?

Q) Where is the resulting binary stored after the Ardiuno IDE is done compiling?  If I can find  it, I can at least hexdump it and see if I can tell what it's changing that's causing the size difference as it sounds like this binary size should not be changing like it is.  This could be what's causing me the problems, but I won't know until I figure out what "this" is, so that's my next goal.


Thanks again, I know it's quite a few questions, but hopefully the answers will give me what I need to figure this problem out.

-- Nick

[Reply #3 on:]

Q) If changing the size of a global variable should have no impact on the size of the binary, what do you think might be causing the change in "binary sketch size" after recompiling with the change - a bug in the IDE?

I don't know why the sketch changed size. I don't know that the only thing you changed was the array size.

Q) Does it do this (avoid object file bloat when increasing global variable allocation) via a .bss section in the binary or something similar?

The dimensions in the global variable declaration should have no affect on the size of an object file.

Q) Are there any docs available describing the binary object file format for the Arduino, and if so, can you point me to them?

Maybe, but I have no idea where they might be.

Q) Where is the resulting binary stored after the Ardiuno IDE is done compiling?

Hold down the shift key before launching the verify or upload process. The (temporary) path where the object files are stored will be revealed.

This could be what's causing me the problems

Unlikely. The much more likely cause of your problems is running out of SRAM. The size of the sketch (in Flash memory) and the size of the data in SRAM are not closely coupled. It is possible to have a sketch that barely fits but uses very little SRAM. It is possible to have a tiny sketch that runs out of SRAM.