mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMEGA8 ISP trotz RSTDISBL dank BOD?


Autor: Philipp F. (nerdture)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
mir ist gerade so eine Idee gekommen. Mich wuerde einfach interessieren, 
ob das funktioniert.

Und zwar kann man ja mit der RSTDISBL Fuse den RESET Pin als normalen 
I/O-Pin  schalten. Das Problem dabei ist ja, dass man zum 
ISP-Programmieren den ATMEGA in den Reset-State versetzen muss.
Kann man nicht den Brown-Out-Detector einschalten, die 
Versorgungsspannung knapp unter die Brown-Out-Detector-Grenze setzen (wo 
der IC ja trotzdem noch lauffaehig ist), und dann wie gewohnt ISP 
betreiben?

Nicht dass ich unbedingt noch diesen einen I/O Pin braeuchte, davon 
abgesehen hat er ja auch andere Eigenschaften als die anderen I/O Pins, 
aber interessant waer es trotzdem zu wissen, ob jemand schonmal sowas 
versucht hat.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probiert habe ich´s noch nicht, aber ich denke nicht, daß es 
funktioniert, da ich der Auffassung bin, daß das ISP-Modul mit dem 
Reset-Pin mehr oder weniger direkt verdrahtet ist.

Autor: Philipp F. (nerdture)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach Schematic im Datenblatt siehts zwar nicht so aus, aber kann schon 
sein.

Habe gerade mal getestet: Ohne BOD konnte ich den ATMEGA8 ca. 2,5 V 
runterwuergen ohne dass er seinen Dienst aufgegeben hat. Aber er ist 
(wegen internem RC-Oszi) langsamer geworden...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp F. wrote:

> Und zwar kann man ja mit der RSTDISBL Fuse den RESET Pin als normalen
> I/O-Pin  schalten. Das Problem dabei ist ja, dass man zum
> ISP-Programmieren den ATMEGA in den Reset-State versetzen muss.

Wenn Du den Reset-Pin als IO brauchst, dann brenn doch einfach nen 
Bootloader in den AVR.
Damit funktioniert das Reprogrammieren immer.
Und man muß nicht mehr darauf achten, ob sich die ISP-Pins mit der 
Applikation vertragen.
Der Bootloader braucht nur (irgend) einen Pin.


Peter

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Thema ist zwar schon ein paar Jahre alt, doch es ist über Google 
leicht zu finden. Definitive Antworten waren bislang keine dabei, also 
habe ich das mal ausprobiert.

Den Reset manuell (nicht über den Programmer / das ICSP Kabel) zu 
bedienen geht wunderbar. Einfach vor abschicken des avrdude den (noch 
aktiven) Reset-Pin mit GND verbinden und schon geht's. Es braucht nicht 
einmal das -F Flag.

Dann habe ich den BOD auf 4,3V gestellt. Legt man 5V an, kann man diese 
5V auch am Reset Pin messen. Legt man 3,3V an, ist der Reset-Pin (wie 
erwartet) auf 0V.

Programmieren kann man den ATtiny (hier ein ATtiny85) auf die Art 
trotzdem nicht, es kommt keine Reaktion vom Chip. Schade eigentlich.

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutlich hält der BOD auch den Taktgenerator an, und ohne Takt geht ja 
auch ISP nicht....

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Legt man 3,3V an, ist der Reset-Pin (wie
> erwartet) auf 0V.

Woher nimmst Du diese Erwartung?

Nach Lesen des Datenblattes erwarte ich genau das Gegenteil.
Der Reset ist nur ein Eingang mit Pullup nach VCC.
Siehe ATmega8 Datenblatt: Figure 14. Reset Logic

Solange man ihn nicht per Fusebit ausschaltet, hat er gefälligst immer 
high zu sein.
Das interne Reset wird nirgends nach außen gegeben. Das wäre auch 
Quatsch, man hätte dann eine ewige Selbsthaltung, er könnte nie auf high 
gehen.


Peter

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Markus H. schrieb:
>> Legt man 3,3V an, ist der Reset-Pin (wie
>> erwartet) auf 0V.
>
> Woher nimmst Du diese Erwartung?

Das würde der beschriebenen Funktionsweise des BODs entsprechen.

> Das interne Reset wird nirgends nach außen gegeben. Das wäre auch
> Quatsch, man hätte dann eine ewige Selbsthaltung, er könnte nie auf high
> gehen.

