ESP32 C3 WROOM 02 - nativ USB

[Alex Z. (alexander_z49)]

Hallo,

ich habe eine Frage zum ESP32 C3 WROOM 02.

Im Datenblatt ist eine native USB2.0 Schnittstelle aufgeführt. Somit 
sollte es doch möglich sein ohne einen USB/UART Konverter den Chip 
direkt am USB Port zu betreiben. Leider finde ich im Netz z.B. bei den 
Dev-Boards immer nur den Aufbau mit USB/UART und keine 
Schemata/Schaltungsbeispiele bei denen es direkt angeschlossen ist. 
Werden hier einfach nur Entwicklungskosten gespart, da der Chip mir den 
Vorgängern kompatibel ist und man sich den Entwurf eines neuen Boards 
sparen will oder hat das einen anderen Grund?

LG Alex

[Gerald B. (gerald_b)]

Alex Z. schrieb:
> Leider finde ich im Netz z.B. bei den
> Dev-Boards immer nur den Aufbau mit USB/UART und keine
> Schemata/Schaltungsbeispiele bei denen es direkt angeschlossen ist.

Das hat einen einfachen Grund. USB arbeitet mit einer Adressierung 
(verschiedene IDs) um ein Gerät gezielt anzusprechen. Der PC weiß anhand 
der IDs, z.B. das gerade eine Maus oder ein Speicherstick angesteckt 
wurde. Diese IDs werden bei einem Controller in der Firmware abgelegt, 
eben damit der Controller in verschiedenen Produkten verbaut werden kann 
und jeder Kunde seinen eigenen Treiber dafür verwenden kann.
Eben das ist bei einem Controller ohne Firmware nicht der Fall. Somit 
ist die in Hardware vorhandene USB Schnittstelle zu dem Zeitpunkt noch 
garnicht ansprechbar. Flashen über OTA funktioniert ja auch nur als 
Update und nicht mit leerem Chip, obwohl WLAN in Hardware schon 
vorhanden ist ;-)

[Alex Z. (alexander_z49)]

Hm, das ergibt Sinn. Ich habe bisher immer mit den Dev-Boards gearbeitet 
und dann µPython per COM-Port geflasht. Da ist natürlich der CP2102 
schon mit einer Firmware versehen, damit das BS das Board sieht. D.h. 
damit der native USB-Port genutzt werden kann zum Programmieren, müsste 
über ISP oder JTAG erstmal µPython oder eine andere FW auf die MCU und 
dort schon die Vendor ID und die entsprechenden Einstellungen rein.

[P.S. (Gast)]

Die eingebaute USB-Schnittstelle des ESP32-C3 ist nicht frei 
programmierbar. Nur USB-Seriell oder USB-JTAG (eingebaute 
USB-to-JTAG-Engine !!!) ist möglich.

Hier ein paar Infos bzgl. JTAG:
https://visualgdb.com/tutorials/esp32/esp32-c3/

Der openocd-Fork auf Espressifs Github-Account enthält den passenden 
Treiber.

[Arno (Gast)]

Ich würde es trotzdem mal probieren - besorg dir ein USB-Kabel, schneid 
es durch und klemm es auf die Pins entsprechend der Anleitung: 
https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/usb-serial-jtag-console.html

Dann schaust du:

a) Ob dein Betriebssystem ein USB-Gerät erkennt (dazu muss vermutlich 
eine Firmware laufen, die das aktiviert hat)
und wenn nicht
b) Ob dein Betriebssystem ein USB-Gerät erkennt, wenn du den ESP32-C3 im 
Firmware-Download-Modus startest (GPIO9 auf Masse ziehen und Chip 
resetten)

Wenns funktioniert: Für "richtige" Geräte packst du dann auf die Platine 
noch 2x 27R Serienwiderstand und 2x 22p Dämpfung (oder so ähnlich - 
steht im Datenblatt).

Beim ESP32-S2 funktioniert Methode b) - ich hab schon über hundert neue 
ESP32-S2-WROOM so geflasht.

Wie gesagt, einen Versuch wäre es mir wert. Wenn a) funktioniert und b) 
auch, würde ich auch testweise eine Firmware flashen, die USB 
deaktiviert, so dass a) nicht funktioniert, und dann b) testen - wenn es 
dann immer noch klappt, stehen die Chancen IMHO gut, dass es bei jedem 
-C3 klappt.

MfG, Arno

[Alex Z. (alexander_z49)]

