Forum: Mikrocontroller und Digitale Elektronik Atmega16 resetiert ohne ersichtlichen Grund


von Alex (Gast)


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

von Benedikt K. (benedikt)


Lesenswert?

CKOPT gesetzt ?

von Alex (Gast)


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

von Benedikt K. (benedikt)


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.

von Alex (Gast)


Lesenswert?

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

von A.K. (Gast)


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).

von Alex (Gast)


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!

von Alex (Gast)


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)

von Stefan (Gast)


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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Brownout-Reset wäre noch eine Möglichkeit, falls aktiviert.

von Alex (Gast)


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

von Alex (Gast)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.