Hallo, wir sind aktuell dabei eine neue Firmware auf einem ARM Controller zu entwickeln. Dieser Controller kann quasi 2 Fehler erkennen beziehungsweise einen Fehler korrigieren. (ECC benutzt Hamming Algorithmus). Wie kann man zum Testen einen RAM Fehler provozieren? Gibt es da eine Möglichkeit?
user schrieb: > Wie kann man zum Testen einen RAM Fehler provozieren? Eigentlich sollte es fast immer einen Fehler geben, wenn man RAM liest, das seit Power On noch nie geschrieben wurde. Bei irgendeinem Controller stand mal dabei, dass man darauf achten soll - in dem Fall, um Fehler zu vermeiden.
> immer einen Fehler geben, wenn man RAM liest, > das seit Power On noch nie geschrieben wurde Grober Unsinn. Bei externem RAM einfach einen kraeftigen Bustreiber nehmen und mit einem Pulsgenerator (z.B. HP 8002A) mit einem kurzen Puls ansteuern. Den Bustreiber an die Datenleitungen haengen.
Cartman schrieb: >> immer einen Fehler geben, wenn man RAM liest, >> das seit Power On noch nie geschrieben wurde > > Grober Unsinn. Hm, aus dem RM0444, STM32G0x1, Sec. 2.3 Embedded SRAM: "Note: When enabling the SRAM parity check, it is advised to initialize by software the whole SRAM at the beginning of the code, to avoid getting parity errors when reading non initialized locations."
user schrieb: > Wie kann man zum Testen einen RAM Fehler provozieren? cache aschalten,Stomversorgung absenken, clock jittern lassen, mit kosmischer strahlung beschiessen. Mal vom Rawhammer szenario inspirieren lassen: https://www.heise.de/news/Blacksmith-RAM-Sicherheitsluecke-Rowhammer-ist-schlimmer-als-angenommen-6268583.html
Jim M. schrieb: > Rowhammer funktioniert nur bei DRAM aber nicht bei SRAM. Ja, wenn der TE mal Infos gegeben hätte, dann müßte man nicht raten. Was für Ram, was für Controller. Wieso glauben die Leute immer, dass ich das gleiche Board auch vor mir auf dem Tisch habe. So, mal Mittagessen machen. Was meint ihr, sollte ich lieber dünsten oder braten? Und wieviel Salz muss daran?
user schrieb: > beziehungsweise einen Fehler korrigieren. (ECC benutzt Hamming > Algorithmus). > > Wie kann man zum Testen einen RAM Fehler provozieren? > Gibt es da eine Möglichkeit? Das kann dir nur Das RefMan oder DataSheet deines Controllers sagen. Alle ECC protected SRAMs in den Controllern die ich bisher am Wickel hatte, hatten nach dem PowerUp keine definierten Zustände für die EEC bits im RAM. Ein Lesezugriff lieferte dann meistens einen Fehler. Wenn der Controller sich aber für Saftey enpfehlen möchte, sollte sowas in der Art in irgendeinem Mem oder Bus Controll register zu finden sein: "Generate Error in ECC for Data Protection The data paths between the SRAM and the LMU bus interface are protected by ECC logic. This bit is used to inject an error into the next write access so that the SMU alarm can be tested. Reading this bit always returns 0B. Writing works as follows: 0B No Effect 1B Inject error into next LMU RAM Write Access." Wenn es sowas nicht gibt, bleibt nur der Power On Fall, der einfach undefiniert sein dürfte. Kann dir aber nur die Doku des Herstellers sagen, ob das wirklich so ist.
Bauform B. schrieb: > Eigentlich sollte es fast immer einen Fehler geben, wenn man RAM liest, > das seit Power On noch nie geschrieben wurde. das ist in den meisten Fällen korrekt. Selbst für RAM, dass in einem definierten Zustand hochfährt (bspw komplett 0) wird in der Regel ein ECC Fehler detektiert, da das ECC Codewort für den Wert 0 in der Regel != 0 ist. Genua für solche Zwecke gibt es "modifizierte" Hamming codes, mit denen genau das erreicht werden kann, dass "unberührter" Speicher valide ist. user schrieb: > Wie kann man zum Testen einen RAM Fehler provozieren? > Gibt es da eine Möglichkeit? Kannst du die ECC-Korrektur+Generierung abschalten was reinschreiben und dann wieder aktivieren? Dann sollte er eigentlich anschlagen beim auslesen. Eventuell schreibt er aber immer ECC codewörter und es lässt sich nur die Detektion/Korrektur unterdrücken. Wenn es sich um internes RAM handelt wird es dann schon schwieriger. Zuverlässig fällt mir da nicht wirklich was alternatives ein. Der Hersteller wird das bspw. durch seinen MBIST (Memory built-in self test) und die Scan Ketten durchaus machen können. Da hat man aber als Kunde keinen Zugriff drauf. Ebenso kann man als Kunde nicht an den Sense-Verstärkern der RAM-Zellen spielen. Damit lassen sich auch bit-Kipper provozieren. Bei externem RAM kann man an einem Board einfach mal mit der Prüfspitze was nach Masse kurzschließen oder so. das ist zwar auch nicht so geil, funtioniert aber. Alternativ im Lesebetrieb ne Leiterbahn kappen. Dann kann man aber auch nicht mehr schreiben. Also ansich nicht so gut im laufenden Betrieb. Oder tatsächlich radioaktiv: Sucht euch jemanden mit Röntgengerät (vorzugsweise zur Baugruppenuntersuchung, wegen der besseren Fokusierung) und ballert einfach im Betrieb ins RAM. Wenn der RAM intern ist, ist es aber eventuell schwierig, da man wahrscheinlicher irgendwelche internen Signale umbringt anstelle der SRAM Zellen. SRAM Zellen sind "leider" relativ robust.
M. H. schrieb: > Genua für solche Zwecke gibt es "modifizierte" Hamming codes, mit denen > genau das erreicht werden kann, dass "unberührter" Speicher valide ist. Aber will man das? Ein Lesezugriff auf eine zuvor nie geschriebene Speicherstelle ist m.M.n ein Fehler. Ist doch gut, wenn das nicht nur vom Compiler/Lint angemeckert wird, sondern zusätzlich auch die µC-Hardware ein Auge darauf hat.
user schrieb: > Es handelt sicxh hierbei um einen Controller von der Firma Silabs. Axo, den. scnr, WK
Könnt ihr den Softwarekram nicht in eine virtuelle Umgebung setzen? Also z.B. Schreib-Leseoperationen logisch von Verifikationsoperationen zu trennen. Dann könntet ihr Schreib-Leseoperationen auf der Hardware testen, und das Verifikationsgeraffel testet ihr in einer komplett anderen Umgebung, wo ihr dem Prüflingcode vor die Füße werft was euch beliebt. Quasi beides in verschiedene Klassen aufteilt und dafür Unittests durchführt. Das ist zwar noch nicht so gut wie die Transistoren auf eurem IC direkt extern ansteuern zu können, aber besser als nichts und grundsätzlich auch nicht schlecht.
Εrnst B. schrieb: > M. H. schrieb: >> Genua für solche Zwecke gibt es "modifizierte" Hamming codes, mit denen >> genau das erreicht werden kann, dass "unberührter" Speicher valide ist. > > Aber will man das? Ein Lesezugriff auf eine zuvor nie geschriebene > Speicherstelle ist m.M.n ein Fehler. Ist doch gut, wenn das nicht nur > vom Compiler/Lint angemeckert wird, sondern zusätzlich auch die > µC-Hardware ein Auge darauf hat. Das kommt doch auf die Anwendung an. Viel Speicher, der erst beschrieben werden muss, kann den Startup deutlich verlängern. Oft spielt das ja keine Rolex, aber wenn doch, ... Außerdem muss der Speicher beim ersten Schreiben in der ECC-Zellgröße beschrieben werden. Bei mir bisher 32 bit. Aber alle haben bisher auch byteweises Schreiben erlaubt, was der MemContoller dann in einen RMW Zugriff umsetzt. Daher würde ein byteweise Erstbeschreiben ebenfalls zum Fehler führen. Die Silabs Dinger kenne ich nicht, kann zu denen also nix sagen.
Darth Moan schrieb: > Das kommt doch auf die Anwendung an. Viel Speicher, der erst beschrieben > werden muss, kann den Startup deutlich verlängern. Oft spielt das ja Wozu denn? Es macht keinen Sinn, Speicher auszulesen, der nicht vorher mit sinnvollen Werten gefüllt wurde. Initialisiert man das gesamte RAM "pauschal", um die ECC-Logik ruhig zu stellen, verdeckt man nur Software-Fehler. Den gesamten RAM-Bereich z. B. zu Nullen, ist nur kontraproduktiv. Und Bereiche, die von der Programmlogik her initialisiert werden müssen, müssen so oder so halt initialisiert werden - ECC hin oder her. Es gibt also sinnvollerweise keinerlei Entscheidungsspielraum.
A. B. schrieb: > Und Bereiche, die von der Programmlogik her initialisiert werden müssen, > müssen so oder so halt initialisiert werden - ECC hin oder her. Es gibt > also sinnvollerweise keinerlei Entscheidungsspielraum. Du würdest also hingehen und auf den Systemen keine Variablen kleiner 32 bit erlauben? Das wäre eine Starke Einschränkung des zB C Standards. Eine uint8_t Variable würde vom Programm ggf. mit einem byteweisen Schreibzugriff initialisiert werden. Wenn du aber Vorher nicht sichergestellt hast, das die 32bit Zelle des ECC geschützten RAM mit eben einem 32 bitigen Schreibzugriff initialisiert wurde, bekommst du dabei einen ECC Fehler. Also ggf. landest du in einem TRAP. Und welchen SW Fehler hast du nun detektiert? Der Trap wird ausgelöst bevor das eigentliche Schreiben stattfindet. Du hast die Speicherstelle also noch immer nicht initialisiert. Also was machst du dann im TRAP Handler? Ausserdem gibt es durchaus auch sowas wie Reset-feste Datenstrukturen. Wenn man zB im Programm in einen fatalen Fehler läuft (zB TRAPS und der Gleichen mehr) kann man durchaus in einem beliebig festgelegten Speicherbereich nützliche Informationen zur Fehlerursache ablegen, um diese dann nach einem Reset auszuwerten. Unmittelbar nach dem Reset weiss man aber zunächst nicht, ob man aus dem Power Down oder einem Hard-Reset kommt. Manche HW kann das unterscheiden andere kann es nicht. Steht dann die festgelegte Magic Number drin, ist das ein Indiz dafür, das vor dem Reset dort Daten abgelegt wurden. Die man dann auslesen könnte. Sollte aber das Schreiben dieser Daten gar nicht vollständig erfolgt sein, weil irgendwas dazwischen kam, bekommt man wohl ggf einen ECC Fehler beim Leseversuch. Diesen muss man dann eben abbrechen mit der Erkenntnis, das dort keine Daten oder nur unvollständige Daten liegen und entsprechend reagieren. Das kann aber niemand pauschal ohne Kenntnis über die Anwednung und deren Anforderungen einfach so festlegen. Daher schrieb ich, das kommt auf die Anwendung an. Wenn es nicht gefordert ist, würde ich nicht auf die Idee kommen einen zyklischen Test der ECC HW oder Reset-festen Datenstrukturen zu implementieren. Wozu auch? Naja OK, so aus Neugier kann man das schon in einem Bastelprojekt einfach so aus Daffke mal rudimentär umsetzten.
Fehler produzieren... ist das nicht offensichtlich ? - undervoltage - overclocking - overtemp - emv
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.