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?
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.
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...
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 :-)
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...
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
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
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?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en537355 Ab Level C braucht man in der Regel redundante Hardware. Gruß Anja
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
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
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
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.