www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Watchdog läßt sich nicht stoppen


Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich bin ein Neuling der Programmierung. Ich hoffe, ich bin hier
richtig. Nun zu meinem Problem:
Ich programmiere für den ATMega88 eine Empfängerschaltung für USART,
Daten werden konvertiert und über TWI an eine Motorsteuerung übergeben.
Das funktioniert (auch mit Interruptsteuerung) einwandfrei. Nun soll
diese Schaltung so ganz nebenbei auch einen Accu laden bzw. überwachen
- das funktioniert auch. Nun möchte ich, wenn der ACCU ganz leer ist,
den Prozessor schlafen legen (SLEEP). Dummerweise ist auch ein Watchdog
programmiert, weil die Schaltung über lange Zeit unbeobachtet (im
Wohnwagen) ist. Will ich den Watchdog ausschalten, verwende ich die
Sequenz aus dem ATMEL Datenblatt:
__disable_interrupt ();
__watchdog_reset ();
MCUSR &= ~(1<<WDRF);
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = 0x00;
Dann den Sleep-Mode Power Down und __SLEEP ();
Der Prozessor kümmert sich überhaupt nicht darum und läuft immer wieder
in diese Routine und wieder und wieder....
Wenn ich den Watchdog nicht einrichte, dann legt er sich schlafen, also
kann nur er daran Schuld sein. Ich habe schon alle möglichen
Schreibweisen probiert, aber kein Erfolg. Das Internet gibt auch nicht
viel her zu diesem Thema, bzw. bechreibt immer nur das selbe wie im
Datenblatt. Ich habe auch schon mit wdt.h probiert, aber die
verfügbaren funktionieren nicht mit dem ATMega88. Bitte Hilfe, ich
verzweifle sonst.  Danke.

Wilfried

Autor: Wilfried Jahn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann das sein?
60 mal gelesen und keiner weiß eine Antwort. Sollte dieses Problem noch
nicht irgendwo anders aufgetreten sein?
Sollte ich den Fehler doch noch selber finden, werde ich es hier
posten. Trotzdem Danke für die Aufmerksamkeit.

Wilfried

Autor: Thomas J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird der Watchdog etwa per WDTON-Fuse aktiviert ? Falls das der Fall
ist lässt er sich nicht durch Software abschalten.

Gruss Thomas

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider nein, sonst hätte ich jetzt den Fehler. Der ATMega ist im
Auslieferungszustand (die Fusebits betreffend). Wenn ich das Datenblatt
richtig verstehe (was für Anfänger nicht selbstverständlich ist), dann
ist WDTON defaultmäßig 1 (unprogrammed) und das soll heißen wegen der
Invertierung "nicht gesetzt". Ich habe mir mit den Versuchen zu
Fusebits bereits 2 Meags erschossen, obwohl ich im Internet darüber
schon viel gelesen habe. AVRDude bringt mir beim Lesen der Hfuse 0x20
und Lfuse 0x9D, das sollte richtig sein.

Gruß (und danke)
Wilfried

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wilfried !

Ich habe beim Mega88 keine Probleme beim Watchdog ausschalten. Habe
ebenfalls den Code aus dem Datasheet übernommen, allerding in
Assembler.

Ich initialisiere den WD direkt nach dem Rest, zuvor kommt lediglich
noch der Stackpointer .

Wenn die Fuses richtig sind, kanns eigentlich nur noch an den
Interruptvectoren liegen. Würde ich mal überprüfen.

Schau noch mal nach bezüglich des Watchdogtimer-Prescalers. Hierzu gibt
es auch eine Anmerkung im Datasheet.

Viel Glück, EC

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ecslowhand,