Ich bin ja jetzt nicht gerade Experte für uC-Interna, doch woher nimmst 
Du diese Selbsthaltung? Und warum sollte es einen Unterschied zwischen 
einem internen und einem externen Reset geben?

Für mich als Quasi-Laie ist das ganz einfach: Ist Reset Low, läuft das 
Ding im Programmiermodus; ist Reset High, läuft es im Standardmodus. Ein 
Wechsel in den Standardmodus stellt den Adresszähler auf Null.

Der BOD ist von all dem unabhängig und zieht eben bei Spannungsmangel 
den Reset runter (und macht offensichtlich noch was Anderes). Atmel 
beschreibt im Datenblatt ja auch, wie man sich einen externen BOD 
basteln kann, von der Recheneinheit hängt der BOD also eher nicht ab.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Der BOD ist von all dem unabhängig und zieht eben bei Spannungsmangel
>den Reset runter (und macht offensichtlich noch was Anderes).

Nein. Die Resetquellen werden intern über eine Art Or zusammengeführt. 
Da erscheint nichts am Resetpin.

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Das würde der beschriebenen Funktionsweise des BODs entsprechen.

Keinesfalls!

Das BOD geht mit den anderen Resetquellen auf ein ODER-Gatter und dessen 
Ausgang auf das Internal Reset.
Nirgends ist eine Rückführung auf den Reset-Pin zu sehen.

Ich traue Atmel schon zu, Schaltpläne richtig zu zeichnen.
Und keine undokumentierten Pfade einzubauen.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Und warum sollte es einen Unterschied zwischen
> einem internen und einem externen Reset geben?

Schon allein deshalb, weil man im MCUSR die Reset-Quelle später
auslesen können muss.

Kommt noch hinzu, dass man dann eine bidirektionale Padzelle bräuchte,
denn das extern angelegte /RESET-Signal wird ja erst über einiges an
Schaltungskram ins Innere geführt.  Da müsste dann noch zusätzlich
ein Ausgangstreiber dran, der das intern generierte Reset (von Brownout
oder Watchdog) dort wieder nach draußen leitet.

Wäre manchmal praktisch, sowas zu haben (bspw. um externe Peripherie
zugleich zurücksetzen zu können), ist aber bei Standard-AVRs nicht
vorhanden.  Der einzige AVR, der sowas (aber mittels getrenntem Pin
namens RSTON) hat, ist der ATmega128RFA1.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Und warum sollte es einen Unterschied zwischen
> einem internen und einem externen Reset geben?

Kannst Du Dir selbst ganz einfach überlegen:

Sobald man RSTDISBL setzt, ist der externe Reset nicht mehr da, sondern 
ein ganz normaler I/O-Pin. Es wäre daher allein schon Unsinn, nun bei 
aktivem BOD diesen I/O-Pin auf GND zu ziehen.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
68k läßt grüßen mit seinem bidirektionalen RESET.

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Kannst Du Dir selbst ganz einfach überlegen:
>
> Sobald man RSTDISBL setzt, ist der externe Reset nicht mehr da, sondern
> ein ganz normaler I/O-Pin. Es wäre daher allein schon Unsinn, nun bei
> aktivem BOD diesen I/O-Pin auf GND zu ziehen.

Vielleicht ist es noch nicht aufgefallen, doch ich habe das RSTDISBL 
noch gar nicht gesetzt, der Reset-Pin funktioniert noch. Von daher ist 
es auch nicht abwegig, dass der äussere Pin dem inneren entspricht.

Schaltplan hin oder her. Die Atmel Datenblätter sind viel zu 
kompliziert, als dass ich allein aus deren Studium eine zuverlässige 
Aussage treffen könnte. Und wie man an an den Beiträgen vor dem Meinen 
sehen kann, gelang das auch sonst niemandem.

Ansonsten vielen Dank für die vielen Erklärungen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Die Atmel Datenblätter sind viel zu
> kompliziert, als dass ich allein aus deren Studium eine zuverlässige
> Aussage treffen könnte.

Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch 
nicht.
Also da nicht drinsteht, daß der Reset-Pin auch Ausgang ist, ist ers 
nicht.

Ich habs auf dem STK500 nachgeprüft. Ich hab ein Blinkprogramm geladen 
und BOD auf 4V gesetzt. Wenn ich nun die VCC auf 3,3V setze, blinkt 
nichts mehr, da er ja im internen BOD-Reset ist.

