Hallo, meiner vielleicht kurzsichtigen Meinung nach, ist es nicht notwendig das komplette Ram eines uC zu testen. D.h., falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt, muss ich auch keinen grösseren Bereich testen? Es sollte ja eigentlich genügen, nur nach dem Reset das gesammte adressierbare Ram und im laufenden Betrieb, z.B. mit einem Hintergrund Prozess, nur den verwendeten und auch im Linker-Config-File festgelegten Bereich zu prüfen? Sorry, falls ich Euch mit offensichtlichen Tatsachen langweile ... Hätte trotzdem gerne eine Antwort :-) lg Urlauber
Urlauber schrieb: > und im laufenden Betrieb, > z.B. mit einem Hintergrund Prozess, > nur den verwendeten und auch im Linker-Config-File festgelegten Bereich > zu prüfen? Du willst in einem laufenden System das RAM testen? MfG Klaus
konnte bei den AVR gehen wenn man den Stackpointer versetzt einen Bereich testet und dann den Stack inkl. des Inhaltes wieder dorthin setzt. RAMEND setzt ja der Assembler je nach Auswahl des µC im AVR Studio, aber das kann man bestimmt auch manuell machen. init: ;Stackpointer initialisieren ldi temp, RAMEND out SP, temp oder bei den größeren Typen ldi temp, low(RAMEND) ;Stackpointer initialisieren out SPL, temp ldi temp, high(RAMEND) out SPH, temp ich kann mir aber nicht vorstellen das ein µC mit defektem RAM die Produktion verlässt. Das sollte doch ein 1A Kriterium zum Aussortieren sein.
denke nicht, ich hatte auch noch nicht das Bedürftniss danach, habe da mal ATMEL vertraut und bisher noch keine Enttäuschung erfahren. Ich glaube aber mal gelesen zu haben das im Automotivbereich irgendwelche Tests vorgeschrieben sind, keine Ahnung ob es sich um das Programm selber handelt -> Checksumme oder ob explizit ein RAM Test erforderlich ist.
Urlauber schrieb: > falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt, > muss ich auch keinen grösseren Bereich testen? Das hängt möglicherweise auch mit der Sicherheitsstufe zusammen die du erreichen willst / mußt. Für SIL2 / ASIL B sollte es reichen. Urlauber schrieb: > und im laufenden Betrieb, > z.B. mit einem Hintergrund Prozess, > nur den verwendeten und auch im Linker-Config-File festgelegten Bereich > zu prüfen? Je nach Sicherheitsstufe reicht eventuell auch nur der RAM-Bereich der Überwachungsfunktionen. Klaus schrieb: > Du willst in einem laufenden System das RAM testen? Interruptsperre nicht vergessen. Insbesonders für die Stack-Bereiche. Thomas O. schrieb: > ich kann mir aber nicht vorstellen das ein µC mit defektem RAM die > Produktion verlässt. Das sollte doch ein 1A Kriterium zum Aussortieren > sein. In sicherheitskritischen Anwendungen geht es darum die (< 1ppm) Bauteilausfälle herauszufinden, die z.B. bei den Temperaturextremen die in der Fertigung nicht getestet werden können, auftreten. Gruß Anja
Thomas O. schrieb: > Ich glaube aber mal gelesen zu haben das im Automotivbereich > irgendwelche Tests vorgeschrieben sind, keine Ahnung ob es sich um das > Programm selber handelt -> Checksumme oder ob explizit ein RAM Test > erforderlich ist. Die Tests sind generell für sicherheitskritische rechnergesteuerte Systeme ab einem bestimmten Sicherheitslevel vorgeschrieben. Es gibt verschiedene Normen hierfür. Einen Einstieg gibts z.B. in AN1229 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en537355 Wobei Class B einer der niedrigeren Level ist. Die Bibliothek ist auch nicht vollständig. Gruß Anja
Urlauber schrieb: > Hätte trotzdem gerne eine Antwort :-) Dann solltest Du erstmal Informationen rüberbringen: Was für ein Sicherheitslevel? Was für eine konkrete CPU? Interner oder externer RAM? Ältere Rechner hatten ja noch externen Komponenten, die über Lötstellen verbunden waren. Und da Lötstellen mit Abstand am unzuverlässigsten sind, macht ein Test durchaus Sinn. Irgendwelche hirnlosen Bürokraten hatten den Zusammenhang aber nicht kapiert und das auch für interne Komponenten gefordert. Ist zwar völlig sinnlos, aber eben Bürokratie, also einzubauen für bestimmte Sicherheitslevel. Interne Komponenten prüft ja schon der Hersteller und zwar um Längen besser, als es je eine Testroutine könnte. Nur er weiß nämlich, was zu prüfen ist und kann auch Temperatur, VCC, Frequenz, Last usw. variieren, was in der Applikation nicht möglich ist. Peter
Thomas O. schrieb: > konnte bei den AVR gehen wenn man den Stackpointer versetzt einen > Bereich testet und dann den Stack inkl. des Inhaltes wieder dorthin > setzt. Geht einfacher. Einerseits weil man für einen RAM-Test auf den Stack verzichten kann. Andererseits weil man, wenns denn schon sein muss, ihn auf Adresse 15 setzen kann. Da sind ja auch ein paar Bytes "RAM".
Peter Dannegger schrieb: > Ältere Rechner hatten ja noch externen Komponenten, die über Lötstellen > verbunden waren. Und da Lötstellen mit Abstand am unzuverlässigsten > sind, macht ein Test durchaus Sinn. Steckverbindungen sind schlimmer. Behauptete zumindest IBM bei einer High-End Kiste, in die sie die Speichermodule nicht gesteckt sondern eingelötet hatten (Spötter sagen freilich, das sei nur geschehen, um die Kunden davon abzuhalten, den Speicher für 30-50% der Kosten anderswo zu kaufen ;-).
Vielen Dank für die bisherigen Antworten ... SIL2 wird verlangt, SIL3 gewünscht ;-) uC -> MC9S08DZ60, es wird also nur das (der) interne Ram verwendet. Class B Bibliothek von Freescale ist vorhanden, Class C Lib -> bisher Fehlanzeige. Es ist geplant das Ram im Hintergrund mit dem "Transparent Galpat" zu testen. Da dieser Test extrem langsam und in Häppchen abläuft, sind wichtige, eigentlich sogar die meissten Daten auch invers abgespeichert. Aber zurück zur Ausgangsfrage: In einem nicht verwendeten Rambereich kippt ein Bit. Dieses Bit ist (dynamisch) mit einem Bit im verwendeten Bereich verbunden und verfälscht es dadurch. So eine Verfälschung kann eigentlich nur durch einen kompletten Ramtest erkannt werden? Muss ich nun meine ursprüngliche Meinung ändern? Anderseits habe ich die wichtigen Daten auch invers abgespeichert und sollte Fälle wie diesen (oder wilde Zeiger) erkennen können? lg Urlauber
Hallo, als allererstes würde ich mir überlegen, was denn das System tun soll, wenn tatsächlich ein RAM-Fehler auftritt. Daten, die Block-oder Recordweise organisiert sind (z.B. Parameter und Messdaten) sichere ich jeweils mit Prüfsummen ab. Werden z.B. die Parameter fehlerhaft gelesen, so werden sie durch Standard-Parameter ersetzt, Messwerte sind im Zweifelsfall alle 0. Gruss Reinhard
Urlauber schrieb: > Es ist geplant das Ram im Hintergrund mit dem "Transparent Galpat" > zu testen. Gibt es ein Zeitlimit für den Test? Ich würde nen Timerinterrupt aufsetzen, der so langsam ist, daß er wichtige Prozesse nicht stört. Und der prüft dann jeweils nur ein einzelnes Byte, damit seine Ausführungszeit die wichtigen schnellen Interrupts nicht behindert. Urlauber schrieb: > Da dieser Test extrem langsam und in Häppchen abläuft, sind wichtige, > eigentlich sogar die meissten Daten auch invers abgespeichert. Ist sowas denn gefordert? Wenn nicht, würde ich es sein lassen. Es erhöht die Komplexität und damit die Gefahr, daß der Programmierer selber nen Fehler einbaut. Peter
Peter schrieb: > Gibt es ein Zeitlimit für den Test? Eigentlich sollte der komplette uC inkl. Peripherie, Ram, Flash, Programmablauf, ... innerhalb 100ms getestet werden. Das Flash ist kein Problem, kann ich auch in Häppchen unterteilen. Peripherie werden wir noch sehen, aber zumindest der Watchdog lässt sich bei dieser CPU nicht im Betrieb testen. > Ich würde nen Timerinterrupt aufsetzen, ... Ja, so ungefähr hab ich mir das auch gedacht, obwohl ein zyklischer Aufruf mit gesperrten Interrupts von der Hauptschleife aus vielleicht besser wäre, weil ich da weiss was die CPU gerade macht und der Stack fast leer ist ... Das invertierte Ram ist nicht gefordert, aber da ein hochwertiger Ramtest unmöglich in 100ms als Nebenjob unterzubringen ist, hoffe ich, mit den invertierten Daten die Zeit in der ein Fehler unerkannt bleibt, hinaufsetzen zu können. Ausserdem hilft diese Methode z.B. auch gegen wilde Zeiger, die unbemerkt irgendwo eine Variable verändern. Das müsste man sonst aufwendiger mit Signaturen erledigen, obwohl ich zugebe, das diese Lösung noch besser wäre. > Es erhöht die Komplexität und damit die Gefahr, daß der Programmierer > selber nen Fehler einbaut. Ja das stimmt schon, erzeugt aber andererseits irgendwie ein Gefühl der Sicherheit (wenns funktioniert). lg Urlauber
Die viel interessantere Frage ist doch: Wie geht es dann eigentlich weiter, wenn der Test tatsächlich einen Fehler entdeckt? Denn, wenn dein RAM fehlerhaft ist, kannst du dem auch nicht mehr vertrauen, dass du zb Funktionen aufrufen kannst und das alles wie gewohnt funktioniert.
Reinhard schrieb: > als allererstes würde ich mir überlegen, was denn das System tun soll, > wenn tatsächlich ein RAM-Fehler auftritt. Da Fehler im internen Ram angeblich extrem selten auftreten, werde ich in diesem Fall wohl das ganze Modul abschalten. Kann gut sein, das ich diesen Notfall selber nicht mehr erleben werde ;-) Eine Datenverfälschung durch fehlerhafte Software macht mir mehr Sorgen ... lg Urlauber
Karl Heinz schrieb: > Die viel interessantere Frage ist doch: Wie geht es dann eigentlich > weiter, wenn der Test tatsächlich einen Fehler entdeckt? In unserem Fall können wir einfach das Modul/Gerät abschalten und warten bis der Techniker kommt. Fehlertolerante Software zu entwickeln muss hingegen wohl die Hölle sein. lg Urlauber
Urlauber schrieb: > Fehlertolerante Software zu entwickeln muss hingegen wohl die Hölle > sein. Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und überträgt die Verantwortung einem Voter (möglichst in Hardware bzw. VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-) Gruß Anja
Anja schrieb: > Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und > überträgt die Verantwortung einem Voter (möglichst in Hardware bzw. > VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-) So gesehen schon, mit Redundanz lässt sich dieses Problem wohl wirklich erschlagen ;-) Aber ich hab noch eine Frage zum Watchdogtest: Verwendet wird der Interne und ein externer Watchdog. Beide werden nach einem Reset getestet, im Betrieb hingegen nicht mehr. Da unser Modul aber über einen Feldbus laufend Meldungen absetzt, müsste sich ein Programmabsturz anhand der Daten der Meldungen bemerkbar machen. Mir scheint, als wäre ein zyklischer Watchdogtest eher an "Standalone" Geräte gerichtet. lg Urlauber
Urlauber schrieb: > Aber ich hab noch eine Frage zum Watchdogtest: > Verwendet wird der Interne und ein externer Watchdog. > Mir scheint, als wäre ein zyklischer Watchdogtest eher an "Standalone" > Geräte gerichtet. Ich weiß nicht was Du unter einem Watchdog verstehst. Der interne ist meist nichts wert da er dieselben Ressourcen wie der Prozessor verwendet (Versorgungsspannung, Takt). In sicherheitsrelevanten Systemen stellt der externe Watchdog (unabhängiger Takt und unabhängige oder überwachte Versorgung) dem Prozessor Fragen die dieser innerhalb einer definierten Zeit richtig beantworten muß. Ist die Antwort falsch oder nicht im Zeitfenster so werden die Sicherheitskritischen Endstufen + Kommunikationswege abgeschaltet. Gruß Anja
Hallo, ich habe beruflich mit der Entwicklung von Software im Automotive Bereich zu tun. Bei den Maßnahmen die wir manchmal ergreifen, um eine Software möglichst sicher zu machen, wird einem oft schwindelig. RAM/ROM sind bei den meisten Micros mit ECC abgesichert um alle ein Bit Fehler erkennen und korrigieren zu können, und um alle zwei Bit Fehler zu erkennen. Damit ECC zuschlagen kann, muss auf die Zelle lesend zugegriffen werden, also schnell mal mit DMA über das ganze RAM lesend drüber um die Logik zu triggern. ECC wird natürlich vorher oder auch zyklisch getestet, ob Fehler auch erkannt werden können. Zusätzlich läuft noch ein Algorithmus, der alle Zellen im RAM rettet, beschreibt, liest und wieder herstellt. Während dem Startup laufen noch RAM Tests(inkl RAM der Peripherien) die in Hardware realiert sind (PBIST). Bei ROM nutzt man auch ECC und CRC Checksummen. CPU Kerne sind oft doppelt vorhanden und führen um 1,5 Taktzyklen versetzt die gleich Instruktion aus. CPU werden zyklisch mit einem LBIST getestet. Da werden alle CPU Register gesichert, der LBIST gestartet, einmal über den Reset Vector und nach Herstellen der Register gehts im Betriebssystem normal weiter.Man ergreift eher mehr Maßnahmen als nötig bevor man sich nachher irgendwas nachsagen lassen kann...Teilweise wird Software komplett in ASIL D nach ISO26262 entwickelt. Bei Interesse kann mal ja mal nach TMS570LS suchen.
Anja schrieb: > Ich weiß nicht was Du unter einem Watchdog verstehst. Der interne ist > meist nichts wert da er dieselben Ressourcen wie der Prozessor verwendet >(Versorgungsspannung, Takt). Ich verstehe das darunter, was als Watchdog im Datenblatt beschrieben ist. So ein Snob bin ich nicht, als das ich einen eingebauten Watchdog auch wenn er primitiv ist, von vornherein nicht benütze ;-) > In sicherheitsrelevanten Systemen stellt der externe Watchdog > (unabhängiger Takt und unabhängige oder überwachte Versorgung) dem > Prozessor Fragen die dieser innerhalb einer definierten Zeit richtig > beantworten muß. Ist die Antwort falsch oder nicht im Zeitfenster so > werden die Sicherheitskritischen Endstufen + Kommunikationswege > abgeschaltet. Also ein eigener uC ... Das bringt mich zu meiner vorher vergessenen Frage: Falls eine laufende zyklische Kommunikation (über einen Feldbus) mit anderen Busteilnehmern vorausgesetzt wird, verliert eigentlich der Watchdog und somit sein Test an Bedeutung? Ist im Grunde ganz ähnlich wie von Dir oben beschrieben, nur nicht am selben Print ... lg Urlauber
Maxwell schrieb: > Zusätzlich läuft noch ein Algorithmus, der alle Zellen im RAM rettet, > beschreibt, liest und wieder herstellt. Ist das der eigentliche (altmodische) Ramtest? "beschreibt" soll heissen, mit einer Signatur beschrieben? "alle Zellen" soll heissen, alle Zellen auf einmal, oder Häppchenweise nur Teilbereiche des Ram testen bis es komplett durch ist? Nicht übel der TMS570LS, würde mir die Arbeit sicher leichter machen. Vielen Dank für den interessanten Einblick :-) lg Urlauber
Anja schrieb: > Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und > überträgt die Verantwortung einem Voter (möglichst in Hardware bzw. > VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-) Und wer garantiert die korrekte Funktion des Voters? So einfach betrachtet führt einen das Konzept von Redundanz und Überwachung in eine endlose Rekursion. Ich habe mal auf Anforderung des TÜV an einem medizinischen Gerät eine unabhängige Überwachung der Ausgangsspannung vorgesehen, worauf gefordert wurde, dass auch die Funktion dieser Überwachungsschaltung wiederum überwacht werden müsste. Auf meinen Einwurf, das könnte man ja endlos so fortsetzen, dabei würden aber immer mehr Bauteile eingesetzt und daher die Ausfallwahrscheinlichkeit erhöht, hiess es dann, mit der Überwachung der Überwachung sei es genug. Aber das ist natürlich eine rein willkürliche Festlegung. Gruss Reinhard
Reinhard Kern schrieb: > So einfach betrachtet führt einen das Konzept von Redundanz und > Überwachung in eine endlose Rekursion. Ist das nicht prinzipiell so? Letztlich läuft das darauf hinaus, Fehlerwahrscheinlichkeiten ausreichend weit drücken zu können. Ganz los wird man sie nie. Das geht doch runter bis auf die Elektronik, wo irgendwelche gesampelten Inputs eine zwar sehr kleine aber nicht wegzukriegende Chance auf Metastabilität haben. In die Rekursionsfalle läuft man freilich, wenn das Überwachungssystem (im Sinne eines anspruchsvollen Watchdogs oder eines Voters) von ähnlicher Komplexität ist wie das überwachte. Das muss man schon deutlich einfacher ansetzen.
Maxwell schrieb: > CPU Kerne sind oft doppelt vorhanden und führen um 1,5 Taktzyklen > versetzt die gleich Instruktion aus. Das halte ich für unmöglich. Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas völlig anderes aus. Peter
Peter Dannegger schrieb: > Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen > werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein > ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas > völlig anderes aus. Wieso? Gleiche Daten / gleicher Input => gleiches Verhalten. Beim erwähnten TMS570LS sind nur die Kerne doppelt, nicht die Peripherie. Bei IBM Mainframe-Prozessorchips einer der letzten Generationen war das ähnlich (weiss nicht mehr ob heute auch noch). Da existiert ausserdem noch ein Hintereingang zum letzten sicheren Zustand. Der wird dann von einem Maintenance-Prozessor ausgelesen und in einen Reserveprozessor geladen, der nahtlos weiter macht. Hat den Nachteil, dass man den internen Cache nur write-through auslegen kann.
Maxwell schrieb: > Bei den Maßnahmen die wir manchmal ergreifen, um eine > Software möglichst sicher zu machen, wird einem oft schwindelig. Das mag sein, aber man hat den Eindruck, daß es überhaupt nichts bringt. Es wird immer die Hardware verdächtigt, daß sie fehlerhaft ist, aber die meisten Fehler entstehen in der Software selber. Deshalb wird auch die Firmware geupdated, bis die Schwarte kracht. Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen Defekt bei der Chipfertigung. Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert in der irrigen Hoffnung, viel hilft viel. Peter
Peter Dannegger schrieb: > Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an > schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen > Defekt bei der Chipfertigung. Die Wahrscheinlichkeit ist zwar über die Jahrzehnte dank besserem Gehäusematerial gesunken, aber transiente Fehler aufgrund von radioaktiver Strahlung sind auch in normaler Umgebung immer noch mit auf der Rechnung. Zumal schrumpfende Strukturen gegenüber Quellen solcher transienter Fehler immer empfindlicher werden. > Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind > mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert > in der irrigen Hoffnung, viel hilft viel. Dieser Ansatz ist natürlich Unfug. Aber mit Fehleranalyse kann Hardware-Redundanz durchaus sinnvoll sein, zumal man - wenn man es ernst meint - bei Software auch ein bischen besser vorgehen kann als so lange try-and-error durchzuziehen, bis es leidlich funktioniert und die Kunden als unfreiwillige Betatester zum Zuge kommen.
A. K. schrieb: > Wieso? Gleiche Daten / gleicher Input => gleiches Verhalten. Die Daten kommen aber von außen, also müssen sie nach 1,5 Zyklen nicht mehr gleich sein. Selbst wenn Du 2 CPUs exakt synchron laufen läßt und einen externen Interrupt an beide anlegst, müssen ihn nicht beide im gleichen Zyklus erkennen. Und schon sind sie asynchron. Nimm 2 D-FFs (74HC74), lege Takt und Daten parallel an und ein EXOR dahinter. Die Daten werden asynchron zum Takt erzeugt und Du wirst an beiden Ausgängen manchmal unterschiedliche Pegel haben. Peter
Peter Dannegger schrieb: > Selbst wenn Du 2 CPUs exakt synchron laufen läßt und einen externen > Interrupt an beide anlegst, müssen ihn nicht beide im gleichen Zyklus > erkennen. Und schon sind sie asynchron. Das setzt voraus, dass die beiden CPUs asynchrone Signale erhalten. Tun sie beim TMS570LS aber nicht, zumindest nicht wenn der Rest vom Chip noch sauber funktioniert. Da sind nur die Cores gedoppelt.
Peter Dannegger schrieb: > Deshalb wird auch die Firmware geupdated, bis die Schwarte kracht. Die Hardware lässt sich leider (noch?) nicht online updaten. Und manch ein Softwareupdate dient dazu, Unzulänglichkeiten in der Hardware auszubügeln. Oliver
Oliver schrieb: > Die Hardware lässt sich leider (noch?) nicht online updaten. Bei FPGAs gewissermassen schon. Theoretisch sogar mit Rerouting um defekte Elemente herum.
>meiner vielleicht kurzsichtigen Meinung nach, >ist es nicht notwendig das komplette Ram eines uC zu testen. >D.h., >falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt, >muss ich auch keinen grösseren Bereich testen? Nun ja, wenn Du einen Compiler verwendest, dann legt doch der Linkler fest, wo die Variablen stehen. Das hat zur Folge, dass das irgendwo im RAM sein kann. Legst Du die Variablen händisch fest, hast Du diese Problem nicht und Du kannst Deinen Bereich vorher testen. >Es sollte ja eigentlich genügen, nur nach dem Reset das gesammte >adressierbare Ram und im laufenden Betrieb, >z.B. mit einem Hintergrund Prozess, >nur den verwendeten und auch im Linker-Config-File festgelegten Bereich >zu prüfen? Wenn Du weisst, wo Deine Variablen stehen, sollte es genügen. Für solche Tests im Vorfeld bietet sich vielleicht ein kleiner Bootloader an, der erst einmal das RAM testet und danach ins Hauptprogramm springt. Kläre aber erst einmal Deinen Anspruch an den Sicherheitslevel!!! Rosa
Hier noch ein interessanter Artikel zum TMS570: http://www.elektroniknet.de/automotive/technik-know-how/bauelemente/article/29575/0/Cortex-R4-Mikrocontroller_fuer_das_Automobil/ für unsere Anwendung leider etwas überdimensioniert ... lg
Hallo, Peter Dannegger schrieb: > Das halte ich für unmöglich. > > > > Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen > > werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein > > ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas > > völlig anderes aus also das mit den 1,5 Zyklen versatz stimmt so. Ich spare mir die Erklärung und verweise auf das Datenblatt ->4.9.1 Dual Core Implementation Es ist ja nicht so, dass jeder Kern die Interrupts vom VIM bearbeitet. Das kann nur von einem gemacht werden. Peter Dannegger schrieb: > Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind > > mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert > > in der irrigen Hoffnung, viel hilft viel. Dazu kann ich nur sagen, dass während dem Software Entwicklungsprozess einige Maßnahmen ergriffen werden, um die Software Fehler auf einen sehr kleinen Wert zu bringen. Stichwort polyspace, QA C, Cantata... Die von mir angesprochenen Maßnahmen dienen nur der Sicherstellung, dass die Hardware funktioniert. Die Auftretenswahrscheinlichkeit von RAM Fehler wird vom Halbleiter Lieferant berechnet und ist sehr sehr gering. Aber trotzdem rechtfertig die kleine Zahl nicht, den Test zu unterlassen. Urlauber schrieb: > Ist das der eigentliche (altmodische) Ramtest? > > "beschreibt" soll heissen, mit einer Signatur beschrieben? > > "alle Zellen" soll heissen, alle Zellen auf einmal, oder Häppchenweise > > nur Teilbereiche des Ram testen bis es komplett durch ist? Altmodisch würde ich jetz nicht sagen, man muss halt jederzeit in der Lage eine Variable im RAM von 1 auf 2 zu setzen. Würde der Schreibbefehl nicht durchgeführt werden können, würde die Software das so erstmal nicht mitbekommen. Damit testet die Software auch die Kette CPU->BUS(evt Bus Matrix->RAM). Üblicherweise wählt man ein Muster was möglichst viele Bits betrifft, aber auch möglichst viele Wechsel zwischen den Bits. 0xAAAAAAAA bietet sich da an. Den Test kann man prima in kleinen Häppchen durchführen. Peter Dannegger schrieb: > Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an > > schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen > > Defekt bei der Chipfertigung. Dafür gibt es auch Maßnahmen. Bei Teilen die in sicherheitsrelevanten Umfeld millionenfach verkauft werden, wird man kein schlechte VCC zulassen. Bis jetzt hatte ich nur wenige Fälle, wo das RAM ein Problem hatte. Das war ein 8-bit Micro und selbst nach Freilegung des Die's konnte der Hersteller nicht sagen, wo das Problem lag. Meine Meinung... Einen einfachen RAM Test zu implementieren kostet nicht viel Zeit. Bei einer Hello World Anwendung würde ich das nicht machen. Sobald aber im Fehlerfall Leben davon betroffen sind, oder Kosten verursacht werden, lässt mich ein RAM Test besser schlafen :)
Urlauber schrieb: > Also ein eigener uC ... Nicht zwangsläufig es gibt ASICs die das mit entsprechender Markov-Kette schaffen. Einschließlich Logik zum Abschalten sicherheitsrelevanter Endstufen. Der Prozessor überwacht den Watchdog indem zyklisch falsche Antworten Eingestreut werden und der Fehlerzähler zurückgelesen wird. Bei einem Defekt des Watchdogs schaltet der Prozessor ab. Falls der Prozessor keine sinnvollen Antworten liefert schaltet der Watchdog ab. > Das bringt mich zu meiner vorher vergessenen Frage: > Falls eine laufende zyklische Kommunikation (über einen Feldbus) mit > anderen Busteilnehmern vorausgesetzt wird, verliert eigentlich der > Watchdog und somit sein Test an Bedeutung? Den Watchdog brauchst du nur bei sicherheitskritischen Aktoren. Oder falls du sicherheitskritische Sensorsignale hast die entsprechende Systemreaktionen zur Folge haben. In dem Fall sollte das "save silent" Prinzip gelten. D.H. defekte Sensorknoten werden vom Kommunikationsbus getrennt um einen "babbling idiot" zu deaktivieren. Reinhard Kern schrieb: > Und wer garantiert die korrekte Funktion des Voters? Natürlich der Zulieferer dem man die Verantwortung überträgt ;-) Reinhard Kern schrieb: > Ich habe mal auf Anforderung des > TÜV an einem medizinischen Gerät eine unabhängige Überwachung der > Ausgangsspannung vorgesehen, worauf gefordert wurde, dass auch die > Funktion dieser Überwachungsschaltung wiederum überwacht werden müsste. > Auf meinen Einwurf, das könnte man ja endlos so fortsetzen, dabei würden > aber immer mehr Bauteile eingesetzt und daher die > Ausfallwahrscheinlichkeit erhöht, hiess es dann, mit der Überwachung der > Überwachung sei es genug. Aber das ist natürlich eine rein willkürliche > Festlegung. Im Normalfall reicht es jeden schlafenden Fehler gelegentlich (POST) zu testen. Wichtig ist daß der Fehler irgendwie dem Benutzer mitgeteilt wird und im Handbuch entsprechende Hinweise sind (sofort Werkstatt aufsuchen). Wenn man es geschickt macht kann man die Hardwareüberwachung auf 3 Chips verteilen (Prozessor + intelligente Endstufen mit Spannungsüberwachung + Watchdog) und das ganze so regeln daß alle Überwachungsfunktionen ineinander greifen. Gruß Anja
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.