GPIO0 ground for upload???

[esp32_tm]

This appears to be a simple question for this forum, but I have a couple of boards with the ESP32-DOWD chip. One requires the BOOT0/GPIO0 switch to be pressed/grounded in order to start an upload and the other does not require this and the upload proceeds without any intervention.

Why the difference in behavior between the two boards?

Thanks,
TM

[ESP_Angus]

Some boards automatically use the DTR & RTS signals from the serial port to toggle GPIO0 and the EN (reset) pin to enter bootloader mode.

You can read more about this here:
https://github.com/espressif/esptool/wi ... bootloader

(Note some third party development boards have a circuit to do this but it doesn't work reliably, so you may need to press the button anyhow in those cases.)

[esp32_tm]

Thanks for the info and the link.

That explains a lot, more than I understand, in fact. The action on this one board (an ESP32 Thing) appears to produce a reliable auto boot mode but it will require a bit more investigation to find out why or how it got into that mode. The unreliability mentioned in the document link indicates that some other side effects may take place and I think this is happening as code that won't fully run on this board will run normally on another that doesn't auto boot. I've been using Arduino, esptool and idf.py, all three, to read and write stuff so I obviously did something to 'corrupt' the board although it does work, mostly.

I'll find a reliable way to read a fresh board and burn that to the offending unit and see what happens.

Thanks,
tm

[esp32_tm]

Posting some updated information.

The condition, as noted above, is that one of four ESP32-D0WDQ6 based boards starts an upload automatically while the other three require a BOOT0 button press, something that appeared to have started while working my way through some tutorials. I was thinking that I most likely flashed or changed something while going back and forth from using ArduinoIDE, esptool and the IDF. A link in a post up above gives some explanations but, considering all of that, I think I found a simpler explanation. Three of the boards ( Sparkfun ESP32 Things, by the way) have the D0WDQ6 revision 1 chip but the fourth board has a revision 0. Revision 0 provided the auto boot. There is also an Espressif 10 page buglist and workaround document I found with some explanations that I haven't gone through thoroughly yet. Probably won't. Here's a link:

https://www.espressif.com/sites/default ... p32_en.pdf

I'm chalking up the BOOT0 issue to a difference in versions between the earlier and later chip and not due to my own mishandling. Good enough for me unless it presents a problem later on.

tm

[ESP_Angus]

code that won't fully run on this board [ESP32 Thing] will run normally on another that doesn't auto boot.

This is probably a different cause, the ESP32 Thing is the only ESP32 development board (to my knowledge) that has used a 26MHz crystal on the board, and Espressif recommends using 40MHz crystal only.

If you configure your project for 26MHz it should work. The ESP-IDF config item is here (default is 40MHz):
https://docs.espressif.com/projects/esp ... l-freq-sel

Three of the boards ( Sparkfun ESP32 Things, by the way) have the D0WDQ6 revision 1 chip but the fourth board has a revision 0. Revision 0 provided the auto boot.

There is a bug in revision 0 at boot time (spurious WDT reset) that makes it easier for the auto boot circuit to work, because it gets a "second chance" to set the pins correctly.

But a correctly designed development board can auto boot a new ESP32 revision on nearly all computers. The problem is with the board design, not the chip.

The "ESP32 Thing" schematic shows that there is no capacitor between EN pin (marked CHIP_PU in the schematic) and GND. This cap is needed for the auto-reset to work reliably. If you add a capacitor to the breakout pins on the board (use approx 1uF value) between CHIP_PU and GND then auto-reset will probably start working.

Sparkfun will need to update the board design for it to work reliably out of the box (same goes for the choice of 26MHz crystal).