Atmega debuggen

Der Controller ist noch ok? Also Ein-Ausschalten hilft?

Ist es sicher, dass Deine Anwendung abschmiert? Und wie sollen wir Dir 
helfen, wenn wir nicht wissen, was Du eigentlich machst?

Einen Post-Mortem-Debugger müsstest Du Dir selbst zusammenschrauben. 
Vielleicht einfach ein paar Statusmeldungen ins EEPROM schreiben, aber 
Vorsicht! Das interne EEPROM kann nur 10000 Schreibzyklen (beim mega88) 
ab. Blick ins Datenblatt hilft.

Oder dasselbe mit externem RAM (das Du auch von extern auslesen kannst),

Also im Prinzip läuft da einfach nur der Stack von Ulrich Radig mit ein 
paar kleinen Erweiterungen um Ports zu schalten etc.

Was abschmiert weiß ich leider nicht, der Controller hält seine 
Pinzustände, macht aber einfach garnix mehr (in der hauptschleife wird 
eine Funktion aufgerufen, die auf Eingänge pollt und dann Ausgänge 
setzt, das funktioniert schon nichtmehr)

Strom Weg, Strom Rein und alles funktioniert sofort wieder ein paar Tage 
lang.

Was tut ein AVR eigentlich bei ner Division durch 0? Bin grad auf der 
Suche, ob ich sowas vielleicht eingebaut hab.


Grüße

Also mit dem JTAGICE MKii geht das.

Du musst allerdings alles schon "vorverkabeln", d.h. PC, JTAG sowie 
Board müssen die 2 Tage lang durchlaufen. Wenn sich der Prozessor dann 
aufhängt* klickst im AVRstudio auf "Pause" und du siehst die Codestelle

*aufhängt in dem Sinne, dass er eigentlich das macht was du programmiert 
hast, typische Fehler sind z.B.:
- Stack-Pointer modifizieren bei eingeschalteten Interrupts
- Register r0 modifizieren (der GCC geht davon aus, dass zu jeder Zeit 
eine 0 drin steht)
- Stack Overflows (irgendwelche Buffer überschreiben den Stack oder 
umgekehrt)

wenn er sich aber "richtig" aufhängt, z.B. durch 
Spanungseinbrüche/Spitzen oder Ausfall des Taktes hilft dir auch der 
Debugger nicht mehr.

Gruß
Roland

Dann werd ich mir mal so nen JTAG besorgen, anders komm ich irgendwie 
nichtmehr weiter :( V.a. ist der Testzyklus echt langwierig wenn es 
immer 5 Tage dauert bis man mal weiß, ob es nun tut oder wiedermal 
nicht...

Wenn er dann richtig abstürzt, dann weiß ich wenigstens, dass ich beim 
hardware bauen schrott gebaut hab und nicht in der software... So weiß 
ich irgendwie garnicht wo ich suchen soll.

Um Hardwareprobleme auszuschließen hab ich nun mal versucht den externen 
Quarz runterzunehmen und ihn mit dem internen osszilator zu betreiben. 
Sollte dann keine Antenne mehr geben und mit der kleineren Frequenz ist 
er dann auch vielleicht ein bisschen stabiler gegen 
Spannungsschwankungen (BOD ist aber auf 4,3V gesetzt)

Danke für euere Hilfe!

Also wenn er wirklich hängenbleibt und nix mehr tut, könnte man ja mal 
den Watchdog einschalten. Wenn er dann durchläuft, ist zwar die 
eigentliche Ursache nicht weg, aber zumindest das Problem, dass er 
irgendwann nix mehr tut.

Ansonsten mal über freie IO's (der Prozessor hat ja genug davon) sowie 
der uart ein-eindeutige Zustände ausgeben, die anzeigen, wo sich das 
Programm gerade befindet. Wenn die Ports nach dem Absturz erhalten 
bleiben, sollte das gehen. Vielleicht lässt sich da ein Muster ableiten 
und eine kritsche Stelle einkreisen.

Ganz blöd wird es nur, wenn das Programm mit den zusätzlichen Ausgaben 
nicht mehr abstürzt...

Oliver