Liebe Kollegen, um Bitflips zu erkennen, die durch ionisierende Strahlung verursacht werden, möchte ich die Checksumme über den ganzen Programmspeicher (Flash) beim ATMEGA1284P berechnen. Wie kann ich mit AVR gcc den Flashspeicher adressieren, um es byte-weise auszulesen? Die CRC-Funktion selbst habe ich schon fertig... Danke! Karel
Karel Marsalek schrieb: > über den ganzen Programmspeicher Wie soll die Funktion sich selbst überprüfen?
Karel Marsalek schrieb: > Wie kann ich mit AVR gcc den > Flashspeicher adressieren, um es byte-weise auszulesen? lesen vom Flash steht doch im Datenblatt drin.
Karel Marsalek schrieb: > um Bitflips zu erkennen, die durch ionisierende Strahlung verursacht > werden, möchte ich die Checksumme über den ganzen Programmspeicher > (Flash) beim ATMEGA1284P berechnen. Und dann? Was für Konsequenzen ziehst du daraus? Und überhaupt, der Programmteil, der die Prüfung durchführt, kann ja auch fehlerhaft sein, ebenso der, der dann die Konsequenzen bearbeitet... Abgesehen davon, Millionen, wenn nicht Milliarden Geräte (angeblich 3 Milliarden mit Java) arbeiten jahrzehntelang ohne solche Bitflips. Es kommt schon mal vor, wenn auch selten, dass ein Programmspeicher defekt ist, aber dann nicht wegen einem Bit. Den Fall wirst du wahrscheinlich nicht erleben. Das einzige, was du tun kannst, ist nach einem erfolglosen Selbsttest alles anzuhalten. Gruss Reinhard
Und wenn er gerne eine rakete in die sonne schiesst? Es soll orte geben wo das schon eher passieren könnte.
Jörg Esser schrieb: > Und wenn er gerne eine rakete in die sonne schiesst? Kommt die Sonde dann zurück, wenn sie einen CRC-Error findet? Gruss Reinhard
Jörg Esser schrieb: > Und wenn er gerne eine rakete in die sonne schiesst? > Es soll orte geben wo das schon eher passieren könnte. Dann muss er eben nachts fliegen. mfg.
hallo Karel, http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-gcc hat natürlich auch eine library, um auf den programmspeicher zuzugreifen. AFAIK hat ein avr einen mit 16bit adressierbaren programmspeicher, und jede adresse zeigt auf ein 16 bit wort. 128kB sind somit maximal adressierbar, der atmega mit 256kb flash hat da noch einen workaround drinnen. problem ist dennoch: den "hashwert" eines korrekten flash-abbilds selber im flash zu hinterlegen. keine ahnung, wie dieses problem heisst, ist aber eine nicht ganze junge frage der informatik. einfacher wäre es, wenn der crc/hashwert abseits vom PGM space hinterlegt werden kann. lg, n.n.
n.n. schrieb: > ist > aber eine nicht ganze junge frage der informatik. Da gibts schon Lösungen, auch ganz einfache: die "Option"-Eproms auf PC-Addon-Karten z.B. müssen eine Bytesumme von Null haben, sonst werden sie vom BIOS nicht ausgeführt. Bei CRC ist es ohnehin so, dass Inhalt plus angehängter CRC bei erneuter Berechnung von CRC über alles Null ergeben muss. Die Software kann sich also problemlos selbst prüfen, aber das beantwortet auch nicht die Frage was dann. Die meisten Roboter in Fukushima fielen nach wenigen Augenblicken durch die Strahlung aus, mit oder ohne CRC. Dan kann man nichts anderes machen als so ein armes Technikerschwein (ganz ohne CRC) hinterherzuschicken, um die Roboter wieder rauszuholen. Gruss Reinhard
Karel Marsalek schrieb: > um Bitflips zu erkennen, die durch ionisierende Strahlung verursacht > werden, möchte ich die Checksumme über den ganzen Programmspeicher > (Flash) beim ATMEGA1284P berechnen. Wie kann ich mit AVR gcc den > Flashspeicher adressieren, um es byte-weise auszulesen? Sinnloses Unterfangen. Sollte es zu einem Bitflip kommen, so wird deine Software sowieso unkontrollierbar. Nur im allerbesten Fall werden dein CRC und darauf folgende Fehlerroutinen noch sicher funktionieren. Genau so gut kann aber deine gesamte Software komplett Amok laufen. Darum: Wenn es um Sicherheit geht, so sind andere Methoden angebracht. Beginnen kann man mit einem Watchdog, zusätzliche Sicherheit würde externe Kontrolllogik bringen.
Reinhard Kern schrieb: > Bei CRC ist es ohnehin so, dass Inhalt > plus angehängter CRC bei erneuter Berechnung von CRC über alles Null > ergeben muss. Nicht unbedingt 0, aber einen konstanten Wert, den sog. "Magic". Der hängt von Polynom und Startwert ab. > Die Software kann sich also problemlos selbst prüfen Nicht, wenn ein Bitfehler in der CRC-Routine liegt. Dann könnte sogar ausgerechnet der Aufruf der Prüfung erst das Teil in's Nirvana schicken. > aber das > beantwortet auch nicht die Frage was dann. Genau das ist das eigentliche Problem.
Hallo Kollegen, erstmals danke hauptsächlich für die Zielführende Antwort von n.n.(Gast). Im Moment brauche ich die Routine um während der Protonenbestrahlung im Labor die Strahlungstoleranz des Prozessors zu evaluieren. Anscheinend habei ich mir die Erklärung, WOFÜR ich das Ganze brauche, sparen sollen. Dadurch habe ich Antworten bekommen, die ich garnicht benötige. Selbstverständlich wird die korrekte Checksumme auf dem übergeordneten Rechner liegen und zwar auf einem Medium, das Strahlungstoleranter ist als "mein" Flashspeicher. Wenn "mein" System noch läuft und die CRC-Berechnung das Programm nicht ins Nirvana schießt, ist die Sache noch einfach. Wenn mein System nicht mehr antwortet, kann man noch ein Power Cycle versuchen und noch eine frische Firmware daraufspielen, aber wenn beides fehlschlägt, muss die "Redundanz" (falls sie gibt) anspringen. Von mir aus kann man das Thema schließen, mit <avr/pgmspace.h> kann ich meine Aufgabe wohl bewältigen. Grüße! Karel
Hi >Anscheinend habei ich mir die Erklärung, WOFÜR ich das Ganze brauche, >sparen sollen. Dadurch habe ich Antworten bekommen, die ich garnicht >benötige. Nein. Du hättest schreiben müssen, das du den ATMega bewusst der Strahlung aussetzt. So wie du das geschrieben hast klingt das wie die Angstreaktion eines Neulings auf nicht vorhanden Gefahren. MfG Spess
Da bisher nur 1 Antwort von 10 auf meine Frage angegangen ist, spare ich mir beim nächsten Mal die Erklärung trotzdem :-) Liebe Grüße Karel
Die Sinn-Diskussion wundert mich jetzt aber auch... Offenbar arbeitet hier keiner mit sicherheitsrelevanten System :-O Also, Flash-Auslesen geht über "avr/pgmspace.h" mit Funktionen wie "pgm_read_byte_near()". Details siehe hier: http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html Wie man die CRC ablegt: 1. Möglichkeit: Im Flash ablegen und diesen Flashbereich von der CRC-Prüfung ausschließen. Hierzu im Linker-File am besten eine eigene Sektion vorsehen, oder mit festen Adressen arbeiten. 2. Möglichkeit: In einem EEPROM ablegen und vor dem CRC-Check aus dem EEPROM laden (und um der Diskussion vorzugreifen: ja, man kann Daten im EEPROM so speichern, daß man sicher erkennen kann, falls sie falsch sein sollten).
Karel Marsalek schrieb: > Selbstverständlich wird die korrekte Checksumme auf dem übergeordneten > Rechner liegen und zwar auf einem Medium, das Strahlungstoleranter ist > als "mein" Flashspeicher. wahrscheinlich hab ich da was falsch verstanden, aber wenn du eh einen übergeordneten Rechner hast, warum liest du dann nicht vom Rechner aus in regelmäßigen Abständen den Speicher ganz aus und vergleichst ihn mit dem Sollzustand?
Hallo Justus, das ist ein Brauchbarer Ansatz. Im Moment möchte ich NUR die Brauchbarkeit des ATMEGAs untersuchen, d.h. wie er sich ohne Sicherheitsmaßnahmen verhält. Grüße K.
Karel Marsalek schrieb: > Da bisher nur 1 Antwort von 10 auf meine Frage angegangen ist, spare ich > mir beim nächsten Mal die Erklärung trotzdem :-) Das ist eben genau falsch. Die Leute hier sind keine Antwort-Roboter, sondern wollen letztlich konstruktive Lösungen für den TO erarbeiten. Bei (fast) jeder Frage ist es so, dass für die Beantwortung etwas mehr Kontext notwendig ist oder die Frage sogar darauf schliessen lässt, dass der Fragende etwas tun will, was er so nicht tun sollte. Dem kann man als TO vorbeugen, indem man die Aufgabenstellung möglichst vollständig beschreibt. Das ist im übrigen auch interessanter für die anderen Teilnehmer und man kriegt mit etwas Glück sogar noch zusätzliche Tipps zum Problem.
Um auf den Protonenbeschuss zurueckzukommen. Ich wuerd annehemn, dass das RAM sensibler ist, und daher erst mal das testen. Also einfach den CRC ueber einen definierten RAM Bereich laufen lassen.
Hallo,
einzelne Bit-Kipper im RAM und im Flash kommen auch ohne Kernkraft immer
wieder vor. Um einmal Größenordnungen zu nennen: Bei einem hier
verwendeten µC kommt es im ~2.5 MB Flash zu rund 120 FIT, im 250 KB RAM
zu 1200 FIT. 1 FIT ist 1 Fehler in 10^9 Betriebsstunden. Der Prozessor
selbst hat dann noch einmal so rund 100 FIT.
Dies ist ein Bare-Die, bei Controllern im Gehäuse ist die Rate bis zu 10
mal höher (wg. Alphastrahlung aus dem Plastik). Damit kommt es wohl
weltweit bei den oben angegebenen Java-Appliances zu rund 30 Bit-Kippern
pro Stunde ("Verdammt, schon wieder abgestürzt - naja, starten wir halt
neu!")...
Wer jetzt glaubt, dass das irrelevant ist, der hat sich offensichtlich
noch nie mit sicherheitskritischen Anwendungen auseinander gesetzt.
Allerdings verwendet man dafür normalerweise auch µCs, die eine
entsprechende Korrektur (z.B. ECC) als Hardware eingebaut haben.
Für den TO gilt: Prüfsumme über Flash ist schon eine Maßnahme, bei dem
Einsatzgebiet (erhöhte Protonenstrahlung) sollten auch für das RAM und
zumindest den Stackpointer und Programcounter Maßnahmen zur Überwachung
implementiert werden (redundant abgelegte Variablen, Ablaufkontrolle
durch Inspektionspunkte, Stack-Frame-Überwachung,...)
Dabei kann ruhig die Prüfsumme selbst im Flash stehen, da es ja egal
sein sollte, welcher Flash-Inhalt defekt gegangen ist. Kritisch wird es
lediglich dann, wenn die Überprüfungsroutine selbst ausfällt. Daher wird
man bei Systemen die nicht ausfallen dürfen immer eine vom
Hauptprozessor unabhängige Hardwarelösung benötigen, die bei Ausfall des
Prozessors einen sicheren Zustand herstellt (z.B. ein
(Semi-)intelligenter Watchdog).
Insgesamt ist es nicht besonders trivial, ein zuverlässiges System zu
entwickeln. Ansätze bieten hier die Normen für funktionale Sicherheit in
der Elektronik (IEC61508, ISO 26262, ...) bzw. deren Umsetzung bei den
Hardware-Herstellern.
Schöne Grüße,
Martin
Karel Marsalek schrieb: > Anscheinend habei ich mir die Erklärung, WOFÜR ich das Ganze brauche, > sparen sollen. Dadurch habe ich Antworten bekommen, die ich garnicht > benötige. Na ja, 2 Sekunden googelm mit den nicht allzu schwer zu erratenden magischen Begriffem "AVR Flash CRC" hätte dir mehr zielführende Antworten geliefert, als du eigentlich benötigst. Denn wie eigentlich immer, irgendwer hat das Problem schon einmal gelöst. Oliver
spess53 schrieb: > So wie du das geschrieben hast klingt das wie die > Angstreaktion eines Neulings auf nicht vorhanden Gefahren. Ich würde mich jetzt nicht gerade als Neuling bezeichnen; aber einen CRC Flash-Check implementiere ich immer. Soweit ich es beurteilen kann, hat es noch nie zugeschlagen und so wie ich es vermute, wird es auch nie zuschlagen. Aber wegen diesen paar Zeilen stelle ich mir die Frage implementieren/nicht implementieren erst gar nicht.
Karel Marsalek schrieb: > Da bisher nur 1 Antwort von 10 auf meine Frage angegangen ist, spare ich > mir beim nächsten Mal die Erklärung trotzdem :-) Dann hast du dafür 10 andere Antworten, die dir nichts nützen: "Wozu brauchst du das?" "Was hast du vor?" "Glaskugel defekt!" "Erklär doch mal deine Hausaufgabe!" Und selbstverständlich Falk Brunner, der dich (wie alle anderen auch 10 Mal pro Tag) auf die Netiquette des Forums verweist. Gruss
Was für eine Farce! Da fragt einer: "Meine Windschutzscheibe ist verschmutzt, wie krieg ich die sauber?" Und dann kommen Antworten à la: "Wozu willst Du die saubermachen, es könnte doch seine, daß Deine Bremse eh nicht geht."
Doofie schrieb: > Da fragt einer: > "Meine Windschutzscheibe ist verschmutzt, wie krieg ich die sauber?" > > Und dann kommen Antworten à la: > "Wozu willst Du die saubermachen, es könnte doch seine, daß Deine Bremse > eh nicht geht." Eben: Hattest du eine schwere Kollision mit einem Vogel oder geht es bloss darum, während der Fahrt Staub und Spritzwasser wegzuwischen? Ist möglicherweise unter dem toten Vogel noch ein Sprung in der Scheibe, der du vor lauter Blut nicht siehst? Oder ist vielleicht nur das Scheibenputzwasser alle und du kannst während der Fahrt nicht mehr putzen? Oder ist es eine spezielle Art von Dreck?
Doofie schrieb: > Was für eine Farce! > > Da fragt einer: > "Meine Windschutzscheibe ist verschmutzt, wie krieg ich die sauber?" Eine gar nicht so uninteressant Frage. Hatte vor 2 Jahren den Fall, dass mir ein liebenswerter Zeitgenosse seine übriggebliebene Ladung Sauerkraut des nächtens auf der Scheibe verteilt hat. Keine Ahnung was die reingetan haben, auf jeden Fall blieb ein Film zurück, den ich weder mit Putzmitteln noch mit Azeton runtergekriegt habe. Fortan war fahren bei Regen einfach nur noch nervtötend. So, und jetzt überleg dir mal, wie ich auf die lapidare Anfrage, dass ich meine Scheibe reinigen will, ohne dieses Zusatzwissen eine für mich vernünftige Antwort kriegen könnte. Einfache Sache: Präsentier immer alle Fakten. Insebsondere dann, wenn es sich nicht um eine Alltagssituation handelt. Soll ich dir sagen, was mein erster Gedanke war? Der war: Himmelherrgott, was programmiert der an Satelliten rum, wenn er noch nicht mal eine CRC auf den Flash hinkriegt? - Na, das kann ja was werden.
Karl Heinz Buchegger schrieb: > Keine Ahnung was die reingetan haben, auf jeden Fall blieb > ein Film zurück, den ich weder mit Putzmitteln noch mit Azeton > runtergekriegt habe. Fortan war fahren bei Regen einfach nur noch > nervtötend. Versuch es mal mit Sidol. Das ist u.a. ein Putzmittel für Silber und zudem ein Geheimtip.
Messi schrieb: > Karl Heinz Buchegger schrieb: >> Keine Ahnung was die reingetan haben, auf jeden Fall blieb >> ein Film zurück, den ich weder mit Putzmitteln noch mit Azeton >> runtergekriegt habe. Fortan war fahren bei Regen einfach nur noch >> nervtötend. > Versuch es mal mit Sidol. Das ist u.a. ein Putzmittel für Silber und > zudem ein Geheimtip. Danke für den Tip. Werd ich mir merken. Wobei mich immer noch interessieren würde, was da so gehaftet hat. Ursprünglich dachte ich an Öl, aber das wär mit dem Azeton runtergekommen. Die Scheibe musste dann sowieso ein Jahr später aufgrund von Steinschlag gewechselt werden.
Karl Heinz Buchegger schrieb: > Die Scheibe musste dann sowieso ein Jahr später aufgrund von Steinschlag > gewechselt werden. Hättest du das gleich gesagt, hätte Messi sich den Rat mit Sidol sparen können. Immer alle Fakten auf den Tisch! Gruss Reinhard
***************************************
FAZIT
***************************************
Für diejenigen, deren Applications Strahlungstolerant sein müssen:
Prozessor ATMEGA1284P-AU, Vss = 5,0 V, FOSC = 20 MHz
Protonenstrahlung, 230 MeV. Gesamtdosis 12 Gray in Silizium, in 2 Gy
Schritten, Dosisrate ca. 25 Gy/Std. Gesamte Testdauer ca. 1 Std.
1. Flash Programmspeicher: keine Veränderung der 16-bit Checksumme
während der gesamten Bestrahlung
2. RAM Speicher: nach jeden 2 Gy mind. ca. 12 Bitflips in 72 000 bits im
RAM (neun 8-bit Arrays Länge 1000). Diese Bitflips sind
höchstwahrscheinlich single innerhalb von jedem Byte. Weitere Analyse
folgt.
3. DataFlash Amel AT45DB161E (die neueste Revision): Während der
gesamten Bestrahlung keine Veränderung der 16-bit CRC. Nur lesender
Zugriff auf den DataFlash Speicher. Schreiben in den Speicher könnte
IMHO anfälliger sein, aber wieviel?
Viktor N. (s.u.) hat richtig angenomen, dass RAM sensibler ist.
Kennt jemand von euch einen ähnlich leistungsstarken µProzessor, der
noch strahlungstoleranter ist als der ATMEGA1284P?
Grüße
Karel
Viktor N. schrieb:
> Um auf den Protonenbeschuss zurueckzukommen. Ich wuerd annehemn, dass
> das RAM sensibler ist, und daher erst mal das testen. Also einfach den
> CRC ueber einen definierten RAM Bereich laufen lassen.
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.