Who can confirm deep sleep alarm wake on D1 mini boards

[kwiley]

I'm trying to get a sense of how pervasive the D1 mini deep sleep error is, in which the D1 mini doesn't properly reset when waking with an alarm from deep sleep (described at https://github.com/esp8266/Arduino/issues/6007). How many people here have used MicroPython on a Wemos D1 of any model. Which model (and which version of that model) were you using, and have you tested waking from deep sleep with an RTC alarm?

Thanks.

[Christian Walther]

I have two Wemos D1 mini v2.1.0 here, to my knowledge original ones from Wemos. They have some ESP-12 module with “WeMos” on the metal shield. They work properly as far as I can tell: When GPIO16 and RST are externally connected, waking from deep sleep using the RTC works as expected (using the code from http://docs.micropython.org/en/latest/e ... sleep-mode on the serial REPL). When GPIO16 and RST are not connected, they surprisingly still wake up at the right time, but into what appears to be the zombie state described in the mentioned iissue. Pushing the reset button is then needed to properly reset them, but machine.reset_cause() still reports DEEPSLEEP_RESET.

There does not seem to be a direct connection between GPIO16 and RST on the board, I measure infinite resistance, but a capacitance on the order of µF, which is apparently sufficient to transmit a weak reset pulse.

[jomas]

There does not seem to be a direct connection between GPIO16 and RST on the board, I measure infinite resistance, but a capacitance on the order of µF, which is apparently sufficient to transmit a weak reset pulse.

Of course there is no connection between GPIO16 and RST. People also want to use GPIO16 as a normal GPIO. And why use a capacitor if a wire works?

[Christian Walther]

That was just me trying to figure out / guess why the MCU would (half-)reset even without the connection. The capacitor is not one I am placing, but must be one that’s on the board (or the module) already. I can’t tell the exact connections from looking at the board because the module obscures the traces, and was too lazy to find a schematic (the current Wemos docs only have one for v3.1.0, which no longer uses a module).

[kwiley]

It isn't immediately and necessarily clear that one should need to connect GPIO16 to RESET to enable wakeup on the reasoning that people might want to use the pin for another purpose. We are at least two levels of abstraction removed from the chip. Sure, on the ESP8266, you have to connect them directly, a feature which enables users to reassign GPIO16 to another role. But perhaps assumptions are built into higher-level products to ease use. There is the question of whether you still have to make the connection on an ESP-12S/E/F, since perhaps that module would be designed to facilitate wakeup more easily and assume users will use the numerous other pins for other purposes. Or, perhaps not and the ESP-12F is still low level enough to require the user to make the connection, but there's another level of abstraction. We are talking about the D1 mini here, a board that itself incorporates the ESP-12F (which then incorporates the ESP8266). Perhaps the design of the D1 mini is intended to be so user-friendly and distanced from the underlying chip as to make the connection already, obviating the need for the user to do so.

After all, each level of abstraction adds additional components all over the board. The ESP-12 modules are full of resistors and capacitors that aren't in the ESP8266, and the D1 mini is full of yet more such components again.

So, it is reasonable to be at least a little unsure whether these kinds of connections are already made on the board. The same thing goes for the various pull-ups and pull-downs that are required to boot the chip into various modes. Does the chip have them? Well no, but does the 12F? Maybe/maybe not. What about the D1 mini that uses the 12F? Again, maybe/maybe not. We can't just be sure about these things off the bat as an upfront presumption. It requires actually figuring out the answer somehow.

So when the boards behave in erratic ways, erroneously, and to make matters worse, differently between individual boards of the same model, it becomes that much more crucial to be really sure what connections already exist and what connections are required of the user in order to get certain functions to work.

Cheers!