www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega16 resetiert ohne ersichtlichen Grund


Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Schaltung mit dem Atmega16 gemacht.
Bis vor kurzem habe ich gedacht dass alles super funktioniert, aber 
momentan hänge ich an einem Problem: Der Atmega 16 resetiert sich ab und 
zu und ich weiss nicht warum.
Zur Schaltung:
12MHz
Mit einem RS485-Converter wird USART1 angesteuert. Die Verbindung läuft 
unidirektional zum Controller und funktioniert auch einwandfrei.
Über CRC-gesicherte Frames in einem Protokoll werden 16 Ausgänge 
Pulsweitenmoduliert (Timer 0, fast PWM mode) geschaltet die auf einen 
ULN2003a gegeben, wovon jeder einzelne Ausgang dann 25 LEDs mit 24V 
versorgt.
Dazu werden nur noch einige Pins gelesen auf denen Jumper sind die die 
eigene Adresse für das serielle Protokoll einstellen. Diese werden 
während des Betriebes natürlich nicht umgesteckt oder verändert.

Fehlerbild:
Der Atmega16 wird ab und an mal während oder nach dem Empfang eines 
Datenpakets resetiert. Das Datenpaket muss nicht an diesen einen 
Controller gerichtet sein.

Schon Ausgeschlossen:
* Reset-Pin bleibt im Fehlerzustand dauernd High.
* Versorgungsspannung bleibt konstant auf 5V
* Watchdog ist nicht enabled
* Brown-out nicht enabled
* JTAG ist ausgeschaltet
* Start-Up-Time 16CK+0ms

Hat jemand eine Idee was den Reset noch auslösen könnte?
Danke für eure Hilfe,
Alex

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKOPT gesetzt ?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hoffe ich habe das mit dem Clock-Timing habe ich richtig verstanden:

ckopt = 0
cksel3..0 = 1111 -> 12MHz Quarz
sut1..0 = 10 // gemeinsam mit cksel0=1 -> 4.1ms Crystal Pscillator, fast 
rising power

Aber wenns hier was hätte würde der Controller ja gar nicht hochfahren 
oder irgendwann abstürzen.
Mein Problem beschränkt sich auf die Tatsache dass der Absturz 
sporadisch nur dann auftritt, wenn über UART etwas empfangen wird.

Danke,
Alex

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn CKOPT programmiert (also 0) ist, dann passt es.
Wenn das nicht der Fall ist, ergeben sich die merkwürdigsten Sachen. 
z.B. stürtzt der AVR ab wenn jemand durchs Zimmer läuft, oder wenn 
bestimmte Daten  verarbeitet werden.
Ich hatte mal einen AVR, der hat ein Audiosignal verarbeitet (FFT). Ab 
einer bestimmten Lautstärke hat er sich ausfgehängt. Es lag an CKOPT.

Wenn das bei dir nicht der Fall ist, dann hast du wohl einen Fehler in 
der Software.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber wenn kein Watchdog enabled ist kann sich er der atmega16 zwar 
aufhängen aber nicht resetieren.
Oder irre ich mich?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst einmal Grund ermitteln: Nach dem Start MCUCSR auf 
Konsole/LCD/wasimmerdaist ausgeben dann die sich auf Reset beziehenden 
Bits auf 0 setzen.

Und wenn darin nach einem solchen Reset nichts gesetzt ist, dann war es 
einfach nur ein Sprung nach Adresse 0. Kann beispielsweise passieren, 
wenn man im Stack an die falsche Adresse schreiben (buffer overflow).

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist natürlich ein guter Tip, den werde ich gleich mal checken.
An den Stack hab ich hier noch gar nicht gedacht.
Danke!

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um mal laut zu denken:
Ich programmiere in WinAVR c;
Angenommen ich resetiere den UART-framing error nicht und es tritt einer 
auf dann wird der interrupt nicht quittiert und wird damit immer wieder 
kommen.
Irgendwann läuft der Stack über und es kann dadurch zu einem Reset 
kommen.
Stimmt das?
(Ich habe die Hardware nicht bei der Hand, darum kann ich das ganze erst 
in ein paar Tagen wieder testen)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Stack ist recht gut möglich, habe ich selbst schon mal 
"verbaut".
Hatte dabei aus Unachtsankeit eine rcall mit einer rjump Anweisung 
vertauscht - und schon stimmte die Stack Bilanz nicht mehr.
Gruß
Stefan

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brownout-Reset wäre noch eine Möglichkeit, falls aktiviert.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rcall und rjump nimmt mir der compiler ab - der läuft ja hoffentlich 
sonst gäbe es einen neuen patch von Atmel.
Brownout ist ausgeschaltet (siehe erster Eintrag unter schon 
ausgeschlossen).
MFG Alex

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das war der Fehler:
UCSRA_FE: always write this bit to zero.
Wenn ein FE auftritt UDR lesen und Byte verwerfen.
Danke

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.