Der sporadische Glitch

Aus dem harten Leben eines Firmware-Entwicklers 😉

Es kommt immer wieder vor, dass Gerätehersteller beim Produkttest nicht sorgfältig genug alle Varianten durchspielen und es dem Kunden überlassen, verbleibende Fehler zu finden. Dies ist das Bananenprinzip: Das Produkt reift beim Kunden. Verständlicherweise ist dies für den Kunden ärgerlich, da die Behandlung solcher Fehler zeitraubend sein kann. Genauso nachvollziehbar ist es, dass technische Systeme immer komplexer werden, was die Abdeckung aller möglichen Testfälle für den Hersteller unmöglich macht. Dies gilt besonders für Geräte, in denen intern ein Mikroprozessor eine mehr oder weniger fehlerfreie Software abarbeitet. Glücklicherweise sind diese Geräte oft Update-fähig und ermöglichen es dem Hersteller nachzubessern. Werden dabei grundsätzliche Fehler korrigiert, fragt man sich, was der Hersteller eigentlich vor der Auslieferung getestet hat.

Um solchen Vorwürfen aus dem Weg zu gehen, sprechen Hersteller und deren Entwickler gerne von sporadischen Fehlern, die sehr selten unter ganz bestimmten Bedingungen auftreten und die man vorher nur schwer voraussehen konnte. Lassen sich solche Fehler beliebig oft reproduzieren, kann man wohl kaum von einem sporadischen Fehler sprechen. Der Hersteller hat diesen Testfall schlicht ausgelassen.

Und doch gibt es sie, diese sporadisch auftretenden Fehler in technischen Geräten. Ihre Hauptursache liegt in den Toleranzen begründet, die jeder Hardware zu eigen sind. Eine Möglichkeit, solche Fehler während der Entwicklung zu erkennen, besteht darin, die Geräte unter Extrembedingungen zu testen. Wenn Geräte diese Tests klaglos überstehen, werden sie voraussichtlich unter Normalbedingungen zuverlässig arbeiten. Auch hier gilt natürlich, dass man nicht alles testen kann. Man beschränkt sich z.B. auf Belastungstests der Software oder extreme Umgebungsbedingungen.

Treten trotz aller Sorgfalt beim Kunden sporadisch Fehler auf, tauscht man das Gerät aus. So etwas kommt vor und die meisten Kunden haben Verständnis dafür. Passiert das häufiger, besteht natürlich Handlungsbedarf. Zunächst herrscht aber Ratlosigkeit: Wie untersucht man Fehler, die sich nicht zuverlässig reproduzieren lassen?

Als Entwickler der Querx WLAN Firmware hatte ich gerade das zweifelhafte Vergnügen, einen solchen Fehler untersuchen zu dürfen. Zwei Kunden berichteten davon, dass die Geräte nach einem Neustart Sensorfehler anzeigten. Nach weiteren Neustarts verschwand der Fehler wieder. Zuerst versucht man, erweiterte Testfälle zu konstruieren. Aus Erfahrung weiß ich, dass man meist einen Zustand herstellen kann, in dem sich der Fehler zuverlässiger zeigt. Allerdings hatte ich diesmal keinen Erfolg, weder mit unseren Testgeräten, noch mit den Rückläufern. Da längere Zeit keine weiteren Ausfälle auftraten, wurde das Problem erst einmal zurückgestellt.

Wie erwartet, holt einen die Vergangenheit immer wieder ein. Ein weiterer Kunde meldete sich mit dem gleichen Problem und ebenso sporadisch erschien der Fehler in unserer Qualitätskontrolle und sogar bei einem Gerät, das wir im Langzeittest betreiben. Nun, wie so oft, kam mir schließlich der Zufall zu Hilfe. In der Qualitätskontrolle tauchte ein Gerät auf, bei dem der Fehler zuverlässig bei jedem Neustart vorhanden war. Eine nähere Untersuchung ergab, dass kein Fertigungsfehler vorlag, der eventuell zu dem gleichen Symptom hätte führen können. Wie ein rohes Ei wurde dieser Querx WLAN an einen Testadapter angeschlossen, der interne Zustand gesichert und mit aller gebotenen Vorsicht mit einer Testsoftware beladen. Mit Erleichterung nahm ich zur Kenntnis, dass der Fehler weiterhin vorhanden war. Nicht einmal eine Stunde verging, und die Lösung war gefunden. Querx meldete nach beliebig vielen Neustarts korrekte Sensordaten.

Aber was genau hatte denn diesen sporadischen Fehler verursacht? Es kommt vor, dass ein Fehler unerwartet verschwindet, nachdem man verschiedene Änderungen in der Programmierung ausprobiert. Der Entwickler wird von Glückshormonen überschwemmt und der weniger erfahrene verzichtet auf weitere Untersuchungen, die diesen Zustand trüben könnten. Dagegen hat sein älterer Kollege zu oft die Erfahrung mit der Vergangenheit gemacht, die an einem nagt und letztlich einholt. Schon aufgrund meines fortgeschrittenen Lebensalters gehöre ich eher zur letzteren Gruppe.

