Static variables (and strings!) and stuff live in RAM and with so little to work with, it's easy to run out. The serial classes use up over 130 bytes alone. Is there an easy way to see the non-stack RAM requirements of a sketch?
It seems to me that this is possible in the underlying AVR GCC tool chain, but how can one get at the info via the Arduino environment?
This link may help: it's a function that will calculate free ram at runtime.
http://forum.pololu.com/viewtopic.php?f=10&t=989&view=unread#p4218
-br
I found this code really helpful:
8192 is the 8k sram of the mega is change for the 2k of the 328
Serial.print("free memory = ");
Serial.print(availableMemory());
Serial.print(" - memory used = ");
Serial.println(8192-availableMemory());
int availableMemory()
{
int size = 8192;
byte *buf;
while ((buf = (byte *) malloc(--size)) == NULL);
free(buf);
return size;
}
It was found in this thread
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1256142087/0
UPDATE: Also discussed here:
When I call that sort of function
setup()
{
notify(PSTR("INSetup"));
}
fct1()
{
notify(PSTR("INfct1"));
fct2();
notify(PSTR("OUTfct1"));
return;
}
fct2()
{
notify(PSTR("INfct2"));
fct3();
notify(PSTR("OUTfct2"));
return;
}
I have this out:
INfct1
INfct2
OUTfct2
Setup
Can somebody confirm an overflow calling stack problem?
An how debug ?(trace the calling stack )
Might not be stack overflow, it could be a restart - the "setup" trace would be the first thing to be printed after restart.
Impossible to say without seeing the code - do you get any of the on-board LEDs flashing?
it could be a restart
There is nothing in my code which ask a restart (my code is quite long for edit) , there is no watchdog (default is no watchdog?)
What sort of code make a restart?
I'm looking for:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1203299186
so it can happened because too serial.prints went out of buffer, is it?
I guess any call via a null pointer would cause a restart - that's how the bootloader does it
The tools that come with Arduino include "avr-size", which will report on static RAM usage if you point it at the .elf file produced by the compile process. I actually have some patches for the IDE that include this output in the verbose build output, but I couldn't figure out anything useful enough to do with the data to make it worthwhile incorporating in the official sources. The problem is that a typical C/C++ program (including Ardino sketches) will end up putting a lot of its RAM requirements on the stack, and it won't be visible at compile-time at all. Compile could check for the "int myarray[2000];" problems, but having a check that said "RAM usage OK" when you could still run out at runtime, didn't seem that useful.
call via a null pointer
have you got example in c cpp of this sort of code?
It's strange i have got some longer program with about the same function wich work fine. I supress many serial code but allway reset at the same point.
Mr westfw, this is my dump memory analysis from compilation:
1>d:\Arduino\libraries\Camera_ControlVS02\examples\EOSCapture>if 1 == 1 D:\Arduino\hardware\tools\avr\bin\avr-size.exe --totals --common -d --mcu=patmega328p .\_vsAddIn\_build\core.a
1> text data bss dec hex filename
1> 260 0 0 260 104 wiring_shift.c.o (ex .\_vsAddIn\_build\core.a)
1> 258 0 0 258 102 wiring_pulse.c.o (ex .\_vsAddIn\_build\core.a)
1> 402 0 0 402 192 wiring_digital.c.o (ex .\_vsAddIn\_build\core.a)
1> 252 1 0 253 fd wiring_analog.c.o (ex .\_vsAddIn\_build\core.a)
1> 562 0 9 571 23b wiring.c.o (ex .\_vsAddIn\_build\core.a)
1> 288 0 4 292 124 WInterrupts.c.o (ex .\_vsAddIn\_build\core.a)
1> 90 0 0 90 5a pins_arduino.c.o (ex .\_vsAddIn\_build\core.a)
1> 150 0 1 151 97 Spi.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 2520 503 23 3046 be6 Usb.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 840 0 1 841 349 Max_LCD.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 1226 141 1 1368 558 Max3421e.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 942 7 0 949 3b5 ptpdebug.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 436 0 0 436 1b4 ptpcallback.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 9172 6 1 9179 23db ptp.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 5044 0 0 5044 13b4 canoneos.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 4140 1 1 4142 102e WString.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 306 0 0 306 132 WMath.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 1383 1 21 1405 57d Tone.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 1468 2 0 1470 5be Print.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 14 0 0 14 e main.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 1282 0 151 1433 599 HardwareSerial.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 20268 598 299 21165 52ad include_sketch.cpp.o (ex .\_vsAddIn\_build\core.a)
1> 51303 1260 512 53075 cf53 (TOTALS)
1>d:\Arduino\libraries\Camera_ControlVS02\examples\EOSCapture>if errorlevel 1 goto fail4
1>d:\Arduino\libraries\Camera_ControlVS02\examples\EOSCapture>if 1 == 1 D:\Arduino\hardware\tools\avr\bin\avr-size.exe --totals --common -d --mcu=atmega328p .\_vsAddIn\_build\EOSCapture.cpp.hex
1> text data bss dec hex filename
1> 0 21770 0 21770 550a .\_vsAddIn\_build\EOSCapture.cpp.hex
1> 0 21770 0 21770 550a (TOTALS)
Other interesting dump is the nm.exe
nm EOSCapture.cpp.elf | sort | less
00000000 T __vectors
1>00000000 W __heap_end
1>00000000 W __vector_default
1>00000000 a __tmp_reg__
(.......................)
1>000027e8 T _ZN3PTP16STD_CloseSessionEm
1>00002864 T _ZN3PTP15STD_OpenSessionEm
(.....................)
Is there a way to trace the stack calling?
I trace the Memory and the less is 0x03FF
with this code:
int availableMemory()
{
int size = 1024;
byte *buf;
while ((buf = (byte *) malloc(--size)) == NULL);
free(buf);
return size;
}
SOLVE SOLVE!!!!!!!!!!!!!!!
I have done a pointer increment bugg and write Accidentally on calling stack!