Dear Espressif,
For the convenience of PCB layout (GPIO16 / PIN 8 close to CHIP_PD / PIN 7) , we wonder whether it is possible to connect GPIO16 to CHIP_PD, other than nRESET / PIN 32, to reset the chip upon exiting deep sleep mode.
If we connect GPIO16 to nRESER pin, everything goes OK to exit the deep sleep and restart. Meanwhile, if we pull-low and then pull-high the CHIP_PD pin via an external PIO, the chip could restart successfully as well.
However, if we connect the GPIO16 to CHIP_PD (sure with a pullup to VCC as well), the boot info would be as below:
"
[b]ets Jan 8 2013,rst cause:0, boot mode:(3,6)
unknown reset
ets_main.c[/b]
"
Interesting that there is still has a notice of "ets_main.c".
What might be the cause and is there a way to avoid it and goes successfully to restart ? Any characteristic data including timing for this two pins could be shared ?
Best regards,
Connect GPIO16 to CHIP_PD for deep sleep mode?
-
- Posts: 140
- Joined: Mon Oct 27, 2014 10:40 am
Re: Connect GPIO16 to CHIP_PD for deep sleep mode?
Postby Espressif_Kelly » Wed Jul 22, 2015 8:30 pm
Hi Li,
We have done a lot of optimizations on deep sleep in SDK lib and all optimizations are based on EST_RSTB(GPIO16---EXT_RSTB).
If you use CH_EN(GPIO16---CH_EN), then many of these optimizations can not be used each time the system restarts. Besides, the results can be unpredictable if GPIO16 is connected to CH_EN in this case.
The optimization can be summarized as below.
1) RTC memory can not be used to store data for the next wakeup.
For example, a temperature sensor to measure at the interval of 10seconds, but sent out data at the interval of 30minutes. So the firmware can store the measurement data into RTC memory, and then go to deep-sleep. At the 30min interval, the firmware send out data by WiFi.
This solution save the energy greatly, since WiFi connections need more time and more current.
2) some optimized function for deep-sleep can not be used any more, for example:
system_deep_sleep_set_option(uint8 option)
However, a new SDK in the end of July, may add more options for the applications, which may power-on rather than deep-sleep wakeup.
Thanks.
We have done a lot of optimizations on deep sleep in SDK lib and all optimizations are based on EST_RSTB(GPIO16---EXT_RSTB).
If you use CH_EN(GPIO16---CH_EN), then many of these optimizations can not be used each time the system restarts. Besides, the results can be unpredictable if GPIO16 is connected to CH_EN in this case.
The optimization can be summarized as below.
1) RTC memory can not be used to store data for the next wakeup.
For example, a temperature sensor to measure at the interval of 10seconds, but sent out data at the interval of 30minutes. So the firmware can store the measurement data into RTC memory, and then go to deep-sleep. At the 30min interval, the firmware send out data by WiFi.
This solution save the energy greatly, since WiFi connections need more time and more current.
2) some optimized function for deep-sleep can not be used any more, for example:
system_deep_sleep_set_option(uint8 option)
However, a new SDK in the end of July, may add more options for the applications, which may power-on rather than deep-sleep wakeup.
Thanks.
Who is online
Users browsing this forum: No registered users and 2 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.