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
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!
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
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.
Vor den Erfolg haben die Götter den Schweiß gesetzt
Wunderbar, das ist eine brauchbare Grundlage für den später beschriebenen Test.A* und Navigation deaktiviert (Funktionen gelassen, Inhalt auskommentiert): Absturz innerhalb 1 min.
Doch Spannungsprobleme? So wie die eingestellte Spannung überschritten wird, sollte der AVR loslaufen ...Brownout aktiviert, jetzt gibt es eher das Problem dass dieser gleich beim einschalten aktiviert wird.
Warum läuft er da nicht an? Da würde ich mich Mal dahinter klemmen, das klingt ... komisch.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.
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.Sieht also nach Stackproblem aus, nur wie findet man den Fehler?
Mit der o.g. Variante die schon nach einer Minute abschmiert kannst du so schnell rauskriegen, wie sich der Speicherverbrauch entwickelt.
mfG
Markus
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!
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Dennoch, der Brown-Out müsste nach erreichen einer stabilen Spannung über dem Schwellenwert den AVR loslaufen lassen. Da dem nicht so ist, scheint was mit der Versorgungsspannung im Argen zu liegen. Evtl. möchtest du testweise hinter den Wandler auch nen Elko setzen.Zitat von damfino
mfG
Markus
Der Speichertest hat folgendes ergeben:
normale Fahrt: 15129Bytes frei
bei Navigation mit A*: 12330 Bytes frei.
Ein Ergebnis wie erwartet, das Programm war für die 4k RAM vom Atmega644 ausgelegt.
Neu war neben einem normalen Absturz über den Watchdog, dass er 4x wegen Tiefentladung des Akkus gestoppt hatte. Dazu muss aber 50x in Folge eine Zellenspannung <2.9V sein, die Zellen haben aber alle noch 3.3V, und nach Neustart ist er wieder losgefahren.
Eine lange Recherche im Internet hat eine weitere Möglichkeit gezeigt: es gibt Atmega1284p bei denen über den UART das RAM verändert wird, mit genau diesen unerwarteten Folgen wie bei mir. Auch wenn das UART gar nicht verwendet wird. Dort gab es den Fehler aber nur bei 20Mhz Takt, nicht bei 16Mhz. Ich hab jetzt die UART Pins auf GND gelegt, und einen bisher verwendeten Eingang auf einen anderen PIN umgeleitet. Mal sehen ob das was bringt.
Die Spannungsversorgung ist mit ein paar kleinen Kondensatoren verbessert worden, passenden Elko muss ich erst besorgen.
LG!
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Interessant, oder besser gesagt: Nicht gut. Es wäre interessant zu wissen, wann dein ATMega produziert wurde, scheinbar ist das ein Fehler von Vorserienmodellen.
Für die Akten hier noch zwei Links dazu (die du vermutlich gemeint hast): ATmega1284P memory problem/fix und avrfreaks.net - atmega1284p UART Rx glitch.
mfg
Markus
Berechtigungen
Zitieren
Lesezeichen