Page 1 of 1

GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Tue Feb 26, 2019 9:41 pm
by gwebb.us
I understand that several pins are sampled upon EN (ie Resetn) going high on powerup. I see several discussion threads about BOOT(GPIO12) and the fact that it has to be pulled high for some modules and low for other variants. Got it.

One method used frequently in situations like this is to degate the bootstrap levels when Resetn(EN) is released. Typically a x244 or fet/transistor is used to place it in an high impedance tri-state mode after reset.

I can not find the Setup and Hold timings for the ESP32 chips. All clocked signals need a Setup and Hold. What are those specs?? Am I simply overlooking them in the documents?

Specifically, I have a Wrover module, but this question should apply to all the ESP32 chips. What is the Tsetup and Thold for the bootstrapping pins relative to EN going high?

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Wed Feb 27, 2019 4:03 am
by ESP_Sprite
That is an excellent question; I've forwarded it to our digital team and will update you as soon as I get their response.

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Wed Feb 27, 2019 8:29 pm
by gwebb.us
Thanks. I did look "everywhere" for it,

My post mentioned GPIO12 and Boot in the same breath. I realize that they are different bootstrapping pins. Just were thinking about them both. The GPIO12 and its conflict with the 4-bit SDCARD DATA2 almost bit me. im going to gate a bootsrap-time pullup/pulldown onto the GPIO12 with a 74LVC1G125 using EN (RESETn) as its enable. Should work, IF the Tsetup and Tdelay timings for the ESP32 are met.

I see other posts talking about slowing down BOOT and EN signals with caps of a "guessed" value. Such capacitive delay is *BAD* engineering practice and will cause problems in high volume runs. Simply meeting a Tdelay/Thold spec is much safer.

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Tue Mar 05, 2019 8:23 am
by ESP_Sprite
I just got news from my colleagues: the setup time is 0, the hold time is >=1mS.

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Mon Mar 25, 2019 6:34 pm
by gwebb.us
Thank you for checking. Is this documented in a spec somewhere?

Is tHold really one(1) millisecond(1)???. Typically thold has been a few nanoseconds since the ttl 7400 series. 1ms seems excessively long to have to hold the bootstrap data after the positive edgc of EN (nreset). It is common to tri-state bootstrap signals after reset. This would result in a thold as long as the propagation delay through the buffer.

Im at a loss of how one can ensure GPIO12 is low during reset , and then hold for 1msec after reset, and then pull it high for SDATA2 . Short of adding a time delay or second delayed power good circuit, how would one reliably accomplish this?

Boot isnt quite as much of a problem becaause one can make use of GPIO0 in a manner that prevents a conflict. GPIO12 though seems to be problematic

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Tue Mar 26, 2019 2:24 am
by ESP_igrr
You can also burn Efuses to fix the VDDSDIO voltage to 3.3V, in which case you don't need to consider GPIO12 bootstrapping limitations.

https://github.com/espressif/esp-idf/bl ... out-gpio12

https://github.com/espressif/esptool/wi ... e-vdd_sdio

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Tue Mar 26, 2019 3:35 am
by WiFive
gwebb.us wrote:
Mon Mar 25, 2019 6:34 pm
Is tHold really one(1) millisecond(1)???. Typically thold has been a few nanoseconds since the ttl 7400 series. 1ms seems excessively long to have to hold the bootstrap data after the positive edgc of EN (nreset). It is common to tri-state bootstrap signals after reset. This would result in a thold as long as the propagation delay through the buffer.
This may suggest strapping pins aren't hw latched by EN edge and instead sw latched/read by rom bootloader code

Re: GPIO12(boot) bootstrap Tsetup and Thold timings

Posted: Tue Mar 26, 2019 4:27 am
by ESP_Sprite
As far as I know, the strapping pins are hardware-latched. However, on the ESP32, a reset effectively resets *everything*, and there are a few things done before the CPU gets started (xtal startup, bias voltage setting, whatnot) that may delay the actual latching.