search

esp8266 / Arduino

ESP8266 core for Arduino
GNU Lesser General Public License v2.1
15.96k stars 13.34k 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?

fsommer1968 commented 5 years ago

Hi, although it would not solve right you problem, I recommend to set always the correct pinmode for GPIO16 during setup() which is in my opinion (D0 refers to GPIO16): pinMode(D0, WAKEUP_PULLUP); Since I have no bad experience with deep_sleep (I´m using it exensively with battery powered applications) I don´t know if a deeper look into the pinmoode for GPIO16 helps. In your sketch there is no configuration for GPIO16.

petrilloa commented 5 years ago

Hi @fsommer1968. Thanks for the suggestion. We also try pinMode(D0, WAKEUP_PULLUP); isn't working.

fsommer1968 commented 5 years ago

In addition check the correct SPI flash mode for the flash rom!

petrilloa commented 5 years ago

Hi @fsommer1968, we already try QIO and DIO, and check with esptool. No changes, still hangs on wake up.

devyte commented 5 years ago

@petrilloa the fact that the same pcb and code work ok with one batch and not with another is a strong hint that the second batch is likely bad somehow. I am closing this, because I see from the posted logs that the code actually goes through the first execution sequence, which I think rules out an issue from the different manufacturer code, and hence our core code.

