Raspberry durch einen µC überwachen?

Udo Neist schrieb:
> Ich würde einfach einen GPIO togglen lassen und das mit dem ATtiny
> detektieren. Fehlen n Signale über ein bestimmten Zeitraum, einfach
> einen Reset auslösen.

Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen 
GPIO triggert.
Bei Power_On schaltet der Tiny den Raspberry an (vllt. mit nem kleinen 
Delay), wartet dann eine gewisse Zeitspanne (3-4min, kann wegen fsck 
auch mal länger dauern) auf ein Signal am GPIO. Sobald da einmal 
getriggert wurde (bzw. der initiale Timeout erreicht wurde) wird im Tiny 
auf Watchdog-Betrieb umgeschaltet, der regelmäßige Impuls resettet den 
Watchdogtimer. Bleibt der aus geht der Tiny in Reset und damit auch der 
RPi. Und dann fängt der Zyklus von vorne an...

Typische Aufgabe für einen Window-Watchdog.
Es darf nicht zu häufig getriggert werden und auch nicht zu selten.

Ich würde noch einen weiteren GPIO einplanen, damit man den Watchdog 
erst aktivieren kann, wenn der RPi komplett gestartet ist.
Sonst löst du ein Reset aus während der RPi gerade normal bootet.

Gruß
Daniel

Nebenbei, externe Watchdogs werden bei einer Sicherheitsbewertung immer 
gerne gesehen :-)

Horstmann schrieb:
> Wie kann der µC sicher erkennen, ob der Raspberry einwandfrei arbeitet?

Und wer überwacht den Tiny?

Den Watchdog kannst du auch mit einem retriggerbaren Monoflop umsetzen.

Programmierer schrieb:
> So prüfst du aber nur ob das Python-Skript und der GPIO funktioniert.

Reicht doch. Das Skript muss halt auf dem RPi schauen ob die gewünschte 
Funktionalität (zB. das ein Server/Service läuft) gegeben ist. Wie genau 
das überlass ich mal dem TO.

Horstmann schrieb:
> Ein Raspberry Zero soll über seine serielle Schnittstelle mit einem µC
> (ATtiny o. ä.) verbunden werden. Der µC soll den Raspberry überwachen
> und im Fehlerfall neu starten.

Dann laß doch den ATtiny zyklisch etwas schicken und der RP muß eine 
Antwort dazu basteln. Stimmt die Antwort nicht -> Reset.
9600 Baud sollte reichen, das schafft ein ATtiny25 mit Bitwackeln (Quarz 
= 7.3728MHz).

Programmierer schrieb:
> Es kann aber halt auch alles mögliche andere kaputt sein.
Es kann auch ein Flugzeug drauf gefallen sein...

Programmierer schrieb:
> Stell dir vor durch kosmische Strahlung verheddert sich etwas im NEON-Block
> des Prozessors
In sehr viel mehr als 99,999% aller ko(s)mischen Fehlerfälle hat sich da 
erfahrungsgemäß einfach deshalb was verheddert, weil der Programmierer 
einen Fehler in der Software hat.

> alle ko(s)mischen Fehlerfälle

Für wirklich sicherheitskritische Aufgaben nimmt man deshalb kein 
Raspberry, sondern zwei möglichst einfach gestrickte RISC Controller wie 
2 ATtinys oder 2 PICs. Das Projekt (der Regler) wird compiliert und alle 
verwendeten Assemblerbefehle aufgelistet. Der ATtiny stellt sich dann 
selber eine Aufgabe, welche genau jeden dieser Befehle mindestens ein 
mal verwendet. Nun kann das Rechenergebnis mit dem erwarteten Ergebnis 
verglichen werden. Tritt eine Abweichung ein, stellt dieser Controller 
die Kommunikation ein und geht in Störung. Duch das fehlende 
Lebenszeichen geht der andere Controller auch in Störung.

Falls es hilft -> jemand hats schon gebaut und verkauft es.
https://de.aliexpress.com/wholesale?catId=0&initiative_id=SB_20210824005848&SearchText=Raspberry+Watchdog

Alexander S. schrieb:
> Udo Neist schrieb:
>> Ich würde einfach einen GPIO togglen lassen und das mit dem ATtiny
>> detektieren. Fehlen n Signale über ein bestimmten Zeitraum, einfach
>> einen Reset auslösen.
>
> Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen
> GPIO triggert.

Das erfüllt aber nicht die Anforderung des TO:

Horstmann schrieb:
> sicher erkennen, ob der Raspberry einwandfrei arbeitet

Es erkennt nur ob das Python Skript noch funktioniert. Und unter 
Umständen noch nicht mal das (wenn jemand anderes am Pin wackelt).

Und damit ist klar, was am Anfang stehen muß: eine möglichst exakte 
Definition, was "einwandfrei arbeitet" überhaupt bedeuten soll.

Axel S. schrieb:
> Horstmann schrieb:
>> sicher erkennen, ob der Raspberry einwandfrei arbeitet
> Es erkennt nur ob das Python Skript noch funktioniert. Und unter
> Umständen noch nicht mal das (wenn jemand anderes am Pin wackelt).
Einer unserer Softies hatte mal die gloriose Idee, für das Rücksetzen 
des externen Watchdogs einen eigenen Timerinterrupt zu verwenden. Und 
dem hat er dann noch die höchste Priorität gegeben. Der Grund: "Sonst 
gibt es immer wieder diese Timeout-Fehler und das Ding läuft in einen 
Reset!"  ;-)

Lothar M. schrieb:
> Einer unserer Softies hatte mal die gloriose Idee, für das Rücksetzen
> des externen Watchdogs einen eigenen Timerinterrupt zu verwenden.

