ESP32 Caricare programmi senza premere BOOT

Per chi usa ESP32 e sin dal primo uso ha avuto problemi a caricarci uno sketch ricordo che dopo la compilazione su IDE Arduino, e quando appare il disegno . . . .. . . .____ bisogna premere il tastino BOOT.

Ora ci viene in aiuto anche una soluzione hardware che carica il programma su ESP32 senza aspettare di premere il pulsantino BOOT alla fine della compilazione del programma.
Si tratta di un condensatore elettrolitico da 10 uF (qualsiasi tensione sopra i 5 volt va bene, basta che sia piccolino) da saldare sul piedino EN e il GND proprio sopra al piedino, sul modulo ESP.
L’ho provato, funziona da subito.
Se volete, qui c’è l’articolo originale.

Io ci ho messo un piccolissimo condensatore elettrolitico 10uF 50v smd.

Stranissimo che i produttori di quelle schede non c'abbiano pensato ... :o :o :o

Che tu sappia, può avere qualche effetto collaterale ?

Guglielmo

Ho provato sulle mie board e funziona perfettamente.
Non mi aspetto nessun effetto collaterale perché è il pin dedicato al download degli sketch

E' spiegato anche qui

Automatic bootloader

esptool.py can automatically enter the bootloader on many boards by using the RTS and DTR modem status lines to toggle GPIO0 and EN automatically.

Make the following connections for esptool.py to automatically enter the bootloader:
ESP32 Pin Serial Pin
EN RTS
GPIO0 DTR

Note that some serial terminal programs (not esptool.py) will assert both RTS and DTR when opening the serial port, pulling them low together and holding the ESP32 in reset. If RTS is wired directly to EN then RTS/CTS "hardware flow control" needs to be disabled in the serial program to avoid this.

Development boards (including all Espressif boards) usually use additional circuitry to avoid this problem - if both RTS and DTR are both asserted together, this doesn't reset the chip. Consult Espressif development board schematics for the specific details.

