EEPROM treibt mich in den Wahnsinn

Gast #2710204
Hallo,
Ich habe ein, wie ich finde, sehr merkwürdiges Problem mit dem internen 
EEPROM eines Atmega88PA. In besagt EEPROM werden während der 
Programmlaufzeit gesteurt durch einen externen Interrupt (Taster) Daten 
gespeichert. Diese Daten sind Einstellungen die der Benutzer verändern 
kann aber die bei einem Neustart des Gerätes oder nach längerem Zeit 
ohne Benutzung nicht vergessen werden sollen. Also genau eines der Dinge 
für die das EEPROM gedacht ist.
Ich habe die Funktion auch gestestet und sie funktionierte. Der Test sah 
so aus, dass ich die Batterie kurz entnahm und nach ca. 30 Sekunden 
wieder einsetzte. Das Gerät startete mit den entsprechnden Einstellungen 
und ich war froh.
Nun habe ich das Gerät über Nacht ohne Batterie liegen lassen und die 
Einstellungen wurden vergessen. Ich hab dann etwas mit dem Voltmeter und 
der Zeitspanne die ich die Schaltung ohne Strom lasse herum gespielt.
Ergebniss: Nach entfernen der Batterie sind die Spannung relativ schnell 
auf unter 1.5V Volt ab, danach sinkt sie langsamer. In der Schaltung ist 
ein Step-Up Wandler verbaut der einen entsprechend großen Kondensator 
auf der Ausgangsseite hat. Lasse ich die Spannun unter einen Wert von 
ca. 0.15V abfallen und lege dann die Batterie wieder ein sind die 
Einstellungen futsch. Lege ich die Batterie vorher wieder ein ( also V > 
0.15V) sind die Einstellungen noch da. Ich kann mir das absolut nicht 
erklären.
Gast
EEPROM zufällig löschen passiert gerne wenn der µC unterversorgt wird.
Mach in den Fuses die BOD an und stell auf einen Sinnvollen Wert ein 
denn die Betriebsspannung hast du ja nicht angegeben.
Eumel schrieb:
> Ich kann mir das absolut nicht
> erklären.
Am EEPROM liegt das wahrscheinlich nicht. Das speichert Daten auch über 
Stromausfälle hinweg.

Hast du das EEPROM mal ausgelesen nachdem du Einstellungen veränderst?
Eventuell werden diese nicht richtig hineingeschrieben oder nicht 
korrekt heraus gelesen.


Gruß Oliver
Gast
Also die ISR ist ziemlich unkritsch. Funktioniert so, dass halt der 
Taster gedrückt wird, dann wird die ISR aufgerufen (Interrupts sind dann 
natürlich gesperrt, soll heißen Prellen ist eh egal) die Werte 
gespeichert und das Wort "Gespeichert" auf einem LCD angezeigt. Danach 
wird mit einer einfachen Schleifen ca. 1 Sekunde gewartet (in der ISR, 
es gibt nebenbei, in diesem Moment, eh nichts kritisches zu tun)
Gast
Womit beschreibst du den EEprom? Ich glaub' der avr-gcc macht das mit 
irgend einer expliziten funktion. Wenn du naiverweise eine Zuweisung 
verwendest, landet das sonstwo. In deinem Fall wohl irgendwo im ram...
Gast
So, Überraschung. Alles steht richtig im EEPROM, allerdings schafft der 
Controller es nach längerer Stromunterbrechung nicht mehr die Daten 
richtig zu lesen.
Was mich eherlich gesagt noch mehr verwirrt.
Persönliche Seite
Eumel schrieb:
> So, Überraschung.
Ja riesige Überraschung. Du hast keine der vorherigen Posts beachtet und 
keinerlei ausstehende Fragen beantwortet. Respekt!

