search

esp8266 / Arduino

ESP8266 core for Arduino
GNU Lesser General Public License v2.1
15.98k stars 13.33k forks source link

ESP.deepSleep hangs after wakeup - ESP12F (Working on older chips) #6007

Closed petrilloa closed 5 years ago

petrilloa commented 5 years ago

Basic Infos

Platform

Settings in IDE

Problem Description

A few months ago, we start developing a custom PCB using ESP8266, ESP12F from AI.

esptool.py --port COM14 flash_id esptool.py v2.6 Serial port COM14 Connecting... Detecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi MAC: cc:50:e3:04:37:7e Uploading stub... Running stub... Stub running... Manufacturer: 20 Device: 4016 Detected flash size: 4MB Hard resetting via RTS pin...

After successfully deploy 100 boards, we receive a new batch from a distributor on China. The new chip, looks the same as the old one, except it has an Expressif logo instead of AI logo.

Then, using esptool, we check that was manufactured by other factory

esptool.py --port COM14 flash_id esptool.py v2.6 Serial port COM14 Connecting... Detecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi MAC: dc:4f:22:5e:93:23 Uploading stub... Running stub... Stub running... Manufacturer: 0e Device: 4016 Detected flash size: 4MB Hard resetting via RTS pin...

The PCB was build using all the following design rules and experiences from Espressif, blogs, etc. Example: https://www.instructables.com/id/ESP-12F-ESP8266-Module-Minimal-Breadboard-for-Flas/

Also, we using several recomendations from videos of Andreas Spiess. @SensorsIOT and read post by @igrr.

image

The sensor, reads a value, then enter a deepSleep cycle until wakeups. All was working fine in more than 100 pcb!!!

After receiving the new batch, with the same PCB and CODE, the ESP hangs after wake up.

We already try 10 chips off the new bach, all have the same issue.

Trying this simple sketch:

MCVE Sketch


/**
 * An example showing how to put ESP8266 into Deep-sleep mode
 */

 #include <Arduino.h>
extern "C" {
#include <user_interface.h>
}

#define STATUS_LED  2   

void setup() {

  pinMode(STATUS_LED, OUTPUT);

  Serial.begin(74880);
  Serial.setTimeout(2000);

  digitalWrite(STATUS_LED, false);

  // Wait for serial to initialize.
  while(!Serial) { }

  Serial.print("Chip ID: ");
  Serial.println(ESP.getChipId());

  rst_info *rinfo = ESP.getResetInfoPtr();

  Serial.print(String("\nResetInfo.reason = ") + (*rinfo).reason + ": " + ESP.getResetReason() + "\n");

  Serial.println(".");  
  Serial.println("I'm awake.");

  delay(1000);

  Serial.println("Going into deep sleep for 3 seconds");
  ESP.deepSleep(3e6);    

  delay(5000);
}

void loop() {
}

Debug Messages ON WORKING CHIP

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 276350

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 276350

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

Debug Messages ON NOT WORKING CHIP

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 6198051

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

Hangs/Freeze until power down, or hard reset (button from RESET to GND).

Things we already try

Similar ISSUES

5892

2768

https://github.com/universam1/iSpindel/issues/59

Please HELP US!!! Can be a faulty batch?

monanto commented 5 years ago

How much is deep sleep current draw can you measure it ?

JensMunkHansen commented 5 years ago

Yes

JensMunkHansen commented 5 years ago

I could measure it but I am away for the next two weeks.

monanto commented 5 years ago

Nope Thanks For help I will order some from there and hope they works Regards

javiercuellar73 commented 5 years ago

Hi,

Basically, this is a hardware problem, isn't it? Any solution besides buying new one?

JensMunkHansen commented 5 years ago

One could try short-circuiting GPIO0 and reset directly on the chip... But, yes a hardware problem... Could be systematic

javiercuellar73 commented 5 years ago

I short-circuiting GPIO0 and reset but didn't work.

I attach 2 images showing the reset pulse on both a working and non-working ESP-12S . The images look the same. This means the pulse is correct... I will take out metallic part and see if there is any difference.

Sig2 Sig1

rdelcorro commented 5 years ago

I also got scammed with my latest batch of ESP modules from Aliexpress. What I have found is that the broken ones have a "DOIT.AM" string in the module shield and the others do not have it. I am hoping to find an answer to this issue and I will be opening and playing with one

tiagobortolini commented 5 years ago

Hi, Same here, and also have doit.am in de module.

hpflatorre commented 4 years ago

