Hallo, hat von euch schon jemand einen CRC Check von seinem Programm gemacht? Es gibt auf der Atmel Seite ein Dokument, wo es "beschrieben" wird (http://www.atmel.com/Images/doc1143.pdf), allerdings kann ich damit nicht wirklich was anfangen. In diesem Dokument werden zwar Abläufe dargestellt, allerdings weiß ich nicht wirklich wie und wo ich die implementieren kann/muss. Vielleicht kann mir ja von euch jemand helfen. Vielen Dank im Voraus! Gruß Michael
Es wird sogar sehr gut beschrieben... Wo ist denn dein Problem genau? Beim ersten Programmdurchlauf wird über den gesamten Programmspeicher eine CRC Checksum gebildet und im EEPROm abgelegt. Danach kann bei jedem Anschalten überprüft werden, ob das Programm noch unversehrt ist. gruß cyblord
Ersteinmal vielen Dank für die schnelle Antwort. cyblord schrieb: > Es wird sogar sehr gut beschrieben... Wenn man genau weiß was man macht wahrscheinlich schon.... Die Flowcharts sind prinzipiell verständlich, nur für was brauche ich z.B. das Status Register = 00 bzw. Status Register != 00 ? Das ist mir nicht ganz klar. Status Register ist doch definiert!?!? Dann noch eine Frage zur Umsetzung, besser in C oder in Assembler? Danke nochmal! Gruß Michael
Dann habe ich gerade noch gelesen, dass man die Kommentare im Code beachten soll. Ich habe aber keinen Code gefunden....Weiß jemand wo der bei Atmel liegt? Ich habe auf der Internetseite und im Dokument keine weiteren Hinweise auf den Code gefunden...
Ok, jetzt zweifle ich gerade an mir.... Wieso finde ich die .zip Datei nicht wenn ich auf der Atmel Seite nach avr236 suche? Naja, vielen Dank für den Link! Jetzt wird dann das Dokument bestimmt auch klarer.... Gruß Michael
Michael P. schrieb: > hat von euch schon jemand einen CRC Check von seinem Programm gemacht? Es muss nicht immer Kaviar, äh CRC sein. In vielen Fällen, z.B. PC-Steckkarten mit BIOS-Erweiterung, wird einfach die Summe (modulo 8 oder 16 bit natürlich) gebildet und dazu der EProm-Inhalt so ergänzt, dass sich 00 ergibt. Gruss Reinhard
Wobei dann ja auch noch das Henne/Ei Problem existiert: Wer sagt mir, dass bei verändertem Flash nicht ausgerechnet die CRC Funktion verändert wurde und daher ganz was anderes tut?
Danke für eure Meinungen! Bin für jeden Hinweis dankbar! @Reinhard Kern: Dann könnte aber ja auch jemand kommen und sagen: Wenn an zwei Stellen ein Fehler auftritt, der genau die gleiche Summe ergibt, dann kann man das nicht erkennen.... @K-H: Wenn sich bei der CRC-Funktion was ändert, dann komm ich ja höchstwahrscheinlich auch nicht durch den Test. D.H. ich muss dann sowieso schauen was den Geist aufgegeben hat. Gruß Michael
Eine 16 Bit CRC (CCITT) ist sehr sicher. Es ist sehr unwahrscheinlich dass im Flash genügend Bits in die richtige Richtung umkippen um wieder eine gültige CRC zu ergeben. Manche Linker können nach dem Builden automatisch eine CRC berechnen. Diese wird dann mit in die .hex Datei gespeichert und wird dann im Flash an die angegebene Stelle geschrieben. Der Controller vergleicht nach dem Einschalten dann die von ihm berechnete CRC mit der des Linkers. Alternativ kann man das auch selbst programmieren. Dazu nimmt man die .hex Datei, die aus dem Linker purzelt, wandelt die ins "Binary" um. Mit Binary sind die Daten gemeint, die später im Flash stehen. Das Programm am PC berechnet die CRC und schreibt sie ins hex file mit dazu. Der Programmer behandelt die CRC wie normale Daten. Gruß PP
Karl Heinz Buchegger schrieb: > Wobei dann ja auch noch das Henne/Ei Problem existiert: > Wer sagt mir, dass bei verändertem Flash nicht ausgerechnet die CRC > Funktion verändert wurde und daher ganz was anderes tut? Wie wahrscheinlich ist es dass durch zufällige Bitfehler eine CRC Funktion derart verändert wird, dass sie aus dem gesamten Programmspeicher eine CRC Summe macht welche zufällig genau mit der im EEPRom gespeicherten übereinstimmt? Und in allen anderen Fällen bekommst du eben mit, falls mit deinem Programmspeicher was passiert ist, oder aber die gespeicherte Prüfsumme im EEProm beschädigt wurde. gruß cyblord
Michael P. schrieb: > Dann könnte aber ja auch jemand kommen und sagen: Wenn an zwei Stellen > ein Fehler auftritt, der genau die gleiche Summe ergibt, dann kann man > das nicht erkennen.... Das ist ja nun seit 50 Jahren oder so bekannt, es ist klar dass die Sicherheit mit dem Aufwand steigt und umgekehrt. Die Frage ist wie sicher das System an sich sein muss, ein Programmfehler in einem MP3-Player hat praktisch garkeine Folgen, bei einer Infusionspumpe ist das was anderes. Für PC-Zwecke halte ich Checksummen durchaus für ausreichend, weil PCs generell ziemlich unsichere Systeme sind und niemand was anderes erwartet. Und wenn ein selbstgebauter Quadrocopter abstürzt, dann bestimmt nicht wegen aus Altersgründen gekippter Bits im Programmspeicher. Gruss Reinhard
Hallo nochmal, ich hab mich jetzt also ein bisschen mehr mit der Materie beschäftigt. Am interessantesten fand ich den Vorschlag von Wooschder, dass mir der Linker die CRC berechnet und das Programm dann eine CRC berechnet und mit dieser vergleicht. Da ich aber noch relativ neu bin in der Mikrocontrollerprogrammierung und mit den Tools noch nicht so vertraut bin eröffnen sich natürlich neue Fragen.... Gibt es in AVRStudio5 die Möglichkeit, dass mir die CRC berechnet wird direkt mit an den Flash geschrieben wird? Ich habe dazu noch nichts gefunden. Spielt es eine Rolle ob ich die CRC vor oder nach dem Initialisieren aller Ports etc. mache? Eigentlich doch nicht, oder? Nochmals vielen Dank! Gruß Michael
Michael P. schrieb: > Spielt es eine Rolle ob ich die CRC vor oder nach dem Initialisieren > aller Ports etc. mache? Eigentlich doch nicht, oder? ?? Der CRC wird über den Programmcode gerechnet und der ändert sich doch (hoffentlich) nicht, wenn da Programm läuft, also auch nicht durch die Initialisierung ;-). Das einzige, was mir einfällt: Da das Programm sich selber überprüft, kann das natürlich nur funktionieren, wenn dieses Prüfprogramm selber noch in Ordnung ist. Daher sollte die Menge Code, die bis zur Ermittlung des Prüfergebnisses benutzt wird, so klein wie möglich sein. Das heißt dann doch: so wenig wie möglich tun, bis die Prüfroutine läuft, und die dann so kompakt wie möglich realisieren (nicht so schnell wie möglich!). Daran sieht man aber auch: CRC-Prüfung liefert keine Garantie zur Fehlererkennung, auch nicht bei Einzelbitfehlern, nur eine gewisse Wahrscheinlichkeit. Gruß Dietrich
Dietrich L. schrieb: > Der CRC wird über den Programmcode gerechnet und der ändert sich doch > (hoffentlich) nicht, wenn da Programm läuft, also auch nicht durch die > Initialisierung ;-). Das dachte ich mir eben auch.... Naja, wenn das Prüfprogramm selber nicht mehr in Ordnung ist, dann funktioniert eben nichts mehr, was ja auch in Ordnung ist. Beim Einschalten hab ich so und so erstmal keinen "zeitlichen" Druck. Das würde ich dann nach dem AVR236 Dokument erstellen. Also zumindest den CRC_gen, da ich es ja gerne mit der errechneten CRC vom Linker vergleichen möchte. Wobei ich da noch nicht weiß wie.... Danke dir! Gruß Michael
spess53 schrieb: > Was erhoffst du dir von diesem Test? Naja, ich würde gerne mitbekommen wenn sich etwas im Programmcode ändert. Also durch Alterung, irgendwelche Störungen etc. Gruß Michael
Hi >Naja, ich würde gerne mitbekommen wenn sich etwas im Programmcode >ändert. Also durch Alterung, irgendwelche Störungen etc. Datenblatt: Data retention: 20 years at 85°C/100 years at 25°C Da alterst du bei mittleren Temperaturen schneller. Reliability Qualification Report: http://www.atmel.com/Images/Mega163.pdf MfG Spess
Hallo Michael, Du mußt Dir erstmal darüber klar werden, was Du mit der Aussage "CRC stimmt" überhaupt anfangen willst. Falls Du ein sicherheitskritisches, eichpflichtiges oder hochverfügbares System bauen würdest, gibt es eindeutige Normen und Vorschriften (z.B. ISO26262), wie diese zu gestalten sind. Da müssen z.B. Variablen doppelt-invers abgelegt werden, das System muß durch einen externen Watchdog überwacht werden oder gleich mehrfach redundant aufgebaut sein. Es gibt Vorschriften, wie in welcher Periode das ROM zu überprüfen ist, in welcher Zeit auf einen Fehler reagiert werden muß, usw. Spätestens bei der Zulassung würde (hoffentlich) auffallen, wenn Du etwas versäumt hast. Für ein "normales" System ist eine ROM CRC ausreichend, aber Du kannst natürlich beliebig hohen Aufwand treiben, wenn's Spaß macht.
spess53 schrieb: > Data retention: 20 years at 85°C/100 years at 25°C > > Da alterst du bei mittleren Temperaturen schneller. Vielleicht ist Michael ja noch so jung und erlebt das noch ;-) Lediglich bei Zerstörung durch unsachgemäße Behandlung könnte die CRC-Prüfung mal zuschlagen. Zu dem Thema: meine DCF77-Uhr mit einem µC 8748 aus dem Jahre 1982 und läuft und läuft... Lediglich der Netzteil-Elko musste schon mal getauscht werden. Aber die Elko-Lebensdauer ist ja auch geringer als die von EPROMS. Gruß Dietrich
Das Thema habe ich zwar schon vor ein paare Monaten angefangen, aber ich bin bisher noch nicht dazugekommen es umzusetzen. Jetzt habe ich mich wieder rangewagt und hab gleich wieder Probleme. Da mein Programm in C programmiert ist dachte ich mir ich mache einfach eine Inline-Assembler Passage, in der ich die crc berechnen kann. Ich habe mich dafür an das asm-Programm von AVR gehalten (AVR236), deshalb der inline-asm. Bis zur Berechnung der CRC ist alles gut, aber weiter funktioniert es nicht. Hier ein Ausschnitt des Codes:
1 | "rot_word: \n\t" |
2 | " ldi r21, 0x11;\n\t" |
3 | "rot_loop: \n\t" |
4 | " dec r21; \n\t" /*decrement counter*/ |
5 | " breq stop;\n\t" /*Break if bit counter = 0*/ |
6 | " lsl r0; \n\t" /*shift zero into lowest bit*/ |
7 | " rol r1; \n\t" /*shift in carry from previous byte*/ |
8 | " rol r2; \n\t" /*preceede shift*/ |
9 | " rol r3; \n\t" |
10 | " brcc rot_loop;\n\t" /*loop if MSB = 0*/ |
11 | " eor r2, r19;\n\t" |
12 | " eor r3, r20;\n\t" /*XOR high word if MSB=1*/ |
13 | " rjmp rot_loop;\n\t" |
14 | "stop: \n\t" |
15 | " ldi r23, 0x01;" /*Read out EEPROM*/ |
16 | " ldi r24, 0x00;"
|
17 | " out eearh,r24;"
|
18 | " out eearl,r23;"
|
19 | " sbi eecr,eere;"
|
20 | " in crc,eedr;"
|
Bis zum Kommentar /*Read out EEPROM*/ funktioniert alles, aber die nächsten Zeilen werden nicht mehr ausgeführt. Hier mal der Auszug aus dem Disassembly:
1 | 00003EF2 LDI R21,0x11 Load immediate |
2 | 00003EF3 DEC R21 Decrement |
3 | 00003EF4 BREQ PC+0x09 Branch if equal |
4 | 00003EF5 LSL R0 Logical Shift Left |
5 | 00003EF6 ROL R1 Rotate Left Through Carry |
6 | 00003EF7 ROL R2 Rotate Left Through Carry |
7 | 00003EF8 ROL R3 Rotate Left Through Carry |
8 | 00003EF9 BRCC PC-0x06 Branch if carry cleared |
9 | 00003EFA EOR R2,R19 Exclusive OR |
10 | 00003EFB EOR R3,R20 Exclusive OR |
11 | 00003EFC RJMP PC-0x0009 Relative jump |
12 | --- Testroutine.c ----------- |
13 | 00003EFD LDI R23,0x01 Load immediate |
14 | 00003EFE POP R30 Pop register from stack |
Nachdem die CRC berechnet wurde und dann auch mit der CRC im EEPROM verglichen wurde - was ja nicht gemacht wird - hol ich die Registereinträge wieder aus dem Stack, aber mir fehlen die restlichen Befehle!! Kann mir jemand sagen woran das liegen kann bzw. was ich falsch mache? Vielen Dank schon mal für die Hinweise... Gruß Michael Nachtrag @Dietrich: Die Speicherung bei 85° hoffe ich schon noch zu erleben, bei 25° ist es eher unwahrscheinlich...
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.