uC-Programmierung: Endlosschleifen befürchten?

Hallo Thomas!

Wenn dein Prozessor niemals nicht hängen bleiben darf, solltest du einen Watchdog verwenden, falls nicht sowieso einer vorhanden ist, den du einfach aktivieren kannst (wie bei vielen AVRs).

Gruß Thorsten

Thomas Rachel schrieb:

Nein, dann ist das Ding kaputt oder gestört und das Programm kann ruhig hängen, damit man auch merkt, dass etwas nicht stimmt. Im Gegenteil steigt durch die Prüfung "eventueller" Fehler das Risiko einen echten Fehler einzubauen. Auf die "Zusicherungen" eines uC muss man sich im Endeffekt irgendwann einmal verlassen - mit welchen Maßnahmen würdest Du denn "eventuelle" Fehler bei der Programmbearbeitung abfangen? In diesem Bereich hat sich eigentlich nur der "Watchdog" durchgesetzt und genau der wird nicht mehr getriggert, wenn Du bei hängender Peripherie nichts machst.

Thorsten Ostermann schrieb:

Den habe ich bereits aktiviert, derzeit allerdings mit einer recht langen Laufzeit, was ich noch ändern werde.

Aber zumindest könnte ich ihn ggf. in einen "sicheren" Zustand fahren oder einen "letzten Versuch" machen, doch noch was machen zu können - gerade im Fall von I2C werde ich dies in jedem Fall machen, in den anderen Fällen tendiere ich dazu, den hier gegebenen Ratschlägen zu folgen.

Thomas

Edzard Egberts schrieb:

Soweit klar.

Ok. Allerdings könnte es in einem der betrachteten Fälle evtl. angeraten sein, eine Aktion durchzuführen, um ihn in einen "sicheren" Zustand zu fahren.

Ein anderer Fall wäre I2C, aber das werde ich in einem anderen Thread nochmal thematisieren.

echten

Das stimmt leider. Ich müßte dann wirklich konsequent die Rückgabewerte meiner Funktionen auswerten und entsprechend handeln.

Da hatte ich mir vorgestellt:

• Peripherie resetten, nochmal versuchen

• wenn wieder Fehler: in sicheren Zustand fahren, Reset (evtl. sogar per GPIO einen Hauptschalter-MOSFET abschalten)

Hier müßte ich dann wirklich auf einen erkannten, jedoch nicht behebbaren Fehler mit einem manuellen Reset reagieren.

Vielen Dank euch beiden für die Anregungen

Thomas

=2E...

=2E..

Du programmierst den PIC in C? Na gut, ich mache im Augenblick nichts mit PICs (erst mu=DF mal fertig verputzt sein...), aber zumindest auf Assembler-Ebene gibt es da auch noch sehr sch=F6n die Alternative, den Peripherie-Interrupt zu verwenden. D.H. Du hast eine Hauptschleife, die irgendwo in einem sleep() m=FCndet (bei Bedarf auch mehrere). Die Peripherals laufen i.A. auch im sleep, der Interrupt vom Peripheral weckt dann den PIC aus dem sleep, der PIC kann nachschauen, was los ist, nach Programm agieren und sich bis zum n=E4chsten Interrupt wieder schlafen legen. Hilft nat=FCrlich auch nicht, wenn der Interrupt nie kommt - aber wie schon gesagt, kaputt ist dann eben kaputt. Aber verhindert zumindest, da=DF ein verpenntes Peripheral alle anderen lahmlegt. Und geht auch nur mit 'echten' Periherals - wenn der UART oder I2C 'nur' eine Library ist, die mit den GPIOs wackelt, dann wird's etwas kopmplizierter ('Interrupt on Change' auf den Pins w=E4re noch eine L=F6sung, bl=E4st dann aber die ISR doch ziemlich auf).

Gru=DF Markus

Thomas Rachel schrieb:

Indem Du den Chip wegwirfst ;-)

...

Ich habe praktisch immer eine Timer-Interrupt-Routine, die mir eine Variable hochzählt, bspw. ...."timer1ms++".. oder "timer1s++"

Abfragen, die nicht "hängenbleiben" dürfen, schreibe ich so: // Warte maximal 100ms auf EREIGNIS timer1ms=0; while((timer1ms < 100) && (~EREIGNIS)); if (timer1ms>=100) fehler(PANIC_DEVICE_BROKEN);...

