Forum: Mikrocontroller und Digitale Elektronik Bug in ATtiny2313?


von Benedikt K. (benedikt)


Lesenswert?

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 ?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Benedikt K. (benedikt)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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.

von Hagen R. (hagen)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

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

von Hannes L. (hannes)


Lesenswert?

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

...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Winfried (Gast)


Lesenswert?

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.

von Hannes L. (hannes)


Lesenswert?

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.

...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Hannes L. (hannes)


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Ich glaub man kann im Memmory View Fenster auf 16bit umschalten!

von Hannes L. (hannes)


Lesenswert?

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

...

von Uhu U. (uhu)


Lesenswert?

> 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 :-(

von T.S: (Gast)


Lesenswert?

Hannes

>Da das Stichwort "Debuggen" gefallen ist, hätte ich noch eine OT-Frage:

kann man zum neuen Drachen gratulieren? :-)

Torsten

von Hannes L. (hannes)


Angehängte Dateien:

Lesenswert?

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

von T.S: (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Hannes L. (hannes)


Lesenswert?

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.

...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Hannes L. (hannes)


Lesenswert?

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

von Uhu U. (uhu)


Lesenswert?

Also ich kenne beide so ziemlich aus dem ff - daß C kryptischer, als ASM 
ist stimmt nicht.

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.