Jeder Bastler und Tüftler kennt diesen Moment: Der Programmcode wurde stundenlang überprüft und ist absolut fehlerfrei, aber das Projekt verhält sich trotzdem völlig unlogisch. Ein Sensor liefert plötzlich wirre Daten, das Display flackert oder der komplette Mikrocontroller startet ohne ersichtlichen Grund neu. Oft liegt der Fehler nicht nur in der Software, sondern auf der physikalischen Ebene – versteckt in der Hardware oder der Stromversorgung.
Ich habe zwar in den einzelnen Projekten von diesen Problemen berichtet und auch die Lösungen gezeigt, aber hier mal zum schnelleren Auffinden zusammengetragen.
Damit die Fehlersuche nicht im Frust endet, hilft diese hoffentlich verständliche Checkliste. Hier sind typische Stolpersteine bei diesen Projekten und die passenden Lösungen, um den Übeltäter schnell zu überführen.
Bereich 1: Strom und Spannungsversorgung
1. Zu schwache USB-Stromversorgung (Universal Serial Bus)
Das Problem: Der ESP32-Mikrocontroller stürzt genau in dem Moment ab oder startet neu, in dem er versucht, eine Verbindung mit dem WLAN (Wireless Local Area Network) aufzubauen.
Die Lösung: Der Funkbetrieb benötigt kurzzeitig sehr viel Strom. Wenn das Board nur am USB-Anschluss eines Computers hängt, reicht die Energie oft nicht aus. Verwende stattdessen einen aktiven USB-Hub mit eigenem Netzteil oder ein separates, starkes Netzteil für die Stromversorgung. Diesen setzte ich schon lange ein: VEMONT, USB 3.0 Hub mit Netzteil
2. Spannungsabfall durch lange Leitungen (Leitungswiderstand)
Das Problem: Ein Sensor, der weiter entfernt platziert ist (zum Beispiel für eine Wetterstation im Garten), liefert unzuverlässige Messwerte oder schaltet sich komplett ab. Leitungswiderstand berechnen kann man online bei tgb-automation.de
Die Lösung: Jedes Kabel hat einen eigenen Widerstand. Je länger und dünner das Kabel ist, desto mehr Spannung geht auf dem Weg verloren. Halte die Kabelwege so kurz wie möglich, nutze Kabel mit einem größeren Durchmesser oder löte einen kleinen Kondensator als Energiespeicher direkt an die Stromanschlüsse des Sensors.
Zum Beispiel:
Für den ESP32‑Auto‑Reset (EN ↔ GND): 10 µF Elektrolytkondensator
Warum genau 10 µF?
Funktioniert auf nahezu allen Dev‑Boards stabil.
Groß genug, um den Reset‑Impuls zu verlängern.
Klein genug, damit der ESP32 trotzdem sauber startet.
3. Fehlende gemeinsame Masse (GND / Ground)
Das Problem: Zwei Bauteile, die jeweils aus einer eigenen Stromquelle versorgt werden (zum Beispiel ein Mikrocontroller und ein externes Display), können keine Daten austauschen.
Die Lösung: Strom muss immer im Kreis fließen. Verbinde die Minus-Pole (GND) aller beteiligten Stromquellen und Platinen mit einem Kabel, damit alle Bauteile das gleiche elektrische Bezugspotenzial haben.
Beispiel Verdrahtungsplan: ESP32-Projekt: DIY Dezibel Messgerät mit Lärmschutzampel
4. Falsche Spannung: 5 Volt an 3,3 Volt Anschlüssen
Das Problem: Ein moderner Sensor liefert dauerhaft Fehler oder geht nach dem Anschließen sofort kaputt.
Die Lösung: Viele moderne Bauteile und Mikrocontroller arbeiten intern mit maximal 3,3 Volt. Schließt man sie an ältere 5-Volt-Anschlüsse an, zerstört das die empfindlichen Chips. Nutze in solchen Fällen einen Pegelwandler (Level-Shifter), der die Signale sicher zwischen 5 Volt und 3,3 Volt übersetzt.
Siehe Beitrag: Mit Logik-Level-Konverter können auch 5V Module sicher am Raspi oder ESP32 laufen
5. Spannungsschwankungen beim Schalten von Relais
Das Problem: Sobald ein Relais einen großen Verbraucher (wie eine Pumpe oder Lampe) einschaltet, stürzt der Mikrocontroller ab.
Die Lösung: Das mechanische Schalten und der plötzliche Stromhunger des Relais lassen die Spannung auf der Hauptplatine kurz einbrechen. Betreibe Relais-Module nach Möglichkeit immer über eine eigene, getrennte Stromversorgung.
Beispiel: Arduino Projekt: Wie funktioniert ein Relay
Bereich 2: Verkabelung und Hardware-Verbindungen
6. Wackelkontakte auf dem Steckbrett (Breadboard)
Das Problem: Das Projekt funktioniert ein paar Minuten lang perfekt. Sobald man den Tisch leicht berührt oder ein Kabel bewegt, bricht alles zusammen.
Die Lösung: Die Kontakte in günstigen Steckbrettern leiern schnell aus. Nutze hochwertige Verbindungskabel (Jumper-Kabel). Wenn das Projekt dauerhaft stabil laufen soll, empfiehlt es sich, die Bauteile fest auf einer Lochrasterplatine zu verlöten.
7. Senden und Empfangen vertauscht bei UART (Universal Asynchronous Receiver Transmitter)
Das Problem: Ein Modul, das über die serielle Schnittstelle kommuniziert (wie ein GPS-Empfänger), sendet einfach keine Daten an den Mikrocontroller.
Die Lösung: Bei dieser Schnittstelle müssen die Datenleitungen gekreuzt werden. Der Sende-Anschluss (TX / Transmit) des Moduls muss an den Empfangs-Anschluss (RX / Receive) des Mikrocontrollers angeschlossen werden – und umgekehrt.
8. Fehlende Pull-Up-Widerstände beim I2C-Bus (Inter-Integrated Circuit)
Das Problem: Ein neuer Sensor wird vom System überhaupt nicht erkannt, obwohl alle Kabel richtig angeschlossen sind.
Die Lösung: Die Datenleitungen des I2C-Busses benötigen im Ruhezustand ein stabiles Signal. Dafür sorgen zwei Widerstände (meist 4,7 kOhm), die zwischen die Datenleitungen und den Pluspol geschaltet werden. Viele fertige Bastler-Platinen haben diese bereits verbaut, nackte Sensor-Chips hingegen nicht.
9. Zu lange Leitungswege beim I2C-Bus
Das Problem: Die Datenübertragung zum Sensor bricht ab oder wird extrem langsam, sobald das Kabel länger als 30 bis 50 Zentimeter wird.
Die Lösung: Die I2C-Schnittstelle wurde entwickelt, um Bauteile auf ein und derselben Platine über minimale Distanzen zu verbinden. Für längere Kabelwege außerhalb des Gehäuses müssen spezielle Verstärker-Chips (I2C-Extender) eingesetzt werden. Siehe auch Punkt 2 – Leitungswiderstand
10. Taster prellen (mechanisches Nachfedern)
Das Problem: Ein angeschlossener Knopf wird gedrückt. Das Programm reagiert jedoch so, als hätte man den Knopf in rasanter Abfolge fünfmal hintereinander gedrückt.
Die Lösung: Metallkontakte in Schaltern federn beim Schließen im Millisekundenbereich nach. Das nennt man „Prellen“. Die Lösung ist das „Entprellen“: Entweder baut man im Code nach der Erkennung eine winzige Wartezeit ein oder man fängt das Nachfedern elektronisch mit einem kleinen Kondensator am Taster ab. Siehe Schalter und Taster richtig einsetzen
Bereich 3: Besonderheiten beim ESP32-Mikrocontroller
11. Falsche Pins (GPIO – General Purpose Input/Output) gewählt
Das Problem: Der Mikrocontroller startet überhaupt nicht mehr, wenn bestimmte Sensoren oder Taster angeschlossen sind.
Die Lösung: Der ESP32 besitzt sogenannte „Strapping Pins“. Diese Pins entscheiden beim Einschalten darüber, in welchem Modus der Chip startet. Liegt an ihnen durch ein externes Bauteil ein falsches Signal an, blockiert das den Start. Prüfe vor der Verkabelung immer genau das Pinout-Diagramm (den Belegungsplan) deines Boards. Die Anschlüsse 34 bis 39 dürfen zudem nur als Eingänge genutzt werden. Siehe Welchen GPIO Pin beim ESP32 kann ich bedenkenlos nehmen?
12. Das Board wartet oder verweigert Programm-Upload
Das Problem: Beim Versuch, neuen Code auf das Board zu laden, bleibt der Vorgang bei der Meldung „Connecting…“ dauerhaft stehen. Oder Meldung COM Schnittstelle Zugriff verweigert erscheint.
Die Lösung: Die automatische Umschaltung in den Programmiermodus klappt bei einigen Boards nicht fehlerfrei. Halte einfach die „BOOT“-Taste auf der Platine gedrückt, während die Software versucht, die Verbindung aufzubauen. Bei COM Zugriff verweigert diesen Betrag anschauen: Arduino IDE Problem: Welches Programm blockiert meinen COM-Port?
13. WLAN stört analoge Messungen (ADC – Analog-to-Digital Converter)
Das Problem: Ein analoger Sensor liefert völlig unbrauchbare oder springende Werte, sobald das Wi-Fi-Modul des ESP32 aktiv geschaltet wird.
Die Lösung: Der ESP32 besitzt zwei interne Blöcke für analoge Messungen. Der Block „ADC2“ teilt sich die Leitungen mit dem WLAN-Modul und wird blockiert, wenn gefunkt wird. Schließe analoge Sensoren daher immer ausschließlich an die Pins an, die zum Block „ADC1“ gehören. Siehe Welchen GPIO Pin beim ESP32 kann ich bedenkenlos nehmen?
Bereich 4: Software und Programmierung
14. Kryptische Zeichen im Seriellen Monitor
Das Problem: Im Textfenster der Entwicklungsumgebung erscheinen statt der Textausgaben nur Fragezeichen, Quadrate oder unlesbarer Buchstabensalat.
Die Lösung: Die Baudrate (die Übertragungsgeschwindigkeit) ist falsch eingestellt. Die Zahl unten rechts im Seriellen Monitor muss exakt mit der Zahl übereinstimmen, die du im Code beim Befehl Serial.begin(…) eingetragen hast (zum Beispiel 115200).
15. Das Programm blockiert sich selbst durch Verzögerungen
Das Problem: Der Mikrocontroller reagiert nur sehr träge auf Tastendrücke oder verpasst regelrecht wichtige Sensorwerte.
Die Lösung: Der beliebte Befehl delay() legt den gesamten Mikrocontroller für die angegebene Zeit komplett lahm. Währenddessen passiert im Hintergrund nichts. Nutze stattdessen den Befehl millis(). Damit lässt sich im Code wie mit einer Stoppuhr prüfen, ob eine bestimmte Zeit vergangen ist, während das Hauptprogramm flüssig weiterläuft. Diese Lösung hält jedoch bei Dauerbetrieb nur etwas 49 Tage. Siehe Arduino Projekt: Funktionstüchtige Uhr mit schwebendem Zeiger erstellen
16. Falsches Entwicklungsboard ausgewählt
Das Problem: Beim Kompilieren (Übersetzen des Codes) bricht die Software mit Fehlermeldungen ab oder der Upload schlägt fehl.
Die Lösung: Es gibt unzählige verschiedene ESP32- und Arduino-Varianten auf dem Markt. Kontrolliere in den Einstellungen deiner Entwicklungsumgebung, ob wirklich exakt das Boardmodell ausgewählt ist, das vor dir auf dem Schreibtisch liegt. Bei ESP32 ist es etwas schwieriger. Jedoch hier kannst du nachlesen wie du die ESP32 Board Info auslesen kannst:
17. Fehlende Bibliotheken (Libraries)
Das Problem: Der Code lässt sich nicht starten und bricht mit einer Fehlermeldung ab, dass eine Datei mit der Endung „.h“ nicht gefunden werden kann.
Die Lösung: Im Programmcode wurden vorgefertigte Funktionssammlungen eingebunden, die noch nicht auf deinem Computer installiert sind. Suche im Bibliotheksverwalter deiner Entwicklungsumgebung nach dem genauen Namen aus der Fehlermeldung und installiere die fehlende Bibliothek nach.
Beispiel LCD ohne oder mit I2C Schnittstelle: Wie bekomme ich ein LCD Display an einem Arduino zum laufen
18. Falsche I2C-Adresse im Programmcode angesprochen
Das Problem: Die Verkabelung des I2C-Sensors ist perfekt, aber das Programm meldet beharrlich, dass kein Sensor gefunden wurde.
Die Lösung: Jeder I2C-Teilnehmer besitzt eine feste elektronische Adresse – wie eine Hausnummer. Stimmt diese Hausnummer im Code nicht, bleibt der Sensor stumm. Lade ein kleines Hilfsprogramm namens „I2C Scanner Sketch“ auf dein Board. Dieses durchsucht alle Anschlüsse und zeigt dir die exakte Adresse im Seriellen Monitor an, die du dann in deinen Code übernehmen kannst.
19. Der COM-Port (Communication Port) ist blockiert
Das Problem: Die Software meldet beim Versuch des Uploads, dass der serielle Anschluss blockiert („busy“) ist.
Die Lösung: Ein serieller Anschluss kann immer nur von einem einzigen Programm gleichzeitig genutzt werden. Prüfe, ob im Hintergrund noch ein anderes Programm geöffnet ist, das auf das Board zugreift (zum Beispiel ein Steuerungsprogramm für einen 3D-Drucker oder ein zweites Monitorfenster) und schließe dieses.
Siehe auch Punkt 12: Bei COM Zugriff verweigert diesen Betrag anschauen: Arduino IDE Problem: Welches Programm blockiert meinen COM-Port?
20. Variablen-Überlauf bei der Zeitmessung
Das Problem: Eine smarte Steuerung läuft tagelang problemlos durch – und stürzt nach exakt 50 Tagen plötzlich und ohne jede Vorwarnung ab.
Die Lösung: Wenn du Zeiten in Millisekunden mit dem Befehl millis() misst, wird die Zahl im Hintergrund Sekunde für Sekunde gigantisch groß. Nach knapp 50 Tagen läuft der Speicherplatz für diese Zahl aber über. Siehe auch Punkt 15
21. Wenn der Serielle Monitor leer bleibt
Das Problem ist: Der Serielle Monitor am Computer bleibt komplett leer. Die Textausgaben aus dem Programmcode landen im Nichts, weil neuere ESP32-Modelle (S2, S3, C3, C6, H2) die Daten standardmäßig an die physischen Steckkontakte der Platine schicken und nicht direkt in das USB-Kabel (Universal Serial Bus).
Lösung: Die CDC-Funktion (Communications Device Class) muss beim Start eingeschaltet werden. Sie leitet die Textausgaben wie eine Weiche direkt über das USB-Kabel zum Computer um.
In Arduino IDE das richte Board auswählen, dann in der Menüleiste auf Werkzeuge die Option USB CDC On Boot aktivieren.
In Visual Studio Code trage dazu in deiner Konfigurationsdatei (platformio.ini) einfach folgende Zeile ein:
build_flags = -D ARDUINO_USB_CDC_ON_BOOT=1
Der Unterschied bei der Hardware
Bei älteren Modellen (wie dem klassischen ESP32 oder dem ESP8266) saß immer ein zusätzlicher, kleiner Baustein auf der Platine (oft ein Chip mit der Bezeichnung CP2102 oder CH340, die Treiber benötigen). Dieser Baustein hat die USB-Signale (Universal Serial Bus) vom Computer in einfache serielle Signale übersetzt. Diese serielle Schnittstelle nennt man UART (Universal Asynchronous Receiver-Transmitter). Der Mikrocontroller hat die Daten dann über seine physischen Sende- und Empfangspins verarbeitet.
Beispiel siehe ESP32-Projekt: Atomgenaue Zeit mit NTP
22. Unerwartetes Verhalten oder es passiert etwas völlig Unerwartetes
Das Problem: Man lädt das Programm auf den Mikrocontroller hoch, aber statt zu blinken, zu messen oder zu steuern, passiert… nichts. Oder noch schlimmer: Es passiert etwas völlig Unerwartetes.
Die Analyse: Um hier eine Lösung zu finden, solltet du prüfen, ob dein Entwicklungsboard Debugging kann und zulässt: