Advanced Users can post their questions and comments here for the not so Newbie crowd.

Moderator: eriksl

User avatar
By StanJ
#89583 FWIW, Erriez has been trying everything to get his modules to wake properly. My strongest suspicion so far is that the XTX Flash chips on his modules have a problem during the boot process when it loads the user code, sort of similar to the problem we had with the XMC flash chips. One person fixed his zombie mode by replacing the Flash with a Winbond chip, but we haven't verified that fixes it. XTX Flash seems to be used by these cheap no-name modules on ali and ebay:


My second guess is that some modules are going into chip self-test mode, which would explain why some people have to power down to get it out of that zombie mode. Dropping CH_PD should also exit chip self-test. GPIO15 has a weird level on it during the boot detection: 0.7V. That should be read as a low, but I don't know if there is a different VIL on that pin. The signal is unusual for sure. Chip self-test is only mentioned in this doc from AI Thinker, ... ual_en.pdf on page 7.


One other interesting item that I found out yesterday: GPIO16 is NOT waking the chip up when you have ESP.deepsleep(x), where x is non-zero. The chip actually wakes ~ 2ms before GPIO16 falls, which you can see in the substrate current and also from the signal levels on GPIO0, GPIO12, GPIO13 and GPIO14. The CPU must be doing something like this:
RTC counts down to 0, triggers start-up of the BB_PLL
CPU wakes, drops GPIO0 and then reads the RTC RAM location(s) that says it had been sent to Deep Sleep
CPU releases GPIO0 and then drops GPIO16 briefly to see if it's connected to EXT_RSTB
If it sees a low level on RST and GPIO0=L, GPIO2=H & GPIO15=L, release GPIO16 and load the user program else check other boot modes and hang if it can't determine boot mode (ets_main.c)
That's just the simplified version for Deep Sleep Wake.


For those two scope captures I had a 1meg pull-up/pull-down so I could see when the pin changed from 2uA drive to 12mA drive. I didn't include the substrate current, but it comes up to ~ 5mA when you see GPIO0 drop (BB_PLL started), and goes to 18mA when GPIO16 falls (BB_PLL shifts to full speed).
User avatar
By Sp0ngeB0b
#90058 Little tidbits i gathered form a motion sensor project :

- gpio0 and 2 MUST be pulled high. If they are left floating gpio2 will bootfail if not "high" state even if there isn't any particular function from boot. gipio0 is obvious if you don't want to enter flash mode.
- GPio2 will "bleep" on boot. ( the only pins that don't are GPIO4 and 5 i think) this may have adverse effects depending on its purpose

- i noticed that you need a 100ms or so delay at boot and before going to sleep.
- if you use a PIR you may need to add circuitry to disable its "input" if its connected to the Reset pin
(mine where reseting crazy on prototypes so i repurposed gpio3 (RX) to disable it trough 2 transistors... pir is "high" when activated so you need to invert that and another one driven by gpio3 to disable that ( so it doesn't reset mid process))

still figuring the wifi up in <1sec ... but so far i think it may be a fluke... one of my project has < than 0.2s but most go from 3s to 8s to boot :-/

other than that i have no issues with booting off from DS...
i am using ESP-01S boards.
User avatar
By eriksl
#90075 All pins have "default" assignments. Most of them are not assigned to GPIO by default, some of them output various clock signals. This is a PITA because it gives a glitch during boot and also it means that if you connect any them to ground or Vcc, the clock signal is muted and the ESP won't start. I'd rather have all I/O pins connected to GPIO by default, as input please ;)