Gruß, Falk

Das sollte man ganz zuletzt machen.

Erstmal so fertigmachen, dass alles funktioniert und erst danach, wenn man der Meinung ist, dass man ihn eigentlich gar nicht benötigt, den Watchdog als zusätzliche Sicherheit einbauen.

Gruß

Stefan DF9BI

So in der Art macht man das, besonders fuer I2C. Es muss ja nichts kaputtgegangen sein, koennte durchaus ein einmaliger "Event" sein. Z.B. eine Stromspitze, weil es in die alte Eiche bei Bauer Schliephake eingeschlagen hat.

Der Watchdog sollte aehnlich wie die Oeldrucklampe beim Auto erst kommen, wenn wirklich etwas grobes passiert ist.

Joerg schrieb:

Ich betrachte (in meinen Geräten) einen auslösenden Watchdog als Fehlermeldung. Entweder Hard- oder Software haben dann einen Bug.

Wenn man beim Reset noch den Grund abfragt und im EEPROM ablegt und ein wenig auf die Stromversorgung schaut (sofern Kapazität vorhanden), hilft das bei der Fehlersuche.

Falk

Das kann man bei sicherheitskritischen Anwendungen so nicht machen, man kann nicht immer gleich die Notbremse greifen lassen. Viele Systeme muessen in einem "Limp Mode" weitermachen. Oft sogar nach GAU-artigen Ereignissen (Thema Crash-Worthiness etc.). Zum Beispiel ist es sehr sinnvoll, dass nach einem Absturz noerdlich des Klondike einige Elektronik weiter funktioniert, auch wenn diverse angeschlossene Datenlieferanten abgerissen, zermalmt oder abgekokelt sind. Selbst in Autos laufen System wie OnStar weiter, auch wenn das Auto Totalschaden hat und GPS nicht mehr funktioniert. Besser ein Notsignal ohne Ortungsdaten als gar kein Notsignal.

Falk hat ein Beispiel aufgezeigt. Hier koennte man anknuepfen. Wenn etwa ein SW Timer dauernd an den Poller laeuft, kann man zuerst einmal nachsehen lassen, warum. Sind es immer wieder I2C Time-Outs, kann der uC weiterlaufen, diverse Sicherheitsvorkehrungen treffen und eine entsprechende Fehlermeldung setzen. So aehnlich wie der Notlauf bei einigen Fahrzeugen, falls der Bordcomputer muckt.

Das kannst du auch mit dem Watchdog erledigen. Viele Watchdogs haben ein Flag das der CPU sagt warum resettet wurde. So kannst du in eine seperate Resetroutine springen die es noch einmal versucht oder wenns nochmal hängt einen sicheren zustand herstellt, dabei auch eine passende Fehlermeldung erzeugt. In einer Hilfsvariable kannst du dir merken an welcher Programmstelle der Fehler auftrat.

In der Frage steht *chipinterne* Peripherie und gerade bei sicherheitskritischen Anwendungen sollte IMHO ein uC mit *internen* Fehlfunktionen unbedingt gestoppt werden.

Bezüglich des neuen Themas "angeschlossene Datenlieferanten" stimme ich Dir aber zu. ;o)

Wuerde ich in vielen Anwendungen dennoch nicht stoppen, erst einmal nur melden. Ich hatte letzte Woche genau so einen Fall von einem Kunden hier. Die Peripherie eines uC hing ab und zu, aber der Grund lag oft an aeusseren Einfluessen. Blitzeinschlaege in der Naehe etc. Hin und wieder zerschoss es auch einen Eingang. Trotzdem muss der uC danach noch sein bestes geben, um einen Steuervorgang moeglichst schmerzarm abzuarbeiten. Ein simpler Run in den WDT mit Voll-Reset haette hier recht unangenehme Folgen. Das ist aehnlich wie beim ABS, was z.B. auch nach Zerstoerung aller Hinterachssensorik durch Auffahrunfall zumindest bis zum Stillstand weiterarbeiten sollte. Das gleiche gilt fuer das Engine Control Module, damit man z.B. nach Unfall noch von einem Bahnuebergang weg kommt (hatte hier letztens jemand nicht mehr geschafft).