Some hints for you:

  1. What happens if you sleep with different sleep times? (don't go over the max)

Consider this:

void deepSleep(uint64_t time_us, RFMode mode = RF_DEFAULT);
void deepSleepInstant(uint64_t time_us, RFMode mode = RF_DEFAULT);
  1. What happens if you use the instant version?
  2. What happens if you sleep with a mode other than the default?
  3. What happens if you WiFi.disconnect() before deepSleep()? before seepSleepInstant()? If you e.g.: delay(5) in between those two calls?

Also: -Are you sure that the new batch has the exact same pin definitions as the previous working ones? I have seen gpio misnumbering and changes between factories. I suggest testing that what you think is gpio16 actually is gpio16. -I suggest looking at the pulse coming out of gpio16 (connected to RST) with an osc, and compare the signal from the good batch vs. the new bad batch. -I seem to remember reading somewhere that the pulse coming out of gpio16 on sleep expiration sometimes required some delay or some timing or something. I don't remember the details, and I didn't find the reference after a quick search. I mention this because you said you are resetting by RST, which is the same thing the gpio16 pulse is supposed to be doing, which would make me suspect either timing or signal strength.

Closing as not a core issue.

petrilloa commented 5 years ago

@devyte, I understand that you close it for apparently not being a specific problem of CORE, however I will continue to add information, since in different posts, on different platforms (not only GITHUB) I have seen this error, and never with a specific resolution ( taking out cases where there was a clear problem in the hardware connection)

  1. What happens if you sleep with different sleep times? (don't go over the max) Checked, same result

void deepSleep(uint64_t time_us, RFMode mode = RF_DEFAULT); void deepSleepInstant(uint64_t time_us, RFMode mode = RF_DEFAULT);

  1. What happens if you use the instant version? Checked, same result

  2. What happens if you sleep with a mode other than the default? Checked, same result

  3. What happens if you WiFi.disconnect() before deepSleep()? before seepSleepInstant()? If you e.g.: delay(5) in between those two calls? Checked, same result

Also: -Are you sure that the new batch has the exact same pin definitions as the previous working ones? I have seen gpio misnumbering and changes between factories. I suggest testing that what you think is gpio16 actually is gpio16. Checked, is physically the same

-I suggest looking at the pulse coming out of gpio16 (connected to RST) with an osc, and compare the signal from the good batch vs. the new bad batch. _Checked, i was getting some trouble using and old osc but can manage to see the reset pulse:

image

-I seem to remember reading somewhere that the pulse coming out of gpio16 on sleep expiration sometimes required some delay or some timing or something. I don't remember the details, and I didn't find the reference after a quick search. I mention this because you said you are resetting by RST, which is the same thing the gpio16 pulse is supposed to be doing, which would make me suspect either timing or signal strength.

I read the same

https://www.esp8266.com/viewtopic.php?f=6&t=17975

But, i it seems to be a different board ESP12S... maybe the same problem?

devyte commented 5 years ago

That sounds like the same problem i remember, but I'm pretty sure it's not the post i saw, and it wasn't a 12s but rather a clone board of a 12F. If i were you i would do something similar as explained in that pist: rip open one of the shields and measure the pulse directly at the rst pin of the EX chip.

WillowBeard commented 5 years ago

I'm having the same issue with my newly arrived ESP12-F (ESP12MOD, containing ESP8266EX) boards. The chip does not wake up from deepsleep properly. Also, even when resetting by shorting rst to gnd there is no proper reset. Reset consistently works when "pressing the rst button" twice. Therefore I'd assume this is not a problem of the signal given by GPIO16 but something else?

petrilloa commented 5 years ago

Hi @WillowBeard, i think so. I also noticed that some times the bad chips needs pressing the reset button twice. I'm waiting for the factory for a replacement (we bought 150 pcs of them... So we are very worry about this). We are thinking that maybe are a cheaper clone of the original ones. I will have news soon.

WillowBeard commented 5 years ago

Hi @petrilloa, thanks for the quick reply. I also bought 15 of these. Really hoping to find a solution to this since the deep sleep functionality is crucial to most of my projects. Would you care to compare the exact labelling of the chips? Mine says "ESP8266EX, 492018, UB00PK7F11. The chip is marked with the espressif logo. Addition: I had some NOdeMCU developement boards lying around. I tested two of them, one is working properly with deep sleep/wakeup, the other one does not. I opened both of them up to check for the data given on the chips. The faulty one says "ESP8266EX, 502018, UB00PK7F17". The other one (working) says "ESP8266EX, 222018, TUBOTWTF10". I guess, the second line has something to do with the time they were manufactured. Probably week/year. The faulty ones are both manufactured end of 2018, while the working one seems to be much older (222018). This fits the pattern you observed. It would be interesting to find out from when to when this problem started. I will now go on and contact the seller (on AliExpress) but I'm not too optimistic about that. Did you contact Espressif about this? Sorry if I missed that. Cheers, WillowBeard

petrilloa commented 5 years ago

Hi @WillowBeard, Where are you checking the exact labelling? You need to unsolder the RF Shield to see the actual ESP8266? I can't do that, because i need to send back the chips to the provider. I didn't contact Espressif itself, maybe i will try with them also. Regards

WillowBeard commented 5 years ago

Yes, I removed the shielding. I see, if you need to send them back you obviously can't do that... Do you think they will notice if one is missing? (Just kidding...)

petrilloa commented 5 years ago

@WillowBeard, can you check the ESP12 circuit (not the ESP8266) for this: image

I ended up removing the shields on both the ESP-12S and ESP-12E to try to track down the differences. There is one major difference that, so far, has not been documented anywhere (even by AI-Thinker).

The schematics of the modules that have been floating around are not 100% correct. Even the schematic from the AI-Thinker documentation for the ESP-12E is incorrect.

In the ESP-12E module, there is a series resistor (about a 450 Ohm) in series between the RST pad and the EXT_RSTB of the ESP8266. There is also a 12k pull-up and some value capacitor. Seems like the RC circuit slows the rise time for the reset. This 450 Ohm resistor doesn't exist in the ESP-12S module which isn't documented anywhere.

Image from this post: https://www.esp8266.com/viewtopic.php?f=6&t=17975

Also, do you have an osciloscope? According to the same post, there is a difference on the RESET pulse. I can´t check that in my batch.

image

WillowBeard commented 5 years ago

Hi @petrilloa, I am definitely going to do this. I have access to a scope, but it's a pretty old model. I will attempt to measure it and let you know when I got the result (likely on Wednesday). I will also try and short the series resistor (if present) to check if this is the reason for the trouble.

WillowBeard commented 5 years ago

Short update: I didn't manage to look at the signal on the rst pin yet. However I measured there is a 470 kΩ resistor between the rst pad and the rast pin. I tried putting a 470 Ω in parallel, which had no effect. There is also a 12 kΩ pull-up resistor on the rst pin and some capacitor. So the circuit looks ver much like in the post linked above. Since the capacitor should be responsible for slowing the voltage change down, I tried to remove the capacitor. This didn't lead to any change. I contacted the seller (on aliexpress) and was granted a refund without further ado. This looks to me like they know about this problem... I'm still trying to measure the actual wakeup signal and will give an update when successful. @petrilloa did you hear anything new from your supplier? cheers

torntrousers commented 5 years ago

I've used a bunch of ESP-12S's with deep sleep and they've worked ok, though they were all bought at least a year ago so its possible something has been changed.

Would you try adding WAKE_NO_RFCAL to the deepSleep call - ESP.deepSleep(3e6, WAKE_NO_RFCAL) ?

WillowBeard commented 5 years ago

hi @torntrousers, thanks for your suggestion. I tried it, but it doesn't seem to change anything. By the way, I also observed a wild voltage oscillation on GPIO00 when in "zombie mode". I tried to put a capacitor between I/O00 and GND with no effect. A 10k pullup resistor on GPIO00 gives 2.7 V on the pin. I suspect there is something wrong with the chip itself, but I am thankful for other suggestions. cheers

petrilloa commented 5 years ago

Hi @WillowBeard,

I also detect the voltage oscillation on GPIO0 when is in "zombie mode". Somewhere i read about the internal clock signal from the ESP.

https://www.esp8266.com/viewtopic.php?f=160&t=16248 https://bbs.espressif.com/viewtopic.php?t=1485

The older ones, don't have this issue neithe

Our supplier is sending a new batch of ESP12F (from AI as the said). I´m going to post news when them arrive.

My biggest concern is how to identify devices with this behavior in advance. If it is a problem of the different factories that produce the ESP8266, and save money on a couple of simple components, it is an unreliable chip to make products using deepSleep (and not because of Espressif directly, but by those who end up making the ESPXX using his chip). In principle, the only alternative is to make sure with the supplier that the chips are NOT clones (they have been offered to me) but, from some of the most important factories. There are differences of a few cents between the "original" chips and the "clones" (as they call them), which do not justify all these headaches in any way.

devyte commented 5 years ago

Has anyone measured that the capacitor is good? Has anyone tried increasing the 470R a bit or increasing the capacitor to have a bigger delay time to RST? Decreasing to have a shorter delay time? I would use a pot to play with the values. Has anyone tried a different delay method, e.g. a 555? Again, different values to adjust the delay might give insight.

WillowBeard commented 5 years ago

hi everyone, I finally found the time to measure the signal on the rst pin. wake up signal The reset pin is pulled down to approx. 0.4 V. The pull down pulse has a duration of about 35 us (from start of pull down to the lowest voltage). From start of the pull down until it is back to 3v3 it's 45 us. This is about twice as fast compared to the post @petrilloa quoted above.

Has anyone measured that the capacitor is good?

I didn't measure the capacitor directly, however I think the waveform indicates, that it is ok (please correct me if I'm wrong). Since I get the same result when triying to wake up from reset by manually pulling rst to gnd, I don't think the short pull down signal is the problem. However, the rising part of the voltage curve might be related to the problem. But I really don't think so... Is it possible, that the RST is not pulled low enough? Could the "remaining" 0.4 V cause a problem like this?

Another observation I made: The gibberish in the serial monitor, that appears when waking up appears even when GPIO16 is not connected to RST and the board goes into the zombie-like state as well. Might this indicate that the actuall error happens before the reset pulse is performed by GPIO16? Also, I received three Wemos D1 mini boards today. They show the same error pattern.

petrilloa commented 5 years ago

Hi @WillowBeard .

First of all, to get ride of the gibberish in the serial monitor, you can set the serial monitor speed on 74880 bauds. In that way, yo can get the messages that the ESP is sending

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

The time of the pulse, seems WRONG, according to this https://bbs.espressif.com/viewtopic.php?p=5027#p5027

RESET is level trigged and the hold time of low voltage needs to be at least 100us.

Also, the level of LOGICAL LOW must be between like this

image

http://henrysbench.capnfatz.com/henrys-bench/arduino-projects-tips-and-more/esp8266ex-gpio-high-and-low-input-thresholds/

So, i think the issue is with the DURATION of the pulse.

Can you check the pulse, with one of the GOOD chips?

WillowBeard commented 5 years ago

I will check this, however I excluded this explanation (that the pulse is too short) since grounding RST even for seconds also leads to a false start into "zombi mode".

girtskagis commented 5 years ago

I have ESP-01 which works perfectly with deep sleep. Recently I got Lolin V0.1(ESP-12E) and it did not wake up. I removed metalic shield from Lolin and found that it has 460ohm in series of rst before filter. This is how the reset pulse looks on oscillator on EXT_RSTB pin(RESET). Yellow shorter one is on ESP-01. White on Lolin. Then I bypassed the resistor and got the same shorter pulse. Unfortunately it did not solve this problem. I have no idea what could be the solution...

IMG_4874 IMG_4877 IMG_4872 IMG_4873

petrilloa commented 5 years ago

Hi @girtskagis can you tell us what picture/logo has the esp12E shield? (Espressif, AI). Also, can you send the LOG of serial monitor on wake up?

Thanks! PD: Great that you can reproduce the pulse on the LOLIN one!

WillowBeard commented 5 years ago

This is what I get on first, normally working boot:

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

Then, when the deepsleep timer expires, I only get this:

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

If i remove the connections from GPIO16 to RST, I get this instead:

ets Jan  8 2013,rst cause:5, boot mode:(3,6)
ets_main.c

I am wondering, if this could have something to do with faulty flash memory or something like that?

mhightower83 commented 5 years ago

FWIW Here is a schematic for the ESP-12S that shows no 470 Ohm resistor in series with JP1 to EXT_RSTB. I also noticed that CHIP_EN now has a 12K Ohm pull-up. Then, the schematic for the ESP-12F with the 470 Ohm resistor.

petrilloa commented 5 years ago

The new ESP12F from AI arrived... and they WORK!

The only thing I have left to think is that the other chips were clones and they did not have the internal components necessary to handle wakeup pulse correctly.

However, in the post of @girtskagis, we see that he could reproduce the problem with a LOLIN board (within a recognized manufacturer). It is strange that LOLIN uses ESP12 generics or clones. Hopefully you answer to identify if it is ESP of AI or ESPRESSIF.

Can you get in touch with LOLIN to talk about the issue?

ximik666 commented 5 years ago

There is Wemos D1 mini . Does not come out of deep sleep. Contacts are connected as it should. After some time, the garbage comes out to the console and that's it.Did you find any solution?

girtskagis commented 5 years ago

@petrilloa This is the shield on Lolin V0.1 lolin

The log when it works before deep sleep:

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v21db8fc9
~ld

Then after wakeup in zombie mode: ets Jan 8 2013,rst cause:2, boot mode:(3,6)

Will have to wait when ESP-12F arrive!

girtskagis commented 5 years ago

Also this isn't genuine Lolin board, it is cheap ALiexpress board.

WillowBeard commented 5 years ago

@petrilloa that's great news! I stillt hope to find a solution to the problem, but I'm not very optimistic anymore. Could you let me know, where you got the working modules from?

petrilloa commented 5 years ago

@WillowBeard, worry for the delay. https://www.kuongshun-ks.com/

The contact is Darren. darren@szeft.net

docm64 commented 5 years ago

@WillowBeard , I have exactly the same issue on a D1 mini clone I baught recently. Did you find a solution? I observed the following: Once the module is in deep sleep, a pulse on RST will not properly reset the chip. I get the same messages as you reported, including the strange "ets_main.c" in case of missing D0-RST link. A second pulse is needed to reboot properly. I am wondering what is happening here. The fact that there are messages from the boot loader would indicate to me that the ESP8266 is starting but then something goes wrong and the program is not loaded. Any suggestions?

girtskagis commented 5 years ago

Got mine ESP-12F from Aliexpress and they work. Wake up and everything!

docm64 commented 5 years ago

Great for you, but doesn't solve my problem. I want to understand what is going wrong, if there is a workaround in software or hardware. Otherwise it is just a matter of luck (production batch, tolerances, environmental conditions?) whether it works or not.

WillowBeard commented 5 years ago

hi everyone, first of all thanks for the info @petrilloa. I baught all my boards off aliexpress too, but that doesn't contain any information really, since aliexpress is just the platform. I got my bugged modules from a shop called "advanced tech" on ali. I have now ordered new modules from XM (ShenZhen) Electronic Trade Co. (also Aliexpress). They state that "authenticity [is] guarateed". We'll see about that... I will give an update, when I learn anything new. @docm64: Is there an AI logo on the shielding of your boards? Unfortunately I don't have any other idea but that the problem is an internal hardware issue. The malfunctioning boards all have chips from batch 50/2018 and similar. Did you by any chance remove the shielding and have a look at the numbers on the chip itself? @girtskagis From what shop did you buy exactly? cheers WB

devyte commented 5 years ago

has anyone tried exaggerating the rc constant to get a longer length pulse on RST? has anyone tried a real pulse delay circuit, like with a 555, to play with the width of the low pulse? I'm thinking of the minimum time the RST must be held low.

girtskagis commented 5 years ago

@WillowBeard Here is the link to Ali ESP-12F that worked for me:

https://www.aliexpress.com/item/5PCS-2015-New-version-ESP-12F-ESP-12E-upgrade-ESP8266-remote-serial-Port-WIFI-wireless-module/32695678523.html?spm=a2g0s.9042311.0.0.4f3d4c4dPF7hNm

@devyte I only shortened the RST pulse on faulty ESP to recreate RST pulse width from working one. (I probed it at the QFN packages RST pin.) Did not change anything. I also tested the RST filter/pullup , but it seems close to the working one. May be the PCB design is bad(some bypass cap not connected or smt else.)

devyte commented 5 years ago

I'm not thinking of getting the waveform of the bad modules close to the good ones, but rather of doing a better job of emulating a pressing of the reset button in different ways, because that obviously works. My reasoning is that, if there is some requirement fir holding RST low for some time, abd nobody is adhering to it, then maybe the good modules have a looser time due to e. g. internal component quality, while the bad modules need a longer or cleaner pulse to accomplish the same thing.

docm64 commented 5 years ago

I tried this approach, but when I press the reset button while the module is in deep sleep, the module will not reboot but change to Zombie state in exactly the same way as it does when GPIO16 tries to reboot it after the deep sleep period. The result is exactly the same, irrespective how long I press reset. I read about many attempts to change the timing of the reset pulse but none of them has been reported successful. However I made the following observation: Pressing the reset button twice during deep sleep let the module boot the application again. Now I try to build some simple circut that shall double the GPIO16 pulse. Two pulses insetead of one. Will keep you posted if that brings success.

liebman commented 5 years ago

@docm64 my only question with that is if it will still preserve RTC memory as deep sleep does.

JensMunkHansen commented 5 years ago

I have made some experiences, which may be related to this. Perhaps someone in this thread could help me out.

I use a DFRobot WiFi Bee v1.0 and according to their diagrams, they have connected both GPIO16 and RST, so I have short-circuited them.

With GPIO16 and RST short-circuited, I get

19:05:51.477 -> Going to sleep. 19:06:20.344 -> 19:06:20.344 -> ets Jan 8 2013,rst cause:5, boot mode:(3,0) 19:06:20.344 -> 19:06:20.344 -> ets_main.c

Without short-circuiting, I get almost the same except for

19:06:20.344 -> ets Jan 8 2013,rst cause:5, boot mode:(3,7)

I read somewhere that 7 means UART1 boot and 0 means Remapping.

Question: Why rst cause:5. Could this be that DFRobot has forgotten to connect the RST or the GPIO16 signals? The funny is that I get a different answer depending on whether I short-circuit the signals.

Thanks in advance Jens

monanto commented 5 years ago

Having same issue with d1 mini https://www.aliexpress.com/item/32643142716.html

fsommer1968 commented 5 years ago

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

monanto commented 5 years ago

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

Yes but the clones i bought few months back work fine and support deep sleep

JensMunkHansen commented 5 years ago

Hi Monato

I just bought a cheap wemos clone. Looks exactly like yours, 2.5USD and it works as anticipated. I will try to power my dfrobot bee using a battery instead of the FDTI adapter to see if it works. Thanks for sharing

On Mon, May 27, 2019, 07:37 monanto notifications@github.com wrote:

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

Yes but the clones i bought few months back work fine and support deep sleep

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/esp8266/Arduino/issues/6007?email_source=notifications&email_token=ABQJKYSZBRXSRZNZWJZAJZDPXNXRZA5CNFSM4HHT54AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWI2EDY#issuecomment-496083471, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQJKYTT3ICUMIABNUGVZ6TPXNXRZANCNFSM4HHT54AA .

monanto commented 5 years ago

From which store can you send link ?

JensMunkHansen commented 5 years ago

https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.6.2.69004c4dQ6aWtc&orderId=101997752945128&productId=32963167122

JensMunkHansen commented 5 years ago

I have only verified the deep sleep functionality since this was the issue on my DFRobot bee

monanto commented 5 years ago

this product and store right ? https://www.aliexpress.com/item/32963167122.html