- Fri Nov 27, 2020 10:00 am
#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, https://docs.ai-thinker.com/_media/esp8 ... 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).
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, https://docs.ai-thinker.com/_media/esp8 ... 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).
