ESP8266 Community Forum

- Sat Sep 17, 2016 4:08 am #55265

In theory you have pulled RST low with GPIO16 to enable deep sleep

..hmm, I'm not sure why you said that..but I am easily confused

As shown in the schematic RST is pulled high with the R6 10k resistor and the device is being put into deep sleep with code that looks something like this:

Code: Select allESP.deepSleep(rtcConfigData.pwrDownLength, rtcConfigData.wakeMode);

..which is working fine to put the device into deep sleep.

When the device is in deep sleep, I've measured that RST and GPIO16 remain in a 3.3v high state.

GPIO16 is linked to RST with the R4 470R resistor and this is working fine to wake the device from deep sleep. I assume that when the device needs to be woken, the RTC pulses GPIO16 off and on and it's this that wakes the device up.

Are you sure that pressing S1 is waking the ESP?

Yes it really is waking the device and as I mentioned in my last post, this wake event is being seen as a rst_reason flag of REASON_DEEP_SLEEP_AWAKE = 5.

I've attached an image of the board and it's traces with some labels highlighting things that will hopefully make the reset part of the circuit easier to follow. This is the board I'm currently using where I'm seeing the odd unexpected REASON_DEEP_SLEEP_AWAKE = 5 when the board is woken via S1 press.

I do think everything is connected on the board as per the schematic and it looks like it should work. In fact it does seem to be working fine apart from this issue where REASON_DEEP_SLEEP_AWAKE = 5 when the board is woken via S1 press instead of REASON_EXT_SYS_RST = 6. This is the only reason I've got the S1 switch on the board - as a means to manually reset the board and hopefully detect that the board was externally manually reset.

I'm totally happy to be told this is connected wrong in some way by you guys

You do not have the required permissions to view the files attached to this post.

- Sat Sep 17, 2016 5:45 am #55267 Hi, you are correct and I'm sorry to put you through the work of posting and having to labling the screen shot - I had never checked GPIO16 and had mistakenly assumed that it went low (pulling RST low) to start the deep sleep and released the low (letting RST high) to wake (as you would do with CH_PD - in my defence I have quite a few projects that do that). So the deepsleep is instigated by software and terminated by hardware (a reset).
Please ignore most of what I said in the last post as in light of this new information it is mostly incorrect or irrelevant.
In answer to your question; I've not come across this but it appears from what you see, that any reset following the commencement of deepsleep is classed as part of the deepsleep function and reported as such.

- Sat Sep 17, 2016 8:22 am #55273 No problem at all the pcb image is there now annotated up and combined with the schematic, perhaps it will help someone in future doing a similar thing.

I'm interested to learn more about your approach of using CH_PD for deep sleep wake / reset. What's the idea here? Is it that GPIO16 gets linked to CH_PD rather than RST? A little schematic and explanation how the software works with it would be very useful.

So far as my S1 manually wake problem goes you could be right - perhaps a reset triggered manually via the switch when in deep sleep mode will always be signalled as REASON_DEEP_SLEEP_AWAKE = 5 rather than REASON_EXT_SYS_RST = 6. If not in deep sleep I do see that rst_reason does signal REASON_EXT_SYS_RST = 6 as expected.

I'll run some more tests to see what I can learn. It might turn out that I need to rearrange where the switch is positioned so it somehow disconnects power completely to enable me to get the desired rst_reason behavior I'm after.

- Sat Sep 17, 2016 9:24 am #55277 igrr confirmed on an arduino core github issue that this is expected behaviour: https://github.com/esp8266/Arduino/issu ... -247773656

I'll have to rearrange things so my reset switch is a power cycling switch because that will work fine.

Thanks for all the help guys it's very much appreciated