EEPROM Beständigkeit

[ikarus_177]

Hi,

ich speichere im EEPROM eines M32 diverse Kalibrierungs- und Interpolationsdaten für die Ansteuerung meiner Servos. Diese Daten machen pro Hexa-Bein 37 Bytes aus, die nach Abschluss der Kalibrierung im EEPROM abgelegt werden. Beim nächsten Programmstart lädt der Bot diese Daten wieder, um die Servos korrekt ansprechen zu können.
Die EEPROM-Files habe ich mit Bascom als *.bin - Dateien am Computer gesichert, um sie gegebenenfalls neu aufspielen zu können.

In den meisten Fällen funktioniert dieses Verfahren auch. Allerdings tritt es manchmal auf, dass anscheinend falsche Werte für einen Servo geladen werden, dieser Servo fährt dann entweder an den Endanschlag oder bewegt sich überhaupt nicht. Nach einem erneuten Aufspielen des (gesicherten) EEPROM - Inhaltes funktioniert alles wieder wie gewohnt. Noch hab ich kein System hinter diesem Verhalten beobachten können - es tritt bei unterschiedlichen Controllern auf, und wie es derzeit den Anschein macht - rein zufällig.

Ist dies ein "normales" Verhalten eines EEPROM's, falls nein, womit kann dieses Verhalten begründet werden? Hat jemand eine Idee?

Viele Grüße
ikarus_177

[Besserwessi]

Das gegelgentliche überschreiben von EEPROM Inhalten kann vor kommen, wenn die Versorgungsspannung langsam sinkt und der µC dann noch ein paar Befehle mit viel zu kleiner Spannung ausführt. Dabei passiert es gelegentlich auch mal das das EEPROM (und angeblich gelegentlich auch mal das flash) überschrieben wird. Meistens die Speicherstelle 0. Die erste Abhilfe ist es nicht gerade das Byte an der Adresse 0 zu nutzen.

Die richtige Lösung ist es den Brownout Detektor zu aktivieren. Oder wenn keinen internen gibt (alte chips) einen externen Brownoutdetektor/Spannungswächter zu nutzen.

[ikarus_177]

Hi,


... Speicherstelle 0 ... | ... überschrieben wird ...
Das habe ich in der Bascom-Dokumentation auch gelesen und deshalb die Adresse 0 unbelegt gelassen. Daran kann es also nicht liegen, da bis jetzt nur die höheren Adressen (~18 - ~ 36) fehlerhaft sind.

Ist denn die Brown-out Detection bei den ATMegas standardmäßig deaktiviert? Sonst werde ich sie am Wochenende einfach mal einschalten, vielleicht ergibt sich ja dann etwas.

Viele Grüße

EDIT: So, hab grad die Brown - out - Schwelle bei allen beteiligten Controllern auf 4V eingestellt (war die höchste auswählbare Spannung im myAVR ProgTool). Reicht denn diese Schwelle aus?

[sdz55]

Das gegelgentliche überschreiben von EEPROM Inhalten kann vor kommen, wenn die Versorgungsspannung langsam sinkt und der µC dann noch ein paar Befehle mit viel zu kleiner Spannung ausführt.Kann bei guter Programmierung nicht vorkommen!!

[thewulf00]

@sdz55: Du weißt nicht, wovon Du redest.
Besserwessi hat recht, dass die Überschreibung von Inhalten nicht-flüchtiger Speicher bei sinkender Versorgungsspannung ungewollt und programmunabhängig passieren kann.

Bitte antworte nur, wenn Du was beizutragen hast.

[sdz55]

@sdz55: Du weißt nicht, wovon Du redest.
Besserwessi hat recht, dass die Überschreibung von Inhalten nicht-flüchtiger Speicher bei sinkender Versorgungsspannung ungewollt und programmunabhängig passieren kann.

Bitte antworte nur, wenn Du was beizutragen hast.Danke gleichfalls... Wenn du Brown-Out detection kennst, dann wüsstestdu dass ich recht habe.. Oder wie wärs denn mit der Stromausfallzeit? Bei Stromausfall hast du eine Flanke von ein paar Nano-Sekunden, dazu gerechnet noch die Kapazität oder eventuell Stützbatterien... Ich weiss sehr wohl wovon ich rede mein lieber.

[Besserwessi]

Durch die Abblockkondensatoren dauert es oft relativ lange bis die Spannung von etwa 4 V (darüber sollte noch alles oK sein) bis auf etwa 1 V (darunter sollte nicht mehr viel passieren) fällt. Das kann durch aus ausreichen, das die CPU noch ein paar relativ unkontrollierte Operationen ausführt, die auch nicht unbedingt was mit dem Programm zu tun haben müssen. Selbst wenn das Programm nie das EEPROM nutzt kann (muß aber nicht) so mehr oder weniger zufällig das EEPROM verändert werden.

