I'm struggling with one or more obscure bugs in a sketch. My current problem is something is causing the Arduino to reboot part way through the setup() method...but I don't know what's causing it.
What's worse, I've discovered that sometimes adding a trace statement (e.g., Serial.println("in routine xxx at yyy")) causes a reboot to occur. Which doesn't make sense to me.
What kinds of things cause an Arduino to crash/reboot? This almost feels like a stack overflow problem, but I don't know how to diagnose that.
Somehow uploading sixteen files containing about a thousand lines of code doesn't seem like a helpful thing to do :).
The problem, as I mentioned, is that the crashes can be triggered by inserting a call to Serial.print in a variety of different places.
However, in stripping things down to involve just the module which I >>think<< is causing the problem, I've run into several oddities. The module in question interacts with EEPROM, so I added the line:
#include <EEPROM.h>
at the top of the cpp code file for the module. That causes a compiler error unless I also include the same line in the "master" PDE file. I don't understand why I should have to reference an include file in both the PDE file and the module file where I actually want to use it.
Also, I discovered what I think is a naming collision. I had named my EEPROM interface module "storage.h" and "storage.cpp". That lead to the compiler complaining that I had undefined references to setup() and loop() called from the main Arduino routine in core.a.
Changing the name to "obj_storage.h" and "obj_storage.cpp" made that problem go away. Which is confusing, because I >>though<< that an #include using quotes only looked in the local directory path...but obviously it doesn't.
Given that I had a namespace collision I need to go back to my original sketch and see if renaming the storage module makes things better.
Generally writing to an address you shouldn't or reading from the wrong location causes halt problems... but you know that.
Break your code into the smallest manageable portion that still demonstrates the problem and post that.
But in the process of doing that you might just find the problem yourself.
uploading sixteen files containing about a thousand lines of code
"master" PDE file. I don't understand why I should have to reference an include file in both the PDE file and the module file
There's a way to link a bunch of files together so they will compile as one? Please tell me how that is done. I have a 1988 line & increasing PDE file and its getting pretty tedious scrolling up & down thru it as I make changes here & there to clean up program performance.
Okay, that problem was narsty. Turns out I was passing the address of a local variable to a subroutine, where I assigned it a different address...which was dumb. I was doing it to return a second return value.
I'm still curious about why I have to reference EEPROM.H in both the PDE file and an include file to use it in the included module...
Ah, so you were being sarcastic. I wasn't sure, so assumed otherwise. I feel for you. Me, if I can't help, for whatever reason, I don't waste lifespan posting.
No, I had a simple conceptual question: what kinds of things cause an Arduino to crash/reboot? I've had past experience with things that I thought would have caused a crash & reboot not doing so. For example, the following code will behave normally:
void setup()
{
pinMode(LED_BUILTIN, OUTPUT); // so we can control the built-in LED
Serial.begin(57600);
int a = 0/0;
Serial.println("exiting setup");
}
You'll see the message on the serial console, even though dividing zero by zero is an invalid operation. So obviously the Arduino execution environment is designed to catch and ignore certain kinds of "exceptions". In fact, it catches and ignores so many kinds of exceptions that I'd never seen it go through a crash & reboot cycle, despite having a goodly number of errors in my code.
I wanted to know what kinds of things >>would<< cause a crash & reboot...which one reply provided. That information in hand, I went back and looked for things that seemed to me to be related to those kinds of uncaught exceptions and saw the problem.
So obviously the Arduino execution environment is designed to catch and ignore certain kinds of "exceptions". In fact, it catches and ignores so many kinds of exceptions that I'd never seen it go through a crash & reboot cycle, despite having a goodly number of errors in my code.
Maybe the compiler does more things that you ever expected.
Anyway, for no concrete reboot causes read the ATmegaXXX datasheet.
of course I can see the code. But how do I tell how much stack space is being used, so that I can tell if I'm going over the limit?