jimbob wrote:
So just to check we don't have to worry about the mention of GPIO4 at the top of page 9?
That's correct. GPIO4 is a strapping pin (pulling it high or low will change the hex value written after "boot:" in the ROM boot message), but it's used for some undocumented test modes.
As long as the strapping pins GPIO 0 & GPIO 2 are configured as per "Booting Mode" in Table 2 of the datasheet, GPIO 4 is not consulted. GPIO 5 is only consulted for configuring SDIO Slave in "Download Boot". GPIO 15 is used to mute UART early boot output, and to configure SDIO Slave in "Download Boot".
(The undocumented test modes are triggered if GPIO 0 is driven LOW and GPIO 2 is driven HIGH - the missing combination in the "Booting Mode" section of Table 2. In that case, GPIOs 4, 5 & 15 are used to determine further details of the test mode.)
jimbob wrote:
However, I'm now puzzled how does the ESP32 get set to boot in SDIO slave mode?
Sorry, I realised I was pretty vague about that part.
"Download Boot" mode, as shown in Table 2, (GPIO 0 driven LOW, GPIO 2 left LOW) supports both UART and SDIO Slave bootloading. The ESP32 will wait for valid input on any of UART 0, UART 1, or the SDIO Slave interface in order to begin loading the firmware.
(For UART loading, "valid input" means auto-bauding and then detecting the "sync" sent by esptool.py or another uploader tool.)
jimbob wrote:
Basically, I'm creating a design and want to know that states of IO pins connected to other devices aren't going to cause the ESP to boot in a wrong mode.
Very understandable. Hopefully the above clarifies things a bit, please don't hestitate to ask if you need more information.