Mir ist gerade etwas interessantes aufgefallen: Wenn man bei einem ATtiny2313 den Watchdog per Software aktiviert, bleibt dieser auch nach einem Hardware Reset aktiv. Allerdings werden die Prescaler Bits gelöscht, weshalb der Watchdog nach 16ms einen Reset auslöst, selbst wenn man den Watchdog z.B. mit 2s gestartet hat !!! Nur ein Abschalten der Spannung stoppt den Watchdog. Habe ich einen versteckten Hinweis im Datenblatt übersehen, oder ist das wirklich ein übler Bug ?
Benedikt K. wrote:
> Habe ich einen versteckten Hinweis im Datenblatt übersehen
Ja, hast du. Dieses Verhalten trifft auf alle neueren Watchdogs zu.
Das Rücksetzen der Prescaler-Bits könnte man ggf. als Bug bezeichnen,
da es meiner Meinung nach nicht sauber dokumentiert ist (allerdings
ist es logisch, da der Chip ja gerade aus einem Reset kommt). Du
kannst natürlich einen Bugreport bei avr at atmelpunktcom aufmachen
dafür, aber erfahrungsgemäß funktioniert das Reparieren der Doku
nicht sonderlich gut (zu viel cut&paste).
Zum Abschalten des Watchdogs musst du explizit vorher das WDRF-Bit
gelöscht haben. Wegen der 15 ms sollte man das so früh wie möglich
in der Applikation erledigen.
Die Dokumentation zu <avr/eeprom.h> in der avr-libc enthält dafür
ein Beispiel.
Jörg Wunsch wrote: > Das Rücksetzen der Prescaler-Bits könnte man ggf. als Bug bezeichnen, > da es meiner Meinung nach nicht sauber dokumentiert ist (allerdings > ist es logisch, da der Chip ja gerade aus einem Reset kommt). Daher dachte ich ja, dass der Watchdog beim Reset aus sein müsste. Selbst mach einem Neuprogrammieren läuft der Watchdog. Ich habe jetzt nochmal den Watchdog Abschnitt gelesen, aber dort steht nirgends, dass der Watchdog bei einem externen Reset aktiv bleibt, lediglich dass bei einem Watchdog Reset der Watchdog aktiv bleibt (was ja nichtmal so abwägig ist). OK, es steht aber auch nirgends ausdrücklich, dass er nicht eingeschaltet ist... Dieses Verhalten sollte in einem guten Datenblatt eigentlich dick und fett erwähnt werden, zumindest im Errata Abschnitt, denn wenn die Prescaler Bits gelöscht werden, dann war dieses Feature mit Sicherheit nicht Absicht der Entwickler. Vielleicht kommt es ja noch, immerhin ist das aktuellste Datenblatt immer noch ein Preliminary von 2006. Ich befürchte aber langsam, dass Atmel ein wenig überfordert ist: Statt die Controller ordentlich zu machen, werden möglichst viele unterschiedliche AVRs auf dem Markt geworfen...
Benedikt K. wrote: > Daher dachte ich ja, dass der Watchdog beim Reset aus sein müsste. > Selbst mach einem Neuprogrammieren läuft der Watchdog. Ja, lediglich ein power-on-reset löscht ihn (logischerweise). > Ich habe jetzt nochmal den Watchdog Abschnitt gelesen, aber dort > steht nirgends, dass der Watchdog bei einem externen Reset aktiv > bleibt, lediglich dass bei einem Watchdog Reset der Watchdog aktiv > bleibt (was ja nichtmal so abwägig ist). Genau, und genau das ist es, was passiert. Der Watchdog bleibt aktiv, und da du ihn nur abschalten kannst, indem du zuvor das WDRF gelöscht hast, bleibt er auch immer weiter aktiv und resetiert den Chip immer wieder. Die anderen Resets können dem nichts anhaben, die fügen bestenfalls andere xxRF-Flags im MCUSR hinzu. > Dieses Verhalten sollte in einem guten Datenblatt eigentlich dick > und fett erwähnt werden, zumindest im Errata Abschnitt, denn wenn > die Prescaler Bits gelöscht werden, dann war dieses Feature mit > Sicherheit nicht Absicht der Entwickler. Doch doch, ich bin mir ganz sicher, dass das Absicht war. Es soll einer wild laufenden Applikation nicht einfach gemacht werden, den Wachhund los zu werden. Daher musst du dich an ganz bestimmte Befehlsfolgen halten, um ihn auszuschalten.
Ich halte das Verhalten für sinnvoll: Der WD führt letztlich auch nur ein Reset aus und seine Aufgabe ist es, einen Warmstart herbeizuführen, wenn der µC aus irgendwelchen Gründen nicht so reagiert wie erwartet. Da solche Situationen auch in der Warmstart-Prozedur auftreten können, nachdem der WD vorher schon angeschlagen hatte, ist in diesem Fall eine kurze Latenzzeit sehr sinnvoll, einerseits solche Situationen abfangen zu können und andererseits der Initialisierung die Möglichkeit zu geben, den WD mit einem für die Anwendung sinnvollen Wert zu initialisieren.
Bleibt denoch das Argument das zu dokumentieren. Wenn es ein gewolltes Feature ist so gehört das im Datenblatt auch dokumentiert. Jetzt weiß ich auch warum bei mir ständig ein Reset auftauchte den ich mir nicht erklären konnte. Pragmatisch wie ich bin, hatte ich den WD deaktiviert. Gruß Hagen
Seolche Fehler bringen einen echt zur Verzweiflung: Man kommentiert im Quellcode alles aus, bis nur noch sowas dasteht wie: PORTD=255; for(;;); Und mit dem Oszilloskop sieht man dann verwaschene Rechtecke, die eigentlich garnicht da sein dürften. Als letzter Ausweg bleibt dann nur noch den AVR zu wechseln, und dann funktioniert es plötzlich. Ich möchte nicht wissen, wieviele AVRs deswegen schon im Müll gelandet sind...
Benedikt K. wrote: > Seolche Fehler bringen einen echt zur Verzweiflung: Man kommentiert im > Quellcode alles aus, bis nur noch sowas dasteht wie: > PORTD=255; > for(;;); > > Und mit dem Oszilloskop sieht man dann verwaschene Rechtecke, die > eigentlich garnicht da sein dürften. > Als letzter Ausweg bleibt dann nur noch den AVR zu wechseln, und dann > funktioniert es plötzlich. Ich möchte nicht wissen, wieviele AVRs > deswegen schon im Müll gelandet sind... Das riecht aber eher nach Wachhund-Fuse (Wachhund immer an)... ...
Hannes Lux wrote:
> Das riecht aber eher nach Wachhund-Fuse (Wachhund immer an)...
Nö, der neue Wachhund benimmt sich halt sehr ähnlich, nachdem er
einmal gebissen hat. Im Gegensatz zur Fuse kann man ihn aber
wieder loswerden.
Finde auch, so eine Eigenheit sollte gut dokumentiert sein. Gut, dass ich jetzt gewarnt/informiert bin. Vermutlich wird man es indirekt aus dem Datenblatt lesen können, wenn man sich anschaut, was bei einem Reset gemacht wird. Werden dabei keine Steuerregister zurückgesetzt, ist folglich auch der Watchdog noch aktiv.
Jörg Wunsch wrote: > Hannes Lux wrote: > >> Das riecht aber eher nach Wachhund-Fuse (Wachhund immer an)... > > Nö, der neue Wachhund benimmt sich halt sehr ähnlich, nachdem er > einmal gebissen hat. Im Gegensatz zur Fuse kann man ihn aber > wieder loswerden. Ich ging davon aus, dass (wie im von mir zitierten Text) das Programm keine Watchdog-Initialisierung mehr enthält. Dann kann nach einem Power-On der Watchdog nur noch zuschlagen, wenn er per Fuse aktiviert wurde. Dass ein Controller nach dem Programmieren (Flashen) nie wieder von der Betriebsspannung getrennt wird halte ich eher für unüblich. Daher meine ich, dass in einem Programm, dass den Watchdog NICHT initialisiert, der Watchdog auch nicht zubeißen kann, solange er nicht per Fuse aktiviert wurde oder der Controller seit einer vorherigen Programmversion, die den WD initialisierte, unter Spannung gehalten wurde. ...
Hannes Lux wrote: > Ich ging davon aus, dass (wie im von mir zitierten Text) das > Programm keine Watchdog-Initialisierung mehr enthält. Dann kann nach > einem Power-On der Watchdog nur noch zuschlagen, wenn er per Fuse > aktiviert wurde. Das ist in der Tat so. > Dass ein Controller nach dem Programmieren (Flashen) nie wieder von > der Betriebsspannung getrennt wird halte ich eher für unüblich. Es ist offenbar üblicher als du denkst. Ich arbeite grundsätzlich und den ganzen Tag lang so, zumal ich im Wesentlichen mit Controllern arbeite, die per JTAG programmiert (und debuggt) werden, da erledigt die JTAG-Maschine einen zuverlässigen Reset -- aber eben keinen Power-On-Reset. Einen power cycle erleben meine Controller oftmals selbst bei intensiver Entwicklungsarbeit nur alle paar Wochen. Offenbar arbeitet aber auch Benedikt so, sonst wäre er da nicht drüber gestolpert.
Danke, gut zu wissen... Da das Stichwort "Debuggen" gefallen ist, hätte ich noch eine OT-Frage: Kann man in AVR-Assembler (AVR-Studio) eine 16-Bit-Variable (2 Register oder 2 RAM-Zellen) so deklarieren, dass sie im Watch-Fenster des Debuggers als ein 16-Bit-Wert angezeigt wird? Wenn ja, wie? Danke, Gruß, Hannes
X Z oder Y Pointer benutzen, und dann in dem Prozessorfenster, da kannste dann die Werte finden.Anders weiß ich es jetzt auch nicht Gruß Jens
Ich glaub man kann im Memmory View Fenster auf 16bit umschalten!
Jens, dieses Fenster ist sehr unübersichtlich, da es immer zu voll ist. Leider lassen sich uninteressante Objekte nicht einfach ausblenden. Die Pointer sind auch die Register, die ich zuallerletzt für Nicht-Pointer-Aufgaben verwenden würde. Läubi, ich weiß, aber die Einstellung gilt immer für das komplette Fenster. Ich mag das Watch-Fenster, weil man darin "ausgesuchte" Register, RAM-Zellen, I/O-Register usw. übersichtlich und platzsparend anzeigen kann ohne vom (momentan unwichtigen) Rest zugemüllt zu werden. In der Hilfe zum Watch-Fenster sieht man an einem Beispiel, dass auch 16-Bit-Variablen angezeigt werden können, als Speicherort sind zwei Register angegeben. Meine Frage bezog sich darauf, ob dies nur unter C möglich ist, oder auch in Assembler. Trotzdem danke... ...
> Meine Frage bezog sich darauf, ob dies nur unter C > möglich ist, oder auch in Assembler. Der ASM kennt doch sicherlich auch verschiedene Speicherreservierung- Direktiven, oder? Auf den Intelprozessoren sind das z.B DB zum reservieren von Bytes, DW für Worte usw. Der Typ solcher Speicherbereiche wird i.d.R. per Symbolfile dem Debugger mitgeteilt und der kann dann - wenn er kann - die entsprechenden Anzeigeformate auswählen. Wie das bei deinem Hof-Assembler geht, weiß ich allerdings nicht :-(
Hannes
>Da das Stichwort "Debuggen" gefallen ist, hätte ich noch eine OT-Frage:
kann man zum neuen Drachen gratulieren? :-)
Torsten
Angehängte Dateien:
-
DW-Kabel01.jpg
210 KB
@Torsten: Jou, man kann, ich geb' auch 'n Käffchen aus. Westwall ist richtung Norden auch wieder frei. Die Test-Area des Drachen ist aber noch nicht bestückt, da die endgültige Variante (Stifte oder Buchsen) noch nicht feststeht. Dafür hat das ISP/DW-Kabel einen Power-Schalter mit LED, was den Power-off-Zyklus nach Verstellen der DW-Fuse vereinfacht.
Hannes > Jou, man kann Herzlichen Glückwunsch! > ich geb' auch 'n Käffchen aus. Das ist ein guter Grund, da kann ich einfach nicht nein sagen. :-) Von DW habe ich aber Abstand genommen. Nach mehreren debug sessions mit dem Mega168 mußte ich meine beiden Exemplare anschließend mit dem STK500 via HV-Prog wieder beleben. Trotz power Off/On cycle. K.A. warum. Benedikt Bitte nicht böse sein wegen OT Gequatsche Torsten
T.S: wrote: > Von DW habe ich aber Abstand genommen. Nach mehreren debug sessions mit > dem Mega168 mußte ich meine beiden Exemplare anschließend mit dem STK500 > via HV-Prog wieder beleben. Der Drachen kann doch aber auch HV-Programmierung? Naja, DW ist eine nette Ergänzung, um AVR einer Klasse debuggen zu können, bei denen man das früher gar nicht konnte. Aber es kann kein Ersatz für richtiges JTAG-Debuggen sein, das ist bei einem 1-wire-Bus auch nicht wirklich zu erwarten. Ansonsten: ja, man könnte das sicher auch in Assembler machen, aber dann musst du als Programmierer dem Debugger die DWARF-2-Info schreiben. Bei C macht das der Compiler für dich.
Jörg Wunsch wrote: > Ansonsten: ja, man könnte das sicher auch in Assembler machen, aber > dann musst du als Programmierer dem Debugger die DWARF-2-Info > schreiben. Bei C macht das der Compiler für dich. Danke für den Hinweis. Was mir Google über DWARF-2-Info mitteilen wollte, macht mich auch nicht wissender. Da werde ich wohl vorerst auf die ordentliche Anzeige mehrbytiger Variablenwerte verzichten müssen. Naja, auch nicht weiter tragisch. ...
Hannes Lux wrote: > Danke für den Hinweis. Was mir Google über DWARF-2-Info mitteilen > wollte, macht mich auch nicht wissender. Lass den Compiler ein oder zwei Beispiele für dich generieren und guck dir an, welche DWARF-2-Anweisungen er in den generierten Assemblercode schreibt. Zusammen mit einer entsprechenden DWARF-2- Doku hilft das ja vielleicht. Ich gebe aber zu, dass stabs hier einfacher zu verstehen scheint.
Jörg Wunsch wrote: > Hannes Lux wrote: > >> Danke für den Hinweis. Was mir Google über DWARF-2-Info mitteilen >> wollte, macht mich auch nicht wissender. > > Lass den Compiler ein oder zwei Beispiele für dich generieren und > guck dir an, welche DWARF-2-Anweisungen er in den generierten > Assemblercode schreibt. Zusammen mit einer entsprechenden DWARF-2- > Doku hilft das ja vielleicht. Danke Jörg, nur habe ich mangels C-Kenntnisse keinen Compiler installiert. Software, mit der ich nicht umgehen kann, ist mir auf meinem Rechner nicht soooooo wichtig. ;-) Ich bin froh, dass ich mit ASM so halbwegs zurecht komme, da muss (und will) ich mir das C (das ich als sehr kryptisch empfinde) nicht auch noch antun. Ich habe Hochachtung vor Denen, die es (wirklich) können, muss da aber nicht dabei sein. Für meine kleinen Dinge reicht mir ASM. Ich werde mir aber von einem Freund, der C benutzt (und auch ASM kann), mal ein paar vom Compiler erzeugte ASM-Listings schicken lassen. > > Ich gebe aber zu, dass stabs hier einfacher zu verstehen scheint. Das verstehe ich zwar jetzt nicht, macht aber nix... ;-( Danke, '73, Hannes
Also ich kenne beide so ziemlich aus dem ff - daß C kryptischer, als ASM ist stimmt nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.