Ausfall des Mikrocontrollers

Hallo!

Ein paar typische Maßnahmen, die sowas beseitigen:

- Resetbeschaltung: externer Pull-up Widerstand ca. 10k und möglichst 
einen Keramikkondensator gegen Masse zur Unterdrückung von Störungen

- Stromversorgung: sollte irgendwie stabilisiert sein, also Elkos + 
Spannungsregler; und (sehr wichtig): möglichst nahe dem Controller ein 
100 nF-Kerko an die Versorgung

- Programmfehler: kann man hier allgemein nicht viel sagen, ohne dass du 
weitere Infos postest. Bei C wird z.B. von nicht verwendeten 
Interruptvektoren standardmäßig an die Adresse 0 gesprungen.

Gruß
David

Wenn mit einem Quarz >10MHz betrieben: CKOPT nicht gesetzt ?

Hallo,

nicht implementierte Interrupts kann man mit

1

ISR(__vector_default) {

2

  //...

3

}

abfangen. Dann landen eben alle (vom Controller angesprungenen) 
Interrupts, die im Code nicht verwendet werden, in dieser Routine. Ist 
aber eher theoretischer Natur, man sollte natürlich keine Interrupts 
aktivieren die man nicht braucht.

Gruß

Hallo nochmal,

was mir so spontan auffällt (sonst recht umfangreicher Code, eventuell 
wäre der Übersichtlichkeit halber das Aufteilen auf mehrere c-Dateien 
angebracht):

- keine eindeutige Schreibweise, z.B. bei den Interruptroutinen 
Deklarationen. Da stehen teilweise Leerzeichen vor der schließenden 
Klammer. Ich weiß nicht, wie aktuell oder ob die Information aktuell 
ist, aber laut Roboternetz macht der avr-gcc hierbei nicht, was er soll:
http://www.roboternetz.de/wissen/index.php/Avr-gcc#Interrupts
angeblich müsste man dann zB exakt die Schreibweise ISR(SIG_ADC) 
verwenden.

- du rufst loescheFensterBits() in einer Interruptroutine auf. Dabei 
sind global die Interrupts deaktiviert. loescheFensterBits() blockt 
dabei eventuell so lange, wie der Delay VERZUGSZEIT ist. Hierbei kann 
der Controller weder seine Arbeit fortsetzen noch auf andere Interrupts 
reagieren.

- F_CPU sollte idealerweise vor dem Inkludieren der anderen 
Headerdateien definiert werden.

Stacküberlauf?

nein, du musst natürlich per software beim start des uC das Flag lesen 
und testen was der Grund war und dann entsprechend 
ausgeben/verarbeiten...

>Ich habe leider keine andere Möglichkeit, außer mit dem ISP, auf den µC
>zu zugreifen. Daher kann ich den MCUCSR nicht auslesen.

Wieso denn das nicht? Natürlich kannst Du das MCUSCR auslesen, auswerten 
(auf das Display schreiben) und danach alle Flags im MCUSCR wieder auf 
"0" schreiben, damit Du den nächsten RESET-Grund herausfinden kannst.

>Ich habe es mal gestestet und herausgefunden, dass alles zurückgesetzt
>wird (alle Variablen die gesetzt waren sind auf ihre standardwerte
>zurückgesetzt wurden)!

Das passiert unter "C" sowohl bei einem echten RESET, als auch bei einem 
"Durchlauf" durch den Flash, welcher von einem Stackoverflow oder einer 
unsauber beendeten Routine ausgelöst werden kann.