ESP32-S3 DevKitC-1 N16R8 statt ESP32-S3-WROOM-1-N16R2 möglich?

[Baxxy13]

Hi,
ich hatte hier noch ein ESP32-S3 DevKitC-1 N16R8 samt USB-OTG-Adapter rumliegen und wollte das RFNETHM mal mit einem HmIP-RFUSB testen.

Flashen verlief problemlos und auf die WebUI komme ich auch.
Leider wird aber mein HmIP-RFUSB nicht erkannt.

  903546I (903546) src-usb: open 1B1F:C020 (vendor-specific) ...
  908546W (908546) src-usb: open failed: ESP_ERR_NOT_FOUND — retry in 2s
  910546I (910546) src-usb: open 1B1F:C020 (vendor-specific) ...
  915546W (915546) src-usb: open failed: ESP_ERR_NOT_FOUND — retry in 2s
  917546I (917546) src-usb: open 1B1F:C020 (vendor-specific) ...
  922546W (922546) src-usb: open failed: ESP_ERR_NOT_FOUND — retry in 2s

Die Frage wäre jetzt ob das eher an meinem ESP32-S3 DevKitC-1 N16R8 (statt wie angegeben YD-ESP32-S3 V1.4 / ESP32-S3-WROOM-1-N16R2) oder an meinem USB-OTG-Adapter liegen könnte?

[tostmann]

Hi @Baxxy13, danke für den ausführlichen Bericht mit Log — und vorweg: am N16R8 liegt es mit sehr hoher Wahrscheinlichkeit nicht.

Kurz, warum das Modul hier ausscheidet: Der USB-Host-Pfad des ESP32-S3 hängt fest an GPIO19 (D−) / GPIO20 (D+) — den dedizierten USB-OTG-Pins, unabhängig von Flash-/PSRAM-Größe. PSRAM ist im RFNETHM-Build ohnehin aus (# CONFIG_SPIRAM is not set), d. h. die 8 MB Octal-PSRAM des R8 liegen einfach brach. Die Firmware sucht denselben Stick (1B1F:C020) unabhängig von der Modulvariante — N16R8 statt N16R2 ändert daran nichts.

Was die Meldung sagt: open failed: ESP_ERR_NOT_FOUND bedeutet, dass auf dem USB-Bus aktuell kein Gerät mit dieser VID:PID angemeldet ist. Der 5-Sekunden-Takt (open → nach 5 s NOT_FOUND → 2 s Pause → neuer Versuch) ist genau die „ich warte, dass ein 1B1F:C020 auftaucht"-Schleife. Der ESP ist gesund, er sieht nur keinen Stick.

Der wahrscheinlichste Grund ist die zweite von dir genannte Option — die VBUS-Versorgung des Sticks über den OTG-Port. Wichtig dabei: Die 5 V für ein Gerät am nativen USB-Port sind bei den meisten S3-Boards nicht automatisch aktiv. Bei den gängigen DIY-/Nachbau-Boards (u. a. dem als Referenz genutzten YD-ESP32-S3 V1.4) muss man dafür eine Lötbrücke auf der Platinenrückseite schließen — ab Werk ist sie offen, und ohne sie liegt am OTG-Port kein 5 V an. Ohne VBUS meldet sich der HmIP-RFUSB gar nicht erst am Bus an → exakt dein NOT_FOUND-Loop.

Zum Eingrenzen:

1. VBUS prüfen: Bekommt der HmIP-RFUSB Strom, wenn er über den Adapter am Board steckt (Power-LED am Stick)? Wenn nein → Versorgungs-/VBUS-Problem, nicht das Board.
2. VBUS-Brücke: Schau auf die Rückseite deines Boards, ob es dort einen 5 V-/VBUS-Lötjumper am USB-Port gibt, und schließe ihn. Bei den DIY-S3-Boards ist genau das der Schritt, der den OTG-Port mit Strom versorgt.
3. Falls es ein originales Espressif-DevKitC-1 ist: dessen nativer USB-Port gibt laut Espressif keine 5 V nach außen („the esp32-sx-devkitC board can not output 5V through USB port") und hat keine solche Brücke — dann die 5 V extern zuführen (OTG-Y-Kabel mit Einspeisung oder aktiver USB-Hub mit eigenem Netzteil).
4. Danach neu ins Log schauen: steht dort statt NOT_FOUND ein open ok — running CP210x init, war der N16R8 nie das Thema.

Falls der Stick nachweislich Strom bekommt und es trotzdem bei NOT_FOUND bleibt, schauen wir als Nächstes, mit welcher VID:PID sich dein Exemplar tatsächlich meldet. Sag gern Bescheid, was Schritt 1 und 2 ergeben.

[Baxxy13]

Hi,
danke für die sehr aufschlussreiche Rückmeldung.
Und um es kurz zu machen: Es war die fehlende USB_OTG - Lötbrücke auf der Unterseite.

Der RFNETHM läuft aktuell (mit HmIP-RFUSB) und einer "angedockten" OpenCCU - Testinstanz.
Das werde ich jetzt erstmal ein paar Tage beobachten.

Auf jeden Fall ein interessantes Projekt. 👍

[tostmann]

Freut mich, dass es läuft 👍 Viel Erfolg beim Beobachten mit der OpenCCU-Instanz — und wenn dir dabei etwas auffällt, freuen wir uns über jedes Feedback von echter Hardware.