mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega168PA, RAM testen


Autor: Andreas H. (heilinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich benutze einen AVR ATmega168PA und möchte nach dem Starten des uC 
einen RAM-Test durchführen. Gibt es da schon vorgeschrieben 
Testfunktionen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Assembler oder C?

2) Bei C musst du sehr früh das Kommando bekommen, ehe sich die C-
   Runtime im Speicher breit macht. Zu Beginn von main() ist es
   jedenfalls zu spät, viel zu spät.

3) Einfach in einer Schleife den Speicher mit 0xAA vollschreiben,
   danach in einer 2-ten Schleife überprüfen, ob überall 0xAA drinnen
   steht.
   Dann dasselbe Spielchen nocheinmal, diesmal mit 0x55

4) Auf einem AVR fällt der SRAM normalerweise nicht aus. Und wenn doch
   dann wurde der IC malträtiert und ist ohnehin nicht mehr glaubwürdig.

Autor: Andreas H. (heilinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Assembler oder C?

->C

Karl heinz Buchegger schrieb:
> Bei C musst du sehr früh das Kommando bekommen, ehe sich die C-
>    Runtime im Speicher breit macht. Zu Beginn von main() ist es
>    jedenfalls zu spät, viel zu spät.

Hm, kann ich dann den RAM-Test zu Beginn der main() durchführen und 
anschließend die Startwerte von allen Variablen setzen?

Karl heinz Buchegger schrieb:
> Einfach in einer Schleife den Speicher mit 0xAA vollschreiben,
>    danach in einer 2-ten Schleife überprüfen, ob überall 0xAA drinnen
>    steht.
>    Dann dasselbe Spielchen nocheinmal, diesmal mit 0x55

Ich denke (hoffe) mal, dass es einen vorgeschrieben C-Code schon gibt. 
Will die Gartenschere ja nicht neu erfinden ;)

Karl heinz Buchegger schrieb:
> Auf einem AVR fällt der SRAM normalerweise nicht aus.

Befürchte ich auch nicht, ist aber einfach nur eine Routine-Kontrolle, 
um 1000000000% sicher zu gehen...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Heil schrieb:

> Hm, kann ich dann den RAM-Test zu Beginn der main() durchführen und
> anschließend die Startwerte von allen Variablen setzen?

Nein.
Du bist zwar fast aber dann doch nicht komplett alleine auf dem µC. Da 
muss der Stack initialisiert werden und wer weiß, was sich die C-Runtime 
sonst noch so alles im Speicher abgelegt hat. Auch wenns nicht viel ist, 
aber ein paar Hilfsvariablen wird es da schon im Speicher geben.

Probieren kannst du es. Mehr als einen heftigen Absturz bei irgendeiner 
Systemfunktion riskierst du nicht.

Aber ich fürchte: Wenn das SRAM tatsächlich fehlerhaft ist, wird dein 
Programm unter Umständen gar nicht bis main() kommen :-)


>> Einfach in einer Schleife den Speicher mit 0xAA vollschreiben,
>>    danach in einer 2-ten Schleife überprüfen, ob überall 0xAA drinnen
>>    steht.
>>    Dann dasselbe Spielchen nocheinmal, diesmal mit 0x55
>
> Ich denke (hoffe) mal, dass es einen vorgeschrieben C-Code schon gibt.
> Will die Gartenschere ja nicht neu erfinden ;)

Wenn dich dieser 8 Zeiler vor Probleme stellt:
Lasse es ganz einfach. Sinn macht das sowieso keinen.

Wie willst du eigentlich das fehlerhafte RAM dem Benutzer anzeigen und 
wie machst du das, wenn du kein funktionierendes SRAM zur Verfügung hast 
:-)

