Go Down

Topic: ESP32 Caricare programmi senza premere BOOT (Read 851 times) previous topic - next topic

steve-cr

Feb 23, 2019, 05:34 pm Last Edit: Feb 23, 2019, 05:35 pm by steve-cr
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.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

gpb01

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

Che tu sappia, può avere qualche effetto collaterale ?

Guglielmo
Search is Your friend ... or I am Your enemy !

steve-cr

#2
Feb 23, 2019, 06:20 pm Last Edit: Feb 23, 2019, 06:23 pm by steve-cr
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

Quote
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.

Quote
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.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

SukkoPera

Mai dovuto premere BOOT sul mio ESP32, mi chiedevo appunto a cosa servisse...
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

steve-cr

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 ?  :D

Comunque oggi avrò fatto una cinquantina di upload su ESP32 e mai un problema: la modifica è perfetta.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

brunello22

#5
Feb 26, 2019, 07:27 pm Last Edit: Feb 26, 2019, 07:41 pm by brunello22
Quote
Mai dovuto premere BOOT sul mio ESP32, mi chiedevo appunto a cosa servisse...
Idem, mai premuto

link

SukkoPera

"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

steve-cr

ESP32 DEVKIT V1
www.doit.am
Si, effettivamente leggevo su questo sito che non c'è bisogno di premere il pulsante.....  :D  :D  :D
E' un sito scritto in cinese, e non ho intenzione di impararlo!

Quello di Brunello22 è diversa dalla mia pur essendo un DEVKIT V1
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

SukkoPera

La mia è identica a quella che hai linkato.
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

gianlucaf

E ti pareva che mi è toccato il modulo sfigato :D
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.

steve-cr

...... 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...
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

steve-cr

#11
Mar 28, 2019, 03:57 pm Last Edit: Mar 28, 2019, 04:07 pm by steve-cr
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:

Code: [Select]

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....
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

steve-cr

Code: [Select]

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.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

dlcflv

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:
Quote
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:
Quote
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
Quote
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:
Quote
(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:
Quote
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


steve-cr

#14
Jun 04, 2019, 03:41 pm Last Edit: Jun 04, 2019, 03:43 pm by steve-cr
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.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

Go Up