@devyte I am pretty sure this issue is related to the core library stack.

I've got a batch with more than a hundred clone ESP-12F modules with this odd behaviour. It doesn't matter how long or how close to 0V the pulse is, it only comes out of deep sleep after a second reset. If reset before entering deep sleep it runs fine with just one pulse. After entering deep sleep it always requires two reset pulses to properly wake up. The same binary works fine with other batches.

The new clue I'm adding to this thread is that if I flash the modules with this deep sleep example from Espressif (https://github.com/EspressifSystems/low_power_voltage_measurement) the modules will wake up from deep sleep properly!

So, it seems like this library may have some responsibility. I already tried the following:

  1. sleep with different sleep times;
  2. use the instant version;
  3. sleep with a mode other than the default;
  4. WiFi.disconnect() before deepSleep(), before seepSleepInstant() and even delay(5) in between those two calls;
  5. Perform Full Flash erase before flashing;

Now I will investigate differences between this core and Espressif's native SKD example.

d-a-v commented 4 years ago

@hpflatorre What version of this core are you using for your tests ?

In git version there is an example esp8266>WiFiShutdown.ino. Can you try it and report whether reset after deepSleep is still not working with your boards ? There is also #6484 that has fixed a number of incoherent behaviours, merged in current git version.

Are you already using git, or are you able to test with it ?

hpflatorre commented 4 years ago

@hpflatorre What version of this core are you using for your tests ?

In git version there is an example esp8266>WiFiShutdown.ino. Can you try it and report whether reset after deepSleep is still not working with your boards ? There is also #6484 that has fixed a number of incoherent behaviours, merged in current git version.

Are you already using git, or are you able to test with it ?

