Strapping pins and SDIO slave timing

[zliudr]

I have a question regarding the MTDO and GPIO5 strapping pins. The manual says they both default to pull-up, which corresponds to rising-edge sampling and rising-edge output I think. There is also a note saying firmware can configure register bits to change the settings after booting.
The reason I'm trying to understand the timing is that I'm using GPIO5 as an input so potentially it could read LOW on power up. This sets timing to put the timing into rising-edge sampling and falling-edge output. Will this potential change mess up my FLASH and SPIRAM access? If these can be configure after booting, then can I set the timing to rising output? How do I do that? I'm potentially looking at changing the pin but I've got over a hundred boards printed so I'd like to try a software fix instead of cutting traces.

Thank you!

BTW, I have one board that is having SPIRAM issues. I wonder if that strapping pin SDIO timing caused it. I measured both pins to be high but that might to too late since the strapping pins only change state after power down? Very confused.

[zliudr]

From my tests, my good unit boots up and uses spiram regardless the voltage I supply on GPIO5, 0V or 3.3V. Maybe the SDIO timing is indeed controlled by software after boot but where?

[ESP_Sprite]

SDIO there relates to the slave interface SDIO boot interface. If you use normal SPI flash (like you do), the state of GPIO5 does not matter.

[zliudr]

Thank you! Could you elaborate on what is SDIO slave interface and what it might be used for? I've been reading but ESP32 has so much information and I could use some direction.

[WiFive]

The intention is so you can use esp32 without a flash chip connected to a host processor over sdio like a more traditional wifi chip. You would load a simple wifi firmware to ram on boot over sdio and all the network processing would be done on the host processor. It's not really supported, at least publically.

[zliudr]

I see. Thank you WiFive! So if I understand correctly, a host controller such as a microcontroller will send firmware to ESP32 on boot so ESP32 acts like a WiFi module for the microcontroller. Yeah that sounds pre-ESP8266 even. Great to have this understanding now. On a separate thread I posted about SPIRAM, I guess my SPIRAM problem has nothing to do with it. I'll probably install 4.x tool chain and explore 2T option. Thank you for untangling these two things.

[ESP_Sprite]

It's not really supported, at least publically.

In case you were wondering 'Well, why is it in there in the first place then?', it's because the automated testing equipment that tests every single ESP32 die uses it to upload testing code.

[zliudr]

You read my mind! Why a useless feature, right? I bet if I study reference manual enough, I could make use of it in place of a push-button to run test code for my production runs. Thank you!