I have two D1 minis, obviously running MicroPython, which exhibit a widely experienced problem in which they don't properly wake from deep sleep. I am forced to physically press the reset switch twice to recover a REPL (curiously, if I tie D0/GPIO16 to RESET, then a single push to RESET does the trick; also manually connecting RESET to ground provides similar assistance with this problem). This problem has been thorough explored by the Arduino community and is extremely difficult to fix. Simple things like tying D0/GPIO16 to RESET don't work. It was also recommended to configure the flash as dio instead of qio during flashing. That doesn't work. Various pull-ups on various pins and other resistor solutions have been tried. Removing resistors and caps from the boards have even been tried. People have oscilloscoped the signal coming off D0/GPIO16 to RESET and although variations are discovered, obviously solutions remain elusive. Trust me, anything you might casually suggest here has been tried. If you want to thoroughly comprehend this problem, I suggest wading through the following discussion, which is one of the best I've found:
https://github.com/esp8266/Arduino/issues/6007
Part way through the discussion, the closest anyone has come to solving the problem is described in the following comment:
https://github.com/esp8266/Arduino/issu ... -542053557
and this follow-up that cleans up the code a bit:
https://github.com/esp8266/Arduino/issu ... -542192213
Those solution involves changing the implementation of deep_sleep(). My question is, what are the options for incorporating the proposed solution into the MicroPython firmware? Without some solution, perhaps the one shown above, certain ESP8266 boards (ESP-12S, ESP12-F, and the D1 mini that relies on those) simply cannot use deep sleep. To make matters worse, it's a bit of a crap shoot to buy new board and simply hope they will contain some sort of new architecture that makes the problem go away, which means one can't confidently buy these boards with any hope of using MicroPython on them reliably (at least the deep sleep feature). I'm studying the MicroPython codebase right now, trying to learn what would be involved in implementing this change, but I'm completely new to making such low-level changes in MicroPython (I've never attempted any MicroPython firmware change yet; I currently use MicroPython but haven't delved into altering MicroPython itelf).
Thanks.
Firmware support for D1 mini deep sleep problem
Firmware support for D1 mini deep sleep problem
Last edited by kwiley on Mon May 18, 2020 6:04 pm, edited 1 time in total.
Re: Firmware support for D1 mini deep sleep problem
GPIO0 should always be high when you reset and if you want a normal start. If it is low on reset your ESP will go into flashmode.
To use the deepsleep you must connect GPIO16 to reset. Then it will work as expected.
The deepsleep is a SDK function and has nothing to do with MicroPython so you will not be able to 'fix' this problem in MicroPython.
The problem that occurs looks to be the consequence of a bad hardware design. That is where it should be fixed.
Btw. I have never heard of, or experienced this problem. A lot of people use deepsleep without problems. (Maybe a bad batch of ESP's?)
To use the deepsleep you must connect GPIO16 to reset. Then it will work as expected.
The deepsleep is a SDK function and has nothing to do with MicroPython so you will not be able to 'fix' this problem in MicroPython.
The problem that occurs looks to be the consequence of a bad hardware design. That is where it should be fixed.
Btw. I have never heard of, or experienced this problem. A lot of people use deepsleep without problems. (Maybe a bad batch of ESP's?)
Re: Firmware support for D1 mini deep sleep problem
My apologies. Where I wrote GPIO0 above, I meant D0 on the D1 mini, which is GPIO16. Ugh. The pin aliases get confusing. I've edited my original post to correct the mistake. Moving on...
Are you sure about hard-wiring GPIO16 to RESET? There are at least two levels of abstraction from the 8266 here. I think you're just describing the ESP8266, but I'm talking about, and one level of abstraction, the ESP-12F that incorporates the ESP8266, and another level, the D1 mini, which incorporates the ESP-12F. Are you saying that you know for a fact that on the D1 mini, we must explicitly connect D0 (GPIO16) to RESET in order to get deep sleep wakeup to work? Are you really saying that?
It is already acknowledged in the thread referenced above (and other discussions) that there is a bad batch of hardware floating around that suffers the described problem. That has already been established. I wasn't suggesting that MicroPython had a bug in it. I was saying that someone on the Arduino discussions had found a solution to the problem by altering the deep_sleep function and I was asking about the possibility of bringing that change into the MicroPython stack so that these problematic chips or boards can still be use with MicroPython.
All that said, if you saying the problem is in the SDK code, not the MicroPython code, that doesn't preclude the possibility of rebuilding MicroPython using the altered version of the SDK. It just means that the change itself wouldn't be in the higher level MicroPython or C routines, but rather would consist of using an SDK altered in the way described in my first post to build the MicroPython firmware.
So, thanks for clarifying that the change is in the SDK used to build MicroPython, but is not necessarily in the MicroPython codebase. That means that in order to fix this problem, not only must one first ramp up on building MicroPython, but must also ramp up on building the SDK. Sheesh. It's getting increasingly low-level to fix this issue. The problem is that without finding a solution, it's just a wild gamble to buy ESP-12Fs and/or D1 minis. It is impossible to know if I will receive defective units. I have two so far and they came from completely different purchases from different venders and manufacturers, and they both exhibit this problem. So I don't trust buying any ESP8266 devices now. I have no particular confidence that they will be able to deep sleep properly.
Are you sure about hard-wiring GPIO16 to RESET? There are at least two levels of abstraction from the 8266 here. I think you're just describing the ESP8266, but I'm talking about, and one level of abstraction, the ESP-12F that incorporates the ESP8266, and another level, the D1 mini, which incorporates the ESP-12F. Are you saying that you know for a fact that on the D1 mini, we must explicitly connect D0 (GPIO16) to RESET in order to get deep sleep wakeup to work? Are you really saying that?
It is already acknowledged in the thread referenced above (and other discussions) that there is a bad batch of hardware floating around that suffers the described problem. That has already been established. I wasn't suggesting that MicroPython had a bug in it. I was saying that someone on the Arduino discussions had found a solution to the problem by altering the deep_sleep function and I was asking about the possibility of bringing that change into the MicroPython stack so that these problematic chips or boards can still be use with MicroPython.
All that said, if you saying the problem is in the SDK code, not the MicroPython code, that doesn't preclude the possibility of rebuilding MicroPython using the altered version of the SDK. It just means that the change itself wouldn't be in the higher level MicroPython or C routines, but rather would consist of using an SDK altered in the way described in my first post to build the MicroPython firmware.
So, thanks for clarifying that the change is in the SDK used to build MicroPython, but is not necessarily in the MicroPython codebase. That means that in order to fix this problem, not only must one first ramp up on building MicroPython, but must also ramp up on building the SDK. Sheesh. It's getting increasingly low-level to fix this issue. The problem is that without finding a solution, it's just a wild gamble to buy ESP-12Fs and/or D1 minis. It is impossible to know if I will receive defective units. I have two so far and they came from completely different purchases from different venders and manufacturers, and they both exhibit this problem. So I don't trust buying any ESP8266 devices now. I have no particular confidence that they will be able to deep sleep properly.