ESP-12E vs. ESP-12S Deep Sleep Wake Up Pulse
Posted: Wed Jul 11, 2018 8:54 amI've been working with AI-Thinker modules ESP-12E and then ESP-12S. I've come across a pulse issue during Deep Sleep Wake Up.
I have a simple setup to test individual modules and I'm experiencing different behavior with the same code and circuit on the different modules (ESP-12E vs. ESP-12S).
The schematic doesn't include the tie between RST and GPIO16 but I've tied them external for the Deep Sleep Wake Up requirement and measured the pulse. See attached for full schematic.
Redline of attached schematic showing external tie between RST and GPIO16:
ESP-12E Pulse:
ESP-12S Pulse:
Test Hardware, pogo pins to connect module:
Using EspressIf SDK, I ran a simple test to go into Deep Sleep and wake up automatically every 30 secs to capture the pulse. Code below, binaries attached.
Flashed binaries with esptool command:
Can anyone else run this test and see what they get? I've contacted AI-Thinker about it but so far they aren't being helpful. I've also contacted EspressIf and they ran this test on their WROOM-02 module and the pulse looks great. The reason I'm concerned is that sometimes the ESP8266 "hangs" when coming out of Deep Sleep, it's random but I have a hunch it's because of this less than ideal wake up pulse.
I have a simple setup to test individual modules and I'm experiencing different behavior with the same code and circuit on the different modules (ESP-12E vs. ESP-12S).
The schematic doesn't include the tie between RST and GPIO16 but I've tied them external for the Deep Sleep Wake Up requirement and measured the pulse. See attached for full schematic.
Redline of attached schematic showing external tie between RST and GPIO16:
ESP-12E Pulse:
ESP-12S Pulse:
Test Hardware, pogo pins to connect module:
Using EspressIf SDK, I ran a simple test to go into Deep Sleep and wake up automatically every 30 secs to capture the pulse. Code below, binaries attached.
Flashed binaries with esptool command:
Code: Select all
esptool.py --port COM4 write_flash -ff 40m -fm dio -fs 4MB 0x0000 eagle.flash.bin 0x20000 eagle.irom0text.binCode: Select all
extern "C" {
#include "espressif/esp_common.h"
#include "gpio.h"
#include "uart.h"
}
/******************************************************************************
* FunctionName : user_rf_cal_sector_set
* Description : SDK just reversed 4 sectors, used for rf init data and paramters.
* We add this function to force users to set rf cal sector, since
* we don't know which sector is free in user's application.
* sector map for last several sectors : ABCCC
* A : rf cal
* B : rf init data
* C : sdk parameters
* Parameters : none
* Returns : rf cal sector
*******************************************************************************/
extern "C" uint32 user_rf_cal_sector_set(void) {
// FIXME - Is this using the correct part of the flash?
flash_size_map size_map = system_get_flash_size_map();
uint32 rf_cal_sec = 0;
switch (size_map) {
case FLASH_SIZE_4M_MAP_256_256:
rf_cal_sec = 128 - 5;
break;
case FLASH_SIZE_8M_MAP_512_512:
rf_cal_sec = 256 - 5;
break;
case FLASH_SIZE_16M_MAP_512_512:
case FLASH_SIZE_16M_MAP_1024_1024:
rf_cal_sec = 512 - 5;
break;
case FLASH_SIZE_32M_MAP_512_512:
case FLASH_SIZE_32M_MAP_1024_1024:
rf_cal_sec = 1024 - 5;
break;
case FLASH_SIZE_64M_MAP_1024_1024:
rf_cal_sec = 2048 - 5;
break;
case FLASH_SIZE_128M_MAP_1024_1024:
rf_cal_sec = 4096 - 5;
break;
default:
rf_cal_sec = 0;
break;
}
// ets_printf("Size map %d \n", size_map);
return rf_cal_sec;
}
/******************************************************************************
* user_init - Entry point into our application. We must initialize our app
* and return from this function to allow the SDK built-in threads to start
* and execute.
*******************************************************************************/
extern "C" void user_init(void) {
printf("SDK version:%s\n", system_get_sdk_version());
system_deep_sleep_set_option(0); // Use EEPROM to determine RF on wake behavior
system_deep_sleep(30000000);
vTaskDelay(100);
}
Can anyone else run this test and see what they get? I've contacted AI-Thinker about it but so far they aren't being helpful. I've also contacted EspressIf and they ran this test on their WROOM-02 module and the pulse looks great. The reason I'm concerned is that sometimes the ESP8266 "hangs" when coming out of Deep Sleep, it's random but I have a hunch it's because of this less than ideal wake up pulse.
