Closed thb584Git closed 2 weeks ago
Draht an Pin20 darf die Funktion nicht stören, am seriellen Monitor sollte Informationen ausgegeben werden wie die bei einem ESP32 WEMOS Mini der Fall ist
Es ist leider nicht möglich alle Hardware und Verkabelungsfehler per Software abzufangen. Ein Draht darf RF Probleme sehr wohl stören. Es ist ja kein Filter vorhanden. Diese Hardware müsstest du aufbauen. Wenn der Fehler so tiefgreifend ist, dass keine Serielle Ausgabe möglich ist, dann startet die Software auch nicht. Was soll es dann da zu diagnostizieren geben?
Sorry, bitte alles lesen. Wenn ich den Pin gegen GND oder VCC klemme bleibt der Fehler, da darf der Draht auf keinen Fall stören. Aufgangspunt war sowieso über Pinleiste direkt eingesteckt in Lochlasterplatte das ist ein normaler Aufbau, Nichts angeschlossen an Pin 20.Das Kabel als Test kam erst später. Soll ich ein Foto hochladen vom Aufbau? Die Frage wäre hat jemand dieses Modul im Einsatz? Der Pin 20 RxD geht direkt auf den Pin 27 U0RCD des ESP32C3. Wird diese Schnittstelle in der SW initialsiert?
@thb584Git das oben gezeigte Modul hat lediglich 16 PINs. Du müsstes klären welches pin_mapping initial aktiv ist und welche GPIOs bei Deinem ESP32-C3 auf welchem Pin nachvaußem geführt werden.
Vielleicht hat ja wirklich noch jemand einen ESP32-C3 im Einsatz. Waren das nicht die neuen RISC Modelle mit anderem Kern ?
Mein Fehler, nicht Pin20 sondern GPIO20. Da ist eine 21 am Pinda runter aufgedruckt für GPIO21.
Pin Mapping ist eigentlich egal weil das Problem ohne jede Beschaltung (außer halt GPIO20) bereits nach dem initialen flashen auftritt. Mein Mapping (damit funktioniert die DTU auch) solange das Modul über USB versorgt wird und man GPIO20 in Ruhe läßt.
[ { "name": "CMT2300A", "nrf24": { "miso": -1, "mosi": -1, "clk": -1, "irq": -1, "en": -1, "cs": -1 }, "cmt": { "clk": 6, "cs": 10, "fcs": 7, "sdio": 2, "gpio2": -1, "gpio3": -1 }, "eth": { "enabled": false } } ]
Ja richtig, da da ist ein RISC-V single-core drin.
Ich hänge mal die Doku mit schematic die ich dazu habe an. Ist das erste mal dass ich den verwende. Ist halt super klein und hat alles für die openDTU. Habe übrigens noch ein zweites Exemplar getestet - gleiches Verhalten.
ESP32-c3 super-mini - WWW.pdf
Um Missverständnisse zu vermeiden doch zwei Fotos: so läuft der chip hoch, ich kann auf die Webpage zugreifen
So ist kein Web-Zugriff möglich:
Nur der Pin von GPIO20 steckt im Sockel auf einer Lochrasterplatine der Sockel ist nicht verdrahtet nur eingelötet. Ziehe ich das Modul heraus kann ich kurze Zeit später auf die webpage zugreifen.
Update:
Der Chip braucht in der platformio.ini folgende Einträge damit das serielle Interface ausgelesen werden kann: monitor_speed = 115200 upload_speed = 921600 build_flags = -D ARDUINO_USB_MODE=1 -D ARDUINO_USB_CDC_ON_BOOT=1
ein blink und ein wifi scan mit dem Chip funktionieren. Dabei tritt das Verhalten mit GPIO20 nicht auf
In der platformio.ini der openDTU ist der Eintrag für der ESP32-c3 auch drin sieht aber so aus:
build_flags = ${env.build_flags} -DARDUINO_USB_MODE=1 -DARDUINO_USB_CDC_ON_BOOT=1
Ich bekomme die Ausgaben am Monitor allerdings nur wenn ich mich mit Coolterm verbinde, im Monitor von VCC/PIO sehe ich nur die "Disable search for AP...done" alles davor fehlt. Mir den Testprogrammen hingegen funktioniert auch die Ausgabe in VSC/PIO. Das Problem mit GPIO20 besteht weiterhin.
Vielleicht kann da mal ein SW-Experte mal draufschauen.
Ich hatte den ESP32-C3 Super Mini bisher schon in einigen anderen Projekten verwendet, aber noch nie mit OpenDTU. Da ich aber noch ein paar Exemplare da habe, dachte ich mir, ich probiere das einfach mal aus.
Ich habe das ESP32-C3-Modul daher einfach in ein Experimentier-Board gesteckt, das alle Pins auf Stiftleisten nach außen führt, auch GPIO20.
Dann habe ich die aktuelle OpenDTU aus github (v24.10.15) mit PlatformIO mit dem Eintrag [env:generic_esp32c3_usb]
unverändert gebaut und per Espressif ESP Flash Tool unter Windows geflasht. Ich kann den Fehler nicht nachvollziehen, das Board funktioniert so weit einwandfrei. Einen CMT2300A habe ich bislang nicht angeschlossen, habe aber dafür eine Prototypen-Platine entworfen und in Fertigung gegeben (ist noch nicht da), damit ich sehen kann, ob auch die Funkkommunikation funktioniert, aber bis jetzt kann ich den Fehler leider nicht reproduzieren.
Übrigens: Mit -DARDUINO_USB_MODE=1
und -DARDUINO_USB_CDC_ON_BOOT=1
kommen die seriellen Ausgaben über USB an, nicht mehr über GPIO20/21:
E (344) esp_core_dump_flash: No core dump partition found!
Initialize Display... done
Initialize LEDs... done
Check for default DTU serial... done
Initialize Hoymiles interface... Invalid pin config
Switch to WiFi mode
Configuring WiFi STA using new credentials... done
Configuring WiFi STA DHCP IP... done
WiFi connected
WiFi got ip: 192.168.xxx.yyy
Network connected
Admin AP remaining seconds: 10 / 180
...
Herzlichen Dank für Deine Mühe, das ist mehr als ich erwarten konnte. Also ich habe das gleiche breakout-board auch hier und gerade damit mal getestet - und zu meiner Überraschung die FW läuft hoch, Das DTU-WLAN ist erreichbar die Webseite lädt. Nun Ist die Frage warum es damit funktioniert. Könntest Du vielleicht noch folgenden Test machen: Einfach ein Stück Buchsenleiste nur an Pin 20 anstecken. Bei mir verschwindet dann das DTU-WLAN, Kommt auch nach einen Reset nicht. Erst wenn ich die Leiste wieder abziehe und spätestens nach Reset läuft die FW wieder hoch. Wie im Foto zu sehen auch mit pullup an Pin20 (ist sogar 1k). Unsere ESP32-C3 boards scheinen mir, soweit ich das auf dem Foto beurteilen kann zwar sehr ähnlich, aber nicht 100% identisch. Ich werd mal schaun ob ich einen Stromlauf zu dem breakout board finde und das Datasheet zum C3 ansehen ob der noch irgendwo ein pullup/-down braucht.
Leider bin ich nicht in der Nähe von meinem Labor-Arbeitsplatz, den Effekt einer Buchsenleiste könnte ich erst am Wochenende testen. Ich hoffe, ich denke dran. Aber ich habe mal kurz ein Stück Kabel, das ich hier herumliegen hatte, an GPIO20 angesteckt. Das ändert bei mir nix, WLAN bleibt up, Web Interface ist weiterhin erreichbar.
Ich kann auch mal sehen, ob ich irgendwo einen Schaltplan vom Breakout-Board habe. Ein paar Infos dazu gibt es jedenfalls hier. Viel ist es aber nicht.
Einen Schaltplan für das Breakout-Board habe ich nicht gefunden, aber ich habe gemessen:
Es gibt also keine Pull-Up-/Pull-Down-Widerstände auf dem Breakout-Board. Einige Mutmaßungen zum Breakout-Board gibt es hier. Aber das ist mit Vorsicht zu betrachten:
Aber das Teil ist trotzdem irgendwie suspekt:
Damit bin ich wieder am Ausgangspunkt:
Sorry für den langen Text. Fazit:
Auch ich wäre dafür, den Bug zu schließen (habe ihn ja nicht reproduzieren können) und diese Diskussion ggf. woanders, z.B. in Discussions weiterzuführen, falls das hilfreich erscheint.
Ich habe mal noch einen Test mit Debugger an der seriellen Schnittstelle (pin20&21) gemacht (build generic_espc3). Getestet mit Stromversorgung über USB bzw. DC/DC an 3,3V Pin. Ergebnis:
Ich mach den case zu, wenn Deine Module sich anders verhalten liegts an meiner HW. Die openDTU-FW würde ich ausschliessen, Werd mal Module aus anderer Quelle bestellen.
Problem nicht openDTU-FW relevant. Ursache HW möglicherweise Modultyp spezifisch.
Was passiert denn, wenn Du einfach mal [env:generic_esp32c3_usb]
baust, flashst und schaust, welche Meldungen über USB so ankommen?
Naja hängt von der Beschaltung ab, also mit dem zusätzlichen Stürzkond kommt der AP hoch:
Starting OpenDTU
Initialize FS... done
Reading configuration... done
Reading PinMapping... [ 364][E][vfs_api.cpp:105] open(): /littlefs/pin_mapping.json does not exist, no permits for creation
using default config done
Initialize Network... done
Setting Hostname... Initialize NTP... done
Initialize SunPosition... done
Initialize MqTT... done
Initialize WebApi... done
Initialize Display... done
Initialize LEDs... done
Check for default DTU serial... done
Initialize Hoymiles interface... Invalid pin config
Switch to WiFi mode
Setting Hostname... done
Disable search for AP... done
Websocket: [/livedata][1] connect
Websocket: [/livedata][1] disconnect
Websocket: [/livedata][2] connect
Allerdings seh is das ganze nur über putty oder coolterm im VSC monitor bekome ich dies:
--- Logging an output to E:\Privatdaten\thomas\PioProjects\OpenDTU\logs\device-monitor-241109-204106.log
Esp32ExceptionDecoder: firmware at e:\Privatdaten\thomas\PioProjects\OpenDTU\.pio\build\generic_esp32\firmware.elf does not exist, rebuild the project?
Please build project in debug configuration to get more details about an exception.
See https://docs.platformio.org/page/projectconf/build_configurations.html
--- Terminal on COM14 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
20:41:32.074 > Disable search for AP... done
Wobei mir diese Exception erst jetzt aufgefallen ist.
Ohne Kondensator, auf der Platine oder etwas an Pin20 bekommt man auch noch das "Disable search for AP... done" aber es wird gar kein AP aufgebaut oder wenn man versucht sich damit zu verbinden schlägt das fehl und er AP verschwindet.
What happened?
Testaufbau ESP32-C3 Super Mini fliegend zu mit CMT2300A mit Jumperwire verbunden funktioniert. Prototypplatine aufgebaut mit fester Verdrahtung. ESP und CMT in Stecksockeln. Aufbau funktioniert nicht. Webseite ist nicht erreichbar Analyse: es reicht wenn man am ESP32-C3 Super Mini ohne angeschlossenes CMT2300A an Pin 20 ein kurzes Jumper Wire ansteckt das am anderen Ende nicht verbunden ist. Alternativ tritt der gleiche Effekt auf wenn jediglich Pin 20 in eine Lochrasterplatte gesteckt wird. Auch hier ohne Verbindung. Webseite ist nicht verfügbar bzw. WLAN AP wird nicht aufgebaut.
Vermutung RF Störung eingefangen deshalb Pin20 mit Pullup/Pulldown geklemmt, aber ohne Änderung. Es scheint ein Problem mit der seriellen Schnittstelle vorzuliegen, Die USB-Porterkennung am Win10-PC dauert sehr lange, irgendwann taucht der Port dann in Deview auf. Auf der seriellen Konsole kommen aber keine Daten - auch im "Gutfall" wenn die Webseite verfügbar ist.
Ein weiter
To Reproduce Bug
ESP32-C3 Super Mini flashen mit letzter Version V24.10.15. Das Modul alleine starten. Der ESP WLAN Hotspot erscheint. An Pin20 kurzes Jumper Wire anstecken. Nach Reset erscheint der WLAN Access Point nicht mehr. OpenDTU startet nicht meht, Webseite kann nicht mehr geladen werden, bzw. WLAN nicht verfügbar.
Expected Behavior
Draht an Pin20 darf die Funktion nicht stören, am seriellen Monitor sollte Informationen ausgegeben werden wie die bei einem ESP32 WEMOS Mini der Fall ist
Install Method
Self-Compiled
What git-hash/version of OpenDTU?
dc5eb96
What firmware variant (PIO Environment) are you using?
generic_esp32c3_usb und generic_esp32c3
Relevant log/trace output
Anything else?
Möglicherweise ist das Probem Modultyp spezifisch. Da es MIni und Super Mini Versionen gibt hier ein Foto dazu
Please confirm the following