Aber der Reseteingang ist natürlich weiterhin high, also genau so, wie 
es laut Datenblatt sein muß. Ist durch den Pullup natürlich kleiner als 
VCC.

Und beim ATtiny85 auch.

Deine 0V waren also eindeutig ein Meßfehler.


Peter

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, noch mal für die letzten Hinterwäldler:

When programming the RSTDISBL Fuse Parallel Programming has to be used 
to
change fuses or perform further programming.

Nix mehr ISP. Schluss, aus, vorbei.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Nix mehr ISP.

Das wurde doch schon vor 4 Jahren geklärt.

Jetzt ging es darum, daß Markus meinte, ein dem Datenblatt 
widersprechendes Verhalten des Resetpins gefunden zu haben.


Peter

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Jetzt ging es darum, daß Markus meinte, ein dem Datenblatt
> widersprechendes Verhalten des Resetpins gefunden zu haben.

Eigentlich gar nicht. Es ging darum heraus zu finden, ob eventuell nicht 
dokumentiertes Verfahren funktioniert. Was der Reset-Pin dabei tut ist 
mir eigentlich wurscht, das habe ich nur beiläufig dazu geschrieben.

> Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch
nicht.

Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader 
verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen 
Bootloader nur geschrieben?

> Deine 0V waren also eindeutig ein Meßfehler.

Noch mehr Beschuldigungen? Ich bedanke mich schon mal im Voraus.

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
>> Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch
> nicht.
>
> Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader
> verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen
> Bootloader nur geschrieben?
Also das war jetzt nich so intelligent ;-)

Ansonsten gilt für deine Behauptung: Big claims require big proofs. Wenn 
du sagst du hast ein Verhalten welches dem DB widerspricht, oder gar 
eine Möglichkeit gefunden ISP ohne Reset-Pin zu machen, dann her damit. 
Reproduzierbar dokumentieren. Sonst ist alles nur heiße Luft. Eine 
verwackelte Messung unter mysteriösen Bedingungen an irgendnem Pin sagt 
da gar nichts aus. Und genau das stört die Leute hier und deshalb gibts 
diese Nicklichkeiten.

gruß cyblord

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader
>verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen
>Bootloader nur geschrieben?

Da es in diesem Thread um den ATMega8 geht solltest du mal das Kapitel

Boot Loader Support – Read- While-Write Self-Programming

im Datenblatt lesen. Dort findest du auch ein kleines Beispiel.

MfG Spess

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cyblord ---- schrieb:
> gar
> eine Möglichkeit gefunden ISP ohne Reset-Pin zu machen, dann her damit

Genau das Gegenteil habe ich behauptet. Es geht nicht. Und 
offensichtlich war ich der Erste, der das mal ausprobiert (und 
dokumentiert) hat, anstatt nur über das Datenblatt zu oraklen. Zumindest 
konnte ich in ausgedehnten Google-Sessions kein entsprechendes 
Versuchsergebnis finden.

Irgendwer hat sich dann zwei nebensächliche Worte raus gepickt und damit 
ein Fass aufgemacht. Prost!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus H. schrieb:
> Irgendwer hat sich dann zwei nebensächliche Worte raus gepickt und damit
> ein Fass aufgemacht. Prost!

Es mag für Dich nebensächlich sein, wenn ein Eingang völlig unerwartet 
ein Ausgang wird, für mich ist es das nicht.
Niemand möchte gerne Überraschungen erleben und dann vielleicht tausende 
Geräte zurückrufen müssen. Und deshalb habe ich das nachgeprüft und 
festgestellt, daß Deine Behauptung falsch ist.

Es gibt natürlich solche ICs, aber dann steht das auch im Datenblatt, 
z.B. der PCF8584. Ich hatte damals allerdings das Datenblatt nicht 
gründlich gelesen. Der Reset dieses IC hing am Bus und hat damit das 
Display nach der Initialisierung resettet. Für das original Display war 
der Reset zu kurz und deshalb war das nicht aufgefallen. Der 
Nachfolgetyp wurde aber dunkel und ich guckte blöd aus der Wäsche. Durch 
ein SW-Update konnte das behoben werden.

Man sollte daher nie etwas annehmen oder behaupten, was einfach nicht 
stimmt!

Wenn Du später mal im Beruf Geräte entwickeln willst, wird Dir solche 
Nachlässigkeit schnell auf die Füße fallen.


Peter

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.