Es ist dabei gut möglich das einige Exemplare des Chips keine sichtbaren Fehler zeigen und einzelne Chips bevorzugt eine EEPROM Addresse verändern, je nach dem welches Gatter zu erst aufgiebt oder Störungen einfängt. Wegen des eher zufälligen und seltenen Fehlers hatte man bei den ersten µCs auch noch keinen Brownout Detektor drin.

Der Brownout detektor verhindert gerade solch unkontrolliertes Verhalten in dem der µC bei zu kleiner Spannung im Rest-zustand bleibt.

Bei ganz kurzen Spannungseinbrüchen wegen fehlender Enkoppelkondensatoren hat man dann ein anderes Problem, dass man aber auch lösen kann.

Edit: zum Nachlesen: Atmel application Note AVR180

[Ceos]

@SDZ ich muss dir auch wiedersprechen, brown out schützt NICHT

selbst wenn ich extern nen reset veranlasse ( OPV-schaltung mit bandgap)... eeprom nutzung KANN kritisch sein, selbst nur beim lesen veränder sich bei mir die werte, wenn die spannungsversorgung mal nicht ganz hinhaut oder ich nen wackler beim anschluss habe

hm hab das note mal überflogen, die einschaltverzögerung ist sehr interessant das problem trat bisher fast nr auf wenn ich beim einschaten ein starkes prellen hatte (oder anstecken)

by the way, der ausdruck "bei guter Programmierung" passt ja auch net ganz, ist ja hardware net software

[sdz55]

ja aber du kannst die BrownOut auch ausschalten ;-)
Das ein eeprom in einem integrierten chip wie einem uC keine hundert prozentige lösung darstellt ist auch mir klar. Fakt ist, dass man solche speicher auslagern und mit stützbatterien sichern sollte. Dann kann man dazu vielleicht ein eeprom nehmen welches sich per hardware (Pin) schützen lässt
mfg

[Ceos]

ich bin bis heute nicht dazu gekommen die idee zutesten, aber wie wäre es wenn ich den controller, an allen aktiven pins über .... sagen wir mal mit dioden entkopple (bei einem bus müsste es wohl schon ein optokoppler sein) und in der µC-versorgung einen relativ dicken kondensator verbaue, der auch mnit einer diode gegen entladung durch die restlichen schaltung geschützt wird ... wnen ich jetzt ne externe spannungsüberwachung dran habe und nurnoch den controller aus dem kondensator speisen muss, während der rest der schaltung unter spannungsmangel leidet, müsste doch theoretisch ein sicheres abschalten gewährleistet sein?!? zusätzlich ne zeitliche einschaltverzögerung einbauen

[thewulf00]

@sdz55:
Die BrownOut hat nichts mit der Programmierung zu tun. Also erst überlegen, dann schreiben. Darüberhinaus schützt sie nicht.

Und mal ganz unter uns: Deine Antwort hat hier keinem was genützt.

[ikarus_177]

Also bietet die Brown - out - Detection auch keinen (Schreib-) Schutz für das EEPROM? Dann kann man sich ja nie wirklich sicher sein, dass seine Daten beim "Herunterfahren" des Systems nicht verändert werden :-k

Viele Grüße

[thewulf00]

Das kommt drauf an, wann und wo Du "runterfährst".

[ikarus_177]

@thewulf00: Wann kann ich denn davon ausgehen, dass das EEPROM verändert wird, wenn der Controller resettet bzw. die Stromversorgung abgeschaltet wird?

Viele Grüße

[sdz55]

@sdz55:
Die BrownOut hat nichts mit der Programmierung zu tun. Also erst überlegen, dann schreiben. Darüberhinaus schützt sie nicht.

Und mal ganz unter uns: Deine Antwort hat hier keinem was genützt.Du hast gar keine Ahnung! Schau mal da:
9.4.2 [highlight=red:c15687c7f0]Brown-Out Detection[/highlight:c15687c7f0]
The Brown-Out Detection (BOD) circuit monitors that the VCC level is kept above a configurable
trigger level, VBOT. When the BOD is enabled, a BOD reset will be given if the VCC level falls bellow
the trigger level for a minimum time, tBOD. The reset is kept active until the VCC level rises
above the trigger level again. The trigger level has a hysteresis that ensures spike free
operation.
Figure 9-4. Brown-out Detection reset.
For characterization data on tBOD consult the device data sheet. The trigger level is determined
by [highlight=yellow:c15687c7f0]a programmable BODLEVEL setting[/highlight:c15687c7f0], see Table 9-2.
Note: 1. The values here are nominal values only. For typical, maximum and minimum numbers consult
the device data sheet.
The BOD circuit has 3 modes of operation:
• Disabled: In this mode there is no monitoring of the VCC level, and hence it is only
recommended for applications where the power supply is stable.
• Enabled: In this mode the VCC level is continuously monitored, and a drop in VCC below VBOT
for at least tBOD will give a brown-out reset.
Und jetzt schreibst du mal eine eMail an Atmel mit CC an mich, das die als Chip-Hersteller was falsches in dem XMega-Datenblatt schreiben! :lol:

Ach ja falls du kein Englisch sprichst:
Da steht: "eine programmierbare Brown-Out-Detektions-Level Einstellung"

@ikarus_177
Die BOD ist eine effektive Methode, da sie oft einstellbar ist und verhindert dass Kommandos des Mikrocontrollers überhaupt gesendet werden.

[Besserwessi]

Ein bischen Programmierung ist beim internen Brownout des AVR schon dabei. Man muß nämlich die Fuse bits richtig programmieren. Mit dem eigentlichen Prgramm hat das aber nichts zu tun.

Gegen die meisten Fehler beim EEPROM sollte der Brownout detektor schützen. Ein externes EEPROM hilft da auch nicht weiter. Wo der Brownout-detektor nicht richtig schützen kann, ist wenn die Spannung bei einem Schreibzugriff aufs EEPROM zusammenbricht. Wenn man da ganz sicher gehen will, müßte man durch Kondesatoren/Elkos dafür sorgen, das die Spannung nicht zu schnell zusammenbrechen kann und vor jedem Schreibzugriff aufs EEPROM testen ob die Spannung noch voll da ist.

Der Interne Brownout detektor sollte fast immer aktiviert werden. Schließlich hat man dadurch fast keine Nachteile aber einen guten Schutz fürs EEPROM. Der Aufwand für die Programmierung der Fuses ist auch nicht so groß.

[Klingon77]

hi,

ich habe für meine kleine Bastelei ein ähnliches Problem mit dem Eeprom (Atmega 168)

Reichte denn das setzen des BOD?
Sind weitere Maßnahmen notwendig?
Was zeigte die Praxis bei Dir?


liebe Grüße,

Klingon77

[Ceos]

ich bleibe bei meiner aussage, wenn die menge des speichers reicht, daten doppelt ablegen, CRC einbauen und gegebenenfalls fehlerhafte daten mit dem backup ersetzen, sollten spannungsschwankungen WÄHREND des betriebs auftreten hat man natürlich ein problem ... da gibts viele ansätze aber da kommts halt auf die verfügbare zeit und den verfügbaren platz für externe schaltungen an.
wenn es möglich ist die kommunikationswege entkoppeln und die spannungsversorgung mit einem dicken kondensator speisen, der über eine diode angeschlossen ist, damit nur der kontroller(oder die gesamte schaltung, falls sie nicht für die schwankungen verantwortlich ist) die spannung aus dem cap ziehen kann, aber nicht der verbraucher, der die spannungsschwankungen verursacht
außerdem noch einen schmittrigger oder ein monstabile kippstufe, die den resetpin auf low hält, solange die spannung nicht mind. zu 90% aufgebaut ist und zusätzlich ne löschschaltung, die den resetpin low zieht, bevor die cap-spannung zusammenbricht wenn man z.B. die batterie abklemmt

das klingt nach viel aber man kanns vielleicht auch nur teilweise umsetzen und erfolge damit erzielen ... es würde schon reichen, wenn man zwischen spannungsversorgung und spannugsregler für die 5V noch ne diode in reihe schaltet und dann nen dicken kondensator zwischen spannungsregler und diode reinpackt und die verbraucher die direkt strom aus dem akku saugen ohne den kondensator zu belasten

zu dem bild, so stell cihs mir ungefähr vor, ausser der verstärkerstufe, die müsste man auch ohne OPV hinbekommen, hab aber grad kein kopf dafür :p

[ikarus_177]

Hallo Klingon77,

seit dem setzen der BOD habe ich keine "Ausfälle" mehr beobachten können. Wirklich sicher bin ich mir aber nicht, da auch ohne BOD diese Lesefehler sehr selten waren.

Schaden tuts auf jeden Fall nicht, auch der Aufwand fürs Aktivieren hält sich sehr in Grenzen.

Viele Grüße

[Besserwessi]

Ohne BOD gab es gelegentlich Probleme mit Speicherstelle 0 im EEPROM.
Mit BOD hatte ich bisher keine Probleme mit dem EEPROM. Allerdings habe ich das EEPROM auch nicht so oft genutzt.

[Klingon77]

hi,

mal Dank für die Info :mrgreen:

In meinem Thread bekam ich die gleiche Aussage.
Den BOD habe ich nun ebenfalls gesetzt und werde die im EEprom gespeicherten Werte mal im Auge behalten.
Die Mehrfachspeicherung und der anschließende Vergleich ist eine ausgezeichnete Idee; das werde ich auch machen.

liebe Grüße,

Klingon77