Gruselig - wenn es schon Eingänge zerschießt, würde ich als notorischer Pessimist von einem ESD-beschädigten uC nicht unbedingt erwarten, dass der noch einen Steuervorgang schmerzarm abarbeitet. Naja, wenn es erfahrungsgemäß klappt - ein klar definiertes und bekanntes Probleme kann man natürlich gut mit Software abfangen.

Weia, amerikanische Autos explodieren bei Unfällen nicht nur sofort, das ABS arbeitet auch bei Sensorausfall weiter? Da kaufe ich mir lieber ein japanisches Auto, wo das ABS bei Sensorproblemen einfach komplett ausfällt und die Reifen wieder blockieren, wenn man mit vollem Muskeleinsatz auf der Bremse steht... ;o))

Theoretisch sollte das doch mit dem Anlasser gehen? Wie auch immer, in diesem Fall konnte das ECM wohl tatsächlich keine weiteren Motorschäden verhindern... ;o)

So, Scherz beiseite, Projekt ist compiliert...

Thomas Rachel schrieb:

Hallo Thomas,

da gibt es keine eindeutige Antwort. Es kommt darauf an was dein MC steuert. Grundsätzlich gilt: Definiere einen sicheren Zustand für dein System und versuche den im Fehlerfalle einzunehmen.

Gib allen Wartefunktionen ein individuelles Prozessabhängiges Timeout mit und definiere eine Regel was passiert wenn Timeout abgelaufen. Der Fehlerfall muss genauso durchdacht werden wie der normale Programmablauf.

Ein Watchdog mit evtl. anschliessendem Neustart löst das Problem nicht, weil der Zustand des Sytems in dem der Fehler aufgetreten ist, nicht mehr existiert.

Dazu auch ein Beispiel aus der realen Welt. Der Smart meiner Tochter hat aus irgendeinem Grunde auf der Autobahn-Überholspur den Motor ausgeschaltet und einen Neustart des Motors nur nach erfolgtem Stillstand des Autos wieder zugelassen. Watchdog + Neustart ?? Gottseidank nix passiert.

Im Fehlerfall kannst du auch nicht immer einfach den MC anhalten. In chemischen Prozessen z.B. ist das Einhalten von Reaktionstemperatur und Zeiten enorm wichtig und wenn da was schief läuft kommt es auch darauf an was zu tun ist. Temperatur halten, Temperatur senken, Rührer abschalten oder besser nicht ?.

Gruß

Hans-Georg

Super, der Brems-Assi kriegt keinen Slot auf dem Datenbus weil ein anderer Teilnehmer einen Fehler hat und, caht einen Reset durch seinen Watchdog und ich rausche ungebremt in den Baum. Danke.

Fehler der Peripherie sollten imo sehr wohl von der Software abgefangen werden. Zumindest wenns um ernstzunehmende Apps geht.

Heinz

Ich wuesste nicht, wie das passieren sollte. Ausser du kannst irgendwie eine Baudrate von Null einstellen. Bei ungleich Null, egal wie klein, wird der Sendepuffer irgendwann frei sein.

Gerrit

Gerrit Heitsch schrieb:

Beispielsweise. Das kann auch durch einen Programmfehler passieren.

Sie es doch mal so: Wenn _alles_ funktioniert, geschieht das. Geschieht es nicht, ist irgendetwas faul. Als Fehlerbehandlung könnte man den UART neu initialisieren. Hilft das, wird ein temporärer Fehler registriert.

Hilft das nicht, werden die Fail-safe Werte gesetzt und andere entsprechende Schritte eingeleitet.

Einfach den Watchdog beißen lassen und unspezifiziert melden, "da war was, ich habe mir aber nichts vorzuwerfen" kann zuwenig sein.

Falk

So aehnlich wie bei Flugzeugen. Wenn die komplette Elektrik ausgefallen ist und der kleine Windgenerator ausklappt, weiss man, dass die K...e am dampfen ist. Aber man kann es noch steuern.

Explodieren tun sie hier normalerweise nicht mehr, da hat man gelernt. Auf jeden Fall muss alles so gut wie moeglich kontrollierbar bleiben. Abruptes Abschalten ist nicht unbedingt der Hit.

Bei Automatik geht das nicht. Auch bei vielen Schaltwagen wie meinem nicht. Das ist ein Japaner, doch der Anlasser dreht nur bei getretener Kupplung. Dieses "Feature" wollte ich schon immer abstellen, hab's aber noch nicht getan.

Na denn, auf in den Test ;-)