sketch fails to run

Hello all,

I have been working on a sketch for my Mega 2560 which has gotten a kinda big if you count lines of code, but according to the IDE "Binary sketch size: 25466 bytes (of a 258048 byte maximum) ".

Just today, I added a few new functions. After that, the sketch no longer runs after it is uploaded. It compiles and uploads without error, but refuses to run. Sometimes when this occurs the red LED at pin 13 will light dimly.

Suspecting the new code, I commented it all out and recompiled. Everything works fine now. So, one by one, I uncomment the new functions. Eventually it fails again. It turns out that it doesn't matter which functions I uncomment, nor what they contain.. if I leave all the new code out and add a few functions with a few trivial instructions for filler, it will still fail. The filler code could be printing some text to the serial port, assigning some values to strings or char[]s, whatever.

Have I hit some memory limit isn't well documented? or [wild guess] is it more likely that some older code has buggered up some memory that didnt get touched until the program got a bit bigger?

I would have posted some code, but the sketch is too big for that, and the filler code that I mentioned above really isn't the cause, just the catalyst. For the record, I suck at C++, as a consequence, only the obvious structures are in C++, and the rest is in C.

UPDATE: «i just noticed that «i can add all the non-member functions I like without breaking anything. The problem occurs when «i add a function to any one of my classes, which are all related, one parent, two siblings.

May be running out of SRAM. There are some tests you can run to see how much is being used, do a little searching for something like "freemem"

Post your code - there's a file attach button in the additional options section that'll let you avoid the length restriction of messages in the forums.

Here you'll find information about how to read the free memory of your device: . It might be this, but it can also be something else (I recognize the problem). So please post your sketch, it might help.


Sorry for the delay. I had to try a bunch of the memory debugging as suggested in the previous post before giving up. In one of my previous comments, I stated that it was only member functions that caused the breakage… this was incorrect, it seems that anything can do it, and also that the behavior varies; sometimes it will fail to start altogether, but more often than not, when it is broken, it will run normally up to a certain point, then start over again at setup(). In its present state, it will run until control gets to screen.cpp line 75. It is intersting to note that when it stopped running correctly, I had not recently made any changes in that part of the file… the changes that broke it are the constructors at the top of the file, which really have nothing much to do with the function that execution fails in.

Aside from the standard arduino ide distribution, this sketch requires GLCD (not included in the zip) and a modified font. The font is included in the zip file.

I am fully prepared to admit that I have overlooked something stupid, but I cant figger out what I have done wrong here. Any insights are greatly appreciated.


broken (23.7 KB)

For those of you do do not care to read this whole message, I will post the moral of the story first: If you would like to write a program, it helps to learn the language first.[/b]
It turns out that the difference between my sketch running, and my sketch not running was a few important looking lines of code in one area, and a couple trivial looking lines in another. The important looking code had function pointers, an array, void pointers and fun stuff like that… all very bug-prone, so I spent all my time looking here. The trivial looking code was a simple constructor… one that layed out the text on an LCD. There was two: one that took 3 args and drew the screen, and another that took 4 args, did stuff, then called the first to finish the job. Until this very moment, I was not aware that C++ did not like this sort of foolishness.
for the benefit of my fellow neophytes: constructors within a class may not call each other. Doing so will result in a temporary object of the class being instantiated for the duration of the called constructor, then destroyed immediately as it falls out of scope at the end of that constructor, leaving your original constructor (the calling constructor) in a somewhat dazed state from which it will make all sorts of bad decisions based on the erroneous idea it has been properly initialized. Since your arduino will not segfault, it might be days before it becomes symptomatic, and you manage to find the source of your grief.
I am still learning, so if anyone with more experience can put all this more clearly, or correct my findings, please post.