Hab mich jetzt nochmal im Netz durchgewühlt. Werde mir Morgen einen 
Adapter bauen von USB auf Leitungsende mit Einspeisung für die 3,3V aus 
dem Labornetzteil. Das was mir  P.S. geschrieben hat, hat mir bei der 
Suche geholfen. Ich muss das USB CDC ansprechen und dann sollte es so 
funktionieren, wie  Arno das bei Option b) geschrieben hat. Es ist hat 
kein USB-device, sondern eine Serielle Schnittstelle zum flashen. Das 
würde mir schon ausreichen.

[Alex Z. (alexander_z49)]

So kleines Update:

Nach einem kleinen Wackelkontakt, tauscht der ESP32-C3 im 
Firmware-Download-Mode, als auch im SPI-Boot-Mode nun im Windows auf.

Den Flash konnte ich über das/die esptools löschen und auch schreiben, 
siehe Bilder.

Windows nervt nur immer, dass für das Gerät keine Informationen gefunden 
wurden, aber how cares.

Wo ich mir nicht ganz sicher bin, ist die Startadresse für die Firmware. 
Habe auf einer Seite gelesen, dass beim ESP32-C3 bei 0x0000 und nicht 
bei 0x1000 angefangen werden muss. Kann mir das wer bestätigen?

Ob die REPL vom µPython mit der nativen USB Seriel-Schnittstelle funzt, 
werde ich morgen mal testen. Als nächstes steht dann noch der Test der 
Anwendung an, ob WiFi und co gehen.

LG Alex

[Arno (Gast)]

Danke für die Rückmeldung, schön dass es funktioniert :)

Alex Z. schrieb:
> Wo ich mir nicht ganz sicher bin, ist die Startadresse für die Firmware.
> Habe auf einer Seite gelesen, dass beim ESP32-C3 bei 0x0000 und nicht
> bei 0x1000 angefangen werden muss. Kann mir das wer bestätigen?

Ich mach mir das bei solchen Fragen einfach: Firmware-Download über die 
Arduino-IDE, alle Meldungen anzeigen lassen und den Aufruf von esptool 
daraus kopieren / analysieren.

MfG, Arno

[Volkmar S. (Gast)]

Richtig, der RISCV-Kern des ESP32-C3 benötigt den Bootloader ab Adresse 
0. Alles andere, Partition bei 0x8000 und Firmware bei 0x10000 ist wie 
bei den "größeren" XTENSA ESP32 gleich.

Die USB-Schnittstelle lässt sich übrigends hervorragend auch aus der 
Software als CDC-Port benutzen. Suche mal in der ESP-IDF nach 
Funktionen, die mit "usb_serial_jtag" beginnen.

Leider sind aber nur RX/TX-Funktionen möglich. Funktionen wie 
CDC_SET_LINE_CODING, CDC_SET_CONTROL_LINE_STATE, CDC_SEND_BREAK werden 
nicht unterstützt. Auch ist es nicht möglich, die USB-Descriptoren zu 
ändern um
eigene USB-VID/PID einzutragen.

Leider sind die USB-Register im Reference-Manual des ESP32-C3 nicht 
aufgeführt, so ist es derzeit leider unmöglich, eigene 
LOW-Level-Routinen zu schreiben, wie es z.B. beim ESP32-S2 möglich ist.

LG
Volkmar

[Alex Z. (alexander_z49)]

So noch ein kurzes Update mit dem Workflow bisher.

Für den ESP32-C3 gibt es auf der µPython Downloadseite 2 Versionen:

1. ESP32-C3
2. ESP32-C3_USB

Die Version 1 scheint für Dev-Boards mit USB-UART-Chip zu sein, hier 
gibt es schon einen stable release. Hatte am Anfang diesen benutzt, 
damit lies sich über putty aber keine Eingabe durchführen.

Die Version 2 ist scheinbar für den bare-chip und direktem Anschluss an 
USB. Hier gibt es bisher nur nightly-builds.

ESPTool habe ich auf Version 3.2 geupdatet, da hier der esp32c3 explizit 
aufgeführt ist und die Meldung mit "chip is unknown" nicht mehr 
erscheint.
Wie oben von Volker beschrieben, ist es wichtig als Startadresse 0x0 zu 
verwenden, ansonsten wird beim Verbinden über COM "invalid field 
0xffffffff" als Meldung übertragen und der Chip bootet nicht richtig.

