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
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
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.
aber wenn kein Watchdog enabled ist kann sich er der atmega16 zwar aufhängen aber nicht resetieren. Oder irre ich mich?
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).
Das ist natürlich ein guter Tip, den werde ich gleich mal checken. An den Stack hab ich hier noch gar nicht gedacht. Danke!
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)
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
Brownout-Reset wäre noch eine Möglichkeit, falls aktiviert.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.