Hallo Zusammen,
Für ein kleines Projekt welches mit einem Attiny85 aufgebaut ist möchte
ich die Geräte ID im EEProm speichern. Bei der Inbetriebnahme soll 0xff
als ID ins EEPROM geschrieben werden sofern die ID noch nicht bereits
gültig abgelegt ist.
Um zu erkennen ob die ID gültig ist oder nicht rechne ich noch 1 Byte
CRC über die 1 Byte ID und speichere diese zusätzlich ab.... leider
funktioniert das nicht immer ab und zu ist aufeinmal wieder 0xff als ID
also muss die CRC nicht gestimmt haben beim einschalten.
Was mache ich hier für ein Denkfehler?
Hi
Du hast einmal
> _crc8_ccitt_update(u8_tmp, current_device_id);
und beim zweiten mal
> tmp = 0;> _crc8_ccitt_update(tmp, dev_id);
Sieh in deiner CRC-Lib nach, was dort mit tmp gemacht wird.
MfG spess
Wenn es in Hardware passiert, stelle auch sicher, das der BrownOut Reset
aktiviert ist. Adresse 0 des EEPROM ist sonst öfter mal Opfer - das war
bei alten AVRs ein richtiger Bug, sollte heute nicht mehr passieren. Da
du die Deklaration deiner EEPROM Zelle nicht gepostet hast, kann ich dir
nur empfehlen, trotz allem an die erste Adresse (also die 0) im EEPROM
ein dummy zu setzen.
CRC über 1 Byte ist nicht unbedingt eine sinnvolle Lösung, schon
überhaupt nicht mit den Lib-Routinen. Wenn es unbedingt CRC sein muss,
sieh dir die Lib an und mach den einen XOR zu Fuß.
@Mathias
Danke ja ich nehme mal an das wenn ich es so Deklariere:
1
/* Byte Device ID */
2
uint8_tee_byte_device_idEEMEM;
3
uint8_tee_byte_device_id_crcEEMEM;
Dann ist die ID jetzt wohl auf Adresse 0.
@Georg
Okay meinst du generell weil nur 1 Byte? Die Lib routine
_crc8_ccitt_update brauche ich sowieso für was anderes von demher wegen
dem platz wäre es unproblematisch. Andere Idee was ich nehmen könnte?
Georg G. schrieb:> Einfach nur das Komplement?
So ist es, denn das bietet die maximale mögliche Redundanz, wenn man für
ein Byte Nutzdaten ein Byte Prüfsumme speichern will und läßt sich
obendrein innerhalb eines einzigen Taktes berechnen.
Also ich habe das jetzt umgebaut wie vorgeschlagen aber noch keine
wirkliche Verbesserung zu erkennen. Jetzt ist mir gerade noch
aufgefallen, dass ich nicht nur Platinen habe bei denen die ID verloren
geht also auf 0xff zurück gesetzt wird - nein ich hab sogar Platinen bei
denen das Flash zerschossen wird.
Das habe ich gerade erst bemerkt. Eine Platine hat sich gar nicht mehr
bemerkbar gemacht deshalb wollte ich diese neu flashen dazu brauchte ich
für den fastboot keinen reset was ja dann heißt es war nur der
Bootloader drauf.
Kann das sein nur weil ich BrownOut Fuse nicht gesetzt habe?
Das ganze ist wirklich komisch wie kann ich bitte mit dem Programm das
Flash zerschießen.
clonephone82 schrieb:> Kann das sein nur weil ich BrownOut Fuse nicht gesetzt habe?
Mach doch mal die Gegenprobe mit BOD.
Die Schreibstrategie für dein EEPROM ist ja aus den Programmstückchen
nicht herauszulesen, also wann und wie oft du schreibst. Am sichersten
wäre vermutlich, die Device ID per Programmer zu schreiben und in der
Firmware nur noch zu lesen. Wenn z.B. dein Programm Amok läuft und bei
der Evaluierung der ID rumirrt, könntest du aus Versehen schon hunderte
von Schreibvorgängen haben.
Und, wie gesagt, vermeide Adresse 0.
Ja das werde ich natürlich machen - habe aber gerade keine Möglichkeit
dazu - programmer nicht dabei.
Ja das ist ja nichts großartiges - verstehe es nicht ich hatte noch nie
solche Probleme mit einem EEPROM.... wobei ich muss zugeben ich hab noch
nie das interne EEPROM verwendet bisher.
update_id() kann dann auch noch extern über rs232 aufgerufen werden. Die
Probleme habe ich aber definitiv beim lesen würde ich sagen bzw. eben
deshalb weil die ID nicht gültig ist und dann eben neu geschrieben wird.
Naja eventuell könnte ich diese auch noch mehrfach ablagen und ein
voting machen so wie hier erklärt.
http://www.avrfreaks.net/forum/brown-out-detection-and-eeprom-corruption
clonephone82 schrieb:> Kann das sein nur weil ich BrownOut Fuse nicht gesetzt habe?
Natürlich. Ein abstürzender µC kann natürlich seinen eigenen Speicher
beliebig verwursten. Tipp: das ist nicht auf den EEPROM beschränkt,
sondern kann durchaus auch den Flash treffen.
Primäres Gegenmittel ist natürlich die Optimierung der Versorgung. Nur
soviel Bypass-Kapazität vorsehen, wie unbedingt für den Betrieb der
Hardware nötig ist und kein bissel mehr...
Ohne diese bewußte und zielgerichtete Optimierung der Hardware ist ein
aktiver BOD praktisch Pflicht. Lediglich für extreme Energiesparer muss
man i.d.R. darauf verzichten. Wenn das der Fall ist, dann sollte man die
Zeit des Verzichtes nach Möglichkeit wenigstens auf die Schlafzeit
beschränken. Leider hat man diese Möglichkeit bei älteren AVR8-Devices
nicht...
Wenn kein aktiver BOD möglich ist und auch keine Optimierung der
Versorgung, dann bleibt nur noch eins: das Programm so zu gestalten,
dass die statistische Wahrscheinlichkeit für einen fälschlichen
Schreibzugriff auf EEPROM oder Flash minimiert wird.
Das ist allerdings schon in Assemblerprogrammen nicht ganz einfach und
ziemlich aufwendig umzusetzen und in höheren Sprachen sogar weitgehend
unmöglich. Da kann man höchstens mal ein paar besonders gefährliche
Pattern in konstanten Daten entschärfen.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang