Forum: Mikrocontroller und Digitale Elektronik AVR m32 hängt sich sporadisch auf


von johnny (Gast)


Lesenswert?

Hallo und frohe Festtage an alle.

Ich habe hier ein Problem für das mir der Lösungsansatz fehlt, ich hoffe 
dass jemand den Umstand kennt und mir eventuell einen Tipp geben kann wo 
ich ansetzen muss.

Und zwar habe ich hier eine Selbstgebaute Kesselsteuerung für meinen 
Heizkessel gebaut. Das ganze Konstrukt besteht aus:
Atmega 32 (DIP), 16MHz Quarz (Abblockkondensatoren 2*100nF)
4*DS18B20
2*16 Zeichen LCD Display
Drehgeber
2-fach Relaisplatine (Relaistreiber befinden sich auf der separaten 
Platine)

Das ganze lief mehrere Wochen fehlerfrei, nun habe ich das Problem dass 
sich der Atmega aufhängt - Displayanzeige bleibt betehen, auf Eingaben 
mittels Drehgeber folgt keine Reaktion, Messen und schalten funktioniert 
ebenfalls nicht.

Was noch erwähnenswert wäre ist dass der Watchdog aktiv ist (mit 2s 
Timeout) dieser jedoch scheinbar ebenfalls ohne Funktion ist.

Wenn ich die Spannungsversorgung kurz unterbreche läuft das ganze dann 
wieder Problemlos weiter (für mehrere Tage). Die Spannungsversorgung 
besteht im übrigen aus einem Hutschienennetzteil mit Stabilen 5V 
(gemessen 5,09V) 2A.


Kennt jemand solch ein Verhalten? Mich wundert sehr dass sogar der 
Watchdog hängt, der hat ja meines Wissens nach sogar eine eigene 
Taktquelle.
Ich hoffe auf sachdienliche Hinweise.

MfG

von Frohe Weihnachten (Gast)


Lesenswert?

Das hört sich nach einem EMV Problem an. Brenner, Pumpen und der Kram 
erzeugen Spitzen und Felder. Das kann den kleinen Käfer richtig 
durcheinander bringen. Du solltest ein paar Entstörmaßnahmen vornehmen.

Damit überhaupt richtige Helfer aktiv werden können, wird der Schaltplan 
und die Einbindung in die Heizungsanlage benötigt.

von F. F. (foldi)


Lesenswert?

Da es ja lange gut lief denke ich eher ans Netzteil.
Was hat sich seit dem verändert? Läuft die Heizung erst jetzt unter 
Last?
Vielleicht kannst du ja mal ein anderes Netzteil anschließen.
Alle Lötstellen gucken ... Kondensatoren, ect. ...

Ich kenne eher dieses Verhalten vom Steckbrett (sprich, schlechte 
Verbindungen).

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Der effektivste Weg, einen AVR trotz Watchdog und/oder sauberer 
Stromversorgung lahmzulegen, dürfte in der Taktversorgung liegen. Manche 
µCs haben eine Art Watchdog für die Taktversorgung, die ggf. auf einen 
Not-Takt umschaltet. AVRs nicht.

: Bearbeitet durch User
von F. F. (foldi)


Lesenswert?

A. K. schrieb:
> dürfte in der Taktversorgung liegen.

... wollte ich noch gerade ergänzen. Das siehst du besonders schön auf 
dem Steckbrett, wenn der Quarz nicht richtig Kontakt hat. Etwas am Quarz 
wackeln und er läuft wieder.

von johnny (Gast)


Lesenswert?

Erstmal vielen Dank für eure Antworten.

Die Taktquelle hatte ich auch vermutet, jedoch hat der Atmega 32 laut 
Datenblatt eine separate Taktquelle für den Watchdog. Sollte das nicht 
bedeuten dass dieser eigenständig läuft? Oder verstehe ich hier etwas 
falsch?