@d-a-v I was using stable releases and tested with 2.0.0, 2.4.2 and 2.5.2. Now I installed the latest git master version (#6625) and used this example 'esp8266>WiFiShutdown.ino'. I observed the same in three different cases:

  1. It won't boot properly after entering deep sleep and receiving the reset pulse from RTC. It will display the boot message "ets Jan 8 2013,rst cause:2, boot mode:(3,6)" and the program won't run until I make a second reset pulse manually;
  2. If I make the manual reset pulse soon after it enters deep sleep and before the programmed wake-up time (before 5s), the same will happen: it will give the boot message and do nothing until I pulse reset again;
  3. If I make a manual reset pulse during the program execution, before it enters deep sleep, it will always boot properly.

In the attached file there is the serial output of these three cases, where >>>>>> indicates my comments. ESP8266_WiFiShutdown_log_fail_to_wake_up.txt

Also, here is the chip info: esptool.py v2.6 Chip is ESP8266EX Features: WiFi MAC: dc:4f:22:5f:66:4e Auto-detected Flash size: 4MB Flash params set to 0x0340

d-a-v commented 4 years ago

And you have no issue with boards not from this batch of more than 100 ? Did you try to add a capacitor, another power supply, cable, capacitor, to read this story, to play with system_deep_sleep_set_option(0 or 4) => Esp.deepSleep(n, RF_DEFAULT or RF_DISABLED) (<= that one is done in the low power voltage espressif example) ?

nikolz0 commented 4 years ago

Hi, propose a simple test for deep-sleep. the test will exclude the SDK from the possible list. I have all modules work without problems. test_0x00000.zip

devyte commented 4 years ago

@nikolz0 thanks, but the bin by itself isn't very helpful. Could you please add the source files?

DamirKh commented 4 years ago

@nikolz0 thanks, it works! Sources, pls!

hpflatorre commented 4 years ago

And you have no issue with boards not from this batch of more than 100 ? Did you try to add a capacitor, another power supply, cable, capacitor, to read this story, to play with system_deep_sleep_set_option(0 or 4) => Esp.deepSleep(n, RF_DEFAULT or RF_DISABLED) (<= that one is done in the low power voltage espressif example) ?

@d-a-v The problem only manifests with the latest batch. It runs fine with other apparently identical boards. I've played with several large and small capacitors on the input and a different power supplies and batteries. Voltage levels are within recommended ranges and there are no voltage drops during boot. I am monitoring with a scope.

The Espressif's example I mentioned (https://github.com/EspressifSystems/low_power_voltage_measurement) is quite old and seems to use Espressif's SDK version 1.0.1b. The example uses the equivalents from this SDK:

@nikolz0 Your deep_sleep example also works perfectly fine on all the boards I have. I hope you provide some useful source code for us.

So, does this suggest an SDK issue?

nikolz0 commented 4 years ago

Hi, this test is written without SDK. The problem is most likely in the Deep Sleep function

I'm using my version of deep sleep function, which I'll post a bit later.

nikolz0 commented 4 years ago

Hi, I have to admit that the problem remains. On Wemos, my test stops working after a while. the reason has not yet found out.

nikolz0 commented 4 years ago

Hi, the problem occurs on boards that have an ESP mode control circuit. And there is no problem on the very first version of NODEMCU. The problem is on WEMOS. Note that the use of deepsleep mode on such boards does not make sense because the adapter consumes a lot. Therefore, the elimination of this problem makes only theoretical sense.

The problem is that the ESP mode control circuit is set to program mode at a random point in time. After that, it can be reset only by disconnecting the power from the module.

BotovNikita commented 4 years ago

Hi nikolz0 I have same problem, and your test.bin works fine! Can you give source code?

nikolz0 commented 4 years ago

Hi, it is my function deep_sleep. written in C:

void ets_wdt_disable(); void ets_delay_us(int);

define _R (uint32 *)0x60000700

void nk_deep_sleep(uint32 time) { ets_wdt_disable(); (_R+4)=0; (_R+17)=4; (_R+1)=(_R+7)+ 5; (_R+6)=8; (_R+2)=1<<20; ets_delay_us(10); (_R+39)=0x11; (_R+40)=3; _R &=0xFCF; (_R+1)=(_R+7)+(45(time>>8)); (_R+16) = 0x7F; (_R+2)= 1<<20; __asm volatile ("waiti 0"); }

hpflatorre commented 4 years ago

Nice @nikolz0. It works well within my application with all modules. Thanks a lot! I've let it run for an hour now waking up every 5 seconds. I'll leave it running on the problematic modules and confirm if it is stable soon.

The only problem though is that it always wakes up with WiFi enabled (RF_CAL option) and I need it to be able to exit deep sleep without WiFi also. t seems to ignore any previous calls to system_deep_sleep_set_option(RF_DISABLED); Could you please provide some insight on which register may control fr calibration at wake up? or at least point to the register reference you used? I can't decipher this function since I wasn't able to find any detailed register map for this address range.

Here is my C port of @nikolz0 deepsleep function correcting a few typos and embedding the ets functions:

#define ets_wdt_disable ((void (*)(void))0x400030f0)
#define ets_delay_us ((void (*)(int))0x40002ecc)

#define _R (uint32_t *)0x60000700
void nk_deep_sleep(uint64_t time)
{
    ets_wdt_disable();
    *(_R + 4) = 0;
    *(_R + 17) = 4;
    *(_R + 1) = *(_R + 7) + 5;
    *(_R + 6) = 8;
    *(_R + 2) = 1 << 20;
    ets_delay_us(10);
    *(_R + 39) = 0x11;
    *(_R + 40) = 3;
    *(_R) &= 0xFCF;
    *(_R + 1) = *(_R + 7) + (45*(time >> 8));
    *(_R + 16) = 0x7F;
    *(_R + 2) = 1 << 20;
    __asm volatile ("waiti 0");
}
nikolz0 commented 4 years ago

Hi, operator *(_R+4)=0; turns off WiFi. if you write in C then it can be inserted into the body of the function user_rf_pre_init().

theshadowsvk commented 4 years ago

@hpflatorre I tried your NK sleep but no matter what time I insert in your function, the esp sleeps and wakes immediately :-/ Can you help please ?

mfacen commented 4 years ago

This is really weird, I had a test module working with Deep Sleep for a month as I was developing on it, was a generic Wemos D1 Mini, no problems with waking up from deep sleep, D0/Reset connection just a short, no resistor or diode. I received new modules, also generic and when tried to flash the same source it started presenting the same symptoms as described in this thread. Then I try on the original module where it was working before with the old firmware: working... When I flash the new version of my firmware: not working, try to revert to my last commit when I knew the module was working and it doesnt anymore. What ??? Now none of the modules works. The difference I see is that in my case if I set the serial monitor to 74880 bauds when the module tries to wake up I just see garbage, not the normal ets Jan 8 2013,rst cause:2, boot mode:(3,6) or something of the sort. nikolz0 code doesn't change anything for me, the module seems to enter sleep fine but can't wake up properly. I find it so weird that my module that I used for a month while working on the software was working fine and then doesn't work anymore, I thought it might have been a espressif issue but tried to revert to 2.1.0 , 2.0.0, 1.8.0 as suggested on this thread and the module still can't wake up . What gives ? It is hardware then ? Was I just lucky with my test module working for a while ?

nikolz0 commented 4 years ago

Hi, I believe that the modules Wemos and Nodemcu worked in deep sleep, you need to disable the adapter and two transistors on the Board.

nikolz0 commented 4 years ago

Hi, rather, disable the control circuit mode, consisting of two transistors.

nikolz0 commented 4 years ago

To understand why the module stopped working, it is necessary to measure the voltage on GPIO0.

mfacen commented 4 years ago

Hi Nikolz0 thanks for the reply, and for posting the deep sleep function. I'll try to take out the transistors without damaging the board but my tools/eyesight are not the best for this kind of work. I took out the shield form one of the non working wemos but even with 25x magnification cant make out the numbers of the date on the ESP8266 chip, I can see it has a expressif logo but it looks pretty faint marking, I'm using 25x magnification. I dont have a digital osciloscope, just an old analog one so I can't record the reset signal but obviously there is something weird about this whole situation and that is: 

 If the module is in normal operation  and i press reset it resets.
 If the module is in deep sleep and I press the reset button it doesn't wake up but goes into zombie mode.

Doesn't that indicate that is has to be a software related issue ? I hope someone can figure this out, if there is a way to fix it. Just received 20 LOLIN V3 modules I was really nervous about those as I was not sure they were going to work as in my case without deep sleep they are useless, I just got them and tried out one and it worked, left it running for a while in a wake up cycle and now its not working anymore. They are marked LOLIN wemos.cc D1 Mini v3.1.0. I'm so frustrated I spent so many months working on this project and now that I was ready to deliver the circuits nothing is working and I got 20 useless boards ( plus the other 5 that aren't working either).

nikolz0 commented 4 years ago

Hi, Wemos is convenient to use for program development and debugging. But if you want to use deepsleep in your devices, you need to take ESP-12 modules (ESP8266) or modules ESP-M2 (ESP8285). Тo program them, use any USB-UART adapter, two resistors and two buttons.

mfacen commented 4 years ago

I know, the plan was to do a proof of concept with the 20 devices on our farms ( the application is temperature monitoring for a shrimp farm ) to work out all the software related issues, once they were tried we'd design a new board with the esp8266 for them. I'm going to try to lift the transistors of the control circuit and see if it makes a difference.

nikolz0 commented 4 years ago

Hi, I recommend paying attention to the ESP-NOW Protocol. If you use it instead of WiFi, the active time of the ESP when you Wake up from sleep can be reduced to 0.15 sec instead of 0.5-4 sec when WiFi.

nikolz0 commented 4 years ago

in my projects, the time of active work on the Wifi Protocol is about 0.25 sec, and on the ESP-Now Protocol 0.15 sec. The module operates from a solar panel without a battery at all.

nikolz0 commented 4 years ago

If you poll the sensor inside the boot, the current consumption can be reduced to 3-15 mA instead of 70 mA.

mfacen commented 4 years ago

The ESP-NOW protocol looks really interesting for creating a mesh of sensors but in my application each unit is independent of the others, I have in mind some sensors for a hatchery lab for shrimp where I was planning to use it but have not gone around to experimenting with it yet. From what I understand it is possible to use ESP-Now and regular TCP at the same time, is that correct ? My specific question is can a module communicate with another by esp-now while running an HTTP server for the user interface ?

nikolz0 commented 4 years ago

Yes, it is possible. The module can simultaneously work with Wi-Fi and ESP-NOW.

fsommer1968 commented 4 years ago

in my projects, the time of active work on the Wifi Protocol is about 0.25 sec, and on the ESP-Now Protocol 0.15 sec. The module operates from a solar panel without a battery at all.

How did you manage it to have only 250ms for WIFI operation after deep sleep? In my opinion it takes >500ms for WiFi calibration and AP assignment. Or how long is the time when the ESP is in deep sleep?

nikolz0 commented 4 years ago

Hi, Usually the connection time is from 540ms to 4 seconds. To get 0.25 sec you need to save the connection settings in RAM RTC and disable DHCP.

mfacen commented 4 years ago

Hey guys just popped back in to inform that after trying one of the 20 boards I received I got so frustrated that just put them aside for a while, today I tried other boards from the same batch and they did work as expected, I didnt try all 20 of them just about half and they all work, the one I tried first is still not waking up... This issue is quite annoying and would be great if someone gets to the bottom of it so we can identify the faulty modules somehow. From now on every time I order them Iḿ going to be wondering what I get...

hpflatorre commented 4 years ago

I don't know if this helps much to identify the faulty ones, but all modules I have with this issue have MAC addresses starting with dc:4f:22. All with this prefix have the problem. Modules with other prefix cc:50:e3 84:0D:8E 84:f3:eb 24:62:ab all work fine.

mfacen commented 4 years ago

Thats very interesting about the mac addresses, I checked and yes all the faulty ones start with dc:4f:22, the LOLIN that was not working starts with 84:f3:eb but I think its a fluke as now I tried the other 19 and they all work. The date marking on the ESP8266 indicate early 2018 : 072018, that would be week 7 of 2018. Well, considering the mac address and the dates I guess we can start figuring out the troublesome modules.

nikolz0 commented 4 years ago

Hi, Write in detail that does not work at ESP12. Show the circuit diagram and the terminal screen.

nikolz0 commented 4 years ago

Hi, Try flashing ESP12 with the DIO parameter instead of QIO. For firmware recommend NODEMCU FIRMWARE PROGRAMMER.

devluz commented 4 years ago

I have two D1 mini clones with this defect. Both have a mac starting with EC:FA:BC though. So far I can identify my broken modules by "DOIT.AM" printed on the shield over the ESP8266 chip.

Thanks a lot to @nikolz0 for the workaround and @hpflatorre for the C port. This is all way beyond my skills but at least I can use my modules for some experiments with the arduino IDE now :)

nikolz0 commented 4 years ago

I assume that in non-working ESP12 slow flash chips are installed, which do not have a Quad mode. Therefore, they must be programmed in double mode. I recommend for such modules to try to lower the frequency for flash.

devyte commented 4 years ago

slow flash chips

What is the flash brand? There is one known case where the flash requires special additional programming to reach max speed.

mfacen commented 4 years ago

Sorry about the delay, was travelling, I'm out of the country for a month so I dont have access to all my tools and I just took with me one LOLIN V3.0 to keep working and one of the faulty generic modules, I dont have the one I took apart here with me but I remember there were no markings in the flash chip. Now to continue with the weirdness the non working module I brought with me decided to start working suddenly and it worked fine for one day, now is back to going into zombie mode when trying to wake up from deep sleep. To be clear this is one of the modules with mac starting with dc:4f:22, but I dont have the "DOIT.AM" marking. The weird thing is that the module was stuck on zombie mode, I left it connected as I had to leave and when I came back it was waking correctly from deep sleep. That would explain how I got lucky and was able to use one of the faulty chips for a while and suddenly it started failing, I spent days trying to figure out where the problem was in my code as I thought I did something to break it. Very annoying...

genotix commented 4 years ago

Nice @nikolz0. It works well within my application with all modules. Thanks a lot! I've let it run for an hour now waking up every 5 seconds. I'll leave it running on the problematic modules and confirm if it is stable soon.

The only problem though is that it always wakes up with WiFi enabled (RF_CAL option) and I need it to be able to exit deep sleep without WiFi also. t seems to ignore any previous calls to system_deep_sleep_set_option(RF_DISABLED); Could you please provide some insight on which register may control fr calibration at wake up? or at least point to the register reference you used? I can't decipher this function since I wasn't able to find any detailed register map for this address range.

Here is my C port of @nikolz0 deepsleep function correcting a few typos and embedding the ets functions:

#define ets_wdt_disable ((void (*)(void))0x400030f0)
#define ets_delay_us ((void (*)(int))0x40002ecc)

#define _R (uint32_t *)0x60000700
void nk_deep_sleep(uint64_t time)
{
  ets_wdt_disable();
  *(_R + 4) = 0;
  *(_R + 17) = 4;
  *(_R + 1) = *(_R + 7) + 5;
  *(_R + 6) = 8;
  *(_R + 2) = 1 << 20;
  ets_delay_us(10);
  *(_R + 39) = 0x11;
  *(_R + 40) = 3;
  *(_R) &= 0xFCF;
  *(_R + 1) = *(_R + 7) + (45*(time >> 8));
  *(_R + 16) = 0x7F;
  *(_R + 2) = 1 << 20;
  __asm volatile ("waiti 0");
}

THIS WORKED FOR ME!! I'm using a WittyCloud with an ESP8266MOD

THANK YOU!!!

nikolz0 commented 4 years ago

Hi, *(_R + 4) = 0; - this command disables WiFi. The simplest solution is to put this command at the beginning of the program. I place my program inside boot, since Wifi is turned on after it works. If Wifi Is not required, then I send the ESP to sleep inside the boot.