Hallo Leute, Kann jemand mir bei Folgendem Tehma helfen : Ich habe eine C-Funktion für die Speichertest programmiert, es funktioniert bis auf ein kleines Problem, und zwar es gibt ein crash wenn die funktion den Breich testet wo die Variablen der Funktion selbst gespeichert sind!. Die frage: Welche möglichkeit gibt's, die Variablen umzulagern in anderen Speicherbereichen die gerade nicht getestet werden?. Bin dankbar für jeden Tipp! Gruß Jeff
Ich würde einfach, nachdem genügend Speicher OK getestet wurde, in diesem Bereich neuen Speicher für die Variablen allokieren und den Inhalt kopieren. Dann alle Pointer auf den neuen Speicherbereich "umbiegen" - fertig.
Danke Oldbug, Ich hab's bis jetzt mit Pointer auf strukturen versucht, also die Variablen in einer struktur "gekappselt" und dann konnte man mit dem Pointer die Anfangsadresse der Struktur festlegen, aber es gab jedesmal ein crash wenn die C-funktion den Bereich testet wo die Pointer selbst gespeichert sind. Ich habe selber noch nicht mit Speicher allokieren versucht, kann man da zum beispiel ein Speicherbereich für eine Struktur reservieren? MfG Jeff
Musst du diesen Bereich überhaupt testen ? Du verwendest den Bereich ja, also muss dieser OK sein, sonst würde der Speichertest nicht funktionieren...
am sinnvollsten wäre es dann meiner meinung nach den tast ganz am anfang des programms in asm zu mach und keinen speicher zu benutzen, denn wenn der speicher(bereich) schrott ist schmier dir sowieso der test ab...
Es könnte ungenutzte aber defekte Zellen geben (Memory-Alignment). Deshalb macht das schon Sinn. @Jeff: Ja das geht. Siehe malloc/free und sizeof...
dann kann man aber trotzdem nicht den speicher benutzen bevor man ihn gtestet hat. was passiert denn wenn genau der speicher schrott ist, den z.b der stack zu anfang benutzt... der test wird nich weit kommen...
@OldBug: danke ich werde es vesuchen! @Benedikt:zur info, dieser Programm soll "endlos" laufen und jede Zelle im Speicher testen. Wenn eien Zelle im Speicherbereich wo die Variablen gespeichert sind defekt ist, wir meine C-funktion trotzdem laufen, aber es kommt ein anderes ergebnis raus (weil es nur der wert eines Variabls geändert wird). Wenn ich aber die variablen umlagere in anderen Bereich und der vorherige bereich teste dann wird die defekte zelle sicher endekt. danke euch! Mfg jeff
Sicher nicht, denn wenn der Speicher kaputt ist und das Programm deshalb statt 192 nur 64 Speicherzellen testet, erkennst du den Fehler nicht ! Welchen uC, und welchen Speicher verwendest du, und welchen Zweck hat das ganze ?
@Benedikt: Also wenn der Speicher Kaputt ist dann läuft überhaupt nicht :). Aber ich spreche nur von dem fall, wenn paar zellen defekt sind. Wenn ich den Bereich nicht teste wo meine C-funktion-Variablen gespeichert sind, dann werde ich auch nie endecken ob irgend eine Zelle defekt ist. Deshalb kann ich beim variablen umlagern in einem Bereich was ich vorher getestet habe die defekte Speicher-zelle endecken, spätestens beim dritten durchlauf. weil: ich muss drei physikalisch getrennte speicherbereiche (DPRAM, DSRAM & PSRAM) testen! von XC164CS, und jedesmal wenn ich einen Bereich teste werden die variablen im anderen Physikalischen Breich gespeichert und das 3-mal!. PS: ich brauche das für Aufbau von einem Steuergerät im sicherheitsbereich (SIL-3)
Solche Diskussionen gab es schon öfters. In Einchippern ist ein Speichertest sinnlos, das muß und kann nur der Hersteller durch seine Qualitätskontrolle sicherstellen. Der macht das auch unter allen kritischen Spannungs-, Frequenz- und Temperaturbedingungen. Bzw. wenn man dem internen Speicher nicht traut, dann dürfte man ja auch den Registern, der ALU, den Timern, der UART usw. nicht trauen. Es muß also nur Speicher geprüft werden, der extern angeschlossen ist, d.h. wo kalte Lötstellen oder Kurzschlüsse möglich sind. Dazu nimmt man dann ein Assemblerprogramm welche nur mit den internen Registern arbeitet. Zu beachten ist dabei, daß es oft mehrere Zugriffsbefehle gibt, die mehr oder weniger kritisch sind. Des weiteren gibt es Flash-Bausteine, die sich selbst umprogrammieren können. Da testet man üblicher Weise, ob eine CRC noch stimmt. Peter
Hallo,
>Bzw. wenn man dem internen Speicher nicht traut, dann dürfte man ja
auch den Registern, der ALU, den Timern, der UART usw. nicht trauen.
Das tut man bei sicherheitsgerichteten Anwendungen auch nicht. D.h.
hier müssen auch Tests für Register... implementiert werden.
Über Sinn und Unsinn lassen sich lange philosophische Diskussionen
führen.
Gruss
Andreas
Hallo, Auch wenn wir alle Einheiten in einer Mikrokontroller trauen, bleib die frage wie lange trauen wir Sie?? Wie jederman weiss für "alles" gibt ein Lebensdauer, ausserdem gibt's sachen wie Kruzschluss, überspannung, umweltbedingungen,... usw. allein aus diesen gründe muss man in der sicherheitstechnick automatisierte tests durchführen. @Andreas Hesse: Also diese Eimalige test vom Hersteller durch seine Qualitätskontrolle garantiert lange nicht, dass das teil für "immer" weiterhin einwandfrei laufen wird MfG Jeff
Hi, Du hast natürlich vollkommen Recht. Man kann die korrekte Funktion nicht durch einmalige Kontrolle beim Hersteller über die Laufzeit garantieren. Mit der Aussage "Über Sinn und Unsinn lassen sich lange philosophische Diskussionen führen" wollte ich lediglich klar machen, das es hier sehr abweichende Meinungen gibt (von "Bringt gar nichts" bis "Ist absolut notwendig"). Tatsächlich ist es wohl so, das wirkliche Hardwarefehler sehr, sehr selten sind. (Daher auch die philosophische Diskussion). Aber wenn jemandem aufgrund eines solchen Fehlers (der durchaus denkbar ist) ein Arm abgrissen wird, dann bekommt die Diskussion eine andere Dimension. Gruss Andreas
Früher auf den Kuchenblechen ware solche Tests noch sinnvoll. Aber in einem einzigen Chip weiß eigentlich nur der Hersteller, wo die Schwachstellen sind. Und er wird den Teufel tun, es jemandem anderen zu verraten. Es könnte ja sonst jemand sein Produkt für unzuverlässig halten. Du kannst Dir die wunderschönsten Tests für alles mögliche ausdenken und bei jedem Fehler das Carry-Bit setzen, aber ausgerechnet dieser Befehl ist fehlerhaft. Und schon denkt Dein Programm, alles ist o.k. Ein kranker Arzt kann sich nun mal nicht selber am Gehirn operieren. Wenn es auf Sicherheit ankommt, dann muß man eben schon vom Hersteller strenger geprüfte Teile nehmem (military) und die Teile weit unter Spezifikation betreiben (max halber Takt). Und wenn das nicht reicht, dann muß eben Redundanz her, z.B. 3 MCs, die sich gegenseitig prüfen und überwachen. In meiner Praxis habe ich z.B. gemerkt, daß Quarze ab und zu mal ausfallen. Da ist dann z.B. der Einsatz der C8051Fxxx sinnvoll, die haben einen Missing-Clock-Detector und können dann auf den Internen Clock zurückschalten und ein Notprogramm ausführen. Und dann kann man eben noch Portpins schroten. Aber daß der interne SRAM spinnt, habe ich noch von keinem einzigen MC gehört. Peter
Hi und wie testet man dann den Befehlsdekoder? Alle Befehle einmal ausfühen lassen und darauf hoffen das der Befehlsdekoder nicht vom Befehl vom letzten Takt beeinflußt wird? Oder alle Befehle nach jedem Befehl testen? Aber was ist dann mit t-2? Wie du siehst wächst das Problem exponentiell und wird nach ein paar Stufen, selbst für Großunternehmen, praktisch unlösbar. Matthias
@Peter: Du hast vielleicht nicht vom interne SRAM der spinnt gehört, aber es gibt gewisse standard die man befolgen soll bei der Sicherheitanwendungen, die vom TÜV und VDE(Verein Deutscher Ingenieure) festgelegt sind. Du hast recht wenn du sagst durch die Redundanz (3MCs) ein gewisses sicherheit gewährleistet, es hat aber zu tun mit dem Bereich wo das ganze eingesetzt wird und daraus folgende SIL(Safety integrity Level 1,2 oder 3) und ob der TÜV mit dem ganze einvertanden ist. Bei SIL-3 aber ist es notwendig auch wenn man Zweikanalige Strukturen mit diversitären Hard- und Software und Unterschidlicher Programmierern vorzieht, auch einen Speichertest Notwendig und zwar für ROM und RAM. Jede Kanal für sich soll Fehler erkennen können, und in den sicheren zustand gehen... Also man kann sich selber eine Weg ausdenken um eine sicherheit Awendung zu realisieren, aber ob es vom TÜV abgesegnet wird ist die grosse frage!. MfG Jeff
Wenn ein Speichertest vorgeschrieben ist, mußt Du ihn natürlich machen. Vorschriften werden ja von Beamten erstellt, die nicht erkennen können, ob in einer konkreten Anwendung eine Sache notwendig ist oder überhaupt einen Effekt hat oder sogar schadet. Vielleicht ist es auch historisch begründet. Ich kann mich erinnern, daß DRAMs früher sehr fehleranfällig waren, auf Mainframes wurde deshalb sogar mit Fehlerkorrektur gearbeitet. Rein statistisch fallen die 1GB in einem PC ja auch wesentlich schneller aus, als die 1kB in einem MC. Bei einem gesunden Menschen ist es sehr unwarscheinlich, daß er in den nächsten 24h stirbt. Bei 1.000.000 Menschen, kann man aber darauf wetten, daß es einen davon trifft. Peter
Hi, die Vorschriften werden aber nicht nur von Beamten gemacht. Hier sind jede Menge Vertreter aus der Industrie dabei (es soll sogar Normen geben, die ausschliesslich von Industrievertretern geschrieben wurden). Ausserdem sind Dinge, die in Normen stehen, zum Teil das Resultat von intensiven Forschungstätigkeiten z.B. der BIA. Gruss Andreas
Nachtrag: Ich gebe Peter insofern recht, das es ziemlich unwahrscheinlich ist, das ein Speicher im MC ausfällt. Aber vermutlich ist es einfacher nachzuweisen, das ein bestimmter Test eine bestimmte Anzahl an Fehlern aufdeckt, als nachzuweisen, wie hoch die Ausfallwahrscheinlichkeit eines Speichers tatsächlich ist. Gruss Andreas
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.