wieder mal unerklärliche Resets

[damfino]

Hi,
die Versorgung der Kontroller ist über Dioden von den Motoren getrennt, und mit 470µF Elko (nach der Diode) gepuffert. Der 2. Kontroller, ein Atmega32, funktioniert immer.
Aber der Hauptkontroller hat irgendwann Fehler in der Programmausführung, bzw wenn aktiviert spricht der Watchdog an.

Bisher gab es auch keine Resets wenns den Mäher im hohen Gras gewürgt hat, die Akkus haben mittlerweile wieder volle Leistung und könnten 50A liefern, daher vermute ich den Fehler in der Software.

LG!

[KR-500]

Hi,

ok dann kann man die Stromversorung ja auschließen. Aus deinem ersten Post entnehme ich das der Fehler eher sporadisch auftritt, was es natürlich noch mal schwieriger macht den Fehler asufindig zu machen

Und ich bekomme das ehemals stabile Programm nicht mehr zum laufen.

Hast du denn mal Probiert ob deine alte stabile Version des Programms überhaupt noch läuft auf dem Atmega1284P? Wäre sicher gut zu wissen, ob der Controller funktioniert.

Ich hatte mal ein ähnliches Problem bei dem sich der Controller immer wieder sporadisch resettet hat, dabei hatte ich versehentlich den USART Empfangsinterrupt aktiviert aber keine entsprechende ISR-Routine dazu gehabt, mit anderen Worten, immer wenn etwas über die Serielle Schnittstelle an den Atmega gesendet wurdem stürzte er ab. Vielleicht hast du auch irgendwo einen interrupt aktiviert aber keine ISR Definiert, dann dürfte der Controller ja irgendwo hinspringen bzw sogar an die Addresse Null, und würde sich somit resetten. (Ich hoffe das war jetzt richtig^^)

KR-500

[damfino]

Das alte Programm kann leider nicht 1:1 verwendet werden. Grund für den Umbau war der Mangel an I/O Pins, deswegen sind das LCD und GPS (UART) auf den 2. Kontroller gewandert, und die Kommunikation erfolgt über TWI.
Die aufwändigen Berechnungsroutinen von Navigation und Karten Arrays sind identisch, die Ausgaben fürs LCD mussten natürlich geändert werden. TWI wurde aber schon vorher verwendet.

Letztes Jahr nur kurz in Betrieb war die ISR für die Messerdrehzahl, hier gab es noch einige Änderungen bis der PID Regler verlässlich funktionierte.

Wegen fehlgeleiteter ISR ist das eingebaut:

ISR (__vector_default) // falsche Interrupt erkennen, abbrechen
{cli();PORTC &= ~( (1<<DDC2) | (1<<DDC3) );PORTC &= ~( (1<<DDC4) | (1<<DDC5) );PORTC |= (1<<DDC6) | (1<<DDC7);
;LED_rot_ein;Anzeige_Sonder(18);
while(1) {wdt_reset();}

Schaltet alle Motoren ab und ich bekomme eine entsprechende Anzeige am LCD.

Ich hatte letztes Jahr ganz ähnliche Aussetzer, damals war das Karten Array schuld.

Der Fehler ist einigermaßen reproduzierbar, seitdem ich die A* Arrays global definiert hab:
Er stürzt nach 1 Umdrehung bei der Spiralfahrt ab. Dabei wird A* aber nicht verwendet. Das Kartenarray wird verwendet, über die oben angeführten Routinen die dafür sorgen sollen dass die Array Grenzen eingehalten werden.

Ein Variablenüberlauf kann dafür sorgen dass eine Berechnung falsch ausgeht, zB wird aus 18000 wegen Überlauf -14000. Falsch berechnete Positionen sollten die Kartenroutinen abfangen. Aber das stört doch nicht den normalen Programmablauf mit unberechenbarem Verhalten, oder?

Oder was kann noch alles den Stack durcheinander bringen?

LG!

[markusj]

Versuch Mal, nach und nach Programmkomponenten zu deaktivieren (zum Beispiel besagten A*), vielleicht lässt sich so die Problemzone eingrenzen. Debug-Ausgaben über den Aufruf einzelner Routinen können ebenfalls helfen, um (ungewollt) aufgerufene Programmteile zu identifizieren.

mfG
Markus

[damfino]

Ich konnte jetzt wieder mal testen:
.) A* und Navigation deaktiviert (Funktionen gelassen, Inhalt auskommentiert): Absturz innerhalb 1 min.
.) alle Inline Funktionen wieder normal eingebunden: wieder viele Abstürze
.) den ganzen Code auf Fehler durchsucht, wieder mal nichts gefunden.
.) Brownout aktiviert, jetzt gibt es eher das Problem dass dieser gleich beim einschalten aktiviert wird.
.) ebenso versucht das Register vom Power on Reset auszuwerten, aber damit bekommt man den Kontroller gleich gar nicht zum laufen. Wollte damit einen eventuellen schlechten Kontakt der Steckverbindungen erkennen.