Das ist durchaus keine schlechte Idee. Dieser Interrupt enthält dann 
mehrere Timeouts, die von den jeweiligen Tasks zurück gesetzt werden. 
Ist einer davon abgelaufen, geht der Handler in eine Endlosschleife.

Es gibt auch bessere externe Watchdogs, die ein Zeitfenster überwachen. 
D.h. der Resetimpuls darf weder zu langsam noch zu schnell erfolgen.

Stefan ⛄ F. schrieb:
> Man kann sich fast immer noch einloggen und
> analysieren, warum eine bestimmte Funktion oder ein bestimmtes Programm
> gerade versagt.

Kann der Attiny so natürlich nicht. Aber er kann zyklisch etwas vom RPI 
verlangen... kann beliebig komplex werden. Vorschläge gab es ja schon. 
Einfach ausgedrückt realisiert man eine "Tot-Mann/RPI-Sicherung". Und 
auch die Schlaumeier des ewigen Regress' könnten sich sinnvolle Gedanken 
zu diesem Szenario machen! Allerdings ist es müßig, das in einer 
allumfassenden Allgemeinheit aufzudröseln. Also wann muß Alarm kommen 
und von wem!?
Gruß Rainer

Stefan ⛄ F. schrieb:
> Doch kann er, über einen seriellen Port.

Ja und dann startest du vom Tiny ein Diagnoseprogramm??? Ich verstehe es 
wohl nicht. Ich dachte, du meinst die diversen Logfiles, die Python 
anlegt und die man sich "natürlich" am PC anschaut oder? Vielleicht 
liege ich aber auch komplett falsch.
Gruß Rainer

Stefan ⛄ F. schrieb:
> Man kann sich fast immer noch einloggen und

Kannst du das als mein Problem akzeptieren? Mich treibt die Frage um, ob 
der Attiny das kann! If you see what I mean...
Gru0 Rainer

Stefan ⛄ F. schrieb:
> Ich habe deine Frage bereits beantwortet.

Ja, aber ich kapiers nicht. Ich verstehe ja, dass der Tiny sich da über 
die ser. Schnittstelle einloggen kann, aber wie soll er denn die 
System/Errormeldungen von Python auswerten? Da braucht es doch entweder 
einen Menschen oder einen (mindestens) PC. Verstehst du mein Proble?? 
Aber wir sollten hier doch nicht in eine Privatdebatte ausarten. Die 
Vorstellung (meine), dass ein Programm auf einem Tiny das Python-System 
auf dem RPI analysiert und auch noch entsprechend komplex reaiert, halte 
ich für schlicht unmöglich...
Gru0 Rainer

Ok, danke stefanus. Habs kapiert...und bin verblüfft...auch über mich 
natürlich. Und da ich kein "Hochsprachler" bin, würde ich meine Strings 
sowieso selbst machen :-)
Gruß Rainer

Im Grunde ist es doch die gleiche Frage (zumindest für mich naivem) 
warum hat mein PC Mist gemacht! Und das durch einen Controller machen zu 
lassen kommt mir schon blöd vor. Will ich tatsächlich nach einem Chrash 
noch genau wissen, was das XY-Logfile dazu zu sagen hat??? Ich will 
wissen, ob es einen Angriff gegeben hat---klar und ich will vielleicht 
wissen, ob die SC-Karte sich nicht mehr meldet...aber man sieht schon, 
dass da Einbildungskraft gefordert ist! Anders herum...der RPI muß eine 
LED blinken lassen und der Controller soll überwachen/kontrollieren, ob 
das läuft. Wenn's nicht mehr läuft, hängt alles von dem Folgeszenario 
ab. Im schlimmsten Fall, hätte der Controller nix mehr zu kontrollieren 
(Ich empfehle Degenhard, "In den guten alten Zeiten")
Gruß Rainer

Rainer V. schrieb:
> Im Grunde ist es doch die gleiche Frage (zumindest für mich naivem)
> warum hat mein PC Mist gemacht! Und das durch einen Controller machen zu
> lassen kommt mir schon blöd vor. Will ich tatsächlich nach einem Chrash
> noch genau wissen, was das XY-Logfile dazu zu sagen hat?

Das ist gar nicht die Aufgabe des Watchdogs. Vollkommen egal, wie der 
realisiert ist. Der soll nur dafür sorgen, daß dein PC nicht hängen 
bleibt. Ob das das Resultat einer grottigen Software, ein Hardwarefehler 
oder ein Angriff war, ist dafür nebensächlich.

Der Attiny wartet alle x Sekunden auf ein "ping" auf der GPIO-Leitung. 
Am Ende wird als einziges Skript aus dem Raspberry noch das Programm 
laufen was regelmäßig den GPIO hochzieht.
Sollte der Attiny dann doch was mitbekommen und den Raspberry resetten 
wird dabei die SD-Karte zerschossen.
Totmann-Schaltungen zur Überwachung sind komplizierter als man denkt.

Die ARM-CPUs haben den Nachteil, daß man sie mit hoher Interruptlast 
anhalten kann, d.h. die Mainloop bleibt stehen, bis kein Interrupt mehr 
pending ist. Z.B. eine floatende Interruptleitung fängt sich eine 
hochfrequente Störung ein.
Im Gegensatz dazu führt z.B. ein 8051 oder AVR nach jedem RETI erst 
einen Befehl der Mainloop aus, bevor in den nächsten Handler gesprungen 
wird. Die Mainloop wird zwar langsam, kann aber noch auf Kommandos 
reagieren und z.B. eine Task mit hoher Interruptrate abschießen.