Tx=20240319.

ESP32 LILYGO LoRa DevKit







Man darf nicht aufgeben! Jedenfalls nicht voreilig. Aber der Reihe nach.

Für ein Projekt verwendete ich einige (etwas über 20) LILYGO ESP32 development boards, so wie eines oben im Bild zu sehen ist. Das development board (DevKit) ist nur das kleine graue Teil mit der Antenne -- die grüne Platine ist von mir. Solche DevKits sind oft billig (5 EURO) aber dieses hat es in sich: neben einem ESP32 ist ein Bildschirm drauf und auf der Unterseite ein LoRa Weitbereichs-Funkmodem (deshalb die Antenne). Natürlich gibt es auch eine USB-Buchse über die man z.B. den ESP neu programmieren kann. Doch dazu gleich mehr. 2 x 13 pins stellen einige GPIO pins und andere Verbindungen (3.3V, 5V, Masse, etc.) zur Verfügung.

Das board im Bild war ca. 2 Jahre ohne Probleme im Einsatz, als plötzlich der ESP nicht mehr bootete. Ich suchte ziemlich lange, aber warum es zwei Jahre ging und dann nicht mehr war nicht ganz klar herauszubringen. Ein anderes DevKit funktionierte auf dem board jedenfalls sofort einwandfrei. Jeder Erbsenzähler hätte an dieser Stelle die ca. 30 EURO für das DevKit abgeschrieben, es ausgetauscht, das Defekte weggeworfen und gut. Eine Sache von 5 Minuten, na ja, vielleicht eine halbe Stunde mit dem Fehlersuchen. Aber das ist nicht meine Art.

Es sieht ja ziemlich klar nach einem Defekt des DevKit aus, denn mit einem neuen geht wieder alles. Aber das wäre zu einfach: wenn ich das DevKit  vom grünen board nehme und nur über die USB-Buchse versorge, funktioniert es wieder einwandfrei!! Was ist denn da los??

Meine Arbeitshypothese ist, dass sich das graue DevKit über die Zeit im Ausseneinsatz mit Feuchtigkeit vollgesogen hat (insbesondere im Winter), wodurch auf pin 16 (GPIO00) ein leichter Masseschluss aufkam, der das Potential dieses strapping-pins zu weit nach GND verschoben hat. Auf der grünen Platine verwende ich das pin 16, um einen Transistor zu treiben, da ist also (über einen 10k) auch ein Massepfad vorhanden. Und zusammen war das dann zu viel. Könnte so hinkommen. Ich habe also den 10k auf dem board auf 20k erhöht (das reicht auch noch dicke) und schon hat das DevKit auch auf dem board wieder funktoniert. Yeaaahh!  Man könnte jetzt sagen "Klasse! Alles gut. Zurück in den Einsatz.", aber wenn ich das Ding schon mal in der Werkstatt habe, dann wollte ich noch ein bisserl dran rumverbessern. Never change a running system! Oh well...

Ich habe also an der software (SW) rumprogrammiert, hier noch eine ein bisserl hübschere Ausgabe auf dem Bildschirm, dort noch etwas verbessert. Man kennt das ja. Dann übersetzen und per OTA (Over The Air) update per WiFi aufgespielt. Was mir dunkel im Hinterkopf war, war, dass ich irgendwann mal in den letzten zwei Jahren einen library update auf dem build System gemacht hatte und dann aber nichts mehr ausprobiert hatte. Das sollte mich jetzt beissen.

Die neue SW meldete sich, alles super, aber dann machte der ESP einen reboot -- ohne ersichtlichen Grund. Und dann noch einen. Grrrr. Ich baute in die SW etwas debug output auf den kleinen Bildschirm (wer hat, der hat!) ein, wollte das hochladen, aber ich konnte nicht mehr in den WiFi-Modus schalten: beim Drücken des dazugehörigen Knopfes bootete der ESP neu, und nichts mit WiFi. Grrrr.

