Hallo Leute, ich würde hier gern einige Meinungen zu einer Problematik hören mit der ich mich gerade auseinandersetze. Folgende Situation: Wir haben einen Mikrocontroller, eher komplexerer Natur, mit einem embedded Linux System. Das ganze braucht zum Booten (sowohl nach Reset als auch beim erstmaligem Einschalten) z.B. 10 Sekunden. Wir wollen die Schaltung robust gestalten und haben vor einen HW-Watchdog zu verwenden, der über einen GPIO Pin des Controllers getriggert wird. Um Schäden an der Hardware zu vermeiden, wollen wir jedoch einen wesentlich kürzeren Watchdog-Timeout einstellen, als die Zeit die das System zum Booten braucht. Gängige Watchdogs (Alle die ich bisher gefunden habe), legen nach dem Reset sofort wieder mit der Überwachung der WDI Leitung los, und resetten den Controller mangels Trigger-Signal danach unmittelbar wieder. Es gilt also den Watchdog für die Zeit des Boots (also nach Auslösen des Reset Signals durch ebendiesen Watchdog) auszuschalten oder abzukoppeln (Reset Leitung trennen, WD-Enable Pin auf GND ziehen oder Ähnliches). Von der Entwicklungsphilosophie her ist es ein Unding den WD über einen weiteren GPIO Pin des Controllers an bzw. auszuschalten. Damit hätte ja die Software, die ja durch den WD überwacht wird, theoretisch die Möglichkeit diesen auszuschalten. Die WD Schaltung muss demnach ausschließlich in Hardware realisiert sein. Nun sollte ich ja, wie euch allen klar sein wird, nicht den WD mit seinem eigenen Reset Signal ausschalten, weil ich mir dann nicht sicher über den Zustand der Reset Leitung sein kann (z.B. wird die Pulslänge so sehr kurz sein, außer ich baue eine Verzögerung ein usw.). Es scheint ein Problem zu sein, mit dem sich bisher kaum jemand auseinander gesetzt hat. Ich habe eine App-Note von TI gefunden (http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slva145&fileType=pdf) die sich mit diesem Thema befasst. Die dort vorgeschlagene Schaltung ist in meinen Augen aber nicht gut (gelinde gesagt), da auch hier HW und SW sich an einer unzulässigen Stelle beeinflussen. Ich zerbreche mir seit einigen Tagen den Kopf über das Problem und konnte bisher keine Patentlösung finden. Vllt. kennt jemand hier im Forum eine elegante Lösung, oder sogar einen Baustein, der nach dem Reset eine einstellbare Delay Zeit hat (nicht nur bei Startup, wie z.B. der MAX6373). Das würde mir weiterhelfen, außerdem glaube ich dass das Thema zu unrecht nicht thematisiert wird. Ich freue mich auf euere Ideen. Danke im Voraus.
Was spricht dagegen, die benötigte Funktionalität in einem kleinen 8 Bein Controller abzubilden?
Man könnte einen ATtiny13 nehmen und das gewünschte Zeitverhalten hinein programmieren. Es ist durchaus gängig, eine komplexere CPU mit einem kleinen 8-Bitter zu überwachen. Manche komplexere CPUs können auch so aussteigen, daß nichtmal mehr ein externes Reset hilft. Der kleine 8-Bitter sollte dann auch ein Power-On/Off generieren können (P-MOSFET in VCC-Leitung).
Daran dachte ich auch. Der Punkt ist, dass die Funktionalität dann ebenfalls als Software umgesetzt wäre. Zwar hätte der zu Überwachende Controller da keinen Einfluss drauf, die Fehleranfälligkeit des Systems (Bitflips, Latchups usw.) wäre aber deutlich höher, als wenn das Ganze eine reine HW Lösung wäre. Was Passiert z.B. wenn der WD-Controller eine Macke hat und die Timer-Einstellungen sich verändern? Das System an dem ich baue wird unter Umständen größeren Strahlungsmengen ausgesetzt und das ist für programmierbare Bausteine pures Gift. Ich würde diese Lösung also nur im absoluten Notfall wählen, wenn sich nichts anderes ergibt.
cyblord ---- schrieb: > Was spricht dagegen, die benötigte Funktionalität in einem kleinen 8 > Bein Controller abzubilden? Zum Beispiel: http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1009&mid=10&lang=en&pageId=74
@Peter: kennst du vllt eine Quelle (App-Note) o.Ä. wo die Verwendung eines kleinen Controllers als WD beschrieben wird? Mir ist sowas trotz langer Suche noch nicht untergekommen. Wäre interessant mal zu sehen um was für Systeme es da geht.
@Peter II: Ja, theoretisch. Das wäre aber eine andere Ebene der Software, als die wo das im Normalbetrieb später erfolgen soll. Der softwareseitige Aufwand und die Struktur des Ganzen würde darunter leiden. Und wir alle wollen ja möglichst ellegante Lösungen haben )) Ich bin kein Informatiker, aber so in etwa wurde mir das erklärt.
Dann fummel halt ein entsprechendes Zeitglied an einen fertigen WD-Controller. Sollte nun auch kein Problem sein. Gibt halt einige Bauteile mehr. Wenn dir das lieber ist.... Es gibt natürlich auch Möglichkeiten einen programmiebaren Controller abzusichern. Erstmal kann man den auch redundant aufbauen, also 2 oder 3 davon. Dann könnte man das Programm im Flash periodisch auf Fehler (z.B. mittels Checksum oder kompletter Kopie) prüfen. Muss ja auch kein Flash-Controller sein. Gibt doch auch OTP-Controller !? gruß cybord
cyblord ---- schrieb: > Gibt doch auch OTP-Controller !? Und OTP schützt vor Fehlern bei der Programmierung des WDT-µCs?
@cyblord: Ja, sicher, das stimmt alles absolut. Redundanz wäre eine Möglichkeit, auch Zeitglied wäre u.U. OK. Ich hab nur immer das Gefühl dass ich den Wald vor lauter Bäumen nicht sehe und dass es irgendwie ohne signifikante Erhöhung der Bauteilmenge möglich sein sollte. Das mit den OTP-Controllern werd ich mir gleich mal anschauen.
Vladi B. schrieb: > Zwar hätte der zu Überwachende > Controller da keinen Einfluss drauf, die Fehleranfälligkeit des Systems > (Bitflips, Latchups usw.) wäre aber deutlich höher, als wenn das Ganze > eine reine HW Lösung wäre. Was Passiert z.B. wenn der WD-Controller eine > Macke hat und die Timer-Einstellungen sich verändern? Und was passiert, wenn die WD-Hardware eine Macke hat? Etwas schiefgehen kann immer. Festverdrahtete Hardware ist nicht unbedingt zuverlässiger als ein Mikrocontroller.
Vladi B. schrieb: > @Peter II: Ja, theoretisch. Das wäre aber eine andere Ebene der > Software, als die wo das im Normalbetrieb später erfolgen soll. Der > softwareseitige Aufwand und die Struktur des Ganzen würde darunter > leiden. Und wir alle wollen ja möglichst ellegante Lösungen haben )) Ich > bin kein Informatiker, aber so in etwa wurde mir das erklärt. könnte man ja umschaltbar machen. Während der boot Phase übernimmt der Kernel, nach dem die Anwendung gestartet ist übernimmt sie das rücksetzen vom WD und schalte das rücksetzen im Kernel aus.
greg schrieb: > Vladi B. schrieb: >> Zwar hätte der zu Überwachende >> Controller da keinen Einfluss drauf, die Fehleranfälligkeit des Systems >> (Bitflips, Latchups usw.) wäre aber deutlich höher, als wenn das Ganze >> eine reine HW Lösung wäre. Was Passiert z.B. wenn der WD-Controller eine >> Macke hat und die Timer-Einstellungen sich verändern? > > Und was passiert, wenn die WD-Hardware eine Macke hat? Etwas schiefgehen > kann immer. Festverdrahtete Hardware ist nicht unbedingt zuverlässiger > als ein Mikrocontroller. Ja, aber zumindest strahlungsresistenter. Das ist meine Hauptsorge an der Stelle.
Peter II schrieb: > könnte man ja umschaltbar machen. Während der boot Phase übernimmt der > Kernel, nach dem die Anwendung gestartet ist übernimmt sie das > rücksetzen vom WD und schalte das rücksetzen im Kernel aus. Wäre vllt. eine Lösung. Ich muss mal die Informatiker hier drauf anhauen. So wie ich die kenne werden sie mir aber einen dreistündigen Vortrag darüber halten wie kompliziert das ist ))
4112 schrieb: > cyblord ---- schrieb: >> Gibt doch auch OTP-Controller !? > > Und OTP schützt vor Fehlern bei der Programmierung des WDT-µCs? Nein, aber wer hat das behauptet? @Vladi: Deine Anforderungen sind etwas widersprüchlich. Du willst ein genau definiertes nicht-Standard Verhalten. Du willst aber keine zusätzlichen Bauelemente und keinen programmierbaren Baustein. Irgendwas passt da nicht. Natürlich kann man jetzt suchen obs was fertiges mit GENAU den Anforderungen gibt. Aber das hast du ja bereits erfolglos getan. Somit musst du einen Tod sterben. Der programmierbare Controller wäre ein gutes Proof-of-Concept und erhöht deine Bauteilemenge praktisch nicht. Im nächsten Schritt kann man immernoch überlegen wie man das ganze robuster machen kann. Vorher wäre aber eine Abschätzung über die Ausfallwahrscheinlichkeiten nötig. Mit welcher Wahrscheinlichkeit wird der WD überhaupt benötigt? Mit welcher W. wird ein Controller durch die Strahlung nach Zeit X unbrauchbar usw. Für sowas im Kernel rumpfuschen halte ich (als Informatiker ;- ) ebenfalls für den falschen Weg. Um ein wenig an Sicherheit zu gewinnen baut man in den Kernel damit evt. neue Probleme ein. Da kann man nur verlieren. gruß cyblord
:
Bearbeitet durch User
Vladi B. schrieb: > Ich muss mal die Informatiker hier drauf > anhauen. So wie ich die kenne werden sie mir aber einen dreistündigen > Vortrag darüber halten wie kompliziert das ist )) Ich könnte mir schon vorstellen, daß einen Kernel neu kompilieren deutlich aufwendiger und fehleranfälliger ist, als schnell mal 10 Zeilen in C für nen 8-Bitter hinzuschreiben.
@Peter: GENAU hier liegt das Problem. Wenn man diese 10 Zeilen "schnell mal" schreibt, hat man danach den Salat )) Aber ich weiß schon was du meinst. Ich seh das inzwischen ähnlich wie Cyblord. Das Problem ist zu speziell um eine vorgefertigte Lösung zu finden. Den Verschaltungsaufwand zu erhöhen bei der Größe meiner Platinen ist auch nicht zweckmäßig. Ich werde erstmal versuchen eine Studie zur Strahlungsresistenz kleiner 8-Bit Controller zu finden und dann einen auswählen.
Vladi B. schrieb: > @Peter: GENAU hier liegt das Problem. Wenn man diese 10 Zeilen "schnell > mal" schreibt, hat man danach den Salat )) Also in diesem Fall kann man das Risiko eines Programmierfehlers praktisch ausschließen. Die Aufgabe ist so klein und dezidiert, da kann man ein fehlerfreies Programm schreiben. Man könnte sogar die Fehlerfreiheit mathematisch nachweisen. Auch wenn ich das hier nicht für nötig halten würde. Auch ist die Funktion so einfach, dass man sie auch sehr leicht testen kann, unter allen Bedingungen sozusagen. Rein auf die SW-Funktionialität bezogen natürlich. NICHT auf Umwelteinflüsse usw.
Vladi B. schrieb: > greg schrieb: >> Vladi B. schrieb: >>> Zwar hätte der zu Überwachende >>> Controller da keinen Einfluss drauf, die Fehleranfälligkeit des Systems >>> (Bitflips, Latchups usw.) wäre aber deutlich höher, als wenn das Ganze >>> eine reine HW Lösung wäre. Was Passiert z.B. wenn der WD-Controller eine >>> Macke hat und die Timer-Einstellungen sich verändern? >> >> Und was passiert, wenn die WD-Hardware eine Macke hat? Etwas schiefgehen >> kann immer. Festverdrahtete Hardware ist nicht unbedingt zuverlässiger >> als ein Mikrocontroller. > > Ja, aber zumindest strahlungsresistenter. Das ist meine Hauptsorge an > der Stelle. In welcher Höhe soll die Schaltung denn betrieben werden? Über 5000ft?
cyblord ---- schrieb: > Vladi B. schrieb: >> @Peter: GENAU hier liegt das Problem. Wenn man diese 10 Zeilen "schnell >> mal" schreibt, hat man danach den Salat )) > > Also in diesem Fall kann man das Risiko eines Programmierfehlers > praktisch ausschließen. Die Aufgabe ist so klein und dezidiert, da kann > man ein fehlerfreies Programm schreiben. Man könnte sogar die > Fehlerfreiheit mathematisch nachweisen. Auch wenn ich das hier nicht für > nötig halten würde. > Auch ist die Funktion so einfach, dass man sie auch sehr leicht testen > kann, unter allen Bedingungen sozusagen. Rein auf die SW-Funktionialität > bezogen natürlich. NICHT auf Umwelteinflüsse usw. War nur so dahergesagt, in diesem Fall ist das wirklich nicht schwer. Ich werde das jetzt so machen. Wahrscheinlich werden wir einen Strahlungstest damit durchführen müssen, wenn es fertig ist und schauen wann es den Geist aufgibt. Wenns zu früh ist, werde ich eine andere Lösung suchen müssen.
ARMdran schrieb: > In welcher Höhe soll die Schaltung denn betrieben werden? Über 5000ft? In 600km ))
Vladi B. schrieb: > Ja, aber zumindest strahlungsresistenter. Das ist meine Hauptsorge an > der Stelle. Auch nicht zwangsläufig. OTP wurde doch schon genannt. Grundsätzlich kommt es drauf an, was der Hersteller in Sachen Strahlungsfestigkeit garantiert, nicht darauf ob festverdrahtet oder Mikrocontroller.
Ansonsten: Nimm einen CPLD, das ist ein gängiger Weg. Programmiere ihn so, dass der Watchdog erst 10sec. nach dem letzten Reset aktiv wird. Das ganze "zählt" idR als Hardware, falls das ein Treiber ist. Und mit SEU hast Du dann bestimmt keine Probleme.
Wie wird denn der Hauptcontroller und seine Datenspeicher vor der Strahlung geschützt? Oder kommt da einfach spezielle Hardware zum Einsatz? Eventuell gibt es ja auch kleine Controller welche bereits Strahlungsresistent ausgeführt sind.
greg schrieb: > Vladi B. schrieb: >> Ja, aber zumindest strahlungsresistenter. Das ist meine Hauptsorge an >> der Stelle. > > Auch nicht zwangsläufig. OTP wurde doch schon genannt. > > Grundsätzlich kommt es drauf an, was der Hersteller in Sachen > Strahlungsfestigkeit garantiert, nicht darauf ob festverdrahtet oder > Mikrocontroller. Ganz richtig ist das aber nicht. Bei Microcontrollern haben wir immer einen Speicher (z.B. Flash in dem Fall, ob es bei OTP ähnliche Effekte gibt weiß ich jetzt nicht) Und die dort abgelegten Daten können sich durch Wechselwirkung mit der Strahlung verändern. Wir haben dann Fehler im Programmablauf ohne dass die HW an sich gelitten hat. Das ist das gefährliche.
Der Tiny hat ja nen RC oszillator drinne für den CPU Takt, und noch einen gesondert für den eigenen Watchdog. Wenn man das noch kombiniert mit nen Analogen Watchdog hat man ja drei Watchdogs.
Vladi B. schrieb: > ARMdran schrieb: > >> In welcher Höhe soll die Schaltung denn betrieben werden? Über 5000ft? > > In 600km )) Dann würde ich mein Konzept grundlegend überdenken, denn SEU ist dort definitiv ein Thema. Rad-Hard-Bausteine sind da schon fast ein Muss, denn teilweise sind die Effekte der Höhenstrahlung nicht reversibel. Da nützt dann auch ein Reset nichts, wenn der Linux-Prozessor defekt ist.
cyblord ---- schrieb: > Wie wird denn der Hauptcontroller und seine Datenspeicher vor der > Strahlung geschützt? Oder kommt da einfach spezielle Hardware zum > Einsatz? Eventuell gibt es ja auch kleine Controller welche bereits > Strahlungsresistent ausgeführt sind. Der WD ist Teil des Strahlungsschutzes, wenn man so will. Zusätzlich gibts da sogenanntes "Spot-Shielding" und bei der Auswahl der Bauteile wurden etwas Strahlungstolerantere bevorzugt.
ARMdran schrieb: > Vladi B. schrieb: >> ARMdran schrieb: >> >>> In welcher Höhe soll die Schaltung denn betrieben werden? Über 5000ft? >> >> In 600km )) > > Dann würde ich mein Konzept grundlegend überdenken, denn SEU ist dort > definitiv ein Thema. Rad-Hard-Bausteine sind da schon fast ein Muss, > denn teilweise sind die Effekte der Höhenstrahlung nicht reversibel. Da > nützt dann auch ein Reset nichts, wenn der Linux-Prozessor defekt ist. Das ist mir bekannt, beim Konzept des restlichen Systems wurde darauf geachtet. Rad-Hard Bauteile hängen vom Budget und von der Entwicklungsphilosophie ab. Ich denke aber dass das hier den Rahmen sprengen würde ))
Blöde Frage: Wenn das System im Fehlerfall >10s für einen Reboot braucht, wäre es dann soo schlimm den WD alle 15s zu triggern un im Fehlerfall >25s. warten zu müssen?
> Blöde Frage: Erst lesen, dann posten: > Um Schäden an > der Hardware zu vermeiden, wollen wir jedoch einen wesentlich kürzeren > Watchdog-Timeout einstellen, als die Zeit die das System zum Booten > braucht.
Kann man nicht 2 WD nehmen, einen für 10 Sekunden und einen für 1 sekunde. der Ausgang von beiden wird UND verknüpft. Die Software resetten nur den 1sec WD.
Hallo, Leider gibt es keine wirklich kleinen CPLDs mehr, aber im Prinzip ist die Funktion ja auch in Hardware einfach zu realisieren, es genügt ein Zähler, der nach einem externen Reset oder dem eigenen WD-Reset von den WD-Time-Events heruntergezählt wird und diese erst weitergibt, wenn er auf Null steht und die somit 10s abgelaufen sind. Natürlich kann da einiges kaputtgehen, aber es ist eben unmöglich mit einem WD vor dem Ausfall eben des WD zu schützen, und JEDE beliebige Schaltung kann ausfallen. Aber immerhin ist eine begrenzte Überwachung des WD durch das Hauptsystem möglich, man könnte z.B. prüfen, ob der Startup-Zähler tatsächlich auf 0 steht und ob ein WD-Rücksetzimpuls auch angekommen ist. Dann würde das System ev. weiterlaufen, aber melden, dass der WD ausgefallen ist und bitte mal der Kundendienst vorbeischauen möge (in 600 km Höhe nicht immer so einfach). Gruss Reinhard
Vladi B. schrieb: > Es scheint ein Problem zu sein, mit dem sich bisher kaum jemand > auseinander gesetzt hat. Es ist ja auch kein Problem. Der Watchdog kann ja nach dem RESET inaktiv oder über 10 Sekunden langsam sein, bis sich das System hochgefahren hat und dann durch eine I/O Operation erst aktiv gesetzt werden, bzw. auf 1 Sekunde verschärft werden. +----+ RESET --------|S Q|--- watchdog disable bzw. langsam | _| I/O ---||--+--|R Q| | +----+ R | GND So ist nur ein scharfschalten per Sofwtare möglich, kein auschalten mehr. Und wenn man will (lnagsamer watchdog) kann man gar hängende Boot-Prozesse neustarten. Obwohl dann eher ein booten einer know good Konfiguration nötig wäre.
MaWin schrieb: > So ist nur ein scharfschalten per Sofwtare möglich, kein auschalten > mehr. > Und wenn man will (lnagsamer watchdog) kann man gar hängende > Boot-Prozesse neustarten. Obwohl dann eher ein booten einer know good > Konfiguration nötig wäre. Du hast recht. Wenn die Software lediglich die Möglichkeit hat den Takt zu verändern, kann es nicht zum unkontrollierten Abschalten des WD kommen. Darüber denke ich mal nach. Vielen Dank Leute, ich hab nicht mit so viel konstruktivem Input in der kurzen Zeit gerechnet. Hilft mir echt weiter.
Reinhard Kern schrieb: > Hallo, > > Leider gibt es keine wirklich kleinen CPLDs mehr, aber im Prinzip ist > > Gruss Reinhard Coolrunner II in 32-qfn oder 48-qfn würde ich in diesem Kontext schon noch als klein bezeichnen.......
wieso nicht ein passenden Gehäuse das die Strahlung abhält. Den internen Watchdog kann man doch aktivieren wenn man lustig ist also nach dem Reboot starten und dann auch sehr kurz. In diesem Einsatzgebiet werden meist ältere µC oder Prozessoren mit größeren Strukturbreiten verwendet die nicht so empfindlich sind.
Als Watchdog eignet sich hervorragend der 74123: 2x monstabiler Multivibrator (MV) mit Retrigger, externe Bauteile nur ein Block-Kondensator sowie je ein R und je ein C für die Zeiten. Im 74123 sind gleich 2 dieser Dinger verbaut, der 1. MV wartet ca 20 sec. bis der Boot-Vorgang beendet ist und hält solange den CLR-Eingang des 2. MV auf low. Der 2. MV ist dann der eigentliche Watchdog und wird über A oder B vom µC nachgetriggert.
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.