habe jetzt das Programm abgespeckt und es ist nur noch die Routine mit
dem Watchdog und sleep vorhanden (die includes und variablendef.
natürlich auch). Habe auch schon mit ATMEL Support Kontakt, die meinen,
daß mein Code "seems to be OK" sei. Das Einzige, was sie sich
vorstellen können, ist die 4 Clock - Sache. Aber ich verwende doch das
originale Programm aus dem datasheet, da sollte man doch meinen es ist
in Ordnung. Mein Chef hat gestern gemeint, nachdem ich ihm die
Einstellung der Fusebits erklärt (so wie ich es verstehe) hatte, ich
sollte doch das WDTON mal ändern, vielelicht ist das Datenblatt nicht
OK. Nachdem ich dann mit AVRDUDE die Batch - Zeile aus
http://www.klaus-leidinger.de/mp/Mikrocontroller/A...
"avrdude -p ATMEGA88 -P COM3 -b 38400 -c avr910  -U hfuse:w:0x30:m"
eingegeben und ausgeführt hatte, meldete AVRDUDE, daß er beim Verify
nicht 30 sondern 10 gelesen hat, bietet recovery an um dann zu sagen
sorry! 10 heißt, daß SPIEN programmiert ist und das wars dann für ISP.
Es wäre mal gut, wenn mir jemand die Sache mit den Fusebits für den
Mega88 genau erklären könnte, sonst werde ich noch Großabnehmer bei
Atmel und wir sollten doch unser Geld im Land lassen.
Jetzt werde ich den Lötkolben anwerfen.

Wilfried

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Wilfried !

Das WDTON-Bit im HighFuseByte musst Du auf "1" setzen, wenn Du den WD
nicht benutzen möchtest. Dies ist auch der Defaultwert bei
Auslieferung.

Mit den Fusebits ist das eigentlich eine simple Sache, Verwirrung gibts
nur, weil eine "1" nicht unbedingt "enabled" heisst.

Schau doch mal im aktuellen Datasheet (REV G) nach auf Seite 283ff.
Mach Dir doch in Excel o.ä. eine Tabelle, die Dir die Fuses berechnet
und dabei einige "spezielle" wie z.B. SPIEN und auch die CKSELx fix
setzt, damit es keine bösen Überraschungen gibt.

Bezüglich der WD-Initialisierung schaue auch mal ins Datasheet Seite
53.


Lg EC

