zuerst BOOT runterziehen, danach Reset

Kann ich die Abfolge Softwareseitig ändern, oder muss ich IO0 und Reset am UMH3N Q5 austauschen ?

Ich habe schon versucht Boot permanent runterzuziehen um dann so zu programmieren, aber das hat auch nicht geklappt. Braucht der ESP die negative Flanke um in den Modus zu kommen ?

Normaler Programiermodus: zuerst Boot runter, dann Reset runter, dann Boot wieder hoch, dann Reset wieder hoch. Wie Du das machst bleibt Dir überlassen, es zählt was an den Eingängen des ESP ankommt.

Normaler Programmstart: einfach Spannung ran, ggf Reset runter und wieder rauf, Boot bleibt unangetastet hoch.

Ok dann versuche ich dass mal so hinzubekommen.

Da einzige was mich noch irritiert ist das ich die Debug Nachrichten nicht bekomme wenn der ESP mit Spannung versorgt wird. Normalerweise würde ich ja auf UART0 so eine Meldung über UART0 bekommen, außer MTD0/GPIO15 ist low gezogen.

1

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

2

configsip: 0, SPIWP:0x00

3

clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

4

mode:DIO, clock div:1

5

load:0x3fff0008,len:8

6

load:0x3fff0010,len:160

7

load:0x40078000,len:10632

8

load:0x40080000,len:252

9

entry 0x40080034

In der Schaltung ist am GPIO15 nichts dran, beim nachmessen liegt der auch auf 3V3. GPIO2 bzw GPIO12 liegen auch auf 0. Liege ich dann richtig dass ich eigentlich so eine Bootmessage bekommen müsste ?

Stephan S. schrieb:

Normaler Programiermodus: zuerst Boot runter, dann Reset runter, dann Boot wieder hoch, dann Reset wieder hoch. Wie Du das machst bleibt Dir überlassen, es zählt was an den Eingängen des ESP ankommt.

Das stimmt nicht ganz. Der ESP prüft beim Booten ob GPIO-0=GND ist. Wenn ja dann springt er in den Programmiermodus, wenn nein bootet er normal. (Siehe technical-documents ) Das heißt es sind diese Schritte notwendig:

1. GPIO-0 auf GND und so belassen
2. Reset auf GND
3. Reset loslassen --> der ESP bootet und springt in Programmiermodus
4. Programmieren
5. GPIO-0 loslassen
6. Reset auf GND
7. Reset loslassen --> der ESP bootet und bleibt in Normalmodus

Anmerkung: man könnte GPIO-0 auch schon während Schritt 4 loslassen, aber meiner Erfahrung nach funktioniert das Programmieren stabiler wenn man GPIO-0 auf GND hält bis die komplette Programmierung abgeschlossen ist.

Auf meinen Custom Boards habe ich diesmal keine Taster vorgesehen, die ich zum programmieren drücken kann. Ich habe mich relativ nahe an dem Reference Design "esp32-devkitc-v4" von esspressif orientiert und die Schaltung so aufgebaut. Wenn ich die Wahrheitstabelle untenrechts mit den gemessenen Werten vom Logic Analyser vergleiche, stimmt das mit dem überein, also :

1

EN IO0/Boot

2

1    1

3

1    1

4

0    1

5

1    0

Momentan sieht es aus, dass aus irgendeinem Grund der TX0 nichts sendet. Selbst wenn ich den DIP Schalter komplett auslasse und direkt am pin1 das Oszi dranhänge, bekomme ich keine Ausschläge angezeigt. Eigentlich erwarte ich ja die oben erwähnte Debug Meldung sobald der ESP Spannung bekommt, unabhängig ob ich mein Programm schon flashen konnte oder nicht.

Mit einer 0 an GPIO12 legt der ESP nur 1,8V VCC an den internen FLASH-Baustein. Dann bootet der nicht mehr. Kannst du dein Signal "Ready" abklemmen oder auf 1 legen? Ebenso ist die Versorgung aus einem Schaltregler ohne RESET-Chip etwas fragwürdig. Der Regler braucht einige ms, bis die Spannung stabil ist. Erst danach sollte der ESP-Reset losgelassen werden. Wenn die Spannungsversorgung stabil ist, nochmal einen Reset ausführen und GPIO12 auf 1 lassen. Danach kann man eine Fuse programmieren, dass der Pin12 keine Umschaltung mehr macht (COM-Port natürlich anpassen):

esptool.py --port com3 --chip esp32 erase_flash

Ausgabe dabei sollte so aussehen:

Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: xxxxxx Uploading stub... Running stub... Stub running... Erasing flash (this may take a while)... Chip erase completed successfully in 1.5s

Wenn hier 0.0s stehen, dann ist der Flash-Speicher gesperrt!

Wahrscheinlich durch schwankende Versorgungsspannung setzen sich beim Ausschalten/Abstecken wohl manchmal einige Bits... Unten stehender Befehl setzt die Statusbits zurück, danach sollte der ESP32 wieder überschreibbar sein.

Statusbits des FLASH zurücksetzten:

esptool.py --port com3 write_flash_status --bytes 3 --non-volatile 0

Ergebnis sollte ähnlich aussehen:

Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: xxxxxxxx Uploading stub... Running stub... Stub running... Initial flash status: 0x205200 <<< vorher Setting flash status: 0x000000 <<< neuer Wert After flash status: 0x001000 <<< Nachher, 1 Bit bleibt gesetzt Hard resetting via RTS pin...

Versorgungsspannung des FLASH auf 3,3V festlegen (ACHTUNG GEHT NUR EINMAL!)

espefuse.py set_flash_voltage 3.3V -p com3