ESP8266 Community Forum

- Fri Nov 08, 2019 8:50 pm #84487 Hi all,

Started this topic to try and capture everything and anything people have found that makes deep sleep reliable, or things to look for when it's not.

From trawling the net for days, it seems that everyone has the same experience as me - sometimes you can get reliable units that work for months, and other times they just never come back.

I've just pulled the very latest NonOS repo and it seems to have made my units fail to come back almost immediately (it also broke my SSL but that's another story - FYI Espressif have re-enabled SSL3). I didn't spend much time, I just rolled back, but I want to try and put some science around this black art.

For my own experience right now, when a unit fails to come back properly from deep sleep it actually attempts to boot, but it never makes it into userland, and you can't hit the reset button you have to unplug it completely for a bit. It will also not respond to flashing.

So here are the things I have found that will stop units from coming back from deep sleep, from the obvious to the not so obvious:

- you have to wire up the connection. Seems obvious but I got tricked by this on some Electrodragon modules. The circuit showed it was wired but the board wasn't

- don't use a resistor, use a diode, preferably a Schottky. When your power is not reliable a resistor can give unpredictable results

- put a short delay after the system_deep_sleep call. Adding even os_delay_us(100); can make a difference

- shut down your wifi and clear your UART before calling deep sleep. The routine does it, but it waits till your UART buffer is empty and seems to maybe almost wait till the wifi is off but if it's not well and truly off it causes problems. At worst it causes delays you may not have figured into any timing calculations

- don't trust the RTC clock to wake you at the right time. The clock is highly temperature dependent and the moment you go into deep sleep it starts to cool down and the time drifts. Mostly it seems to wake the unit early, so my approach is to get the correct time via NTP and always use that. Since the maximum deep sleep time is approximately 3.5 hours, the drift isn't usually huge and this works well for me. I also use a moving average that takes into account the difference between the event time and the time the unit gets into run mode, and I use that to correct my sleep time value, so my units quite quickly adjust to waking up really very accurately

- make sure your power supply can handle the current surge at start up. If your power supply is not quite right and don't have enough current then it won't wake up properly

- change the RF calibration settings on wake using set_deep_sleep_option. If you can get away with not doing a full calibration every time you wake up, then change the setting and it will significantly decrease the initial current draw. This may help with the tip above

So they are the things I know about - one other thing I suspect but am in the process of testing is use of I2S or DMA interrupts. I have a feeling this may be messing me up and that if you have DMA running and ISRs being called for any of your peripherals like HSPI or I2S then that may mess things up. I'd like to hear your opinions.

OK so that's me.... and.... GO!!

- Sat Nov 09, 2019 4:33 am #84490 Another factor that can have an influence is how the RESET line is internally wired. On many modules it has a ull up resistor to Vdd and a capacitor to ground. The capacitor is I think to hold the reset line low during power up but it can also introduce a significant lag on external signals trying to reset the module.

I tend to use the EN / CH_PD line instead as this is normally a more raw connection. It does mean the RTC memory is also cleared which might be problematic if that is being used.

- Sat Nov 09, 2019 7:40 am #84491 I do use the RTC memory constantly so that is an issue for me - I'll have to look up how I've wired mine but I think using a diode means you get a good pulse in the time needed.

Another thing I have seen in posts is that people who don't have pull ups on GPIO0 and GPIO2 have problems when the ESP wakes up - that seemed obvious to me but obviously not to some out there so definitely worth listing.

I have always added them on my own circuits, but I'm currently having problems with my test breadboard, designed around the Lolin V3 NodeMCU module - they use 12k pull ups on that and I am now wondering if maybe that is too weak? I'm going to try adding a couple of external 10k resistors to strengthen the pullups a bit and see if that helps.

- Sun Nov 17, 2019 3:18 am #84592 Interesting reading stuff, thx Davy!

I am not using DeepSleep but my $0.02:

- I've learned the hard way one should add a small capacitor to both RST and CH_PD lines. If you don't, any RF noise (like starting a TL tube) will reset the unit. This additional to an explicit pull up resistor of something like 10 kOhm.
- I also learned that both GPIO 0 and GPIO 2 really need an explicit pull up resistor for the boot to always work reliably. If I leave them out, the module often does not enter user image.
- It seems sometimes it's necessary to add small capacitors to unused GPIO pins, to stop them radiating RF noise. I also tried resistors, but capacitors definitely work better.

Can't you configure the UART and do some debugging there, including output from SDK boot code? Or are all pins already in use?