Vermutlich erwarten Sie jetzt von mir, dass ich endlich die Fakten auf den Tisch lege und dieser Blogbeitrag zu einem Abschluss kommt. Da ich aber nicht weiß, wer diesen Text liest (außer diversen Suchmaschinen), sollte ich mich allgemeinverständlich ausdrücken. Das wird knifflig, aber ich will es versuchen.

Beim Querx WLAN TH wird die Temperatur von einem kombinierten Temperatur- und Luftfeuchtesensor gemessen und in digitale Signale umgewandelt. Diese gehen dann über das sichtbare Sensorkabel ins Innere des Gehäuses an einen Mikroprozessor des Typs STM32F4, genauer an dessen sogenannte I2C Schnittstelle. Dabei handelt es sich um zwei Leitungen, eine davon enthält nur ein konstantes Taktsignal, das fest zwischen 0 und 3 Volt wechselt. Die andere Leitung, die sogenannte Datenleitung, wechselt den Pegel in diesem Takt oder auch nicht, entsprechend der zu übertragenden Daten. Um den Temperaturwert 0 zu übertragen, bleibt die Datenleitung für 16 Takte auf 0 Volt.

Nun gibt es ein kleines Problem. Konstruktionsbedingt ist eine solche I2C Schnittstelle anfällig für Störungen von außen, z.B. für elektromagnetische Felder, verursacht durch Mobilfunkgeräte oder elektrische Motoren. Diese Felder können kurze Impulse in den Leitungen erzeugen, so dass aus 16 plötzlich 17 Takte werden. Das ist übrigens der Grund dafür, warum Querx TH nur ein relativ kurzes Sensorkabel besitzt. Bei Querx PT darf dieses Kabel mehrere Hundert Meter lang sein. Dennoch ist auch bei kurzen Kabeln mit Störungen zu rechnen und daher befindet sich im Mikroprozessor ein Filter, welcher kurze Störimpulse unterdrückt.

Sie konnten mir bis hier hin folgen? Gut, dann haben wir es fast geschafft. Die logischen Schaltkreise des Mikroprozessors bestehen, wie der Name schon andeutet, aus einer Anhäufung von Schaltern. Ein gefürchtetes Problem beim Design solcher Schaltkreise ist der sogenannte Glitch. Denken Sie an die Lichtschalter in Ihrer Wohnung, im Flur gibt es üblicherweise mehrere Schalter für eine Lampe. Wenn man nun zwei Schalter gleichzeitig betätigt, passiert nichts. Die Lampe bleibt an oder aus. Genau wie es Ihnen nicht gelingen wird, die Schalter wirklich gleichzeitig zu betätigen, kann es auch im Mikroprozessor aufgrund von Toleranzen zu kurzzeitigen Ungenauigkeiten kommen. Wenn im Flur die Lampe trotzdem kurz aufleuchtet oder flackert, nennt man das in der Elektronik einen Glitch. Solch ein Glitch führt im STM32F4-Mikroprozessor, der im Querx verbaut ist, zu einem Fehlerzustand im Filter der I2C-Schnittstelle. Also ausgerechnet in dem Teil, welches zusätzlich zur Fehlervermeidung eingebaut wurde. Der Filter gibt den falschen Pegel der Datenleitung an den Mikroprozessor weiter. Bei der Komplexität dieser Mikroprozessor-Schaltkreise gehört die Vermeidung von Glitches zum grundsätzlichen Handwerk jedes Chip-Designers. Hier hat jemand offensichtlich nicht ganz sauber gearbeitet. Noch schlimmer: Normalerweise hat der Programmierer die Möglichkeit, einen Fehlerzustand der Hardware durch ein Rücksetzsignal in den Grundzustand zu setzen. Eine solche Möglichkeit wurde hier nicht vorgesehen. So gibt es keine sichere Methode, diesen Fehlerzustand zu beenden, außer man trennt Querx von der Versorgung.

Lösen konnte ich das Problem durch eine geänderte Abfolge der Initialisierungsschritte, die diesen Glitch vermeidet. Die korrigierte Firmware steht als Version 3.2.15 zum Download zur Verfügung. Auch wenn Ihr Querx WLAN TH nicht diese Ausfallerscheinung zeigt, sollten Sie das Update auf Ihr Gerät übernehmen, denn sporadische Fehler haben eine weitere unangenehme Eigenschaft: Sie treten oft im ungünstigsten Moment auf. In diesem Fall beispielweise nach einem Stromausfall, bei dem Sie sicher genügend andere Probleme haben werden.