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.
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.
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.
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.
