Muss ich Brown out detection aktivieren, wenn ich nur Werte aus dem eeprom lesen will? (atmega8)

[Chris (Gast)]

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.

[Stefan F. (Gast)]

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.

[c-hater (Gast)]

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.

[Chris (Gast)]

Danke, dann rüste ich da noch ein delay nach. Ich wusste nicht, dass das 
auch beim Lesen kritisch ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

[F. F. (foldi)]

Darf ich mal eine Querfrage zum BOD stellen?
Wenn ich 5V Spannungsversorgung habe, auf was sollte der BOD eingestellt 
werden?

[c-hater (Gast)]

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

[c-hater (Gast)]

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

[F. F. (foldi)]

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

[c-hater (Gast)]

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

[Stefan F. (Gast)]

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

[Stefan F. (Gast)]

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

[F. F. (foldi)]

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?

[F. F. (foldi)]

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.

[Thomas (kosmos)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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'?

[Georg A. (georga)]

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

[Peter D. (peda)]

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.