Hallo,
brauche ich die Brown out detection nur, um Schreibzugriffe abzusichern,
oder kann der eeprom-Inhalt auch verändert werden, wenn man gar nicht
rein schreibt?
Ich habe eine "LED-Anordnung", bestehend aus 5 Modulen, die jeweils von
einem Atmega 8 angesteuert werden. Zwischen den Modulen liegen 3 Adern
für 5V, GND und serielle Daten.
Im eeprom jedes dieser Module ist ein Byte abgelegt, 1, 2, 3, 4 oder 5,
entsprechend der ID des Moduls. Somit kann die Firmware und Hardware
überall identisch sein. Die Firmware liest diesen Wert beim Start
einmalig aus und legt ihn in einer Variable ab. Schreibzugriffe finden
sich im Code keine.
Nun ist es mehrfach passiert, dass die eeprom-Daten sich von selbst
verändert haben und an der eeprom-Adresse irgend ein anderer Wert stand.
Seit Aktivieren der BOD scheint das nicht mehr zu passieren.
Ja, das EEPROM ist auch beim Lesen gefährdet, wenn die
Spannungsversorgung instabil ist. Der Brown-Out Detektor hilft dagegen.
Ich hatte bei manchen Schaltnetzteilen das Problem, dass sie beim
Einschalten zunächst kurz genug Spannung abgeben und dann doch nochmal
absacken. Dagegen hilf der Brown-Out Detektor nicht vollständig.
Deswegen habe ich ganz am Anfang meines Programmes VOR dem Auslesen des
EEPROMS nochmal zusätzlich eine Sekunde Delay eingebaut.
Die Kombination aus Delay + Brown-Out Detektor stellte sich als 100%
verlässlich heraus.
Chris schrieb:> brauche ich die Brown out detection nur, um Schreibzugriffe abzusichern,> oder kann der eeprom-Inhalt auch verändert werden, wenn man gar nicht> rein schreibt?
BrownOut kann allen möglichen Scheiß bewirken, die Korruption des
EEPROM-Inhaltes ist dabei in den meisten Fällen noch als eher harmlos
einzustufen. Viel ultimativer kann die Flash-Korruption wirken...
Beides ist weitgehend unabhängig davon möglich, ob dein Code
Schreiboperationen für EEPROM oder Flash enthält. Das Vorhandensein
solcher Codeteile steigert nur die Wahrscheinlichkeit, daß es passiert,
die Absenz solcher Codeteile garantiert aber leider keinesfalls, daß es
nicht passiert.
> Nun ist es mehrfach passiert, dass die eeprom-Daten sich von selbst> verändert haben und an der eeprom-Adresse irgend ein anderer Wert stand.> Seit Aktivieren der BOD scheint das nicht mehr zu passieren.
Glückwunsch: Du hast nicht nur den Sinn des BOD entdeckt, sondern gleich
auch noch dessen Wirksamkeit empirisch nachgewiesen...
Kurzfassung: Du hast etwas gelernt.
Stefan Us schrieb:> Ja, das EEPROM ist auch beim Lesen gefährdet, wenn die> Spannungsversorgung instabil ist.
Inwiefern?
> Der Brown-Out Detektor hilft dagegen.
Inwiefern?
Gefährdet ist das EEPROM nur, wenn die Löschspannung erzeugt wird, und
durch den Powerfail der Schreibpointer auf eine ungültige Adresse
umkippt. Das ist dann gerne die Adresse 0, und dann wird zwar mit dem
Löschen und Programmieren der eigentlichen Zelle begonnen, aber beim
Powerfail mit einer anderen weitergemacht. Fazit: beim Schreiben kann
jede beliebige Zelle korrumpiert werden.
Der BrownOut hilft dagegen nicht prinzipiell, sondern er verringert
nur die Wahrscheinlichkeit, dass bei zu niedriger Spannung ein neuer
Schreibvorgang begonnen wird. Und dann reicht die verbleibende
Spannung im System hoffentlich noch zum Fertigschreiben der Zelle. Wenn
aber keinerlei oder nicht ausreichend große Pufferkondensatoren im
System sind, wird weiterhin das EEPROM korrumpiert werden...
Chris schrieb:> Danke, dann rüste ich da noch ein delay nach.
???
Du hast echt nicht begriffen, was BrownOut ist. BrownOut bedeutet, daß
der µC schlicht abstürzt, weil die Spannung nicht mehr (oder noch nicht)
genügt, um einen regulären Programmablauf sicherstellen zu können.
D.h.: In deinem Programm selber kannst du rein garnichts dagegen tun,
denn es wird ja gerade nicht mehr so abgearbeitet, wie du es geschrieben
hast. Das gilt sogar dann, wenn es eigentlich tatsächlich fehlerfrei
ist...
F. Fo schrieb:> Darf ich mal eine Querfrage zum BOD stellen?> Wenn ich 5V Spannungsversorgung habe, auf was sollte der BOD eingestellt> werden?
Das hängt vom Takt ab. Je höher der Takt ist, desto höher ist die
Spannung, die nötig ist, damit der µC noch korrekt arbeitet. Das
entsprechende Diagramm kannst du in jedem noch so verschissenen
Datenblatt finden und daran auch direkt ablesen, wie der BOD
einzustellen ist. (eigentlich: einzustellen wäre)
Leider ist die Wahl bezüglich des BOD-Treshold nicht so variabel, wie
man sie gern hätte. Man benutzt einfach die Schwelle, die dem aus o.g.
Diagramm entnommenenen Wert am nächsten kommt und betet, daß es
jederzeit reichen möge...
c-hater schrieb:> Das hängt vom Takt ab. Je höher der Takt ist, desto höher ist die> Spannung, die nötig ist, damit der µC noch korrekt arbeitet. Das> entsprechende Diagramm kannst du in jedem noch so verschissenen> Datenblatt finden und daran auch direkt ablesen, wie der BOD> einzustellen ist.
Ich habe mal gerade beim Tiny13 nachgesehen. Also ein Diagramm gibt es
nur über den Stromverbrauch vom BOD, aber als Fußnote stand irgendwo,
dass "einige IC's " direkt unterhalb Vcc liegen sollen.
So stelle ich den schon immer ein. Gab auch noch nie Probleme.
Aber Interessantes habe ich auch, dank dieses Themas hier, dort gelesen,
was ich bisher nicht wusste.
Dann bin ich mal wieder raus. :-)
F. Fo schrieb:> Ich habe mal gerade beim Tiny13 nachgesehen. Also ein Diagramm gibt es> nur über den Stromverbrauch vom BOD
Es gibt weit mehr als 100 Diagramme im DB des Tiny13. U.a. diese beiden
neckischen auf Seite 117 (Abschnitt 18.3 "Speed Grades")...
Ja, Datenblätter setzen eine gewisse Eigenintelligenz voraus. Es ist
einfach völlig unmöglich, von jeder Stelle aus auf alle denkbaren
Abhängigkeiten des jeweils dargestellten Sachverhalts explizit zu
verweisen...
Aber wenn man ein nur einigermaßen funktionsfähiges Gehirn besitzt,
sollte es nicht so schwer sein, aus dem Sachverhalt, daß bei Takt X erst
oberhalb Spannung Y ein sicherer Betrieb möglich ist und der Tatsache,
daß der BOD den "Betrieb" überhaupt erst ab Spannung Z freigibt, den
Schluß zu ziehen, daß es eventuell nützlich wäre, Z >= Y zu
konfigurieren...
> Du hast echt nicht begriffen, was BrownOut ist.
Doch habe ich. Aber in diesem Fall ist das Problem nicht immer ein
abgestürzter Mikrocontroller. Bei instabiler Versorgungsspannung kommt
es manchmal vor, dass der AVR sein Programm völlig korrekt abarbeitet
und trotzdem Inhalte des EEPROMS verloren gehen. Dieser Effekt passiert
nicht nur bei AVR, sondern auch bei vielen anderen Chips mit EEPROM.
Der Brown-Out Detektor hat in diesem Fall primär die Aufgabe, den
Controller anzuhalten, wenn die Versorgungsspannung für ordentliche
Funktion des EEPROM unzureichend ist.
@Lothar:
>> Schreibzugriffe finden sich im Code keine.> Der BrownOut hilft dagegen nicht prinzipiell, sondern er> verringert nur die Wahrscheinlichkeit, dass bei zu niedriger> Spannung ein neuer Schreibvorgang begonnen wird.
Das passt nicht ganz zusammnen. Ich kann aus mehrfacher Praxis-Erfahrung
(nicht nur mit AVR's) bestätigen, dass bei instabiler
Versorgungsspannung auch reine Lesezugriffe destruktiv wirken können.
Ich stimme Dir aber zu, dass der Brown-Out Detektor die
Warscheinlichkeit reduziert.
c-hater schrieb:> F. Fo schrieb:>>> Ich habe mal gerade beim Tiny13 nachgesehen. Also ein Diagramm gibt es>> nur über den Stromverbrauch vom BOD>> Es gibt weit mehr als 100 Diagramme im DB des Tiny13. U.a. diese beiden> neckischen auf Seite 117 (Abschnitt 18.3 "Speed Grades")...>> Ja, Datenblätter setzen eine gewisse Eigenintelligenz voraus. Es ist> einfach völlig unmöglich, von jeder Stelle aus auf alle denkbaren> Abhängigkeiten des jeweils dargestellten Sachverhalts explizit zu> verweisen...>> Aber wenn man ein nur einigermaßen funktionsfähiges Gehirn besitzt,> sollte es nicht so schwer sein, aus dem Sachverhalt, daß bei Takt X erst> oberhalb Spannung Y ein sicherer Betrieb möglich ist und der Tatsache,> daß der BOD den "Betrieb" überhaupt erst ab Spannung Z freigibt, den> Schluß zu ziehen, daß es eventuell nützlich wäre, Z >= Y zu> konfigurieren...
Mein Gott, warum gleich so aggressiv?
Ich bin mit der Suchfunktion nach "Brown" gesprungen und nur eine
Tabelle war "in der Nähe" zu sehen.
c-hater, ich weiß ja, dass du der Intelligenteste hier bist und
zumindest ich zu doof bin ein Datenblatt "richtig" zu lesen.
Bist du jetzt zufrieden?
Habe mir jetzt mal die Diagramme angesehen.
Bisher habe ich mir immer das raus gesucht, was ich im Moment brauchte.
Aber ich muss sagen, da steht ne Menge drin, was ich noch nicht wusste
und sicher mal sehr hilfreich sein wird.
Aber C-hater, weißt du, ich lese schon ne Menge Datenblätter und zu
jedem IC gibt es ein Datenblatt, alle nie sehr kurz. Wenn ich dann auch
noch mal was bauen will und ich zunächst alle Datenblätter dieser Welt
eingehend studieren soll, dann würde ich wohl nie was bauen.
Es ist nicht mein Beruf und ich mache das vor allem aus Spaß an der
Sache. Daneben habe ich einen Beruf, einen Haushalt zu versorgen, meine
Freundin, immer auch mal was in der Wohnung oder am Auto/Fahrrad zu
reparieren, bei meiner Freundin fällt auch dies und das an.
Mein Leben besteht nicht nur aus Elektronik und vor allem nicht aus dem
Studieren von Datenblättern.
Nebenbei gibt es auch noch Sport und auch manchmal, man möge es mir
verzeihen, auch einfach mal keinen Bock.
Probiert es doch mal mit einem 10µF Elko parallel zum 100nF Kerko. Ich
frage mich wie schlecht muss die Versorgung sein das sie die paar
zusätzliche mA beim Eeprom Zugriff nicht verträgt.
Und mir will immer noch nicht eingehen, wie so ganz ohne
"Hochspannung" der Inhalt der Zelle korrumpiert werden könnte...
Stefan Us schrieb:> Ich kann aus mehrfacher Praxis-Erfahrung (nicht nur mit AVR's)> bestätigen, dass bei instabiler Versorgungsspannung auch reine> Lesezugriffe destruktiv wirken können.
Was passiert dann mit den Zellen? Werden die auf '1' gelöscht, oder auf
'0' geschrieben? Was bedeutet 'instabile Versorgung'?
> Und mir will immer noch nicht eingehen, wie so ganz ohne> "Hochspannung" der Inhalt der Zelle korrumpiert werden könnte...
Wollte mir auch nicht. Bis es immer mehr Fälle von Flash-Corruption bei
einem 8515 gab, wobei da in der SW weder EEPROM noch Flash-Schreiben
benutzt wurde. Dann habe ich die Versorgungsspannung einfach mal
zitterig per Draht angelegt und innerhalb von 10s war das Flash versaut.
Tw. waren auch die Flash-Fuses verstellt (kein Lesen des Flashs mit LPM
möglich). Mit dem BOD war das Thema erledigt.
Beim ATmega8 ist die POR-Schwelle bei 1,4V, der erlaubte Arbeitsbereich
beginnt aber erst ab 4,5V (ATmega8L: 2,7V).
Das POR funktioniert also nur dann, wenn die VCC schnell genug den
Arbeitswert erreicht und auch nicht zwischendurch einbricht.
Das BOR zu enablen ist daher immer Pflicht, außer man will absichtlich
Obsoleszenz einbauen.
Insbesondere bei Batteriebetrieb kann es leicht beim Wechseln der
Batterie zu mehrfachen Kontaktunterbrechungen kommen und Flash oder
EEPROM korrumpiert werden.
Falls der Stromverbrauch des internen BOR zu hoch ist, gibt es auch
externe Reset-ICs mit <1µA Verbrauch.
