Hallo zusammen, ich muss zurzeit eine Projektarbeit über Selbsttests in Mikrocontrollern schreiben. Leider habe ich davon absolut keine Ahnung und habe noch keine Website gefunden die mir das Gut und möglichst einfach erklärt. Es geht um das Stichwort BIST (Built in Selftest) bei Mikrocontrollern. Wäre super wenn mir vielleicht einer von euch weiter helfen könnte! Vielen Dank!
Die Suche nach "IEC60730 Self Test Code" liefert Dir Beschreibungen und Codebeispiele von diversen Controller-Herstellern.
Amelie Vollmer schrieb: > Wäre super wenn mir vielleicht einer von euch weiter helfen könnte! > Vielen Dank! Also, Selbsttest als solches ist bei Mikrocontrollern nicht üblich, aber so etwas wird bei Steuereinheiten gebraucht, d.h. beim Einschalten muss geprüft werden, ob bestimmte Ventile Auf oder Zu sind, ob die Motoren sich in der Startpositionen befinden usw. Evtl. kann noch Eeprom auf richtigen Inhalt geprüft werden, auch ADC wird manchmal kontrolliert, aber das wird eher selten der Fall sein. Was und wie soll in deiner Projektarbeit konkret getestet werden ?
Danke für die schnelle Antwort. Die Fragestellung ist etwas schwammig gestellt, in der Vorlesung ging es zuvor aber um FMEDA, also Fehleranalyse. Ich habe auch schon mehrere Sachen gelesen bei denen ein Test in einem Mikrocontroller integriert ist nur leider waren die Artikel nie wirklich aufschlussreich.
Vielleicht könnte allgemein auf die Fragen eingegangen werden: Welche technische Funktionen muss ein Mikrocontroller erfüllen ? Welche Fehlermöglichkeiten sind bei Mikrocontroller möglich ? Wie verhalten sich Funktion / Teilfunktion beim Auftreten dieser Fehler, d.h. welche Auswirkungen ( Folgen) können diese Fehler haben und anhand welcher Symptome treten Auswirkungen in Erscheinung ? Welche Ursachen können diese Fehler haben?
Amelie Vollmer schrieb: > Vielleicht könnte allgemein auf die Fragen eingegangen werden: > > Welche technische Funktionen muss ein Mikrocontroller erfüllen ? > Welche Fehlermöglichkeiten sind bei Mikrocontroller möglich ? > Wie verhalten sich Funktion / Teilfunktion beim Auftreten dieser Fehler, > d.h. welche Auswirkungen ( Folgen) können diese Fehler haben und anhand > welcher Symptome treten Auswirkungen in Erscheinung ? > Welche Ursachen können diese Fehler haben? Ab jetzt befindest du dich auf dünnem (Hausaufgaben-)Eis.
Amelie Vollmer schrieb: > Vielleicht könnte allgemein auf die Fragen eingegangen werden: > > Welche technische Funktionen muss ein Mikrocontroller erfüllen ? > Welche Fehlermöglichkeiten sind bei Mikrocontroller möglich ? Nöö, eben nicht. Ein uC kann sich nicht selbst testen, bzw. diese Tests wären sowieso nutzlos, da immer erfolgreich oder gar nicht ausgeführt. Aber eine Steuereinheit mit eingebautem uC könnte das tun.
:
Bearbeitet durch User
Das heißt es gibt keinen tatsächlichen Selbsttest innerhalb des Mikrocontrollers?
:
Bearbeitet durch User
Hallo, also ganz langsam, was ist der Unterschied von: Steuereinheit zu uC? > Ein uC kann sich nicht selbst testen, bzw. diese Tests wären sowieso > nutzlos, da immer erfolgreich oder gar nicht ausgeführt. > Aber eine Steuereinheit mit eingebautem uC könnte das tun. Die Steuereinheit besteht mit größter wahrscheinlichkeit auch nur aus einem uC. Wenn mehr als ein Kreis für die Sicherheit vorhanden ist spricht man von Redundanz. Wichtig wäre erst einmal festzulegen welche art von Sicherheit gefordert wird, um auf den Grad des Selbstests eingehen zu können. jetzt war bereits IEC60730 schon erwähnt und wenn man nach SIL schaut gibts das für diverse Fachrichtungen unter anderer Normbezeichnung auch zu finden. Die Grundnorm für SIL ist die DIN EN 61508 Teil 1 bis 7. Davon steht Teil 3 für die Software. Die Test werden niemals 100% erreichen, das dürfte ja wohl uns klar sein. Und sporadische Fehler die durch Einstrahlung oder Blitzentladung kommen werden auch niemals auszuschließen sein. Es soll sogar tatsächlich schon uC geben, die den Selbsttest ab Werk im Bauch haben. Ich meine das habe ich in einer Werbung des Infineon automotiv Kontroller gelesen. Frag mal da nach. Gruß Sascha Wenn ein uC
quote Nöö, eben nicht. Ein uC kann sich nicht selbst testen, /quote Das erzählst mal Texas Instruments http://www.ti.com/product/rm48l952 @ Amelie Vollmer (amelie) wühl dich mal durch die Doku zu diesem Prozessor... Da kannst dir sicher nützliche Infos rauslesen.
Man kann Werte in den RAM schreiben und wieder auslesen um den RAM zu testen. Man kann Rechenoperationen mit bekanntem Ergebnis durchführen, um die ALU zu testen. Man kann kritische Werte doppelt (invertiert) speichern, um durch Einstrahlung gekippte Bits zu erkennen. Alles Standard im Automotive Bereich.
Marc Vesely schrieb im Beitrag #3918636: > Amelie Vollmer schrieb: >> Das heißt es gibt keinen tatsächlichen Selbsttest innerhalb des >> Mikrocontrollers? > > Nein, es gibt keinen. Wie sollte das auch funktionieren ? > Ein Beispiel: > Beim Selbsttest will man prüfen, ob RTC funktioniert. Dazu wird > aber funktionierender Takt und ein funktionierender Timer gebraucht. > > Wie will man prüfen, ob das funktioniert`? Du bist da auf dem falschen Dampfer. BIST bedeutet nicht detailierte Diagnose welche submodule funktionieren oder nicht. Hat es keinen takt kann der Test garnicht starten und das "PASSED" nicht signalisiert werden -> BIST mit Ergebniss FAIL durchgeführt.
Dr. Sommer schrieb: > Man kann Werte in den RAM schreiben und wieder auslesen um den RAM zu > testen. Man kann Rechenoperationen mit bekanntem Ergebnis durchführen, > um die ALU zu testen. Man kann kritische Werte doppelt (invertiert) > speichern, um durch Einstrahlung gekippte Bits zu erkennen. Alles > Standard im Automotive Bereich. RAM, FLASH und EEPROM testen gehört nicht zum Selbsttest. Das sind vom User geschriebene funktionen.
Marc Vesely schrieb im Beitrag #3918646: > Siegfried Siemens schrieb: >> Messung der Stromaufnahme während eines definierten Algorithmus ist auch >> ne Möglichkeit annomalitäten aufzuspüren. > > Und wie soll der uC seinen eigenen Verbrauch während dieser Zeit auf > picoAmper genau und noch dazu kontinuierlich messen ? Indem er den externenen health-moni chip ausliest oder ein entsprechender health moni mit in den uC eingebaut wurde. Beispielsweise über einen analogcomperator der die Spannung über einen C überwacht dessen ladestrom aus dem Shunt in der power-rail nimmt. -> Für einen Vollpfosten sind das natürlich böhmische Dörfer die es nicht gibt. MfG,
Siegfried Siemens schrieb: > Diagnose welche submodule funktionieren oder nicht. Hat es keinen takt > kann der Test garnicht starten und das "PASSED" nicht signalisiert > werden -> BIST mit Ergebniss FAIL durchgeführt. LOL. Hat es keinen Takt, wird der uC gar nicht starten. Insofern kann auch gar nichts signalisiert werden. Siegfried Siemens schrieb: > Indem er den externenen health-moni chip ausliest oder ein Selbstverständlich gehört ein externer Chip zu Selbsttest.
Marc Vesely schrieb: > Dr. Sommer schrieb: >> Man kann Werte in den RAM schreiben und wieder auslesen um den RAM zu >> testen. Man kann Rechenoperationen mit bekanntem Ergebnis durchführen, >> um die ALU zu testen. Man kann kritische Werte doppelt (invertiert) >> speichern, um durch Einstrahlung gekippte Bits zu erkennen. Alles >> Standard im Automotive Bereich. > > RAM, FLASH und EEPROM testen gehört nicht zum Selbsttest. > Das sind vom User geschriebene funktionen. Mumpitz, klar zählt das zum selbsttest beispielsweise wenn sie im Masken-ROM Bereich des µC liegen, wie bei diesem: http://www.ti.com/lit/ds/symlink/tms470mf06607.pdf Oder man bedient sich PNR Generator die in Verbindung mit ein paar Counter angeschlossene Speicher beschreiben - gängig bei FPGA's. Klar was der Vollpfosten nicht kennt das zählt er nicht. MfG,
Marc sieht offenbar das Wörtchen "Selbsttest" zu wörtlich. Er sieht es als ein Test, sich selbst - und nur sich selbst - zu testen. Dabei übersieht er offenbar, dass man unter einem Selbsttest eher den Test des kompletten Moduls, in dem der µC werkelt, versteht.
Sucht man bei Google nach "mikrocontroller selbsttest", findet man auch ein paar interessante Links von Infineon.
Datenblattauszug: The CPU self-test controller (STC)is used to test the ARM-CPU core using the Deterministic Logic Built-in Self-Test (LBIST) Controller as the test engine. Im RM48 sind Möglichkeiten verbaut um die Funktion der z.b. CPU auf Gatterebene zu prüfen. Das versteh ich jedenfalls unter einem eingebautem Selbsttest. Da brauch ich keinen externen Chip oder sonstwas. Die Funktionalität kann ich mit dem Controller ausführen. Wie das IM Controller selber realisiert ist, das ist mir relativ egal. Ob die dafür n 2ten Core verbauen, irgend ne verrückte Logik oder was auch immer...
Frank M. schrieb: > Marc sieht offenbar das Wörtchen "Selbsttest" zu wörtlich. Er sieht es > als ein Test, sich selbst - und nur sich selbst - zu testen. Ja, offensichtlich kennt er nur das Wort und nicht die Praxis/Theorie dahinter. Also komplett ignorieren. MfG,
Vielen Dank für die vielen Beiträge! Ja genau ich habe auch schon etwas gelesen darüber das BIST in mehreren Varianten vorkommen kann dem MBIST (Memory), LBIST (Logiken) und ABIST (Arrays). Vielleicht ist jetzt die Fragestellung etwas deutlicher :)
BIST schrieb: > Das versteh ich jedenfalls unter einem eingebautem Selbsttest. Es geht nicht um DEIN Verständnis sonder was die Industrie darunter eingebaut hat. Und das meint "Test ohne Testequipment, also im Einsatz. Selbst bezieht sich hier auf das Objekt nicht auf das Subjekt. also "der µC selbst wird getestet" und "nicht der µC testet sich allein selbst" . Das tutu er nicht sondern das macht der dazugebaute BIST teil. Macht dich mal über "Design for test" - DFT schlau. MfG,
Frank M. schrieb: > Dabei übersieht er offenbar, dass man unter einem Selbsttest eher den > Test des kompletten Moduls, in dem der µC werkelt, versteht. Nein, das habe ich schon weiter oben geschrieben. BIST schrieb: > The CPU self-test controller (STC)is used to test the ARM-CPU core using > the > Deterministic Logic Built-in Self-Test (LBIST) Controller as the test > engine. Auch das habe ich weiter oben geschrieben. Ein eingebauter Controller um uC selbst zu testen, ist eben nicht üblich. Natürlich kann man (und sollte es vielleicht) sich so etwas bei 2 Cores leisten.
@siegfried siemens lies meinen Post nochmal. Wir sind doch einer Meinung ;-) Genau das was du schreibst: quote sonder was die Industrie darunter eingebaut hat. Und das meint "Test ohne Testequipment, also im Einsatz. /quote sehe ich auch als einen Selbsttest an.
quote Auch das habe ich weiter oben geschrieben. Ein eingebauter Controller um uC selbst zu testen, ist eben nicht üblich. /quote beim Feld- Wald und Wiesen 0815 Controller natürlich nicht...
Marc Vesely schrieb: > Auch das habe ich weiter oben geschrieben. Ein eingebauter Controller > um uC selbst zu testen, ist eben nicht üblich. Du solltest Dich mal um das Studium der Bedeutung von "BIST" kümmern. Hier eine kleine Hilfe: http://de.wikipedia.org/wiki/Built-in-self-test Zitat: "Built in self test (BIST) bedeutet, dass ein elektronischer Baustein eine integrierte Testschaltung besitzt, welche Testsignale erzeugt und meist auch mit vorgegebenen richtigen Antwort-Signalen vergleicht, so dass das Testresultat an ein ATE (Automatic Test Equipment) ausgegeben werden kann. Built in self tests sind durch automatisierte Designprozesse immer einfacher zu implementieren und nehmen bei der heute üblichen großen Anzahl von Schaltelementen relativ wenig Platz ein, reduzieren aber den materiellen und zeitlichen Aufwand beim Testen erheblich. Sie werden auch zum regulären Selbsttest von Prozessoren während ihrer Anwendung oder beim Ein- bzw. Ausschalten verwendet, um Fehlfunktionen rechtzeitig zu erkennen und Folgeschäden zu vermeiden. Es existieren verschiedene Arten von Built in self tests: Analog- und Mixed-Signal-BIST Boundary Scan Test Logik-BIST Prozessor-BIST Signaturanalyse Speicher-BIST - z. B. mit dem Marinescu-Algorithmus" --- Zitat Ende ---- Der oben im ersten Satz erwähnte "elektronische Baustein" ist nicht der µC, sondern kann u.U. eine komplette Schaltung (meinetwegen auch inkl. µC) sein, um Antworten zu bekommen. Woher die Antworten kommen? Das kann ein µC, ein Speicher-Modul, ein Sensor oder was-weiss-ich sein.
Frank M. schrieb: > Du solltest Dich mal um das Studium der Bedeutung von "BIST" kümmern. Frank M. schrieb: > Der oben im ersten Satz erwähnte "elektronische Baustein" ist nicht > der µC, sondern kann u.U. eine komplette Schaltung (meinetwegen auch Threadname ist: Selbsttest in Mikrocontrollern (BIST). Nicht: Selbsttest in Modulen mit Mikrocontrollern Auch nicht: Selbsttest in Schaltungen mit Mikrocontrollern Wie schon oben geschrieben, es gibt ein paar uC mit Selbsttest, aber dazu wird ein speziell dafür vorgesehenes IC oder sogar ein eigener Controller verwendet. Dass die beiden zusammengegossen sind oder sich sogar auf einem DIE befinden, ändert nichts daran.
Also zumindest die RAM/Flash auf den Controllern werden in der Fertigung mit BIST getestet, das geht viel schneller, als die Signale von aussen anzulegen. Somit ist die Logik dafür in den Controllern vorhanden, allerdings kann sie selten von den Controllern selbst angestossen und ausgewertet werden. Ist aber im Zweifel kein Problem. Ansonsten gibt es natürlich Methoden wie ECC, dann kann man direkt beim Auslesen erkennen, ob im RAM ein Bit gekippt ist oder gar feststeht. Gruss Axel
Amelie Vollmer schrieb: > Leider habe ich davon absolut keine Ahnung und habe noch > keine Website gefunden die mir das Gut und möglichst einfach erklärt. Kein Wunder, das Thema ist so komplex, Du bräuchtest Mannjahrhunderte dazu. Und das meiste davon ist Bürokratie, also was irgendwelche Gremien irgendwann mal festgelegt haben. Und das ist auch ständig im Fluß. Und selbst der umfangreichste BIST ist völlig wertlos, wenn nicht die Schaltung und die Platine adäquat konstruiert wurden, z.B. ne simple Suppressordiode an VCC vergessen wurde. Du kannst nur etwas an der Oberfläche kratzen. Z.B. irgendwelche Normen raussuchen, welchen Sicherheitslevel diese abdecken und was im groben dafür zu implementieren ist. Vermutlich muß man für den Einblick in diese Normen aber erstmal tief in die Tasche greifen.
Es gibt z.B. einen uC, welcher zwei mal Ram hat. Beim Startup wird dieser getestet, in HW, BIST , und dann der funktionierende zum uC geschalten, bervor dieser startet. Auch gibt es vielfach einen Bereich im Flash/Rom, welcher einen Bereich des restlichen Flash ersetzten kann. Dies sind zwei Beispiele, um die Ausbeute des Wafers zu erhoehen. Ein LFSR welcher alle Register als Schieberegister schaltet, bondary scan like, sowie ein weiteres LFSR welches das Resultat prueft, haben die meisten uC.
Marc Vesely schrieb: > BIST schrieb: >> The CPU self-test controller (STC)is used to test the ARM-CPU core using >> the >> Deterministic Logic Built-in Self-Test (LBIST) Controller as the test >> engine. > > Auch das habe ich weiter oben geschrieben. Ein eingebauter Controller > um uC selbst zu testen, ist eben nicht üblich. Alter, woher willst du das wissen? Wenns für den Konsumenten nicht dokumentiert ist, heisst es noch lange nicht, das es das nicht gibt. Es sind sehr viele Strukturen auf einem µC, die nur "Testhalber" drauf sind. Klar wer will schon Chips in teuere Gehäuse packen die sich dann als Defekt erweisen! Und mit einem Selbsttest spart man sich Zeit am ATPG Tester oder sogar den teuren Teil des ATE-Geräteparks. Und im Vergleich zu den contact pads für die testprobes ist so ein Testcontroller winzig. Der User braucht sowas nicht, also wird es auch nicht im Gehäuse gebondet. Oder die BIST Strukturen sind auf dem Wafer in den Bereichen die dann zersägt werden - der BIST hat seine Schuldigkeit getan, der BIST kann gehen. JTAG als der Industriestandard für Testcontroller sieht das kommando RUNBIST vor:. http://dictionary.sensagent.com/Joint_Test_Action_Group/en-en/ > Natürlich kann man (und sollte es vielleicht) sich so etwas bei 2 Cores > leisten. Glaub uns, einen Test/Selbsttest der zu 0 ppm ausgelieferten Defekt-IC's führt leistet man sich auch bei den Single Cores oder µC. So ne Signaturanalyse braucht nicht viele Gatter https://de.wikipedia.org/wiki/Signaturanalyse_%28Digitaltechnik%29
Marc Vesely schrieb: > Wie schon oben geschrieben, es gibt ein paar uC mit Selbsttest, > aber dazu wird ein speziell dafür vorgesehenes IC oder sogar ein > eigener Controller verwendet. > Dass die beiden zusammengegossen sind oder sich sogar auf einem DIE > befinden, ändert nichts daran. Nein das muß kein extra controller sein, sondern die Testschaltung ist mit dem uC regelrecht "verschmolzen". Stichwort: Scanpath - FF http://www.ohio.edu/people/starzykj/network/Class/ee617/Handouts/Scan%20Path%20Design.pdf.
STM32 class B library http://www.st.com/web/en/resource/technical/document/application_note/CD00290100.pdf
Marc Vesely schrieb im Beitrag #3918646: >> Messung der Stromaufnahme während eines definierten Algorithmus ist auch >> ne Möglichkeit annomalitäten aufzuspüren. > > Und wie soll der uC seinen eigenen Verbrauch während dieser Zeit auf > picoAmper genau und noch dazu kontinuierlich messen ? Dafür hat man die BICS erfunden - Built-In Current Sensor -> http://www.researchgate.net/publication/4132082_Built-in_current_sensor_for_IDDQ_test/links/0deec5242dc009fc11000000 Wobei man damit eher den Ruhe- als den Arbeitsstrom misst. MfG,
Amelie Vollmer schrieb: > geht um das Stichwort BIST (Built in Selftest) bei Mikrocontrollern. "Handbuch der Electronic Design Automation" ist empfehlenswert: ISBN: 3-446-21288-4
:
Bearbeitet durch Admin
kopfkratz Tja nun bei schwammigen Formulierungen einfach mal nachhaken. Wenn Ihr schon mit den µCs gearbeitet habt und die Testschaltung kennt ist die Aufgabe wohl das durchzutesten. Üblicherweise macht man einen kompletten Test der internen Logik/CPU und der angeschlossenen Peripherie. Sollte es um eine spezielle Anwendung gehen z.B. einen PID Regler testet man das idR indem man eine Vorgabe und dazu passende Ausgabe hat und dann überprüft ob der Regler nachdem die Vorgabe eingegeben worden ist die korrekte Ausgabe erreicht. Ansonsten wurde ja schon auf passende Literatur hingewiesen.
Hallo, Aktuelle (multicore) Prozessoren machen einen Lockstep auf dem "security" core um einen kontinuierlichen Befehlstest (der ALU) durchzuführen. http://en.wikipedia.org/wiki/Infineon_AURIX http://pradeepchakraborty.wordpress.com/2009/10/15/stfreescale-intro-32-bit-mcus-for-safety-critical-applications/ Gruß Anja
Naja... BIST war vom TO angezeigt ( Build in Self Test >> eingebauter selbst Test ) Und da isses fast so wie bei den Menschen: komm auf die Idee, dich selbst zu überprüfen ( nur warum eigentlich und vor allem an was mess ich mein Ergebnis ) und was fang ich damit an?!? Vor allem, wenn mir das Ergebnis nicht gefällt? Selbstreflektion ist eine Schwäche die mehr als 80% nicht beherrschen! Auf mCs runtergebrochen: ich traue ihm nicht über den Weg und will ihn sich selbst testen lassen, aber wie kann ich dann seinem Ergebnis trauen?! Und jetzt die gesellschaftliche Analogie: Du brauchst n Freund, dem du vertraust oder auch eine Resonanzgruppe. Und wenn der/die dir sagt, Hey ALoch überdenk dich, dann brauchst nur noch etwas Charakterstärke um das anzunehmen und zu reagieren. Bei mCs: will ich Sicherheit, dann brauch ich einen der ihn überprüft und dem MUSS ich vertrauen. Besser noch wenn sich beide gegenseitig überprüfen. Darauf basiert ja auch Class C. Aber ganz ehrlich, n Gast der mit solch Beleidigungen um sich wirft... Selbstreflektion!?!
BIST ist in Hardware, heisst ja auch "build in" und nicht IEC60730 . Was man zumindest damit garantieren kann, dass die Register in Ordnung sind, der Programmzaheler funktioniert, die Alu sowie einige Peripherials, wie ADC. Neuerdings wird damit auch das Timing kontrolliert. Es kann sein, dass BIST durch die FW komplettiert wird, FW auf die man als User nicht rankommt, dieselbe welche die Register initialisiert. Was passiert, wenn ein Fail auftritt. Der uC kommt einfach aus dem power up delay nicht raus.
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.