Von DerSchneider<\/strong><\/p>\n\n\n\n Einleitung: Die Suche im Nebel<\/strong><\/p>\n\n\n\n Stellen Sie sich vor, Sie schreiben ein Programm f\u00fcr Ihren PC. Es st\u00fcrzt ab. Sie haben einen Bildschirm, eine Tastatur, eine Maus. Sie k\u00f6nnen Breakpoints setzen, Variablen inspizieren, den Call-Stack durchsuchen. Der Computer selbst erz\u00e4hlt Ihnen, was falsch l\u00e4uft.<\/p>\n\n\n\n Stellen Sie sich jetzt vor, Sie programmieren einen Mikrocontroller in einer laufenden Maschine. Es gibt keinen Bildschirm, keine Tastatur, keine Maus. Das Programm l\u00e4uft \u2013 oder eben nicht. Aber es sagt Ihnen nichts. Es ist ein stummer, unsichtbarer Geist im Silizium, und Sie m\u00fcssen herausfinden, warum er sich nicht so verh\u00e4lt, wie Sie es wollen.<\/p>\n\n\n\n Das ist die Realit\u00e4t des Embedded-Debuggings. Es ist die Kunst, Unsichtbares sichtbar zu machen, mit begrenzten Mitteln aus winzigen Hinweisen die Ursache eines Fehlers zu erschlie\u00dfen. Dieser Artikel f\u00fchrt in diese Kunst ein. Wir lernen die Werkzeuge und Techniken kennen, mit denen Embedded-Entwickler ihre unsichtbaren Kollegen zum Reden bringen.<\/p>\n\n\n\n Hauptteil<\/strong><\/p>\n\n\n\n 1. Die einfachste Methode: Serial over Debug<\/strong><\/p>\n\n\n\n Beginnen wir mit der einfachsten und zugleich m\u00e4chtigsten Debugging-Methode: der seriellen Ausgabe. Fast jeder Mikrocontroller hat eine UART-Schnittstelle. Schlie\u00dft man sie an einen USB-Seriell-Wandler an, kann man Nachrichten an den PC senden.<\/p>\n\n\n\n c<\/p>\n\n\n\n Das ist das Embedded-\u00c4quivalent zu Die Grenzen: Es braucht die UART-Hardware, es beeinflusst das Timing (ein Trotzdem: In mindestens 80 Prozent aller F\u00e4lle reicht die serielle Ausgabe, um einen Fehler zu finden. Sie ist das Schweizer Taschenmesser des Embedded-Debuggings.<\/p>\n\n\n\n 2. Die n\u00e4chste Stufe: LED-Debugging<\/strong><\/p>\n\n\n\n Was, wenn keine UART vorhanden ist oder die Schnittstelle selbst Fehler macht? Dann hilft die \u00e4lteste Debugging-Methode der Welt: die LED.<\/p>\n\n\n\n Man nehme eine LED, schlie\u00dfe sie an einen freien Pin an und lasse sie in bestimmten Situationen blinken:<\/p>\n\n\n\n c<\/p>\n\n\n\n Die LED ist der Urvater aller Debugging-Werkzeuge. Sie ist immer da, kostet nichts und verr\u00e4t oft genug: L\u00e4uft das Programm \u00fcberhaupt? Kommt es in diese Schleife? Bleibt es an dieser Stelle h\u00e4ngen?<\/p>\n\n\n\n Manche Entwickler haben ganze Kodierungen entwickelt \u2013 zwei LEDs, die bin\u00e4r den Zustand anzeigen, oder eine LED, deren Blinkmuster eine Fehlernummer codiert.<\/p>\n\n\n\n 3. Der Profi: In-Circuit-Debugger (JTAG\/SWD)<\/strong><\/p>\n\n\n\n F\u00fcr ernsthafte Debugging-Arbeiten kommt man um einen Debugger nicht herum. Die meisten Mikrocontroller haben eine spezielle Debug-Schnittstelle \u2013 JTAG (Joint Test Action Group) oder SWD (Serial Wire Debug).<\/p>\n\n\n\n Mit einem Debugger kann man:<\/p>\n\n\n\n Das ist so, als h\u00e4tte der Mikrocontroller pl\u00f6tzlich einen Bildschirm und eine Tastatur. Man kann live hineinschauen, w\u00e4hrend das Programm l\u00e4uft \u2013 oder es genau dort anhalten, wo der Fehler auftritt.<\/p>\n\n\n\n Die Hardware kostet wenig (ein ST-Link oder J-Link ist schon f\u00fcr unter 20 Euro zu haben), und die Entwicklungsumgebungen (Eclipse, VS Code mit entsprechenden Plugins) unterst\u00fctzen das hervorragend.<\/p>\n\n\n\n 4. Die Zeitmaschine: Der Logikanalysator<\/strong><\/p>\n\n\n\n Manche Fehler sind zeitkritisch. Ein Interrupt kommt zu sp\u00e4t, ein Signal ist zu kurz, zwei Ereignisse \u00fcberlappen sich unerwartet. Solche Fehler sieht man mit einem Debugger nicht, weil der das Programm anh\u00e4lt und damit das Timing zerst\u00f6rt.<\/p>\n\n\n\n Hier kommt der Logikanalysator ins Spiel. Er zeichnet digitale Signale \u00fcber die Zeit auf und zeigt sie als Wellenform an. Man sieht genau, wann welcher Pin seinen Zustand \u00e4ndert, wie lang Impulse sind, ob die zeitlichen Abl\u00e4ufe stimmen.<\/p>\n\n\n\n Ein einfacher Logikanalysator (oft f\u00fcr unter 10 Euro als USB-Stick erh\u00e4ltlich) kann Wunder wirken:<\/p>\n\n\n\n Die aufgezeichneten Signale l\u00fcgen nicht. Sie zeigen die physikalische Realit\u00e4t, nicht die Programm-Logik.<\/p>\n\n\n\n 5. Das Fenster in die Vergangenheit: Der Oszilloskop<\/strong><\/p>\n\n\n\n Wo der Logikanalysator nur digitale Signale (HIGH\/LOW) kennt, zeigt das Oszilloskop die tats\u00e4chlichen Spannungsverl\u00e4ufe. Das ist wichtig, wenn es um analoge Probleme geht:<\/p>\n\n\n\n Ein Oszilloskop ist teurer und komplexer als ein Logikanalysator, aber f\u00fcr bestimmte Probleme unersetzlich.<\/p>\n\n\n\n 6. Die Kunst des Printf, wenn kein Printf geht<\/strong><\/p>\n\n\n\n Oft hat man keine UART frei oder die Ausgabe st\u00f6rt das Timing zu sehr. Dann muss man kreativ werden:<\/p>\n\n\n\n Ringspeicher im RAM:<\/strong> Man legt einen Puffer im RAM an und schreibt Debug-Informationen hinein. Wenn das Programm anh\u00e4lt (oder gezielt gestoppt wird), liest man den Puffer aus.<\/p>\n\n\n\n c<\/p>\n\n\n\n Nach einem Absturz kann man den Puffer \u00fcber den Debugger auslesen und sieht, was vor dem Absturz passiert ist.<\/p>\n\n\n\n GPIO als Logikanalysator:<\/strong> Man nutzt einen freien Pin, setzt ihn vor wichtigen Aktionen und l\u00f6scht ihn danach. Mit einem Logikanalysator kann man dann die Dauer und Reihenfolge der Aktionen messen.<\/p>\n\n\n\n 7. Der Klassiker: Heisenbugs<\/strong><\/p>\n\n\n\n Die fiesesten Fehler in Embedded Systems sind die, die verschwinden, wenn man sie sucht \u2013 sogenannte Heisenbugs (nach Werner Heisenberg, der zeigte, dass Messung das Gemessene ver\u00e4ndert).<\/p>\n\n\n\n Klassische Beispiele:<\/p>\n\n\n\n Die Ursache ist fast immer ein Timing-Problem. Der Debugger verlangsamt das Programm, die LED-Ausgabe dauert ihre Zeit, der Release-Modus optimiert Code anders. Pl\u00f6tzlich sind die zeitlichen Bedingungen andere, und der Fehler zeigt sich nicht mehr.<\/p>\n\n\n\n Die L\u00f6sung: So nah wie m\u00f6glich an der Realit\u00e4t debuggen. Logikanalysator statt Printf, Ringspeicher statt serielle Ausgabe, genaue Analyse der Timing-Anforderungen.<\/p>\n\n\n\n 8. Fallstricke und typische Fehler<\/strong><\/p>\n\n\n\n Die Erfahrung zeigt: Bestimmte Fehler treten immer wieder auf. Eine kleine Ph\u00e4nomenologie:<\/p>\n\n\n\n Vergessene Initialisierung:<\/strong> Ein Timer l\u00e4uft nicht, weil das entsprechende Register nie gesetzt wurde. Das Programm wartet ewig auf ein Ereignis.<\/p>\n\n\n\n Falsche Register:<\/strong> Man schreibt ins falsche Register oder verwechselt die Bitpositionen. Der Pin tut nicht, was er soll.<\/p>\n\n\n\n Interrupt-Konflikte:<\/strong> Zwei Interrupts st\u00f6ren sich gegenseitig. Ein niederpriorer Interrupt wird nie bedient, weil ein hochpriorer dauernd kommt.<\/p>\n\n\n\n Stack-Overflow:<\/strong> Der Stack w\u00e4chst in den Variablenbereich (oder umgekehrt). Das Programm zeigt merkw\u00fcrdiges, scheinbar zuf\u00e4lliges Verhalten.<\/p>\n\n\n\n Race Conditions:<\/strong> Zwei Tasks greifen gleichzeitig auf dieselbe Variable zu. Mal geht’s gut, mal nicht.<\/p>\n\n\n\n Optimierungsfallen:<\/strong> Der Compiler optimiert Code weg, den er f\u00fcr \u00fcberfl\u00fcssig h\u00e4lt (z.B. Zugriffe auf Hardware-Register, die er nicht als solche erkennt). Das Schl\u00fcsselwort 9. Ein Praxisbeispiel: Der flackernde Taster<\/strong><\/p>\n\n\n\n Erinnern Sie sich an das Taster-Beispiel aus Artikel 3? Der Taster prellt, und wenn man nicht entprellt, flackert die LED.<\/p>\n\n\n\n Das Debugging mit verschiedenen Methoden:<\/p>\n\n\n\n Jede Methode hat ihren Beitrag geleistet, und zusammen ergeben sie ein vollst\u00e4ndiges Bild.<\/p>\n\n\n\n 10. Pr\u00e4vention ist besser als Debugging<\/strong><\/p>\n\n\n\n Die beste Debugging-Strategie ist, Fehler gar nicht erst zu machen. Einige Grundregeln:<\/p>\n\n\n\n Trotzdem: Fehler werden passieren. Die Kunst ist, sie systematisch zu finden \u2013 nicht durch wildes Herumprobieren, sondern durch methodisches Vorgehen mit den richtigen Werkzeugen.<\/p>\n\n\n\n Fazit und Ausblick<\/strong><\/p>\n\n\n\n Debuggen in Embedded Systems ist eine Detektivarbeit. Die Spuren sind oft klein, die Zeugen schweigen, und der T\u00e4ter ist unsichtbar. Aber mit den richtigen Werkzeugen \u2013 von der einfachen LED \u00fcber den Debugger bis zum Logikanalysator \u2013 und einer methodischen Vorgehensweise lassen sich auch die hartn\u00e4ckigsten Fehler finden.<\/p>\n\n\n\n Wir haben die Werkzeuge kennengelernt. Aber Werkzeuge allein gen\u00fcgen nicht. Man muss auch wissen, wo die besonderen Gefahren lauern \u2013 gerade in sicherheitskritischen Systemen, wo ein Fehler nicht nur \u00e4rgerlich, sondern lebensbedrohlich sein kann.<\/p>\n\n\n\n Mit diesem Thema \u2013 der Sicherheit in Embedded Systems \u2013 besch\u00e4ftigen wir uns im n\u00e4chsten Artikel.<\/p>\n","protected":false},"excerpt":{"rendered":" Debuggen im Verborgenen \u2013 Die Kunst, Unsichtbares sichtbar zu machen Von DerSchneider Einleitung: Die Suche im Nebel Stellen Sie sich vor, Sie schreiben ein Programm f\u00fcr Ihren PC. Es st\u00fcrzt ab. Sie haben einen Bildschirm, eine Tastatur, eine Maus. Sie k\u00f6nnen Breakpoints setzen, Variablen inspizieren, den Call-Stack durchsuchen. Der Computer selbst erz\u00e4hlt Ihnen, was falsch […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[46,26],"tags":[2069],"class_list":["post-2154","post","type-post","status-publish","format-standard","hentry","category-industrie-4-0","category-mit-den-handen","tag-embedded-world"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2154","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=2154"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2154\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=2154"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=2154"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=2154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\n
\n\n\n\nprintf(\"Sensorwert: %d\\n\", wert);<\/pre>\n\n\n\n
System.out.println()<\/code> oder console.log()<\/code>. Einfach, aber oft genial effektiv. Man sieht, welche Werte das Programm verarbeitet, welche Pfade es nimmt, wo es h\u00e4ngen bleibt.<\/p>\n\n\n\nprintf<\/code> kann Tausende von Taktzyklen dauern) und es funktioniert nicht, wenn der Fehler genau in der Kommunikation liegt.<\/p>\n\n\n\n\/\/ Fehlerfall signalisieren<\/em>\nif (fehler) {\n while(1) {\n led_ein();\n delay(100);\n led_aus();\n delay(100);\n }\n}\n\n\/\/ Programmfortschritt anzeigen<\/em>\nvoid funktion1() {\n led_gruen_ein();\n \/\/ ... Arbeit ...<\/em>\n led_gruen_aus();\n}\n\nvoid funktion2() {\n led_rot_ein();\n \/\/ ... Arbeit ...<\/em>\n led_rot_aus();\n}<\/pre>\n\n\n\n\n
\n
\n
#define DEBUG_SIZE 100\ntypedef struct {\n unsigned long time;\n int event;\n int value;\n} debug_entry_t;\n\ndebug_entry_t debug_buffer[DEBUG_SIZE];\nint debug_index = 0;\n\nvoid debug_log(int event, int value) {\n debug_entry_t *e = &debug_buffer[debug_index];\n e->time = millis();\n e->event = event;\n e->value = value;\n debug_index = (debug_index + 1) % DEBUG_SIZE;\n}<\/pre>\n\n\n\n\n
volatile<\/code> ist oft die L\u00f6sung.<\/p>\n\n\n\n\n
\n
\n\n\n\n