Nach dem Flashen kann dann die Verbindung aufgebaut werden. Je nach dem, 
ob der Chip einmal hart resettet wurde oder nicht erscheint die Meldung 
"ESP-ROM:esp32c3-api1-20210207" durch Eingabe der Enter-Taste, startet 
die REPL. Verbindet man sich gleich nach dem Flashen drauf wird 
angezeigt, dass der Chip initialisiert wurde.

Wie von Volker ebenfalls beschrieben, handelt es sich um eine reine 
serielle USB Verbindung (vCom), im Windows HW-Manager wird zwar was 
erkannt, aber kann nicht identifiziert werden, die Kommunikation geht 
aber trotzdem. Vllt. kommt das in Zukunft mal noch, stört mich 
persönlich aber nicht.

@Volker die ESP-IDF habe ich bisher nicht verwendet. Ich habe die 
µPython Scripte immer mit ampy übertragen. Ob das hier auch geht, werde 
ich morgen testen.

Vllt. hilft dem Einen oder Anderen die Beschreibung ja.

LG Alex

[Alex Z. (alexander_z49)]

Update:

Auch ampy (Adafruit MicroPython) zum Hochladen der Scripte auf den ESP 
funktioniert sehr gut. WMir ist noch aufgefallen, dass man den ESP 
scheinbar nicht in den Download-Mode versetzen muss, um Daten zu 
schreiben oder eine FW zu flashen. Warum weiß ich aber auch nicht.

So das wars dann hier würde ich sagen.

LG Alex

[Marc H. (march)]

Alex Z. schrieb:
> Mir ist noch aufgefallen, dass man den ESP
> scheinbar nicht in den Download-Mode versetzen muss, um Daten zu
> schreiben oder eine FW zu flashen.

Die Daten die da per USB übertragen werden beinhalten ja nicht nur die 
gesendeten Daten sondern auch die zustände der Steuerleitungen.
Auf vielen Baords funktioniert der automatische Upload so das zwei 
dieser Steuersignale auf den Reset und den Boot Pin gezogen werden und 
so der Programmer den Chip in den Modus zum flashen versetzt.
Meine Vermutung ist das diese Signale im C3 auch abgegriffen werden um 
so zu erkennen das er in den Modus wechseln soll.

Für eine genauere Beschreibung der Schnittstelle mal nach RS232 suchen.

Gruß Marc

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Alex Z. schrieb:
> Update:
>
> Auch ampy (Adafruit MicroPython) zum Hochladen der Scripte auf den ESP
> funktioniert sehr gut. WMir ist noch aufgefallen, dass man den ESP
> scheinbar nicht in den Download-Mode versetzen muss, um Daten zu
> schreiben oder eine FW zu flashen. Warum weiß ich aber auch nicht.
>
Das Flashen erfolgt ueber Jtag und nicht den Bootloader.

[Alex Z. (alexander_z49)]

Hallo

Marc H. schrieb:
> Auf vielen Baords funktioniert der automatische Upload so das zwei
> dieser Steuersignale auf den Reset und den Boot Pin gezogen werden und
> so der Programmer den Chip in den Modus zum flashen versetzt.

Bei meinem Testaufbau ist nicht viel mit Steuerleitung ;) siehe Bild.

Uwe B. schrieb:
> Das Flashen erfolgt ueber Jtag und nicht den Bootloader.

Ja, bei den DevBoards mit ESP32, mit denen ich bisher gearbeitet habe, 
ging das Flashen und Laden von Dateien immer erst, nach einem Reboot und 
wenn der Code noch nicht ausgeführt wurde.

Wie dem auch sei, das macht es sehr viel angenehmer so zu arbeiten. 
Anschließen, Batch ausführen, einmal den Chip mit einem soft-reset neu 
starten und gut ist.

[Stefan F. (Gast)]

Alex Z. schrieb:
> 20220114_164616.jpg

Ich sehe dass du noch eins der alten hochwertigen Steckbretter hast. 
Wenn deine Kabel ebenso gut sind, hast du wahrscheinlich kein Problem.

Das was heute allgemein verkauft wird, ist jedoch leider nicht gut 
genug. An den dünnen Eisen/Alu Kabeln und Kontakten fällt unter Last zu 
viel Spannung ab. Die Stromaufnahme des Moduls springt beim Senden auf 
500 mA hoch. Es will für stabilen Betrieb maximal 100 mV Ripple haben -> 
also dürfen die Leitungen und Kontakte der Stromversorgung insgesamt nur 
0,2 Ohm haben.