Hallo, immer mehr Controllerhersteller unterstützen in ihren MCUs beim on-chip SRAM ein Parity-Bit um die Sicherheit zu erhöhen (funktionale Sicherheit). Nicht jedoch beim on-chip Flash Speicher. Ich halte ein Parity-Bit beim Flash-Speicher für viel wichtiger, alleine schon, weil sich jeder Flash-Speicher über die Zeit (Jahrzehnte) von selbst löscht, irgendwann fangen die Bits zu kippen an. Bei schlechten Exemplaren evtl. auch schon früher. Und dann macht die Firmware irgendeinen Scheiss. Weiter ist eine SRAM-Speicherzelle mit 6 Transistoren was die Datenintegrität und das Auslesen angeht sehr robust. Dagegen dürfte das Auslesen einer Flash-Zelle kritischer sein, sonderlich niederohmig ist der eine MOSFET der Zelle nicht. Kennt jemand die Motivation dahinter?
Der RAM ist schnelllebig und muss deswegen schnell geprüft werden. Wenn ein Flash-Prüfungen gewünscht ist kann der Programmierer das ja per CRC oder MD5 von Zeit zu Zeit vom Programm machen lassen.
Außerdem gibt es auch immer mehr Controller die ECC nicht nur im RAM sondern auch im Flash haben.
AVR32SD20/28/32 Preliminary Data Sheet: – 32 KB in-system-programmable Flash memory with ECC – 4 KB SRAM with ECC – 256B EEPROM with EC
Steffen K. schrieb: > immer mehr Controllerhersteller unterstützen in ihren MCUs beim on-chip > SRAM ein Parity-Bit um die Sicherheit zu erhöhen (funktionale > Sicherheit). > Nicht jedoch beim on-chip Flash Speicher. Ich bezweifle, dass eine einfache Paritätsprüfung viel bringt. Und eine CRC-Prüfung des Flash-Roms bieten sogar die ollen ATxmegas, siehe XMEGA AU [MANUAL] (8331F–AVR–04/2013) Seite, 313: > 26. CRC – Cyclic Redundancy Check Generator > > Cyclic redundancy check (CRC) generation and checking for > * Communication data > * Program or data in flash memory > * Data in SRAM and I/O memory space Das hilft aber nichts, wenn die begnadeten Software-Entwickler diesen nicht aktivieren (weil der Mehraufwand die Boni der Vorstände gefährdet :-) Grüßle, Volker
> Ich halte ein Parity-Bit beim Flash-Speicher für viel wichtiger,
Die Hersteller auch. Geh mal davon aus das die das alles
intern machen ohne das du es nach aussen siehst.
Vanye
Man kann bei manchen µC sogar eine komplette CRC Prüfung des FLASH (fast/nahezu) ohne CPU Zeit bewerkstelligen. Viel schwieriger (aber nicht unmöglich) ist die Aufgabenstellung ein etwaig erkanntes Problem wieder gerade zu biegen. Und — noch wichtiger — was passiert zwischen dem letzten guten und dem ersten schlechten Lauf?
Steffen K. schrieb: > Ich halte ein Parity-Bit beim Flash-Speicher für viel wichtiger, alleine > schon, weil sich jeder Flash-Speicher über die Zeit (Jahrzehnte) von > selbst löscht Um den Inhalt größerer Datenblöcke zu validieren, ist ein Parity-Bit so ziemlich die ineffektivste Methode. Das wissen auch die Hersteller. Üblicherweise werden Prüfsummen (z.B. CRC über den Gesamtinhalt) verwendet, um die sich dann allerdings der Programmierer selbst kümmern muss.
:
Bearbeitet durch User
Rainer W. schrieb: > Um den Inhalt größerer Datenblöcke zu validieren, ist ein Parity-Bit so > ziemlich die ineffektivste Methode. Das wissen auch die Hersteller. > Üblicherweise werden Prüfsummen (z.B. CRC über den Gesamtinhalt) > verwendet, um die sich dann allerdings der Programmierer selbst kümmern > muss. Das ist bei NOR-Flash aus dem Code ausgeführt wird nicht zielführend. Zwar ist es bei jedem MCU/MPU möglich, dass z.B. der Bootloader vor Start der Applikation über den Flash-Bereich in dem die Applikation liegt eine Checksumme berechnet und mit einer gespeicherten vergleicht. Das hilft jedoch nicht, wenn Bits gelegentlich kippen. Beim PC gibt es seit der Anfangszeit einen ECC, das jedoch auch heute bei den meisten Systemen nicht verwendet wird. Das war anfangs ein Parity Bit pro Byte, heute sind es wohl 4 Bit bei einem Speicherriegel mit 64 Datenbits, mit denen mit ECCs mehr möglich ist als das blosse Erkennen von Ein-Bit-Fehlern.
Norbert schrieb: > Viel schwieriger (aber nicht unmöglich) ist die Aufgabenstellung ein > etwaig erkanntes Problem wieder gerade zu biegen. Bei einer MCU im MSR-Bereich: - MCU in Reset bringen (und anhalten). - ISR aufrufen, die dann das System geordnet abschaltet und einen Fehler meldet.
Für Anwendungsfälle, wo das relevant ist, gibt es Controller die sowohl für RAM als auch für Flash das Feature "ECC" unterstützen. Dabei wird nicht nur ein Parity-Bit hinzugefügt, sondern eine ganze Reihe, und bei jedem Lesezyklus genutzt. Einfachfehler werden automatisch korrigiert, und bei Mehrbitfehlern gibt's eine Exception, in der man entscheiden kann, wie man weiter verfahren will (z.B. ignorieren, wenn in bestimmten Bereichen erwartet, oder Reset auslösen oder was auch immer). Beispiele https://automotive.wiki/index.php/Bolero (schon über 10 Jahre her) oder https://www.infineon.com/cms/en/product/microcontroller/32-bit-traveo-t2g-arm-cortex-microcontroller
Hat selbst ein oller STM32L4 (und weiters STM32 vermutlich auch) https://www.st.com/resource/en/reference_manual/rm0351-stm32l47xxx-stm32l48xxx-stm32l49xxx-and-stm32l4axxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf 3.3.2 Error code correction (ECC)
Steffen K. schrieb: > Das war anfangs ein Parity Bit pro Byte, heute sind es wohl 4 Bit bei > einem Speicherriegel mit 64 Datenbits, mit denen mit ECCs mehr möglich > ist als das blosse Erkennen von Ein-Bit-Fehlern. Vier Bit ECC bei 64 Bit Speicherbreite reichen nicht einmal, um Einzelfehler zu korrigieren und hilft nur, um neben Einzel- auch Mehrfachfehler (bis zu 4) zu erkennen. Eine Information, welche Bits gekippt sind, bekommt man aber nicht.
Rainer W. schrieb: > Steffen K. schrieb: >> Das war anfangs ein Parity Bit pro Byte, heute sind es wohl 4 Bit bei >> einem Speicherriegel mit 64 Datenbits, mit denen mit ECCs mehr möglich >> ist als das blosse Erkennen von Ein-Bit-Fehlern. > > Vier Bit ECC bei 64 Bit Speicherbreite reichen nicht einmal, um > Einzelfehler zu korrigieren und hilft nur, um neben Einzel- auch > Mehrfachfehler (bis zu 4) zu erkennen. Eine Information, welche Bits > gekippt sind, bekommt man aber nicht. Desshalb werden die 64 Bit breiten DIMMs auch um acht weitere Bits auf 72 Bit erweitert.
Steffen K. schrieb: > Das ist bei NOR-Flash aus dem Code ausgeführt wird nicht zielführend. Zur Validierung des Flash kann ein regelmässig ausgeführter CRC-Check in Software durchaus sinnvoll sein. Natürlich ist das nicht absolut perfekt, weil dieser Check an Fehlern scheitern kann und das Flash nicht bei jedem Zugriff kontrolliert. Man kann das Prinzip auch auf einen Konfigurationsspeicher in z.B. EEPROM ausdehnen. Realisiert vor 2 Jahrzehnten bei einem AVR, war ~15 Jahre in Betrieb. Blieb im Fehlerfall mit Meldung stehen.
:
Bearbeitet durch User
Steffen K. schrieb: > Bei einer MCU im MSR-Bereich: > - MCU in Reset bringen (und anhalten). > - ISR aufrufen, die dann das System geordnet abschaltet und einen Fehler > meldet. Also so ähnlich wie bei SpaceX? ;-)
Georg M. schrieb: > AVR32SD20/28/32 Preliminary Data Sheet: > > – 32 KB in-system-programmable Flash memory with ECC > – 4 KB SRAM with ECC > – 256B EEPROM with EC Die ersten Multi-Kern AVRs. Allerdings nur im LockStep betreibbar soweit ich das verstehe -- echter Multicore würde einen erweiterten Instruktionssatz erfordern und Möglichkeiten / hardware zur Synchronisation zwischen den beiden Kernen.
*Heartbeat LED* The AVR32SD32 may be configured to output a heartbeat signal on an I/O pin to monitor if the controller detects an error. The heartbeat signal oscillates as a square wave when no error is detected. If an error is detected, the heartbeat signal stops oscillating, and the I/O pin is tri-stated. https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/UserGuides/AVR32SD32-CuriosityNano-UserGuide-DS50003842.pdf
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.