strapping Pin clarification
strapping Pin clarification
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?
Re: strapping Pin clarification
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.
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.
Re: strapping Pin clarification
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.
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.
Re: strapping Pin clarification
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.jimbob wrote: So just to check we don't have to worry about the mention of GPIO4 at the top of page 9?
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.)
Sorry, I realised I was pretty vague about that part.jimbob wrote: However, I'm now puzzled how does the ESP32 get set to boot in SDIO slave mode?
"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.)
Very understandable. Hopefully the above clarifies things a bit, please don't hestitate to ask if you need more information.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.
Re: strapping Pin clarification
We can set permanent boot mode with efuse also, correct? To force flash boot and silent boot?
Re: strapping Pin clarification
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.WiFive wrote:We can set permanent boot mode with efuse also, correct? To force flash boot and silent boot?
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.
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: strapping Pin clarification
Fyi, silent boot, as far as I know, can only be done by bootstrapping the mTDO pin.
Re: strapping Pin clarification
Thanks -- that's a great help.
-
- Posts: 6
- Joined: Fri Nov 20, 2015 8:34 pm
Re: strapping Pin clarification
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)?
So I don't have to add pu/pd resistors anymore (as everybody did for the ESP8266)?
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: strapping Pin clarification
Yes. THe default pullups and -downs are documented in the pin list document: https://espressif.com/sites/default/fil ... t_en_0.pdf
Who is online
Users browsing this forum: MicroController and 104 guests