Hallo zusammen, gibt es eine Möglichkeit beim Atmega328 und AVR Studio 7 über die Fuses den EEPROM auf nicht mehr veränderbar festzusetzen? Ich führe an einen Gerät so eine Art Kalibrierung durch und schreibe diese Parameter ins EEPROM. Dabei kommt es selten vor, dass sich die EEPROM-Werte ändern, ich weiß nicht warum. Da wäre es gut, wenn ich den Zustand des EEPROMs quasi einfrieren könnte und der erst nach einen kompletten erase und Neuprogrammierung wieder zugänglich werden würde. Die Lockbits sind ja nicht für diesen Zwecke da, oder? Die verhindern ja nur das Auslesen, wenn ich das richtig verstanden habe. Danke schon mal und Grüße.
Michael schrieb: > gibt es eine Möglichkeit beim Atmega328 und AVR Studio 7 über die Fuses > den EEPROM auf nicht mehr veränderbar festzusetzen? Nein. > Ich führe an einen > Gerät so eine Art Kalibrierung durch und schreibe diese Parameter ins > EEPROM. Dabei kommt es selten vor, dass sich die EEPROM-Werte ändern, > ich weiß nicht warum. Das genau ist das tatsächliche Problem. Löse es und alles wird gut. Tipp: Wurde hier im Forum unzählige Male diskutiert...
Michael schrieb: > Ich führe an einen > Gerät so eine Art Kalibrierung durch und schreibe diese Parameter ins > EEPROM. OK. Michael schrieb: > Dabei kommt es selten vor, dass sich die EEPROM-Werte ändern, > ich weiß nicht warum. Also stimmt die Kalibrierung fast immer? Wegen Deiner Kalibrierungsroutine.
Brown out ist auf 4,3V gesetzt und ansonsten gibt es auch keine undefinierten Zustände. Oder was wäre denn hier sonst der Fehlerklassiker?
Wendels B. schrieb: > Also stimmt die Kalibrierung fast immer? Also die Kalibrierung funktioniert so weit, aber manchmal verstellt es sich eben.
Wenn Platz vorhanden ist, kannst Du die Kalibrierungsdaten in den Flash-Speicher schreiben und das entsprechende Lockbit setzen.
Michael F. schrieb: > Brown out ist auf 4,3V gesetzt und ansonsten gibt es auch keine > undefinierten Zustände. Oder was wäre denn hier sonst der > Fehlerklassiker? In dem Fall Bitkipper… Noch viel unwahrscheinlicher wäre natürlich ein Fehler im Programm oder an der Hardware, aber das kannst du ja definitiv ausschließen, oder? Oliver
Michael F. schrieb: > Brown out ist auf 4,3V gesetzt und ansonsten gibt es auch keine > undefinierten Zustände. Das behauptest du. Also jemand, der sogar schon explizit zugegeben hat, nicht zu wissen, warum der EEPROM überschrieben wird... Es gibt eigentlich nur zwei Möglichkeiten, die sich allerdings leider nicht gegenseitig ausschließen, also durchaus auch in trauter Eintracht gemeinsam auftreten können: 1) Hardware ist Scheiße. 2) Software ist Scheiße. Ein aktivierter BOD eleminiert schlechte Hardware als Ursache leider nur teilweise. Der kann, wie der Name schon sagt, nur vor dem Problem des Brownout schützen, also zu langsam abfallender Versorgungsspannung. Er kann aber z.B. nicht schützen gegen negative Spikes auf der Vorsorgung. Da wird er sogar kontraproduktiv. Insbesondere dann, wenn auch noch räudige Software werkelt, die nichtmal mitbekommt, wenn sowas passiert ist...
Ok, ich kann nicht mit Sicherheit sagen, ob der Brown-Out gut
funktioniert. Auf jeden Fall ist die entsprechende Fuse gesetzt.
Das Gerät wird mit einer UART-USB-Bridge "kalibriert", die sich aber auf
der Platine befindet. Evtl. passiert der Fehler, wenn die USB-Buchse an
uns ausgesteckt wird, und irgendwas dabei auf dem Bus landet. Also die
Hardware ist sicher nicht optimal.
Die SW funktioniert folgendermaßen:
Im String sehe ich mir die Zeichen an, und je nachdem, was das erste
Zeichen ist, wird die entsprechende Variable verändert
switch (str[0]-'0')
{
case (0):
sscanf(&str[2],"%d",&Wert1);
eeprom_write_float(&Wert1,Wert1);
str[0]=0;
break;
}
Das ist wahrscheinlich nicht super fehlerresistent, aber dennoch sollte
sich doch da nichts einfach so verstellen, oder?
Bernd schrieb: > Wenn Platz vorhanden ist, kannst Du die Kalibrierungsdaten in den > Flash-Speicher schreiben und das entsprechende Lockbit setzen. Da habe ich leider keine Platz mehr.
Michael F. schrieb: > Das Gerät wird mit einer UART-USB-Bridge "kalibriert", die sich aber auf > der Platine befindet. Evtl. passiert der Fehler, wenn die USB-Buchse an > uns ausgesteckt wird, und irgendwas dabei auf dem Bus landet. Oder auf der Versorgung... > Also die > Hardware ist sicher nicht optimal. Dann musst du da halt nachbessern. Schauen, was passiert und entsprechende schaltungstechnische Gegenmaßnahmen vornehmen. Also einfach: den ganz normalen Job eines Hardwareentwicklers ausführen. > Die SW funktioniert folgendermaßen: > Im String sehe ich mir die Zeichen an, und je nachdem, was das erste > Zeichen ist, wird die entsprechende Variable verändert [...] > Das ist wahrscheinlich nicht super fehlerresistent, aber dennoch sollte > sich doch da nichts einfach so verstellen, oder? Bei einem negativen Spike auf der Versorgung, während diese Zeile > eeprom_write_float(&Wert1,Wert1); abgearbeitet wird: natürlich kann sich da was "verstellen". Und nichts in der Software wird das bemerken können. Dazu wäre im Minimum eine Art Marker erforderlich, der anzeigt, dass da gerade was geschrieben werden sollte und eine Überwachung nach eine Reset, die aus dem gleichzeitigen Auftreten dieses Markers und der Tatsache eines BOD-initiierten Resets diesen Schluß ziehen könnte. Damit wäre dann zumindest die Ursache eindeutig festgestellt. Die Verbesserung der Hardware bleibt aber trotzdem zu erledigen. Der ganze Code zur Erfassung der Situation ist nur nötig, solange die Hardware scheisse ist. Danach kann man ihn weglassen. Aber eben nicht vorher!
Michael F. schrieb: > Im String sehe ich mir die Zeichen an, und je nachdem, was das erste > Zeichen ist, wird die entsprechende Variable verändert Da vermisse ich eine Prüfsumme oder gleichwertiges, was das Telegramm absichert. Auf der Sellerieschnitte musst du immer mit dummen Zeichen rechnen.
OK, alles klar, vielen Dank für eure Antworten, ihr habt mir schon sehr geholfen!
Nur mal so: Ändern sich die Daten im EEPROM zur Laufzeit, also nach der Kalibrierung irgendwann, obwohl die SW da eigentlich weit davon entfernt ist in das EEPROM zu schreiben? Ansonsten: Wie sehen die Änderungen denn aus? Kippen da einzelne Bits, betrifft das größere Bereiche etc.? Ah, und du solltest die Verbindung per SW-Befehl logisch trennen, bevor da die USB/UART Bridge physikalisch abgezogen wird. Das Abziehen kann von der UART des AVRs recht leicht als weitere Bytes erkannt werden - wenn da dem AVR vorher nicht gesagt wurde "ne, da kommt nichts mehr, ignoriere alles folgende" kann sonstwas passieren. Ach ja, ein Startcodewort über die UART wäre auch sinnvoll.
Michael schrieb: > Ich führe an einen > Gerät so eine Art Kalibrierung durch und schreibe diese Parameter ins > EEPROM. Dabei kommt es selten vor, dass sich die EEPROM-Werte ändern, > ich weiß nicht warum. Direkt nachdem du deine Konfig. geschrieben hast? Was ist, wenn du das was du geschrieben hast, nicht nochmal gegenliest, da es ja wichtig ist...und es so belässt...dann weist du nie, ob du richig geschrieben hast. Evtl. Ursachen: Der Schreibvorgang darf nicht durch Interrupts unterbrochen werden, bei einigen FLASH/EEPROM Zugriffen je nach Architektur.
UND... 1) ich würde empfehlen, NACH dem EE-Schreiben die Werte jeweils zurückzulesen und zu vergleichen. 2) wie bereits erwähnt könnte eine Plausibilitätskontrolle beim UART-Empfang auch mal nix schaden.
Hermann Kokoschka schrieb: > 2) wie bereits erwähnt könnte eine Plausibilitätskontrolle beim > UART-Empfang auch mal nix schaden. Michael schrieb: > gibt es eine Möglichkeit beim Atmega328 und AVR Studio 7 über die Fuses > den EEPROM auf nicht mehr veränderbar festzusetzen? Ich denke, es ist das interne EEPROM gemeint.
Schreib Dir einen weiteren Befehl, der an eine Adresse des EEPROM einen bestimmten Wert schreibt, z.B. 0xFF. Beim Programmieren wird er mit einem anderen Wert vorbelegt, z.B. 0xA5. In Deinem Programm prüfst Du dann vor jedem EEPROM schreiben, ob da 0xA5 drinsteht. Somit ist der EEPROM gelockt, sobald da nicht mehr 0xA5 drin steht. Auch diese Adresse selber kann dann nicht mehr geändert werden.
c-hater schrieb: > 1) Hardware ist Scheiße. > 2) Software ist Scheiße. Ja! Und solange hier kein Schaltplan, kein Aufbau und keine Software gezeigt wird bleibt es bei dieser Behauptung bzw. Annahme. Hier wird nämlich seit vielen Stunden über ein Spekulations-Objekt geredet/gerätselt das keiner kennt. Ausser der Controller-Typ, der ist bekannt.
Wenn du noch einen Pin frei hast nutze einen Taster, der während der Änderung gedrückt sein muß.
Michael schrieb: > Dabei kommt es selten vor, dass sich die EEPROM-Werte ändern, > ich weiß nicht warum. Ja kommt vor...... Aber.. Nur in Speicherzelle 0 Das kommt, auch bei aktivierter BrownOut, dass beim Hochfahren INIT der CPU ein kurzer Schreib Befehl kommt und der dir die Zelle 0 verschiesst Also immer bei 1 Beginnen !!! Gruß Thomas
Thomas Kalmeier schrieb: > Also immer bei 1 Beginnen !!! Erstaunlich, wie lange sich solch alte Kamellen halten. Zu der Zeit hieß der Bundeskanzler noch Helmut Kohl.
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.