-->
Page 1 of 1

Re: deep sleep not working on code card

PostPosted: Sat Jan 25, 2020 11:20 pm
by StanJ
edit: the post I replied to has since been deleted, so my reply is hanging out in the air. The OP has an Oracle Code Card, and said that Deep Sleep doesn't work on it.
https://github.com/noelportugal/codecard
Looking at the schematic at github, I have NO earthly idea why they designed it like that.
https://github.com/noelportugal/codecar ... /schematic

----------------------------------------------------------------------------------------------------------------------------------------------------

Deep Sleep works fine. I've just spent a couple of weeks beating it up in every way imaginable. :lol: It's severely bruised, but still alive.

https://en.wikipedia.org/wiki/Crash_cart aka Code Cart

It looks like the diode logic & pulldowns on your buttons and GPIO16 is upside-down: the default state is power-down. You have to press a button to enable it, and hold the button until GPIO16 goes high once the pin is initialized during boot. When the Deep Sleep timer times out, the chip goes back into power-down, waiting for you to press the button again; it can't come out of Deep Sleep without a button press the way that board is wired.

Image

edit: I just tried ending Deep Sleep using the CH_PD pin instead of RST, and it doesn't work on the ESP-07S module I have. The chip wakes up after it's enable goes high again (after Deep Sleep timeout puts it in power-down), but it reports UNKNOWN RESET and gets stuck in ets_main.c, which is pretty useless. If I were you, I'd swap out that whole section with the buttons and chip enable to something better, and drive the RST pin with GPIO16 instead of CH_PD (diode or wire, your choice). Note that my test was done with the current Non-OS SDK and Arduino IDE; your mileage may vary with other tool chains and source trees. Here's the post at the Espressif BBS from 2015 where someone else tried what you're doing with CH_EN & Deep Sleep:
https://bbs.espressif.com/viewtopic.php?t=562
Apparently it's not fixed in the Non-OS SDK that we're using in the Arduino build.