Derzeit verwende ich die letzte halbwegs stabile Version, nur die ISR vom PID Regler ist inzwischen etwas optimiert. Einmal löste der Watchdog nach ein paar Minuten aus, jetzt ist er grade >2h ohne Fehlfunktion gefahren.
Ich hatte auch mal den Watchdog deaktiviert, aber dann macht im Fehlerfall das Programm was es will, da ist es besser wenn der Watchdog mal die Notbremse zieht. Ist mit 4s auch großzügig einstellt.

Sieht also nach Stackproblem aus, nur wie findet man den Fehler?

LG!

[Vitis]

Zum Einen sind Variablennamen wie xx xy yyxx etc. nur sehr übel zu debuggen,
eindeutigere Namen helfen da mitunter schon den Baum im Wald besser zu sehen ...
ich verwende z.B. in Variablennamen auch häufig gleich das jeweilige Format mit im Namen z.B.
x_pos_1_byte,
dann kann ich in Rechenoperationen gleich
"abschätzen" ob der Wert oder die Berechnung in die Variable passen kann.

[markusj]

A* und Navigation deaktiviert (Funktionen gelassen, Inhalt auskommentiert): Absturz innerhalb 1 min.

Wunderbar, das ist eine brauchbare Grundlage für den später beschriebenen Test.

Brownout aktiviert, jetzt gibt es eher das Problem dass dieser gleich beim einschalten aktiviert wird.

Doch Spannungsprobleme? So wie die eingestellte Spannung überschritten wird, sollte der AVR loslaufen ...

ebenso versucht das Register vom Power on Reset auszuwerten, aber damit bekommt man den Kontroller gleich gar nicht zum laufen. Wollte damit einen eventuellen schlechten Kontakt der Steckverbindungen erkennen.

Warum läuft er da nicht an? Da würde ich mich Mal dahinter klemmen, das klingt ... komisch.

Sieht also nach Stackproblem aus, nur wie findet man den Fehler?

Es gibt einen Trick um die Speichernutzung zu betrachten: Den kompletten Speicher mit einem bestimmten Wert beschreiben und dann später nachsehen, wieviel von diesem Wert/Muster noch vorhanden ist. Sieh dir Mal den RN-Wissen Artikel Speicherverbrauch bestimmen mit avr-gcc an.
Mit der o.g. Variante die schon nach einer Minute abschmiert kannst du so schnell rauskriegen, wie sich der Speicherverbrauch entwickelt.

mfG
Markus

[damfino]

Hi,

die uninspiriten Variablennamen wie xx werden nur als einfache Zähler innerhalb einer Funktion verwendet, wichtige Zwischenergebnisse haben normalerweise sinnvolle Bezeichnungen.
Ein Überlauf könnte aber nur ein falsches Ergebnis, aber keine fehlerhafte Ausführung des Programmes bewirken, oder? Wenn die Positionsbestimmung falsch läuft, muss er zB trotzdem die Bumper beachten.

Die Speichernutzung habe ich eingebaut, wird laufend statt der Pos_x im LCD angezeigt, es gibt also keine größere Änderung im Programmablauf. Morgen Abend kann ich wieder testen.

Die Einschaltprobleme könnten vom Stepdown Regler kommen, ich muss die 5V Seite schalten und nicht die 12V damit die Kontroller richtig starten. Aber ohne Oszi wird eine Diagnose schwierig. Vorm Wandler ist ein 470µF Elko, die Kontroller haben alle Abblockkondensatoren und 10k Pullup am Reset. Der 1284 hat zusätzlich einen 100nF am Reset. Der Atmega32 fürs GPS und Display läuft ohne Probleme, die größeren 644 und 1284 sind anscheinend empfindlicher, das musste ich letztes Jahr schon feststellen. Deshalb auch der 2A Step down Regler anstatt eines heisslaufenden 7805.

LG!