Hag Nag schrieb:
> Zwei von Drei schrieb:
>> Eine Taste macht man NIE mit einem Interrupt. Denn die Taste kann und
>> wird prellen. Das sind noch ein paar kontakte in ms-Bereich.
>
> Geil. So einen Muell habe ich schon lange nicht mehr gelesen.
Wie lautet dein Gegenargument? Ein externer Interrupt für das auslesen 
eines Tasters ist in 99,999% der falsche Weg.
Gast
Ich habe die Erfahrung gemacht, dass das EEPROM erheblich strengere 
Anforderungen an die Spannungsversorgung stellt, als alle anderen 
Funktionen des Mikrocontrollers.

Wenn die Spannungsversorgung nicht stabil genug ist, kann es durchaus 
sein, dass das EEPROM funktionelle Aussetzer bis hin zum Datenverlust 
hat, während der Rest der Schaltung problemlos funktioniert.

Wie jemand anderes bereits empfohlen hat, kann ein Brown-Out Detecter 
das EEPROM vor Zugriff bei unzureichender Versorgungsspannung schützen. 
Er kann aber auch neue Folgeprobleme auslösen, nämlich wenn er jetzt den 
AVR zu Zeitpunkten resetted, wo Du es nicht erwartest.

Versuche erstmal, die Spannungsversorgung zu stabilisieren. Vor allem 
könnte der Startvorgang interessant sein. Eine simple 
Verzögerungsschleife von 1s VOR dem ersten Zugriff auf das EEPROMkönnte 
schon helfen.
Eumel schrieb:
> Interrupt ist raus, jetzt wird gepollt. Bringt nicht.

Pollen alleine reicht nicht, da muss noch eine Prise Entprellung mit 
rein. Einzelheiten spare ich mir jetzt, das wurde in diesem Forum 
bereits bis zum Erbrechen diskutiert und erklärt. Desweiteren prüft man 
vor jedem EEP-Schreibzugriff, ob das Schreiben wirklich nötig ist, also 
ob der Inhalt nicht bereits schon richtig ist. Das vermeidet unnötiges 
Schreiben und damit unnötige "Abnutzung", erhöht also die 
Lebenserwartung des EEP.

Ich kann nur sagen, dass in meinen AVR-Basteleien Tasten nicht prellen 
und die EEPROMs nix vergessen. An den AVRs liegt es jedenfalls nicht.

...
Gast
das EEPROM scheint wirklich unschuldig zu sein. In ihm steht das 
richtige und es verliert auch keine Daten.
Das Problem ist nun folgendes: Sinkt die Spannung einmal unter 0,15V 
lässt sich der Controller nicht mehr anständig starten. Nur neu flashen 
hilft, dabei bleibt das EEPROM unangetastet und der Controller startet 
dann wieder mit den gewünschten (d.h. vorher im EEPROM gespeicherten) 
Einstellungen.
Delay Funktion nach dem Reset bringt keine besserung. Reset ist mit 10k 
an Vcc gelegt.
Gast
Eumel schrieb:
> Das Problem ist nun folgendes: Sinkt die Spannung einmal unter 0,15V
> lässt sich der Controller nicht mehr anständig starten.

Das wäre der erste Controller, dem man die Versorgungsspannung nie 
klauen darf ;-)
Gast
Das Problem entsteht auch, wenn man schon zu oft in das EEPROM 
geschrieben hat.
Das passiert schnell, wenn in einer Laufschleife, insbesondere in ASS, 
sehr schnell in das EEPROM geschrieben wird.
Die Zahl der Schreibzyklen ist begrenzt, siehe Datenblatt.
Bei solchen Aktionen ist das EEPROM dann im Eimer.

Joe
Gast
10k sind dran. Anschwingzeit ist auf 64ms. Irgendwie verschluckt sich 
der Controller ganz arg wenn er eine Zeitlang ohne Spannung war. Ist mir 
auch noch nicht untergekommen. Das EEPROM wird bedingungslos beim Start 
gelesen, und zu oft gespeichert wurde mit Sicherheit auch noch nicht. 
Geht ja nur über einen Tastendruck und 100000 mal hab ich noch nicht 
gedrückt ;)
Gast
Hmm, also es ist ein HT7750 Step up. Die Sache mit der Spannungsrampe 
macht durchaus Sinn. Aber sollte sowas nicht vom BOD abgefangen werden? 
Wie dem auch sei, mit welcher Beschaltung könnte ich das denn für den 
Controller angenehmer gestalten?
Eumel schrieb:
> So, Überraschung. Alles steht richtig im EEPROM, allerdings schafft der
> Controller es nach längerer Stromunterbrechung nicht mehr die Daten
> richtig zu lesen.
> Was mich eherlich gesagt noch mehr verwirrt.

