Unerwünschter Reset - wie Interrupt abfangen?

Ich hatte gerade eben einen ähnlichen Fall. Drei Tage gesucht nach einem
sporadischen Neustart. Ursache: Kondensatoren am Quarz fehlten.
Ich wollts echt nicht glauben, aber ich kann das Verhalten
reproduzieren.
Fazit: Nicht immer ist die Software schuld.

Doch, leider schon. Da bin ich sicher.
Bei den Interrupts stehe ich auch auf dem Schlauch. Eigentlich habe ich
nur einen UART und Timer. Beide fange ich ab. Aber beim 8-Bit Timer
blicke ich eh noch nicht durch. Auf dem mega16 stimmt rein gar nichts
überein. Lt. Datenblatt heißen die Register CS2x, im iom16.h ist es
CS0x und laufen tut's nur mit CS1x. Grr.

Bezüglich den Timern.
Es gibt beim mega16 mehrere Timer.
Deshalb auch 0, 1, 2.

So, Problem gefunden:
Der Speicher war zu knapp. Obwohl beim compilieren nichts darauf hin
wies (wie ich finde):
Program:   13320 bytes (81.3% Full)
(.text + .data + .bootloader)

Data:        894 bytes (87.3% Full)
(.data + .bss + .noinit)

Aber ein paar Byte gespart und schon wurde die Sache wieder stabil, wie
gewohnt. Das soll einer verstehen... (tut er vielleicht auch, nur ich
eben nicht).

Möglichwereise ein Stacküberlauf, falls du große Mengen an lokalen
Variablen benutzt.

Verwendet man die avr-libc, so kann man einen default-IRQ-Handler wie
folgt definieren:

ISR(__vector_default)
{
// user code here
}

Alle nicht anderweitig definierten IRQ-Vektoren zeigen dann darauf.
Aber man kann auch nicht nachvollziehen, welcher Vektor jetzt genau
angesprungen wurde.

Ich hatte übrigens bis gestern exakt das gleiche Problem auf einem
AT90S2313. Der Code lief bis dahin problemlos, Flash-Belegung ca. 70%,
RAM ca. 60%. Dann eine einzige Zeile hinzugefügt, in der eine globale
Variable verändert wurde --> Reset-Endlosschleife. Mit obigem
default-Handler habe ich festgestellt, dass ein IRQ kommt, dann habe
ich für jeden IRQ einen eigenen Handler geschrieben wie von Jörg
angeregt, und konnte so den INT0 als Ursache ermitteln. Dieser IRQ wird
in meinem Hauptprogramm explizit noch einmal deaktiviert, d.h. obwohl
ich eigentlich wusste, welche IRQs aktiv waren, wurde einer der
inaktiven Vektoren benutzt. Dies führte zur Vermutung, dass es sich
nicht um einen "echten" IRQ, sondern eine kaputte Rücksprungadresse
auf dem Stack handeln könnte.

Grund für den zu kleinen Stack bzw. das zu volle RAM war die Definition
mehrerer Zeichenketten per "....". Da dies mein erstes
avr-libc-basiertes Projekt ist, wusste ich bis gestern noch nicht, dass
in diesem Fall die Strings im RAM angelegt werden. Umstieg auf
PSTR("....") und fputs_P() brachte dann auch eine deutliche
RAM-Entlastung, und seitdem läuft alles wieder stabil. Vorsorglich habe
ich jetzt noch ein paar lokale Variablen, sofern sinnvoll machbar,
"globalisiert", um den Stack-Bedarf zu reduzieren.

Schon klar. Interessanterweise hat es aber auch den Flash-Bedarf
geringfügig reduziert, vermutlich weil der Prolog der betroffenen
Funktionen jetzt kürzer ist? Ich hatte gestern leider keine Zeit mehr,
mir die List-Files genauer anzusehen, muss ich heute abend mal
nachholen.

Hi
Ist das hier noch aktuell?
Also ich hab grad auch ein Problem mit ständigem unregelmäßigem Reset.
Könnte es daran liegen, dass die Kondensatoren am Quarz zu klein sind?? 
(Laut Datenblatt (des Quarzes) sind 32pF nötig, mit 33pf hats nicht 
funktioniert, also hab ich 12pF verwendet, damit läuft es zwar, aber ich 
hab diese ständigen Resets.
(Hab leider keine anderen da sonst würde ich es schnell testen)

Ok, Danke, hast sich aber erledigt.
Musste nur die Fuse-Bits anders setzen.