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?
GPIO12(boot) bootstrap Tsetup and Thold timings
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: GPIO12(boot) bootstrap Tsetup and Thold timings
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
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.
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.
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: GPIO12(boot) bootstrap Tsetup and Thold timings
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
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
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
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
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
This may suggest strapping pins aren't hw latched by EN edge and instead sw latched/read by rom bootloader codegwebb.us wrote: ↑Mon Mar 25, 2019 6:34 pmIs 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.
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: GPIO12(boot) bootstrap Tsetup and Thold timings
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.
Who is online
Users browsing this forum: No registered users and 89 guests