Es sagt Dir doch eindeutig, daß der Fehler in Deinem Programm liegt.
Daran ist nichts verwirrendes.

Es ist eher die Regel, daß sich ein Fehler an einer ganz anderen Stelle 
auswirkt, als an der, wo man ihn gemacht hat.

In Assembler hat man natürlich viel mehr Fehlermöglichkeiten als mit 
einer Programmiersprache.
Vielleicht wird der SRAM nicht initialisiert und enthält Zufallswerte.
Oder Dein Stack kommt durcheinander (verdrehtes push/pop, jump+ret, 
call+jump).


Peter
Gast
Hallo Peter. Du hast natürlich recht, in den meisten Fällen ist man 
selber schuld und nicht der Controller. Ich werde das Programme nochmal 
auf die von dir genannten Fehlerquellen untersuchen. Was mich so 
verwirrt ist halt, dass es nach erneutem Flashen funktioniert. Wenn das 
Programm übertragen wurde wird ja vom Programmer auch ein Reset 
ausgelöst ( benutze einen Avr isp mk2). Also eigentlich das gleiche als 
wenn ich den Strom wegnehmen und wieder anlege.
Gast
Wird der Interupt der Taste die das schreiben ins EEPROM triggert so 
früh ausgeführ das noch keine gültigen Werte in den Variablen drin sind 
( z.B. 0) und werden dann diese Nullen ins EEPROM geschrieben ?
Gast
Na dann ist doch alles gut 8)
Ne jetzt mal ehrlich du hast mich falsch verstanden.
Nach dem abschalten stimmt der EEPROM Inhalt vieleicht aber nicht nach 
dem erneuten anschalten (Siehe oben). Denn dann wird irgednwie ein 
erneutes schreiben getriggert obwohl noch keine Gültigen Werte in den 
Variablen sind.
Und der vorher richtige Inhalt wird überschrieben. Oder wenn die 
Spannung einen Bestimmten wert ereicht wird irgendwie ein schreiben ins 
EEPROM getrigger. Überprüfe noch mal den BOD. Und poste doch mal deine 
Software. Ist ja echt nen ratespiel hier.
(Firma: Raich Gerätebau & Entwicklung)
>Was mich so verwirrt ist halt, dass es nach erneutem Flashen funktioniert.

Klingt danach als ob das Programm durch irgendwas überschrieben wird. 
Hast du mal das ausgelesen und verglichen?

Grüsse
Gast
Hallo, Olli. Der Taster wird jetzt gepollt. Die eine Seite ist einfach 
an GND gelegt die andere an den Pin des Controllers. Interne Pullups 
sind eingeschaltet.

Zum flash auslesen:
Ich programmiere im AVR Studio5. Für jedes Projekt gibt es ja einen 
eigenen Ordner in dem dann auch ein Hexfile liegt welches schließlich 
auf den Controller übertragen wird. Muss das ausgelesene Hexfile mit 
diesem identisch sein?
Gast
Hi

>Muss das ausgelesene Hexfile mit diesem identisch sein?

Nein. Beim Auslesen (mit Read) wird der komplette Speicher gelesen. Das 
originale ist nur so lang, wie es der Code erfordert.

MfG Spess
Gast
Ok, also ab einer bestimmten Stelle steht im Hexfile nur noch FF, da ist 
das Programm dann wohl vorbei. Aber bis zu diesem Punkt sollten sie 
gleich sein? Sie sind es nämlich nicht.
Eumel schrieb:
> Sie sind es nämlich nicht.

