CRC über den ganzen ROM

[mika (Gast)]

Hallo,
habe die Aufgabe einen CRC über den kompletten ROM zu berechnen.
Das Ganze muss ständig im Hintergrund (einer StateMachine) laufen.

Bin mir leider nicht ganz im klaren was der günstigste Weg ist.
µC ist ein PIC16F917.

Hat jemand sowas schon mal gemacht oder hat ne gute Idee ?

Gruß Mika

[Troll (Gast)]

...was ist das Ziel ... den Bitfehler im ROM nach 1000 Jahren sicher zu
bemerken.. oder wars eher ein EEPROM

[mika (Gast)]

Das verlangt der TÜV weil es sicherheitsrelevant ist.

[Tony _. (tony_s)]

Ich würde das so machen, dass ich periodisch (reicht einmal pro
Sekunde?) vom ROM vom ersten bis zum letzten Byte den CRC berechnen
würde.

Zum Thema CRC gibt es viel hier und auch im Netz oder was meinst du
genau mit "der günstigste Weg"?

Gruss

[<°--->< (Gast)]

...irgendwie muss ja auch mein CRC-Wert wieder dem Programmm bekannt
gemacht werden - kann aber nicht im Code stehen.....

**Abo**

[mika (Gast)]

Der CRC-WERT kommt in den EEPROM oder die Speicherstelle, an der der
abgelegt ist, wird von der Prüfung ausgeschlossen.

[Gonzo (Gast)]

Hallo,

ich denke dass die CRC Berechnung über den gesamten ROM Bereich relativ
lange dauert und evtl. deine Applikation stören könnte. Um diese
Störungen zu minimieren könntest Du deine CRC Berechnung so aufteilen,
dass pro Aufruf immer nur ein paar Byte hinzugefügt werden.
Ist ein bestimmter CRC Algorithmus vorgeschrieben?
Auf welche Norm beziehst Du dich?

Gruß,
Gonzo

[mika (Gast)]

@Gonzo EN 61508-7:2001

[Anfänger (Gast)]

Hallo,

kann mir da einer ein Programmier Beispiel geben. wie das ganze laufen 
sollte?

[Gast (Gast)]

Ich nehme (o.B.d.A.) an, Du hast einen 10ms Timerinterrupt.
Die CRC Pruefung solle einmal durch sein, bevor der Watchdog
ablaeuft und diesen triggern. Rechne fuer einen Tabellen-CRC16
~20 Taktzyklen(Assembler), folgende Signatur:

crc-16: CRC-16-State-alt x 1 Byte  -> CRC-16-State-neu

Eine weitere Annahme ist, dass Du in der in der Timerroutine
160 Taktzyklen Zeit hast (-> 8 Werte). Das (E)Eprom sei 32KB gross.
Anf-Addr und End-Addr sind die Anfangs bzw. Endadresse des zu
ueberpruefenden Speichers.

init: Eprom-pointer=Anf-Addr
      watchdog-reset sequence
      ret

;Timerinterruptroutine
t10msint: <Timerroutine-alt>
      8 x { CRC-State := crc-16(CRC-State,Eprom-pointer++) }
      [ggf. je nach WDT bzw. mainloop eine watchdog-reset sequence]
      Eprom-pointer == End-Addr+1 ? nein -> RETI(Return from Interrupt)
      CRC-State == abgespeicherter CRC-Pruefsumme? ja -> init(); RETI
loop: alle Peripherie in Safety Konfig, jmp loop; (warte auf wdt)

Damit wird alle 32k/8 = 2^15/2^3 *10 ms =
                4096 *10 ms ~ 40 Sekunden das (E)EPROM
ueberprueft. Der CRC ist nicht geeignet fuer "bewusste" Aenderungen
des Inhalt (hier besser mindestens z.B. SHA-1), da war der TUEV
gnaedig ;-) .

Viele Gruesse,
Hans Hein

PS: Updates des Inhalts sind mit den Anforderungen um
einiges interessanter!

[Ralph (Gast)]

Die Vorgabe für sicherheitsrelevante Systeme ist die Prüfung des 
Programmspeichers. Datenspeicher wie das EEPROM sind etwas anderes und 
müssen Inhaltsbezogen überprüft werden.
Vorschlag für den Programmspeicher wäre:
1. Das letzte Datenwort des Programmspeichers ist die Checksumme
2. Beim erzeugen des Programms die zu erwartende Checksumme  in das 
letzte Datenwort des Programmspeichers schreiben.
3. Während der Programmausführung zeitgesteuert, zb TimerIRQ, oder 
taskbasierendes System, wird bei jedem aufruf einige Datenworte des 
Programmspeichers auf die Checksumme aufgerechnet. Bei erreichen der 
Checksumme sollte die berechnete und die abgelegte Checksumme passen.

Welche Checksummenberechnung mindestens verwendet werden muss, ist vom 
Sicherheitslevel abhängig. Das kann von einfacher Addition aller 
Datenworte über CRC bis hin zu hardwareunterstütze Verfahren gehen.