RAM Fehler provozieren

internes oder externes Ram?

> 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.

Es handelt sicxh hierbei um einen Controller von der Firma Silabs.

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.