Eine Stolperfalle könnte sein, dass Du die falsche Datei brennst. 
Zumindest bis AVRStudio4 musste man beim ersten Brennen eines neuen 
Projekts explizit die neue Datei auswählen, sonst wurde einfach die des 
letzten Projektordners gebrannt. Ich weiß nicht, ob das bei Version 5 
oder 6 bereits korrigiert ist, halte es aber für gut möglich, dass das 
nicht der Fall ist.

...
Gast
Schreibst du irgendwo ins Flash??

hast du einen Bootloader geschrieben? Kling für mich so, als würdest Du 
irgendwo ins Flash schreiben! Das kann passieren, wenn du einen 
Bootloader programmiert hast, der dann irgendwie angesprungen wird und 
Teile des Flashes überschreibt (z.B. mit Müll).
Ansonsten kann ich mir nicht erklären, warum die hex Files nicht 
übereinstimmen und das ganze nach dem Neuprogrammiern wieder 
funktioniert!
Hast du ein Oszilloskop? Schau dir mal an wie lange diese Startrampe ist 
bis der Schaltregler in die Pötte kommt. Danach richtest du dann dein 
RC-Glied der Resetbeschaltung aus. So wird der µC erst starten nachdem 
die Spannung stabil ist, was bei ungünstiger Auslegung auch mal länger 
als 64 mSek dauern kann.

Einen Schaltregler würde ich aber nicht gerade als 
µC-Spannungsversorgung nehmen, mach da zu mindestens noch eine 10µH 
Drosselspule vor den 100nF Kerko des µC's, wie es Atmel bei der 
ADC-Spannungsversorgung empfiehlt.

Kann es sein das im Datenblatt des Schaltreglers einen Low ESR Elko am 
Ausgang empfohlen wird?
Angehängte Dateien:
Gast
Eumel schrieb:
> Hmm, also es ist ein HT7750 Step up. Die Sache mit der Spannungsrampe
> macht durchaus Sinn. Aber sollte sowas nicht vom BOD abgefangen werden?
> Wie dem auch sei, mit welcher Beschaltung könnte ich das denn für den
> Controller angenehmer gestalten?

Bevor man da auf Verdacht mit einem zusätzlichen 
Spannungsüberwachungs-IC oder sonstiger Reset-Beschaltungs Akrobatik den 
µC im Reset-Zustand hält, bis sich die Stromversorgung vom Einschalten 
berappelt hat, könnte man sich erstmal mit einem DSO die 
Versorgungsspannung beim Hochfahren ansehen. Alternativ gibt es hier 
bestimmt jemand, der den Aufbau nachstellen kann, um zu prüfen, ob mit 
anderer Stromversorgung die gleichen Sympthome auftreten. Wenn man den 
µC dazu ein Triggersignal für die kritische Phase ausgeben läßt, weiss 
man auch, wo man gucken muß ;-)
Soetwas wie ein Schaltplan und etwas Code wären da natürlich u.U. 
hilfreich.
So eine große Akrobatik ist es auch nicht das RC Glied am Resetpin zu 
verändern und das ganze ohne Oszilloskop machbar. t = r * C

Gehen wir mal von der Musterbeschaltung aus 10kOhm + 100nF aus

10.000 Ohm x 0,0000001 F = 0,001 Sek = 1 mSek

nun wechseln wir den Widerstand gegen 100 kOhm aus und schon hat man 
eine Verzögerung von 10 mSek.

Wobei ich den Widerstand nicht zu hochohmig gestalten würde. Lieber die 
üblichen 10 kOhm nehmen und einen Elko zw. 1-10µF + Diode einfügen womit 
man 10-100mSek erreicht und das sollte genug Zeit sein damit der 
Spannungsregler sich einfängt.
Gast
Hannes Lux schrieb:
> Autor:

>       Datum: 11.06.2012 16:35
>
> Eine Stolperfalle könnte sein, dass Du die falsche Datei brennst.
> Zumindest bis AVRStudio4 musste man beim ersten Brennen eines neuen ....

AVR 5 macht den gleichen Blödsinn, fall auch immer wieder mal rein.
Es steht immer der hex.pfad vom Vorprojekt drin.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 14 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.