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.
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
Oliver J. schrieb:> Eventuell werden diese nicht richtig hineingeschrieben oder nicht> korrekt heraus gelesen.
.... oder beim Einschalten sieht der µC gleich einen Tastendruck und
überschreibt das EEPROM.
Schaltplan?
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)
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...
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.
Hag Nag schrieb:> Geil. So einen Muell habe ich schon lange nicht mehr gelesen.
Konstruktiver Gegenvorschlag?
Bevorzugst du die Kondensator-Kurzschluß-Entprellung?
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.
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.
Simon K. schrieb:> Ein externer Interrupt für das auslesen> eines Tasters ist in 99,999% der falsche Weg
Naja, so würde ich das nicht unterschreiben. Es gibt einen Fall, wo es
durchaus angebracht ist: den AVR aus dem Schlaf aufwecken.
Gruß Oliver
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.
...
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.
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 ;-)
Kannst sein, dass irgendeine Vorbedingung für das eeprom-lesen nach dem
Spannungsverlust fehlt (irgendein Bit anschalten oder stromsparfunktion
aktiv) und beim flashen gesetzt wird?
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
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 ;)
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
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.
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 ?
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.
>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
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?
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
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.
...
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?
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.
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.
