Forum: Mikrocontroller und Digitale Elektronik Selbsttest von Mikrocontroller


von Markus (Gast)


Lesenswert?

Hallo
Will eine Testroutine schreiben die selbstständig zyklisch den CPU und
den Speicher auf Fehler  testet. Kann mir einer sagen wie ich
vorzugehen habe? Bin nicht so gut in der Materie.

M F G

von Johannes Raschke (Gast)


Lesenswert?

Um CPU-Fehler zu finden, brauchst Du wohl ein System aus mindestens 2
CPUs, die sich gegenseitig überwachen...
RAM-Tests sind generell unzuverlässig und dauern lange.

von Markus (Gast)


Lesenswert?

Das System ist mit einer 1oo2D- Struktur zweifach Redundant ausgelegt
also mit 2 CPUs. Muss CPU sowie Speichertests durchführen (wird
vorgeschrieben). Weiß aber nicht so genau wie ich vorgehen muss.

von Schmittchen (Gast)


Lesenswert?

ROM: Checksummenprüfung zur Laufzeit mit anschließendem Vergleich ob
errechnetes Ergebnis mit dem zuvor auf dem PC errechneten, erwarteten
Ergebnis übereinstimmt. Sinnvolle Prüfung!

RAM: zyklisch RAM-Zellen mit bestimmten Testmustern beschreiben (z.B.
0xAA oder 0x55) und rücklesen, ob auch tatsächlich der korrekte Wert
abgelegt/übertragen wurde.
(Die Qualität des RAM-Tests hängt allerdings stark vom verwendeten
Testmuster ab, das auf die interne Struktur der RAM-Organisation
angepasst sein muß. Ohne intimes Detailwissen dazu (das normalerweise
nur die Prozessorhersteller haben) bleibt dir eigentlich nur die
einfache Prüfung z.B. mit 0x55/0xAA übrig).

CPU: Du könntest dir spezielle Befehlssequenzen zusammenstellen, die
möglichst alle Befehle des AVRs abprüfen. Am Ende muß bei fehlerfreier
Ausführung ein definiertes Ergebnis rauskommen. Ein Ergebnis könnte
z.B. ein Rechenergebnis sein, oder eine definierte Stelle, an der dein
Testcode verlassen wird...

Über den Sinn von RAM und CPU-Tests kann man natürlich streiten, denn
im Fehlerfalle würde praktisch sehr wahrscheinlich zuerst irgendetwas
unvorhergesehenes im Programmablauf passieren, bevor ausgerechnet die
Prüfroutine durchlaufen wird und den Fehler erkennt bevor dadurch ein
undefiniertes, unversagbares Verhalten resultiert.
Zusätzlich stellt sich die Frage, wie du bei erkanntem Fehler weiter
reagierst.

Wofür willst du diesen Aufwand eigentlich treiben?
Den Branchen, denen solche Prüfungen auferlegt sind (wer macht sowas
schon freiwillig um zu überprüfen, ob eine LED richtig blinkt?), sind
typischerweise nicht die Abnehmer von Atmel-CPUs. (kleiner Seitenhieb
;)

PS: Zwar nicht von dir angesprochen, aber auch (nicht den
Programmablauf störende) Stacküberläufe lassen sich zur Laufzeit
erkennen. Wurde hier an anderer Stelle auch schon diskutiert.
Man kann auch durch externe Hardware einen Monoflop (ich vermeide hier
den Begriff Watchdog) retriggern, das einen Ausfall oder verspätetes
Triggern signalisiert. Somit kannst du den Komplettausfall oder z.B.
das Aussetzen einer PLL erkennen... viele Möglichkeiten - viel
Diskussionsraum um Sinn und Unsinn solcher Maßnahmen.

Schmittchen.

von Schmittchen (Gast)


Lesenswert?

Sorry, hatte in deinem ersten Beitrag wohl versehentlich 'Atmel'
gelesen...
Je nach CPU gibt's noch spezielle Features, die solche
Hardwaremonitoring Funktionen unterstützen (z.B. ADC-Prüfungen...).
Welche CPU setzt du ein?

Schmittchen.

von Markus (Gast)


Lesenswert?

Erstmal Danke für die Antwort.
Muss dies test mache um die Sicherheitsnorm 61508 zu erfüllen. Die
schreib nun mal vor das ein Selbsttest durch zu führen ist.
Es muß auf einen XEMICs- Mikrocontroller durchgeführt werden.

Hat dies schon mal jemand gemacht?(muß nicht auf diesen Typ sein)
Oder kann mir ein paar Links empfehlen?

von Martin S. (Gast)


Lesenswert?

Die Chance, daß sich die CPU oder Speicher verändern, sind nach meiner
Einschätzung extrem gering (wenn man nicht grade den Prozessor neben
dem leuchtenden Reaktorstab plaziert)

Die Chance, daß sich ein Programmablauf verhakt und alles verkeilt
halte ich für wesentlich höher. Wie siehts denn (zusätzlich) aus mit
einem externen Wachhund (Watchdog) ? Damit kannst du belegen, daß das
System sich noch in einem konsistenten Zustand befindet....

Einen Speichercheck auf Schreib- oder Lesespeicher könnte sinnvoll auch
darin besteehen, daß man ECC Bits hinzu fügt. Sollte da eine komplexe
MMU die Fehlerüberprüfung / korrektur machen, dann sollte diese auch im
Falle eines Einzelfehlers "Alarm schlagen". Somit weißt du auch daß da
was mit dem Speicher "im Unreinen" ist...

von Schmittchen (Gast)


Lesenswert?

> Die Chance, daß sich die CPU oder Speicher verändern, sind nach meiner
Einschätzung extrem gering

Naja, es muß ja nicht immer der Reaktorstab sein, aber
(Flash)-Speicherzellen können schon mal kippen (z.B. durch
Alterung/Ladungsverlust...), z.B. vom programmierten in den
unprogrammierten Zustand. Eine Checksummenprüfung erkennt dies
zuverlässig.

> Die Chance, daß sich ein Programmablauf verhakt und alles verkeilt
halte ich für wesentlich höher

Dafür ist dann ja der von dir schon angesprochene Watchdog geeignet.

Schmittchen.

von Benedikt (Gast)


Lesenswert?

>(Flash)-Speicherzellen können schon mal kippen (z.B. durch
>Alterung/Ladungsverlust...), z.B. vom programmierten in den
>unprogrammierten Zustand. Eine Checksummenprüfung erkennt dies
>zuverlässig.

Stimmt, das kann einfach so kommen oder verstärkt durch Überspannung
verursacht werden.
Ich habe schon dutzende TVs, PCs o.ä, gesehen die einfach so (oder nach
einen Gewitter) nicht mehr funktionieren. Neue Software ins EPROM
geschrieben und das Gerät läuft wieder.
Vor allem wenn die Geräte im Dauerbetrieb laufen, verlieren gerne mal
die Boot ROMs auf Grafikkarten, SCSI Karten o.ä. ihren Inhalt.

von Markus (Gast)


Lesenswert?

Ob die test sinnvoll sind oder nicht müssen halt gemacht werden!!
Watchdog Einsatz wird woll nicht zu vermeiden sein um einen test der
Programmroutine durchführen zu können.
Danke für die Anregungen mal seh was ich daraus machen kann!!

Bitte 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
Noch kein Account? Hier anmelden.