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.
5V Betriebsspannung BOD ist auf 4,3V eingestellt. Vergaß ich beides zu erwähnen obwohl nicht ganz unwichtig.
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?
Eine Taste macht man NIE mit einem Interrupt. Denn die Taste kann und wird prellen. Das sind noch ein paar kontakte in ms-Bereich.
In der ISR FLag setzen, dann in aller Ruhe im Hauptprogramm die Daten im EEPROm speichern und "whileeepromnotready" nicht vergessen.
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.
Ich programmiere in ASM und halte mich an die read/write Beispiele aus dem Datenblatt.
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. ...
Wie ich schon bereits geschrieben habe: es prellt nix und das EEPROM vergisst nichts.
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
Die 100n und 10k am Reset vergessen? Wartezeit zum Quarz einschwingen auch mal auf 64ms stellen.
Martin Wende schrieb: > Die 100n und 10k am Reset vergessen? Da die nicht vorgeschrieben sind, kann man sie nicht vergessen.
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 ;)
Vielleicht erzeugt dein Spannungswandler eine Rampe beim Starten, mit der der µC nicht klar kommt. Sowas gibts oft.
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?
Achso, 100nF ist natürlich an den Versorgungspins dran. Ansonsten habe ich keine "Schutzschaltung"
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
Wie sieht denn die Beschaltung für den Taster aus? Gruß Oliver
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.
Statt die HEX-Files zu "interpretieren" mach doch einfach einen Verify! Dann kriegst Du auch die Werte und Adressen.
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!
Angehängte Dateien:
-
Resetbeschaltung.png
10 KB -
ADC_Stromversorgung.png
18 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.