(Some third party ESP32 development boards use an automatic reset circuit for EN & GPIO pins, but don't add a capacitor on the EN pin. This results in unreliable automatic reset, especially on Windows. Adding a 100nF (or higher) value capacitor between EN pin and GND may make automatic reset more reliable..)

Il problema, come dicono loro, potrebbe risiedere nell'IDE che non prepara adeguatamente ESP32 a ricevere il programma.

To be honest we’re not sure why that happens with the newer boards. We don’t have any ESP32 board with that behavior. We think there might be something different with your specific board or the Arduino IDE fails to send the right command sequence to put the ESP32 automatically in flashing/uploading mode.

Mai dovuto premere BOOT sul mio ESP32, mi chiedevo appunto a cosa servisse...

SukkoPera:
Mai dovuto premere BOOT sul mio ESP32, mi chiedevo appunto a cosa servisse...

A questo punto mi piacerebbe sapere che scheda è, così, per curiosità.
Si sono dimenticati un componente ? :smiley:

Comunque oggi avrò fatto una cinquantina di upload su ESP32 e mai un problema: la modifica è perfetta.

Mai dovuto premere BOOT sul mio ESP32, mi chiedevo appunto a cosa servisse…

Idem, mai premuto

link

ESP32 DEVKIT V1
www.doit.am

SukkoPera:
ESP32 DEVKIT V1
www.doit.am

Si, effettivamente leggevo su questo sito che non c'è bisogno di premere il pulsante..... :smiley: :smiley: :smiley:
E' un sito scritto in cinese, e non ho intenzione di impararlo!

Quello di Brunello22 è diversa dalla mia pur essendo un DEVKIT V1

La mia è identica a quella che hai linkato.

E ti pareva che mi è toccato il modulo sfigato :smiley:
mi chiedo perchè sulla questione esistano esperienze completamente diverse.
Gente che non l'ha mai fatto gente che lo ha fatto una volta e poi non ha dovuto più farlo, gente che se alcuni pin specifici sono collegati alla breadboard non riesce a caricare. assurdo.
Grazie per la dritta comunque.

gianlucaf:
...... gente che se alcuni pin specifici sono collegati alla breadboard non riesce a caricare.....

Si, sta succedendo proprio a me e devo scoprire quale è il pin incriminato collegando la ESP32 con cavetti MF alla board che ho realizzato e staccarne uno a uno per vedere come mai non mi carica...

Fatto tutte le prove del caso: Nella mia board, dove monto ESP32, ho una resistenza da 2k tra +3.3 e l'ingresso GPIO2 e solo se la porto a 10k ricomincia a funzionare.

Poi sono andato a cercare e ho visto questo:

Strapping Pins

The ESP32 chip has the following strapping pins:

    GPIO 0
    GPIO 2
    GPIO 4
    GPIO 5
    GPIO 12
    GPIO 15

These are used to put the ESP32 into bootloader or flashing mode. On most development boards with built-in USB/Serial, you don’t need to worry about the state of these pins. The board puts the pins in the right state for flashing or boot mode. More information on the ESP32 Boot Mode Selection can be found here.

However, if you have peripherals connected to those pins, you may have trouble trying to upload new code, flashing the ESP32 with new firmware or resetting the board. If you have some peripherals connected to the strapping pins and you are getting trouble uploading code or flashing the ESP32, it may be because those peripherals are preventing the ESP32 to enter the right mode. Read the Boot Mode Selection documentation to guide you in the right direction. After resetting, flashing, or booting, those pins work as expected.

Quindi occhio ad avere attaccato qualcosa a questi pin in fase di upload....

Select bootloader mode
GPIO0

The ESP32 will enter the serial bootloader when GPIO0 is held low on reset. Otherwise it will run the program in flash.
GPIO0 Input 	Mode
Low/GND 	ROM serial bootloader for esptool.py
High/VCC 	Normal execution mode

GPIO0 has an internal pullup resistor, so if it is left unconnected then it will pull high.

Many boards use a button marked "Flash" (or "BOOT" on some Espressif development boards) that pulls GPIO0 low when pressed.
GPIO2

GPIO2 must also be either left unconnected/floating, or driven Low, in order to enter the serial bootloader.

In normal boot mode (GPIO0 high), GPIO2 is ignored.
Other Pins

As well as GPIO0 and GPIO2, the following pins influence the serial bootloader mode:
GPIO 	Meaning
12 (MTDI) 	If driven High, flash voltage (VDD_SDIO) is 1.8V not default 3.3V. Has internal pull-down, so unconnected = Low = 3.3V. May prevent flashing and/or booting if 3.3V flash is used and this pin is pulled high, causing the flash to brownout. See the ESP32 datasheet for more details.
15 (MTDO) 	If driven Low, silences boot messages printed by the ROM bootloader. Has an internal pull-up, so unconnected = High = normal output.

Quindi meglio non connettere niente a GPIO0, GPIO2, GPIO12 e GPIO14 in fase di upload.

Ho avuto anch'io la brutta sorpresa di scoprire che debbo pigiare il bottoncino BOOT per caricare uno sketch.

Debbo dire che sono completamente privo di esperienza con l’ESP32; ne ho comperato uno avendo sentito grandi lodi su questo dispositivo, ma già l’acquisto è stato complicato, poiché non riuscivo a districarmi nella selva di produttori di schede di sviluppo. Alla fine ho comperato quello della Hiletgo, e temo che non sia stata la scelta migliore, vista l’assoluta mancanza di documentazione nel sito della Hiletgo. Anche l’installazione su IDE Arduino non è stata semplicissima, perché ho faticato a capire quale tra le innumerevoli schede ESP32 dovevo selezionare. Una volta superato questo scoglio, è comparso il fatidico messaggio:

Serial port COM5
Connecting............................_____...
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header.

Nella pagina di Github dedicata a espressif/arduino-esp32 è scritto:

Sometimes to program ESP32 via serial you must keep GPIO0 LOW during the programming process.

Anche qui non è immediato capire che per tenere low il GPIO0 bisogna pigiare il famoso bottoncino. Comunque a tentativi e spintoni ci sono arrivato, anche a capire che il bottoncino va pigiato quando compare il messaggio “Connecting….”

Tuttavia, che si debba intervenire manualmente per caricare uno sketch è intollerabile. Ho provato ad immaginare che fosse un problema dell’IDE Arduino, e ho caricato l’ambiente di sviluppo suggerito da Espressif (esp-idf), ma le cose non sono cambiate molto: alcuni sketch caricano, altri no; e lo stesso sketch, alcune volte si, altre volte no. È evidente che c’è una criticità circuitale e/o di configurazione dei tools.

La soluzione segnalata da Steve-cr mi solleva qualche perplessità, perché io, senza dettagliate informazioni sulla circuiteria sottostante, non connetterei mai un condensatore così grosso ad un ingresso logico. Il suo effetto è quello di rallentare i fronti dei segnali e se la capacità è grossa, li potrebbe rallentare oltre il consentito. Spesso le specifiche degli integrati dichiarano il limite massimo per il tempo di transizione dei segnali, perché un segnale lento lascia più a lungo i transistor in zona lineare, dove assorbono più corrente del normale, provocandone l’invecchiamento prematuro (in casi estremi, la morte istantanea). Per questo, non sapendo nulla della circuiteria sottostante, io a priori non fare mai una manovra del genere.

Perciò mi sono messo a studiare le soluzioni circuitali adottate per realizzare la funzione illustrata nel documento citato da steve-cr

Development boards (including all Espressif boards) usually use additional circuitry to avoid this problem - if both RTS and DTR are both asserted together, this doesn't reset the chip. Consult Espressif development board schematics for the specific details.

La circuiteria menzionata sono i due transistors NPN con gli emettitori incrociati verso gli ingressi alle basi, che realizzano in maniera un po’ naif (nell’epoca delle FPGA è più facile integrare un intero processore che due stupidissime porte logiche) due funzioni logiche: En=/DTR+RTS e GPIO0=DTR+/RTS. In questo modo, se DTR e RTS sono asseriti o negati contemporaneamente, En e GPIO0 non fanno nulla (restano alti in pull-up), se invece DTR e RTS sono asseriti alternativamente, En e GPIO0 fanno quello che devono, Il boot o il reset.

Ho guardato gli schemi del modulo della Hiletgo e il DevKitC V4 della Esperssif. In effetti il modulo della Espressif ha due condensatori di debouncing da 100nF in parallelo ai due bottoncini e altri 100nF vicini al pin EN, che il modulo della Hitletgo non ha (e ci sono altre piccole differenze su valori delle resistenze di pull-up).

Siamo nella situazione descritta dalla succitata pagina:

(Some third party ESP32 development boards use an automatic reset circuit for EN & GPIO pins, but don't add a capacitor on the EN pin. This results in unreliable automatic reset, especially on Windows. Adding a 100nF (or higher) value capacitor between EN pin and GND may make automatic reset more reliable..)

Quindi la soluzione va nella direzione indicata da Steve-cr (ma con un valore del condensatore ben più ragionevole).

Tutto induce quindi pensare che ci sia un problema nel timing dei segnali.
Infatti gli sviluppatori di esptool.py dicono:

Entering the Bootloader
Both ESP8266 and ESP32 have to be reset in a certain way in order to launch the serial bootloader.
On some development boards (including NodeMCU, WeMOS, HUZZAH Feather, Core Board, ESP32-WROVER-KIT), esptool.py can automatically trigger a reset into the serial bootloader - in which case you don't need to read this section.
For everyone else, three things must happen to enter the serial bootloader - a reset, required pins set correctly, and GPIO0 pulled low

La scheda Hiletgo è una NodeMCU, quindi non dovrei preoccuparmi, ma evidentemente non è così. La mia impressione è che tanti disegnatori di schede di sviluppo per l’ESP32 si siano gettate sull’affare, copiandosi più o meno l’un dall’altro, senza approfondire certi dettagli circuitali.
Quindi è un problema di timing dei segnali, che il condensatore sul segnale EN tende a risolvere, o mitigare.

Ma poi in quest’altra pagina si scopre che, per lo stesso modulo, il problema affligge chi usa Windows ma non chi usa Linux, e si scopre che la causa sta nel driver USB to UART della Silicon Labs per il chip CP2104, implementato in Windows, che introduce un piccolo ritardo sul segnale GPIO0, per cui bisogna ritardare artificialmente il segnale EN. L’equivalente driver per Linux non ha questi problemi, e gli sviluppatori di esptool.py non hanno workaround. Non resta che il condensatore su EN.

Va detto che il problema è stato segnalato alla Slicon Labs (vedi qui), ma per ora non hanno reagito positivamente.

Debbo anche dire che ho fatto qualche prova e per la mia scheda il problema si è risolto con soli 10nF.

Ps.: Mi scuso del lungo post, ma ho dedicato molto tempo a capire questo problema, e il post è il risultato delle mie annotazioni, sperando che siano utili a qualcuno

Post molto utile. Complimenti.
Si, certo, quando uno deve mettere un elettrolitico non stai a vedere se hai la capacità perfetta, ti adatti con quello che hai. Le prossime schede proverò anche io un 10 nF.

P.S.
Invece, a proposito di ESP32, sono rimasto colpito , sorpreso e amareggiato (?!?!) che ogni scheda legge i valori analogici come gli pare, nel senso che non hanno una taratura comune uguale per tutte.
Sembra che con le nuove schede tutto sia stato risolto (ancora non ho provato).
Comunque se provi a leggere il valore analogico della stessa resistenza (per esempio) su diverse schede ESP32 vedrai che non ti da lo stesso valore.

Se posso accodarmi alla discussione.

Ho una scheda ESP32 AZ-delivery, che mi sono pentito di aver comprato perchè a 38 pin quasi sconosciuta a tutti e senza led interno di stato.

Comunque, anche io ho il problema del tasto boot da premere per caricare gli sketch, anche perchè la mia applicazione prevede che l'ESP3 stia dentro un contenitore. Proverò ad inserire il condensatore come detto sopra.

L'altro problema, più rognoso, è quello del "A fatal error occurred: “Failed to connect to ESP32: Timed out...".

Ho provato a reinstallare i driver, diminuire la velocità di caricamento, alimentare ESP32 da alimentatore esterno ma nulla.

Dopo diverse prove e letture ho notato che disconnettendo due resistori di pull up da 10K che avevo connesso al pin 3.3, lo sketch viene caricato. Assurdo! Come si fa a scollegare ogni vola il proprio circuito, supponiamo che l'esp32 sia montata su un PCB...?

Grande scheda potenzialmente, ma affetta da una miriade di problemini che la rendono poco utilizzabile nelle realizzazione di prototipi semi-professionali.

Ciao.

Daigs:
.....
Grande scheda potenzialmente, ma affetta da una miriade di problemini che la rendono poco utilizzabile nelle realizzazione di prototipi semi-professionali.
....

Su questa ultima frase, oggi come oggi, avrei delle riserve, specie dopo il "fattaccio" che gli "innumerevoli" ingressi analogici (se uno ne trova così tanti pensa, quantomeno, che funzionino bene...) hanno bisogno di una taratura scheda-per-scheda (ognuna legge la medesima resistenza o tensione con diversi valori), che detti ingressi NON sono lineari e che non coprono tutti i 4096 punti con i 3,3 volt....

Che poi abbia altri "problemini" ad essere programmato se alcuni pin sono occupati da circuteria, è un altro lato negativo a cui non c'è soluzione se non utilizzare altri pin diversi da quelli incriminati.

Ti puoi riferire a QUESTO articolo, molto ben fatto, per sapere quali pin usare e quali, assolutamente NO.

Daigs:
Grande scheda potenzialmente, ma affetta da una miriade di problemini che la rendono poco utilizzabile nelle realizzazione di prototipi semi-professionali.

molte delle ciabatte e prese smart in commercio usano un ESP32 come controller.
magari sono versioni che montano solo il chip e il resto della circuiteria è fatto da loro.

Ciao,

ho risolto il problema del "Failed to connect to ESP32: Timed out..." durante la programmazione cambiando i pin assegnati al circuito esterno. Ora carica tranquillamente, a meno di premere boot (da risolvere con il condensatore).

Grazie per il link steve, lo avevo già visto ma non mi aveva dato warning sui pin che stavo usando (mi sembra il 4 ed il 2).

Questa cosa della taratura degli ADC è assurda!

gianlucaf:
molte delle ciabatte e prese smart in commercio usano un ESP32 come controller.
magari sono versioni che montano solo il chip e il resto della circuiteria è fatto da loro.

Usano gli ESP8266, ancora non ne ho vista una con ESP32
La linea Sonoff, la Shelly (che non è cinese!) usano tutti l'ESP8266.