Autor: Andreas H. (heilinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ich denke dass ich diese Aufgabe meistern kann, nur eben mit etwas 
mehr Zeitaufwand... Aber najut, ich bekomme das schon hin.

Und wenn mein kompletter uC im Arsch ist, kann ich das auch schlecht 
ausgeben über ihn, das ist mir schon klar. Aber was ist denn, wenn nur 
einige Zellen vom SRAM defekt sind, oder kann das nicht passieren (also 
nur komplett oder gar nicht?) Habe es noch nicht erwähnt, aber ich 
möchte nur den internen SRAM von Speicherzelle 0x0100 bis 0x04FF prüfen 
(siehe Datenblatt). Benutzt die C-Runtime auch dort Speicherplatz?

Ich benutze ne RS232-Schnittstelle, in dem ein Flag gesetzt ist, wenn 
der uC und die angehörige Hardware okay ist. Und bei dieser Prüfung 
möchte ich eben auch nen RAM-Test machen, wie sinnig oder unsinnig das 
ist, sei jetzt mal offen gelassen...

Wie du schon siehst, bin ich kein Crack, der sich mit dem 
Speichermanagment eines uC voll auskennt, daher habe ich mich ja hier an 
das Forum gewendet...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Mähr vom RAM-Test kommt noch aus den Zeiten, wo der RAM auf extra 
Chips saß oder sogar noch auf extra Platinen.
Da vielpolige Steckverbinder sehr unzuverlässig sind, hatte das durchaus 
seinen Sinn.
Die Tests liefen dann ausschließlich mit Variablen in den Registern der 
CPU.


Bei einem Micro ist so ein Test total unsinnig, da die ALU-Register, die 
IO-Register und der interne SRAM alle aus den gleichen Flipflops 
aufgebaut sind.
Man hat also für den Test keinerlei Satz an vertrauenswürdigen 
Registern.
Der RAM-Test wird also nicht in der Lage sein, eine Fehlermeldung zu 
generieren, er wird nur abstürzen.
Und ob der RAM-Test abstürzt oder die Applikation, macht das System 
keinen Jota sicherer.


Sinnvoller wäre es, die IO-Register zu testen. Sie sind zwar genauso 
aufgebaut, wie der SRAM, können aber über die Anschlüsse des MC leichter 
zerstört werden (EMV).


Peter

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Befürchte ich auch nicht, ist aber einfach nur eine Routine-Kontrolle,
>um 1000000000% sicher zu gehen...

Optimist. Z.B. solltest du mit deinem 'Test' auch erkennen ob beim 
Schreiben eines Bits in einer Speicherstelle nicht auch ein Bit in einer 
anderen kippt. Dazu reicht das $55/$AA Schreiben und Lesen nicht ganz 
aus.

Als Programmierübung ist das alles vielleicht mal ganz nett. Praktisch 
aber ohne Nährwert.

>Sinnvoller wäre es, die IO-Register zu testen. Sie sind zwar genauso
>aufgebaut, wie der SRAM, können aber über die Anschlüsse des MC leichter
>zerstört werden (EMV).

Könnte aber ganz lustige Effekte in einer Schaltung haben.

MfG Spess

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Bei einem Micro ist so ein Test total unsinnig, da die ALU-Register, die
> IO-Register und der interne SRAM alle aus den gleichen Flipflops
> aufgebaut sind.

Ist aber in vielen Sicherheitsnormen (IEC61508 / ISO26262) so 
vorgeschrieben (bzw. wird daraus abgeleitet).
Man will damit diejenigen (< 1ppm) Verdrahtungsfehler in den 
Metallmasken der Halbleiter herausfischen die beim Endtest beim 
Hersteller durchgerutscht sind, weil der Fehler vielleicht nur bei einer 
bestimmten Temperatur auftritt. Im Normalfall wird das System dann in 
einen sicheren Zustand gebracht. (z.B. Dauer-Reset).

> Man hat also für den Test keinerlei Satz an vertrauenswürdigen
> Registern.

Die muß man natürlich vor dem RAM-Test mit einem eigenen Test prüfen. 
Genauso wie sämtliche ALU-Funktionen.

Einen Teil der Routinen (für niedrige Sicherheitslevel) findet man bei 
Microchip (AN1229)
http://www.microchip.com/stellent/idcplg?IdcServic...

Ab Level C braucht man in der Regel redundante Hardware.

Gruß Anja

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anja schrieb:
> Ist aber in vielen Sicherheitsnormen (IEC61508 / ISO26262) so
> vorgeschrieben (bzw. wird daraus abgeleitet).

Ja, das ist das Problem.
Was vor 20 Jahren durchaus mal sinnvoll war, darf natürlich niemals mehr 
in Frage gestellt werden und muß bis in alle Ewigkeit so gemacht werden.


Peter

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ja, das ist das Problem.
> Was vor 20 Jahren durchaus mal sinnvoll war, darf natürlich niemals mehr
> in Frage gestellt werden und muß bis in alle Ewigkeit so gemacht werden.

So lange gibts diese Normen noch gar nicht. Die ISO26262 wird gerade 
verabschiedet. Du hast Recht: für unkritische Bastelzwecke sind die 
Maßnahmen sicher nicht notwendig.

Von diskreter Bauweise mit mehreren Steckkarten (Fehlerrate ca 1/1000) 
zu integrierter Bauweise (Fehlerrate kleiner 1ppm) gibt es natürlich 
eine gewisse Verbesserung. Allerdings ist die Anzahl der 
sicherheitskritischen Steuerungen im gleichen Zeitraum ebenfalls 
signifikant gestiegen.

Wenn Du Millionen sicherheitskritischer Steuerungen im Feld hast (oder 
eine die tausende Leben gefärden kann) mußt Du natürlich den "Stand der 
Technik"  an Sicherheitsmaßnahmen (= Norm) einhalten.

Und glaube mir: bei Millionen Steuerungen gibt es schon mal die eine 
oder andere, bei der diese Tests berechtigt zuschlagen. Und in Folge 
fließen dann auch Verbesserungen im Herstellprozess oder zusätzliche 
Testschritte beim Chip-Hersteller ein.

Gruß Anja

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anja schrieb:
> Und glaube mir: bei Millionen Steuerungen gibt es schon mal die eine
> oder andere, bei der diese Tests berechtigt zuschlagen.

Das Problem ist, daß oft irgendwelche Tests gemacht werden ohne Sinn und 
Verstand.
Bevor man einen Test einbaut, muß man erstmal feststellen, was er bring.
Es macht keinen Sinn etwas zu testen, was gegenüber anderen 
Ausfallquellen zu vernachlässigen ist.
Wenn der Test 999 andere Fehler nicht erkennt, ist er sinnlos. Da muß 
ich erst für die 999 anderen Fehler einen Test haben, ehe er das Gerät 
zuverlässiger macht.

Das ist vergleichbar, als wenn ich einen Programmteil optimiere, der nur 
0,1% CPU-Last bewirkt, völlig nutzlos.

Mit solchen Tests wird also nur eine Pseudosicherheit suggeriert. Und 
dann explodieren eben Ölplattformen usw., weil man sich in falscher 
Sicherheit wiegt.

Zu einem Test gehört immer zuerst eine Fehleranalyse.

Ein RAM-Test ist außerdem eine Wissenschaft für sich. Man müßte dazu 
erstmal die Internas des Chips vom Hersteller erfahren.
Wenn z.B. die Rückführung des FF gestört ist, kann er immer noch 
wunderbar kurz Ladung speichern, aber nach einem Tag umkippen. Niemand 
kann aber pro Bittest einen Tag warten.


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.