Fehlersuche, Tipps und Tricks austauschen



  • @yahendrik mir ging es auch nicht um Löttipps, sondern um den Austausch zum finden von Fehlern.
    Wie komme ich der Ursache eines (Programmier)Fehlers auf den Grund?
    Die Ausgabe das eine IF-Bedingung ausgeführt wurde hat mir geholfen den Fehler einzugrenzen und damit zu finden, es lag also nicht, wie von mir gedacht, am Code.


  • Mod

    Eingrenzen eines Fehlers ist oft gleich Lösen eines Fehlers. Nach und nach alles unnötige wegwerfen, bis man ein minimales, reproduzierbares Beispiel hat. Dieses ist dann oft so einfach, dass der Fehler direkt durchschaut werden kann. Oder man stellt bei der Erstellung fest, dass die Ursache ganz woanders liegt, als man dachte, wenn der Fehler plötzlich verschwindet, nachdem man vermeintlich unnötige Codeteile gekürzt hat. Und wenn es dann noch nicht klappt, zieht man die üblichen Hilfswerkzeuge, wie einen Debugger hinzu (oder zur Not Log-Ausgaben). Damit erwischt man relativ schnell und systematisch die überwältigende Zahl aller Fehler.

    Die 0.1% der Fehler bei denen das nicht hilft, das sind dann die interessanten. Da hilft mir dann die Quietscheentchenmethode (vorzugsweise aber mit einem echten, intelligenten(!) Menschen statt einem Quietscheentchen): Man erklärt Schritt für Schritt, was man über den Fehler zu wissen meint, und hinterfragt dabei genauestens, ob eventuelle Annahmen wirklich stimmen, wieso man weiß was man zu wissen meint, und so weiter. Damit stößt man dann oft auf falsche Annahmen oder Fakten, die weniger gesichert sind als man dachte.



  • @Quiche-Lorraine da es sich um mein eigenes Projekt handelt gibt es weder eine Doku noch eine Errata, sondern trial and error.
    Mir geht es dabei um die Erfahrungen die andere gemacht haben um Fehler zu finden.
    Natürlich habe ich nach dem Löten auch die Verbindungen durchgemessen auf Durchgang, in diesem Fall gab es keinen Durchgangsfehler, nur einen im Vergleich zu einem gleichen Bauteil deutlich niedrigeren Widerstand, der den Fehler ausgelöst hat.
    Erst durch die Ausgabe der IF-Anweisung konnte ich mir den bestimmten Teil auf der Platine angucken und habe dann erst bei einer vergleichenden Widerstandsmessung das Problem identifiziert.



  • @SeppJ So weit Teile des Codes auszukommentieren war ich bei einem vorherigen Problem auch schon, was mich auch zur Lösung geführt hat.

    Deine "Erklärmethode" hat einen ganz spannenden Hintergrund. Wissenschaftler haben herausgefunden, das a) das Erklären eines Problems, einem selbst tiefere Einblicke in selbiges geben und auch b) "Unterhaltungen/Monologe" mit einem nicht vorhandenen anderem Gegenüber/Wissenschafter einen Mehrgewinn an Erkenntnis bringt.

    Wobei ich, um ehrlich zu sein, die 0.1% mag, da erst, setzt man sich damit richtig auseinander, kostet zwar Zeit und Nerven, dafür ist auch der Gewinn entsprechend hoch.



  • @filzlaus sagte in Fehlersuche, Tipps und Tricks austauschen:

    da es sich um mein eigenes Projekt handelt gibt es weder eine Doku noch eine Errata, sondern trial and error.

    Nein, das meinte ich nicht. Ich meinte die Doku zu der CPU, weiteren genutzten Chips, usw.

    Da du ein Arduino Nano_V3 mit 32 KB Flash und 2kByte SRAM hast, musst du relativ low Level programmieren. Und je mehr man low level programmiert, desto eher treffen einem hardware-spezifsiche Probleme.

    Sei es der Funkchip welcher den Deep Sleep Modus ab und zu simuliert, der Watchdog welcher alle 200ms gefüttert werden will usw.

    Von daher ist deine Dok die zu ATmega328P.


  • Mod

    @filzlaus sagte in Fehlersuche, Tipps und Tricks austauschen:

    Deine "Erklärmethode" hat einen ganz spannenden Hintergrund. Wissenschaftler haben herausgefunden, das a) das Erklären eines Problems, einem selbst tiefere Einblicke in selbiges geben und auch b) "Unterhaltungen/Monologe" mit einem nicht vorhandenen anderem Gegenüber/Wissenschafter einen Mehrgewinn an Erkenntnis bringt.

    Damit das klar ist, da man bei dem Begriff "Qietscheentchenmethode" vielleicht an einen Scherz von mir denkt: Das ist ein feststehender Begriff für eine bekannte, gängige, Debuggingtechnik:
    https://en.wikipedia.org/wiki/Rubber_duck_debugging
    (Man beachte auch die weiterführenden Links)



  • Ich kann nur eine Anekdote von meinem letzten Job anbieten. Da haben wir Spielgeräte gebaut die u.A. einen Münzprüfer hatten, also das Teil wo die eingeworfenen Münzen durchlaufen und das dann prüft ob sie echt sind und um welchen Münzwert es sich handelt.

    Die Softwarekomponente zum Ansteuern des Münzprüfers sowie zum Ansteuern von einigen Leuchten/Lampen in dem Gerät kam von uns, die Spielsoftware die auf dem Gerät lief kam vom Kunden.

    Ein grosser Kunde hatte eine grosse Anzahl dieser Geräte bestellt. Bei den ersten Tests mit der Software des Kunden hat er dann festgestellt dass der Münzprüfer meist nicht funktioniert. Die Münzen sind einfach durchgefallen = wurden nicht erkannt. Da die Softwarekomponente zum Ansteuern des Münzprüfers/der Lampen von uns kam hatten wir auch ein Testprogramm für diese Komponenten mit dem man die Komponenten ein-/ausschalten/konfigurieren konnte und das die erkannten Münzen anzeigt.

    Der Kunde hat den Münzprüfers auch mit unserem Testprogramm getestet und damit hat alles wunderbar funktioniert.

    Wir waren ziemlich ratlos. Die Schnittstelle zum Ansteuern unserer Softwarekomponente war so einfach, damit konnte man quasi nichts falsch machen. Und da mit unserem Testprogramm alles funktioniert hat, wussten wir nicht wo wir ansetzen sollen das Problem zu suchen.

    Es war auch keine einzige neue Komponente im Spiel. Das Gehäuse des Spielgeräts war nicht neu. Der Münzprüfer war nicht neu. Der Controller für den Münzprüfer und die Lampen war nicht neu. Und die Softwarekomponente zum Ansteuern des Controllers war nicht neu. Alles Komponenten die wir davor schon ohne Probleme verwendet hatten.

    Die Lösung: Unser Testprogramm hatte eine Eigenheit die ein Problem des Geräts maskiert hat. Die Softwarekomponente zum Ansteuern der Hardware steuert normalerweise die Beleuchtung des Münzeinwurfs an - die Lampe soll an sein wenn der Münzprüfer aktiv ist. Darum kümmert sich die Softwarekomponente selbst - sie steuert diese Lampe also automatisch. Das Testprogramm erlaubt aber auch das manuelle ein- und ausschalten aller Lampen. Beim Start des Testprogramms wird der Münzprüfer eingeschaltet (was auch diese Lampe einschaltet) und danach alle Lampen ausgeschaltet. D.h. die Beleuchtung des Münzeinwurfs ist dann aus obwohl der Münzprüfer aktiv ist.
    Diese Eigenheit war uns schon lange bekannt, weswegen wir das komplett ignoriert haben.

    Beim Testen ist uns dann aber aufgefallen dass der Münzprüfer auch mit unserem Testprogramm nicht mehr funktioniert, sobald wir ihn über das Testprogramm deaktiviert und wieder aktiviert haben.

    Irgendwann ist mir dann glücklicherweise doch noch aufgefallen dass nach dem Deaktivieren und Reaktivieren des Münzprüfers die Lampe an ist. Also quasi...
    Nach Start des Testprogramms:

    • Münzprüfer aktiv
    • Lampe aus (weil Eigenheit unseres Testprogramms)
    • Münzprüfer funktioniert

    Nach Start des Testprogramms + Deaktivieren + Reaktivieren des Münzprüfers:

    • Münzprüfer aktiv
    • Lampe an
    • Münzprüfer funktioniert nicht

    Nachdem mir das aufgefallen ist hab ich dann die Lampe einfach aus der Fassung gezogen. Und siehe da: sobald die Lampe aus/weg war hat der Münzprüfer immer funktioniert, auch nachdem man ihn mehrfach deaktiviert + reaktiviert hat.
    Das Problem war ein optischer Sensor im Münzprüfer, der durch eine Öffnung im Gehäuse Licht von der Lampe bekommen hat. Und dadurch nicht mehr funktioniert hat.
    In anderen Geräten hatten wir mit dem selben Münzprüfer Typ kein Problem, da bei denen die Lampe etwas anders positioniert war und daher nicht direkt auch den Münzprüfer geleuchtet hat. Und mit anderen Münzprüfer Typen hatten wir in diesem Gerät kein Problem da diese kein Problem mit der "Beleuchtung" hatten.

    Im Endeffekt haben wir dann eine Blende an der Stelle eingebaut und das Problem war behoben.

    Was lernen wir daraus?

    • Unterschiede zu ignorieren nur weil sie durch bekanntes Verhalten einer Komponente erzeugt werden ist nicht schlau.
    • Wenn eine Korrelation zwischen zwei Dingen existiert sollte man dem nachgehen, auch wenn man nicht weiss wie das eine mit dem anderen zusammenhängen sollte.
    • Nur weil man etwas aus Komponenten zusammenbaut die man alle schon kennt und die bisher immer gut funktioniert haben, heisst das nicht dass das Ergebnis funktionieren wird.

    Punkte 1 und 2 sind natürlich nicht Dinge denen man zu Anfang der Fehlersuche nachgehen sollte - es macht schon Sinn sich erstmal auf die wahrscheinlichen Fehlerquellen zu konzentrieren. Aber wenn man schon länger sucht und nichts findet, dann ist es Zeit sich diese Dinge anzusehen.



  • So einen Lerneffekt hatte ich auch mal, nachdem ich ein paar Gesetze von Murphy gelesen habe, eines lautete: der Fehler, der über jeden Zweifel erhaben ist, ist meist ursächlich für das Problem.



  • @filzlaus
    Bei meiner Geschichte gab es dann noch einen weiteren "Lerneffekt"...
    Der Kunde war zu der Zeit unser wichtigster & grösster Kunde. Wir hatten schon ziemlich viel Zeit mit Fehlersuche verbracht und der Kunde war ziemlich sauer. Man sollte annehmen dass jeder froh war dass ich den Fehler gefunden hatte. Der Kunde war das auch, weil jetzt das Projekt endlich weiter voranschreiten konnte.

    Nicht so unser Inhaber & Firmenleiter. Der hat meinem damaligen Abteilungsleiter (Leiter der Hardware- und Softwareentwicklung) einen Anschiss verpasst dass es peinlich ist/"einfach nicht sein kann" dass einer seiner besten & teuersten Programmierer seine Zeit opfern/verschwenden musste um so einen Fehler zu finden. Ja, klar, wäre wohl besser gewesen wenn ich es mir nicht angesehen und wir den Kunden deswegen verloren hätten.

    Gut, dass der Inhaber/Firmenleiter ein A**** war wussten wir schon lange. Aber dass er komplett den Bezug zur Realität verloren hatte war zumindest mir neu.



  • @hustbaer So einen Anschiss musste ich mir auch schon anhören, vom Chef. Bezugs- und realitätsfern.
    Da geht es nicht um das Ergebnis oder die Leistung, sondern der schlechten Laune des Chefs, mangels Selbstbeherrschung, Luft zu machen, die Gründe werden zur Not auch an den Haaren herbeigezogen, wie lächerlich man sich selbst dabei macht, wird gewissenhaft ignoriert, genauso wie das das ganze keine Einbahnstrasse ist.


Anmelden zum Antworten