strapping Pin clarification

[jimbob]

In table 2: Strapping pins on page 9 of https://espressif.com/sites/default/fil ... eet_en.pdf is MTDO duplicated rather than a GPIO4 entry? If so,which does MTDO really effect, the U0TX log or the SDIO slave config?

[ESP_Angus]

Hi jimbob,

It's a little confusing, but the MTDO pad influences both. The short answer is that you can probably ignore the "SDIO Slave" strapping choice.

The SDIO Slave mode is used when driving the ESP32 as a peripheral over an SDIO bus from an embedded host (in this configuration, the ESP32 is used as a BT/WiFi peripheral rather than a microcontroller.) Because the ESP32 loads its firmware from the SDIO host in this configuration, it needs to have the correct SDIO configuration immediately following a reset.

In the other (more usual) configuration, when the ESP32 is instead is loading firmware from attached flash, this SDIO Slave configuration is not important (the firmware in flash can configure the SDIO Slave peripheral itself and override any "strapping" configuration that was read on reset.)

The assumption is that U0TXD is not used in SDIO Slave mode, and vice versa - this is why the same pin is used for both modes.

[jimbob]

Thanks,

So just to check we don't have to worry about the mention of GPIO4 at the top of page 9?

However, I'm now puzzled how does the ESP32 get set to boot in SDIO slave mode?

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.

[ESP_Angus]

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

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

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.

[WiFive]

We can set permanent boot mode with efuse also, correct? To force flash boot and silent boot?

[ESP_Angus]

We can set permanent boot mode with efuse also, correct? To force flash boot and silent boot?

You can use EFUSE to set the SPI config for flash booting (overriding the flash header which esptool.py attaches) and I believe you can disable silent boot. I'm not certain about disabling boot modes.

The Technical Reference section for EFUSE should be out soon which will give in-depth explanation for these. The efuse registers are exposed in esp-idf, but as they're not reversible I don't recommend trying them out quite yet.

[ESP_Sprite]

Fyi, silent boot, as far as I know, can only be done by bootstrapping the mTDO pin.

[jimbob]

Thanks -- that's a great help.

[MarsWarrior]

If I understand it correctly, the ESP32 itself contains the (weak) default pull-up and pull-down resistors?

So I don't have to add pu/pd resistors anymore (as everybody did for the ESP8266)?

[ESP_Sprite]

Yes. THe default pullups and -downs are documented in the pin list document: https://espressif.com/sites/default/fil ... t_en_0.pdf