Was war passiert: durch den library upgrade funktionierte die LoRa SW nicht mehr. Beim booten wurde einmal ein Datenpaket in die Warteschlange gestellt, aber nie ausgeliefert. Beim Drücken des Knopfes um in den WiFi-Modus zu kommen, wird aber zuerst mal ein Datenpaket geschickt (je nach dem, wie lange man drückt: erst Daten, nach 5 Sekunden WiFi und nach 10 Sekunden würde er die power runterfahren und sich abschalten). Das ging bisher immer problemlos, aber wenn das LoRa versagt, dann war programmiert, dass ein reboot ausgelöst wird, um die Dinge wieder zu richten. Und das passierte, bevor die 5 Sekunden für den WiFi Mode abgelaufen waren. Also kam es nie bis zum WiFi. Aaargh!

Für diese Fälle kann man über die USB Buchse per serieller Verbindung (via USB) ein neues Programm flashen. Kein Problem, dachte ich. Aber der ESP meldete sich nicht per USB: kein neuer Port, nichts! Ich habe wirklich alles probiert, power, reset, ... keine Spur vom ESP auf dem USB. Ja Mist! Ein anderes DevKit tauchte sofort mit einem port auf dem USB auf, so wie es sein müsste, aber nicht dieses DevKit. Weder mit grünem board noch ohne.

Als erstes hatte ich die kleine Micro-USB Buchse im Verdacht. Kann ja leicht mal eine Leiterbahn abgehen oder die Kontakte oxidieren, oder Dreck, oder einfach Wackelkontakt. Tatsächlich zeigte sich bei näherem Hinsehen, dass ich diese Buchse schon mal nachgelötet hatte. Hmm. Also USB Kabel eingesteckt und mit dem DMM die Verbindung bis zum CH9102F (das ist der USB nach seriell Wandler auf dem DevKit) überprüft: einwandfrei! Kein Wackler. Rock solid!

Dann die andere Seite vom CH9102F zum ESP32: keine Verbindung. Hmmm. Laut Schaltplan ist da eine direkte Verbindung, aber wie sich zeigte, sind da zwei 470 Ohm Widerstände in die Leitungen eingeschleift (wenn man den Schaltplan genau anschaut, findet man auch diese beiden Widerstände!). Wenn man das berücksichtigt, dann war alles OK. Nun könnte es sein, dass vielleicht einige der Hilfsleitungen (z.B: sleep/enable/suspend oder die Betriebsspannung oder Masse) keinen guten Kontakt mehr machten. Also habe ich versucht, mit viel flux und der Heißluftpistole (nein, nicht die aus dem Baumarkt) das IC zu reflowen, leider ohne Erfolg. Es könnte defekt sein. Mist!

Dann kam mir die Idee, die seriellen Anschlüsse TXD (pin 2, GPIO01) und RXD (pin 3, GPIO03), die ja herausgeführt sind, mit einem externen USB/seriell Wandler anzusprechen. Ich musste ja nur einmal ein neues Programm flashen, denn das hatte ich mittlerweile so umgebaut, dass man den WiFi-Modus sicher erreichen konnte, egal was los war. Einen FTDI232 hatte ich, also nur ein paar Kabel provisorisch gesteckt (RX -- TX, TX -- RX, GND, +5V) und schon konnte ich auf dem seriellen Monitor der Arduino-IDE meine debug-Texte lesen! Yeaaah!

Aber der upload-Versuch scheiterte. Keine Verbindung. Vielleicht liegt es an den 470 Ohm Widerständen, dass die nicht gut genug trennen? Denn auf das RX pin des ESP arbeiteten nun ja zwei Treiber: der CH9102F und der FTDI232. Wenn die gegeneinander arbeiteten, dann gab das vielleicht Salat. Also flux die beiden 470 Ohm Widerstände ausgelötet und wieder probiert: nada. Keine Verbindung.

Da erinnerte ich mich, dass man zum Aktivieren des boot loaders noch irgendein Signal geben musste. Das i-net half schnell: man muss den rechten BOOT Knopf drücken. Nur hat mein DevKit den nicht! Das hat nur einen RESET Knopf. Welches pin ist denn nun der BOOT Knopf? Erst dachte ich GPIO02 (pin 17), aber das funktionierte nicht. Nochmal genau gelesen: meisten ist es GPIO00 (pin 16) -- knapp daneben. Und damit hat es dann endlich funktioniert: GPIO00 während des bootens auf Masse legen, dann geht der ESP in den boot loader modus und erwartet die Daten via seriellem Interface. Yeaaah! Es hat geklappt!

Damit ist der Zombie-ESP wieder unter den Lebenden. Nur nicht aufgeben!



Zurück zur Hauptseite