EMV wäre natürlich eine Möglichkeit, jedoch hängt der AVR unabhängig vom 
Betriebszustand der Heizung also auch wenn weder Brenner noch Pumpe 
eingeschalten sind.

Ich werde wohl bei nächster Gelegenheit mal das Oszi nehmen und 
versuchen mir die Quarzfrequenz anzuschauen. Nur das mit dem Watchdog 
macht mich stutzig...

von F. F. (foldi)


Lesenswert?

johnny schrieb:
> Sollte das nicht
> bedeuten dass dieser eigenständig läuft?

Also vom ATmega 32 weiß ich das nicht, aber bei anderen Atmel ist der 
trotzdem abhängig vom Systemtakt.

Da lies doch noch mal selbst das Datenblatt an entsprechenden Stellen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Der Watchdog ist zwar unabhängig vom CPU-Takt, aber wenn der CPU-Takt 
nicht läuft nützt das nichts.

von (prx) A. K. (prx)


Lesenswert?

Ein wenig invasiver Test wäre, den AVR mit internen 8MHz laufen zu 
lassen, statt mit Quarz. Komplizierter als Fuses umstellen und dem 
Programm die geänderte Frequenz mitzuteilen sollte das nicht sein. Der 
obigen Beschreibung nach sollte das auch ausreichen.

Den Takt per Oszi zu kontrollieren ist problematisch, denn eine normale 
Probe am Quarz verändert die Situation signifikant. Ausserdem geht es 
hier um das Langzeitverhalten.

von johnny (Gast)


Lesenswert?

Wohl wahr, der Test mit der internen Taktquelle ist jedenfalls ein prima 
Ansatz. Das werde ich, sobald die Speicher voll sind, gleich einmal 
machen.

Also zu dem Watchdog - wie gesagt - steht im Datenblatt folgendes:

The Watchdog Timer is clocked from a separate On-chip Oscillator which 
runs at 1MHz.

Das finde ich nach wie vor merkwürdig, allerdings steht da eben nicht ob 
zusätzlich ein externer Takt nötig ist. Wäre ja möglich dass der 
Watchdog dauerhaft im Reset hängt wenn der AVR nicht läuft...

von Rudi (Gast)


Lesenswert?

Hi,

naja ich kenne die Atmels nicht so sonderlich gut, aber andere uC's..... 
Also es kann schon sein das der WDT über einen separaten Taktversorgt 
wird, aber das muss man doch konfigurieren! Also wenn man ein Projekt 
auf den uC bringt sollte man seine Takte und deren Quelle schon halbwegs 
kennen.

Wie auch immer wenn du den Quarz im Verdacht hast würde ich mal einen 
margin Test durchführen. Da bekommst du dann auch die richtigen Last C's 
für deinen Quarz......hier mal eine Anleitung....

http://www.murata.com/ensg/products/timingdevice/crystalu/basic/margin

Ansonsten würde ich die Pufferung deiner Versorgungspins prüfen und ggf. 
etwas verbessern.....100nF sind zwar der Klassiker aber nicht immer 
optimal. Probier mal kleinere C's parallel zu schalten die decken dann 
einen anderen Frequenzbereich ab.

Mit freundlichen Grüßen
Marcel

von Marvin (Gast)


Lesenswert?

Hi,

Was für Lastkapazitäten hat der Quartz?
Der WD resettet den uC, aber wahrscheinlich nicht den Taktgenerator. 
Wenn der Takt ausfällt ist er nach einem Reset immer noch nicht da. Bei 
Unterbrechung der Versorgung läuft er wieder mit an.

Temperatur im Raum hat sich geändert um ein paar Grad?

Gruß Marvin

von Rudi (Gast)


Lesenswert?

Hallo,

normaler Weise beschaltet man den Quarz mit 2C's an jedem "Bein" gegen 
GNDQ. Diese sind im algemeinen 10pF groß bzw. dies wird als Startwert 
für die Optimierung genommen. Genau wie 1k Reihen und 1M Parallel R.

Wenn nach einem RST der Takt immer noch nicht da ist liegt da was im 
argen..... sprich das ding schwingt nicht mehr an. Also Quarzbeschaltung 
ansehen und ext. Pufferung optimieren.

Gruß
Marcel

von (prx) A. K. (prx)


Lesenswert?

johnny schrieb:
> Das finde ich nach wie vor merkwürdig, allerdings steht da eben nicht ob
> zusätzlich ein externer Takt nötig ist. Wäre ja möglich dass der
> Watchdog dauerhaft im Reset hängt wenn der AVR nicht läuft...

Der Watchdog läuft auch ohne Quarz. Aber wenn der nur CPU und I/O 
resettet, aber den Quarzoszillator nicht anfasst, dann steckt die CPU 
unverändert in der Klemme.

Rudi schrieb:
> Also es kann schon sein das der WDT über einen separaten Taktversorgt
> wird, aber das muss man doch konfigurieren!

Die Taktversorgung des Watchdogs ist hardwired. Nicht der Timeout, aber 
der Takt aus dem sich der Timeout ableitet. Ein interner, ziemlich 
unpräziser und separater R/C-Oszillator.

: Bearbeitet durch User
von MWS (Gast)


Lesenswert?

CKOPT Fuse gesetzt?

von F. F. (foldi)


Lesenswert?

johnny schrieb:
> The Watchdog Timer is clocked from a separate On-chip Oscillator which
> runs at 1MHz.

Leider weiß ich nicht mehr wo ich den Zusammenhang las, aber da gibt es 
einen.

von F. F. (foldi)


Lesenswert?

So, nun habe ich das doc2551 wieder gefunden. Der Abschnitt 2.5 ist da 
schon sehr interessant.
Vielleicht liest du das ja mal und entdeckst dann evtl. einen 
Programmfehler, wenn es nicht an der Hardware lag.
http://www.atmel.com/Images/doc2551.pdf

von Thomas (Gast)


Lesenswert?

Einen Tipp von mir wegen den DS1830:
Während der 1Wire-Abfrage keine Interrupts verwenden!

Dann hängen die Sensoren (was aber den Watchdog auslösen würde)

von Dietrich L. (dietrichl)


Lesenswert?

Ist der Brown-out Detector eingeschaltet?
Ohne könnte sich der Prozessor bei kleinen Spannungseinbrüchen aufhängen 
- zumindest theoretisch...

Gruß Dietrich

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

In der überwältigenden Mehrzahl versteckt sich hinter so einem 
Fehlerbild ein Softwarefehler. Es soll sogar Leute geben, die den 
Watchdog in einem Timerinterrupt quittieren...

von johnny (Gast)


Lesenswert?

So, ein gesundes neues noch an alle.

Erst einmal vielen Dank für eure Antworten, ich war über den 
Jahreswechsel einige Tage verreist, daher die späte Rückmeldung.

Ein glücklicher Nebeneffekt hat sich durch meine Abwesenheit allerdings 
ergeben - die Fehlerursache ist gefunden.

Und zwar verfügt der Kessel über eine externe Brenneranforderung 
(derzeit bestehend aus einer Steckbrücke), über diese wurde der Kessel 
bis zur Ergänzung der Steuerung ein- und ausgeschalten.

Da ich nicht da war und die Steuerung erneut den Fehler zeigte mussten 
meine Eltern die Steuerung rücksetzen, da ihnen aber nur der o.g. 
Stecker bekannt war steckten sie eben diesen ein und aus. Und siehe da - 
es führte zu einem Reset.

Der Fehler lässt sich nun teilweise auch reproduzieren, es handelt sich 
um ca. 80cm (2x40cm) Steuerleitung welche von der Klemmleiste zum 
Stecker und dann auf den Relaiseingang gelegt ist.

Nun werde ich das ganze etwas entstören und bin guter Dinge dass es dann 
stabil läuft.

MfG

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.