Beste Methode zur Diagnose von Problemen mit eingebetteten Computern im Feld?

Ich werde bald ein neues eingebettetes System bereitstellen. Ich habe eine separate serielle Schnittstelle, die eine Verbindung zu einem Diagnoseprogramm herstellen kann. Ich habe auch zwei LEDs, eine blinkt, um anzuzeigen, dass das Betriebssystem läuft, die andere, dass die Anwendung läuft. Ich befürchte, dass es schwierig wird, herauszufinden, was passiert ist, wenn das eingebettete System jedoch einen Totalabsturz erleidet. Es hat einen Watchdog, würde also neu starten, aber ich würde gerne herausfinden können, warum der Absturz auftritt, falls dies der Fall ist.

Die einzige Möglichkeit, die ich in der Vergangenheit getan habe, besteht darin, ein paralleles System im Labor zu haben, ihm die gleiche Art von Eingaben zu geben, zu versuchen, das Problem auszulösen, und dann durch Debug-Drucke oder Ausgaben an digitale I/Os zu analysieren, um es herauszufinden heraus, woran es liegen könnte. Oft ist es jedoch sehr schwierig, das Problem zu reproduzieren.

Hat jemand irgendwelche Ratschläge zu guten Methoden, die sie zum Debuggen bei Feldproblemen haben?

Danke Fred

Sie erwähnen ein "OS", was verwenden Sie? Wenn es ein persistentes Dateisystem hat, dann fällt mir zuerst eine Protokolldatei ein. Wenn nicht ... dann bearbeiten Sie Ihre Frage vielleicht mit einigen weiteren Spezifikationen Ihres Systems und ich schreibe eine Antwort. Sind Sie auch daran interessiert, in der Lage zu sein, aus der Ferne zu debuggen und zu diagnostizieren? Oder möchten Sie das Gerät bergen und dann eine Post-Mortem-Analyse durchführen?
Ich würde die Option „Im dauerhaften Speicher protokollieren“ empfehlen. Es nützt wahrscheinlich nichts für einen totalen Absturz, aber wenn Ihr Code eine Anomalie erkennt (Deadlock, Behauptungsfehler usw.), kann er zuerst protokollieren. Wenn Sie die Zeit und den Arbeitsspeicher erübrigen können, können Sie während des Betriebs ein Umlaufprotokoll schreiben. Wenn das Protokoll beim Start vorhanden ist, schreiben Sie es in den permanenten Speicher. Der „Ort, an dem es aufgehört hat“ könnte einen Hinweis geben. Im Allgemeinen ist beim Debuggen eines Remote-Embedded-Systems JEDER Hinweis, den Sie bekommen können, Gold wert. Aber ich schätze, du hast das schon erlebt.
Auf dem System läuft ein Bare-Bones-Betriebssystem zur Maschinensteuerung. Es gibt kein Dateisystem, aber wir haben etwas freien RAM und Flash-Speicher, auf den blockweise zugegriffen werden kann. Ideal wäre eine Ferndiagnose. Diese eingebetteten Systeme sind mit einem PC verbunden und wir haben logmein, mit dem wir von überall auf die PCs zugreifen können.
Kommentar von RE Wouter; Wenn Sie im RAM protokollieren, würden Sie dieses Protokoll im Falle eines Absturzes nicht verlieren? Und dann ist es normalerweise unpraktisch, sich bei Flash anzumelden, da Sie sich mit Flash-Verschleiß, Wear-Leveling usw. auseinandersetzen müssen.
Wenn sie an vernetzte PCs angeschlossen sind, würde ich eine Protokollierungsanwendung für diese PCs schreiben, die Debug-Meldungen von der seriellen Schnittstelle des eingebetteten Geräts erfassen und in einer Datei protokollieren. Wenn etwas schief geht, können Sie sich aus der Ferne am PC anmelden und die Protokolldatei überprüfen. Wenn Sie viele Geräte an einem PC haben, sollten Sie USB-zu-Seriell-Port-Kabel und einen USB-Hub verwenden, um mehrere serielle Ports zu haben.
Das System verfügt bereits über eine serielle Schnittstelle, die vom PC zur Karte führt, die zum Senden von Befehlen verwendet wird. Diese Befehle und Antworten sind bereits auf dem PC protokolliert. Klingt so, als könnte ich einfach einen neuen Nachrichtentyp "Protokollnachricht vom Gerät" hinzufügen, der asynchron an den PC gesendet werden kann, wenn Fehler erkannt werden?
Klingt für mich nach einer ziemlich guten Lösung. Vielleicht schreiben Sie später eine Antwortzusammenfassung für alle Methoden, die Sie am Ende ausprobieren.

Antworten (1)

Kürzlich habe ich ein paar Einheiten eines neuen Embedded-Produkts für einen freundlichen Test bereitgestellt. Ich versuchte herauszufinden, wie gut der IP-Stack in der realen Welt funktionierte, daher war die Verwendung des integrierten Ethernets für die Fehlersuche keine Option.

Ich habe mehrere serielle Datenlogger von Sparkfun gekauft (viele ähnliche Geräte sind verfügbar) und einen über TTL-Seriell an jedes Gerät angeschlossen. Als ich die Einheiten zurückbekam, habe ich die Protokolle von den SD-Karten abgerufen.

Im Falle eines Systemabsturzes können Sie durch das Ausgeben von Registern an die serielle Schnittstelle den fehlerhaften Code später über die Zuordnungsdatei finden.

Beste Methode zur Diagnose von Problemen mit eingebetteten Computern im Feld?
AntwortenHierDatenschutz-Bestimmungen1y, 0v