Hallo, habe einen T-Beam bekommen der per USB nicht mehr ansprechbar ist um zB. die neue Meshtastic Software aufzuspielen. Warum das so ist, kann ich nicht sagen. Der Gerätemanager von Win7 meldet "Gerät wurde angehalten mit Code 43", der von Win 10 "Fehler beim Anfordern einer Gerätebeschreibung". Auf dem Node läuft eine ältere Meshtasticversion, aber auch mit seltsamen Verhalten, wie dann und wann Dauersendung. Die App will sich gerne verbinden, man sieht den Beam auch, aber just wenn er sich scheinbar verbunden hat, bricht er wieder ab und geht nicht ins Menü. Über das Einstellmenü der Webseite lässt sich auch nur kurz eine Verbindung herstellen, man sieht dann die empfangenen Knoten, aber dann bricht die Verbindung wieder ab. Schietendreck, wahrscheinlich verflascht oä. Der USB Handler ist ein CH9102. Entsprechende Treiber ordentlich installiert, andere Knoten gleicher Bauart werden einwandfrei erkannt. Erster Versuch war nun mit einer all in One UART Platine per Tx/Rx eine Verbindung herzustellen, was zB. in der Seriellen Konsole des Webflashers funktioniert hat und es kommen fleissig Daten. Allerdings kann ich so nicht neu flashen. Wie, oder was kann ich noch ausprobieren. Es gibt einzelne kleine CH9102 USB Platinen mit io Ports, kann ich da was mit ausrichten, indem ich den scheinbar defekten überbrücke? In diesen Dingen bin ich nicht so firm, und es wäre toll, wenn man den Knoten wiederbeleben bzw. erstmal "resetten" könnte.
Ich würde erstmal ein paar andere Kabel ausprobieren, am besten unter Linux mit lsusb gucken ob VID/PID erkannt wird.
am besten unter Linux mit lsusb gucken ob VID/PID erkannt wird.
Warum muss man dafür Linux verwenden? Zeigt das schönere oder buntere VID/PID an?
Es zeigt vor allem alles an, weil man keine extra Treiber installieren muss.
VID/PID zeigt Windows schon immer mit Bordmitteln an, auch ohne irgendwelche installierten Treiber.
Warum muss man dafür jetzt mit Linux missionieren gehen?
VID/PID zeigt Windows schon immer mit Bordmitteln an
Vielleicht erklärst Du Klaus wie es unter Windows geht? Dann kann er es gleich ausprobieren.
Hallo, unter Ubuntu erkennt er den Beam auch nicht, alles schon probiert. Gerade probier ich die ebenso angebotene CLI Installationsmöglichkeit per Python und GitBash aus, aber auch da nach Eingabe von esptool chip-id > Failed to connect to Expressive Device. Der Com Port mit dem gemounteten UART Board wird erkannt. Komisch ist, das ich den Beam per Web Client ansprechen und dort auch Veränderungen vornehmen kann.
Die Meldung unter GitBash lautet: $ esptool chip-id esptool v5.2.0 Found 1 serial ports... Serial port COM13: Connecting...
COM13 failed to connect: Failed to connect to Espressif device: No serial data received. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.
Und wie ist denn nun die VID/PID? Wenn der CH9102 erkannt wird wird ein Austausch nichts bringen.
Vielleicht erklärst Du Klaus wie es unter Windows geht? Dann kann er es gleich ausprobieren.
Gerätemanager, unbekannte oder mit gelben Dreiecken versehene USB-Geräte suchen, Eigenschaften anzeigen lassen, und dort unter "Details" die "Hardware-IDs" anzeigen lassen.
Da der Serial Port ja erstellt wurde scheint es den ja doch zu erkennen. Lege mal den Pin 0 auf Masse zum flashen.
Alexander, genau das habe ich gemacht, allerdings mit den empfohlenen 10K und das hat tatsächlich geklappt. Nun ist die richtige und aktuelle Firmware drauf und ich kann auch über Bluetooth, oder den Webclient darauf zugreifen und ganz normal konfigurieren. Allerdings der USB Port ist weiterhin tot. Ist aber nun weniger schlimm, weil man per UART eben doch wieder darauf zugreifen und so trotzdem aktualisieren kann, wenn auch etwas umständlicher. Das war eine schwere Geburt (für mich), aber immerhin vorm Mülleimer gerettet. Danke für die Tipps.
-
IMG_4016.JPG
(370 KB)
Nutze doch die Android App für OTA‑Update per Bluetooth?
werde ich wenn es nötig ist ausprobieren. Hatte aber gelesen das man es wegen möglicher wackeliger Verbindung beim Flashen eher nicht machen sollte.
Dann wäre es schlecht implementiert. Ein ESP32 hat ja extra zwei Partitionen dafür, da sollte ein CRC Check genau sowas absichern.
nun in der App steht unter Firmwareaktualisierungen das es noch ein "work in Progress" sei. Was passiert denn genau bei einem "Send Reboot OTA? Wird dann die Binary aus dem Internet per WLan, oder 4G/5G geholt und gleichzeitig per BT aufs Gerät geschrieben? Wie läuft das genau ab?
Hätte ich auch gedacht, aber: habe keine Lust mich damit zu beschäftigen. Kurze Unterhaltung mit Gemini: Das Board wird mit einem eigens dafür vorgesehenen BLE-Bootloader neu gestartet (OTA-Bootloader). Dort kann dann der Meshtastic BLE Flasher im Chrome-Browser (oder die Android App) direkt flashen. Die OTA-Slots des ESP32 werden nicht genutzt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.