Autor: Mark Hämmerling (haemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil's grad ums Berechnen der Fuse-Werte ging...

Der Online-Fuse-Rechner ist abrufbar unter: http://palmavr.sf.net/fc/

Ich muß aber nachwievor darauf hinweisen, daß Atmels XML-Files
(hauptsächlich bei älteren AVR-Modellen) teilweise widersprüchlich bis
falsch sind. Und da diese XML-Files das Backend des Rechners bilden,
kann es zu falschen Ausgaben kommen.

Nähere Infos hier:
http://www.mikrocontroller.net/forum/read-1-305204.html

Mark

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an Alle,

habe mir gerade die neue Version "G" von Atmel geholt, aber da steht
nicht viel Neues drin für meine Sache. Ich habe gelesen auf der Seite
283, daß SPIEN nicht über die serielle Programmierung verädert werden
kann. Warum hat dann AVRDUDE die 0x20 der hfuse nicht in 0x30 wie
gewollt, sondern in 0x10 geändert (SPIEN = 1, also unprogrammiert). Ich
habe normalerweise überhaupt kein Problem (ich bin schon älter, aus der
Zeit des 8080) mit der Umrechnung von hex nach binär oder Wertigkeiten
oder..., aber hier steige ich offensichtlich aus. Für den nächsten
Versuch mit dem WD dauert es noch etwas, denn ich muß auf der
selbstgeäzten Platine schon zum 3. mal den Prozessor (TQFP32)
wechseln.

Wilfried

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist Du sicher, das der WD das Problem erzeugt ???
Oben schreibst Du : "Der Prozessor kümmert sich überhaupt nicht darum
und läuft immer wieder
in diese Routine und wieder und wieder....".

Welche Routine ? Die der WD-Initialisierung ? Oder macht der ATMEGA
"zufällig" einen Reset ?

TIPP: Gib Dir doch als erstes (also nach dem power-on-reset) mal das
MCUSR-Register aus (per rs232 oder Leds oder..).

Deaktiviere mal den Sleep-Mode (ist ja auch recht komplex
einzustellen), nicht das Du Dir da irgendwas "ins Gemüse haust".

LG EC

Autor: Wilfried Jahn (wilfried)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ecslowhand,

jetzt kommt ja richtig Leben rein, das macht ja Spaß.
Vielleicht denke ich ja falsch, aber wenn ich den Wachhund erst nicht
enable, also die Initialisierung nicht anspringe, dann schläft der
Prozessor wunderbar und läßt sich nur durch Resetknopf oder aus-ein
wieder zum Leben erwecken, genauso wie ich es haben will. Die Routine,
die ich meine, ist eine Endlosschleife, in der der Accu gemessen wird
und Verschiedenes, wie voll, halbvoll, fastleer, ganzleer (dann soll er
schlafen) erkannt wird und entsprechende Maßnahmen eingeleitet werden
sollen. Eine davon ist eben schlafen. Ich habe das Programm ja schon
abgespeckt, USART, TWI und Interruptsteuerung ist raus. Eine LED hat
bis zur letzten Änderung permanent geleuchtet, die hat im Fehlerfall
dann schnell geblinkt, so als ob das Programm nur bis zum sleep läuft
und dann resetiert wird.
Wer mir verspricht, nicht zu lachen, der kann die PDF im Anhang
anschauen - ich programmiere erst seit ein paar Monaten in C und hab'
mehr auf Erfolg gesetzt als auf programmieren lernen (der Druck von
oben). Das Meiste hab' ich auch schon geschafft, bis auf....

Wilfried

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, hallo,

ich muß da nochmal eingreifen, wenn die PDF so oft angeschaut wird. Das
Programm ist noch lange nicht fertig! Wenn es fertig wird (hoffentlich)
soll es jeden Accuzustand erkennen und auch eine Erhaltungsladung
machen können. Auch habe ich schon an die Steuerung verschiedener
Ladeströme gedacht oder die Erkennung von Accutypen (das wird aber
schwierig).
Oder will da nur jemand etwas zu lachen?

Wilfried

Übrigens ecslowhand, die Vorbereitung für den sleep ist meiner Meinung
nach ganz einfach - nur zwei Zeilen - funktionieren tut es, auch wenn
es zu einfach sein sollte.

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit meinte ich die verschiedenen Konfigurationen (sleep, powerdown,
powersave,...). Die "Wakeup"-Initialisierungen der entsprechenden
Module  wird oft vergessen und plötzlich macht der Prozessor nicht das,
was man sich erhofft (erdacht) hat.

LG EC

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ecslowhand,

OK, verstanden. In meinem Fall soll ja nur ein Reset oder Spannung
unterbrechen wieder zum Start führen, da brauch ich mir auch keine
Gedanken machen, den Knopf wird jeder finden.
Übrigens, Platinchen läuft wieder. Aber das nächste Mal wird es eine
Flickerei. Es sind schon 2 Pad's angehoben. Nach dem Neuprogrammieren
ist mir dann aufgefallen, daß ich auch den Aufruf "init_usart();"
gelöscht habe - bei soviel Unterspannung ist allerdings mein Fehler
sofort wieder aufgetreten.
Hatte gerade eine kleine Pause während des Schreibens. Ich habe die
"wdt_init" mal disabled und hab' mich gewundert, warum der Fehler
immer noch auftritt. Erst nachdem ich auch den Aufruf "wdt_off" mit
// behandelt hatte, geht er wieder in den Schlafmodus. Das heißt, meine
Routine "wdt_off" schaltet den Hund EIN! UND DAS SOLL NICHT SEIN!

Wilfried

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
void wdt_off ()
{
__disable_interrupt ();
__watchdog_reset ();
 
   MCUSR = 0x00;
   WDTCSR |= (1<<WDCE) | (1<<WDE);
   WDTCSR = 0x00;

__enable_interrupt ();
}

kann man sich ja nun eigentlich nur noch so erklären, das das verodern
und zurückschreiben evtl. länger als 4Takte dauert.
Kannst Du dir nicht mal den erzeugten ASM der Routine wdt_off()
ausgeben lassen? Vlt. istz die Compileroptimierung irgentwie blöd
eingestellt und es dauert 5 oder 6 Takte.
Denn erst bei Atmega 48/88 usw. "liegt" der Watchdog im extenden
IO-Bereich und ist nicht mehr mit IN/OUT, sondern mit STS/LDS ect. zu
erreichen. Das braucht wohl zwei Takte länger.
Allerdings sollte der IAR da locker irgentwas fertiges bei haben, um
den Watchdog ein-und auschaltzen zu können, oder?

Autor: Wilfried Jahn (wilfried)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel,

daran habe ich auch schon gedacht und den Wert als 0x1e ausgegeben. Der
Abstand zwischen dem ersten sts und dem nächsten sind eigentlich nur 2
Taktzyklen. Nämlich der nächste Ladebefehl (ob mit 1<< oder 0x ist hier
dasselbe). Wenn man den sts, der das WDCE - Bit setzt nicht rechnet weil
er ja schon gelaufen ist, dann sind es wirklich nicht mehr. In der
angehängten PDF (leider keine bessere Qualität möglich mit meinen
augenblicklichen Mitteln) ist das gut zu sehen mit entspr.
Vergrößerung. Außerdem ist bei der Initialisierung dieselbe Problematik
und da funktioniert es ja ausgezeichnet. Ich habe schon mal aus dem
Internet eine wdt.h probiert, aber die funktioniert überhaupt nicht
oder ich bin zu dumm (500 errors). IAR selbst gibt darüber nichts her.
Ich weiß jetzt natürlich auch nicht, wieviele Taktzyclen ein sts
braucht aber Atmel sollte es schon wissen sonst hätten sie sich den
Druck sparen können.

Wilfried

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STS braucht 2 Taktzyklen

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na dann weis ich auch nicht.
vlt. durch den Simluator vom AVR Studio schieben und den CycleCounter
ansehen? Wird der IAR ja auch irgentwas in der Art haben. kA.

Gruß und viel Erfolg/Glück noch
AxelR.

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, an alle, die sich hier beteiligt haben.

Jetzt funktioniert mein Watchdog!
Mit Freude kann ich verkünden, daß ich den Fehler selbst beseitigt
habe, allerdings ist dies nicht ohne Eure Hilfe geschehen. Die
hartnäckigen Hinweise auf diese 4 Zyklen haben mich auf eine Idee
gebracht, die allerdings vom original Datasheet abweichend ist. Es ist
schon schwach von Atmel, ein Assemblerprogramm abzudrucken, das so
nicht funktionieren kann, denn da hat der Compiler möglicherweise nicht
mehr soviel Einfluß darauf.
Nun zu meiner Lösung, die sicher mancher brauchen kann.
Ich habe (mit IAR - Compiler) ein Register (15) gelockt, dieses mit dem
Befehl
"__regvar __no_init unsigned char WDTCSR_BYTE @15;"
definiert, das ich in der main belegen kann. Jetzt gibt der sts direkt
das R15 aus ohne es vorher mit ldi laden zu müssen.
Ich hab' natürlich mit einer Endlosschleife getestet, ob der Watchdog
überhaupt noch funktioniert - er tut es, und diesmal auch mit der
eingestellten Zeit. Ich muß zugeben, daß die Idee zwar von mir ist, für
die Ausführung habe ich allerdings gespickt und bis zum funkionieren die
Errormeldungen des Compilers ausgewertet.
Vielen herzlichen Dank nochmal für alle, die sich an diesem Problem
beteiligt haben. Jeder hat ein bisschen dazu beigetragen. Beim nächsten
Problem bin ich wieder hier.

Viele Grüße

Wilfried

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Respekt!
Und das hat noch kein anderer rausgefunden?
Wie machen das andere Compiler? ich habe mal das Forum durchforstet,
aber nichts in der Art gefunden.
Schade ums R15, oder?

AxelR.

Autor: Wilfried Jahn (wilfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal danke für die Anerkennung, aber Not macht erfinderisch, außerdem
denken vielleicht gerade Anfänger noch "ungebremst".
Eigentlich müßte es gereicht haben, denn in Assembler angeschaut
brauchen ein ldi und ein sts nur 3 Takte. Aber ich weiß ja nicht, was
der IAR noch dazubastelt, dazu müßte man den hex-code disassembieren.
Aber man muß ja nicht alles wissen. Ich habe auch mit dem AVR-Studio 4
probiert, aber das konnte ich gar nicht starten, der hat alle in der
iom88.h definierten pin's angemeckert. Wahrscheinlich hat noch
irgendwas gefehlt. Außerdem bin ich jetzt mit dem IAR eingearbeitet,
der ist auch bis 4K kostenlos. Das R15 kann ich noch verschmerzen, der
ATMega88 hat genug davon (noch).
Nochmal vielen Dank. War bestimmt nicht das letzte mal hier.

Wilfried

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.