wieder mal unerklärliche Resets

[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!

[markusj]

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.

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.

mfG
Markus

[damfino]

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!

[markusj]

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

[damfino]

Also, das Stillegen des UART hat definitiv das Verhalten verbessert, aber es gibt immer noch (jetzt seltenere) Fälle wo der Watchdog auslöst.

[damfino]

Der Robi war jetzt ein paar Stunden im Einsatz:
UART deaktiviert: eine große Verbesserung, es gibt nur mehr seltene Resets durch den Watchdog.
Als weitere Ursache habe ich den TWI Bus in Verdacht, starte Kommunikation jetzt immer mit zB if(!(i2c_start(0xd0))) ..., und nicht mehr mit i2c_start(_wait). Seitdem löst der Watchdog nicht mehr aus, aber man merkt dass der Bus sich immer wieder aufhängt und Daten verloren gehen. Anscheinend hat vorher der blockierte Bus gleich den Kontroller mit blockiert.
Immerhin ein paar neue Erkenntnisse....

LG!