ESP32: how to keep a pin high during deep sleep (RTC GPIO pull-ups are too weak)?

It's not clear that making the resistor change you propose will be effective at solving your problem.

The MCP160 requires that the enable input is taken below 20% of Vin to effectively switch the device off. If Vin is (say) 5 volts then 20% is 1.0 volts and, because the ULN2003 is a darlington, it may not reliably switch this low. However assuming it does switch lower than 1 volt then there is still the possibility that my guess about the value of Vbatt of 5 volts doesn't cover the low end of the range.

For instance if Vbatt is expected to work down to say 2 volts then you can only switch the MCP160 off if the enable pin is taken to less than 0.4 volts. This sounds all to close for my liking and I would recommend you think about the problem a bit more.


Well, sorry to revert my acceptance to the answer by Harry Svensson! And I shouldn't really be adding to a question that is 14 months old by now.

However I just found the perfect software solution, which would have saved the tankful of gasoline I eventually burned (sorry, nature!).

Instead of setting the pin to be pulled-up during deep sleep, you can use the pin hold feature to keep the pin to whatever state it was before sleep:

#include "soc/rtc_cntl_reg.h"
#include "soc/rtc.h"
#include "driver/rtc_io.h"
...
digitalWrite(pin, HIGH);
gpio_hold_en(pin);
...

That's all you need! The pin will be kept as a CMOS output, and strongly driven to HIGH or LOW, whatever you need.

I verified it with the following schematic:

schematic

simulate this circuit – Schematic created using CircuitLab

While running, the current measured is approx 110µA (as expected). During deep sleep, with the old code (in the question, that sets up a weak pull-up), the current falls to ~50µA (so the pull-up resistor value is in the 30k range). With the suggested code here, it stays 110µA.


Here's two other links of people who have tried. fail, probably fail.

So it doesn't look promising with solving it in software, as you have tried. So right now there's 3 failures, you and the 2 links.

Proposed solutions:

  • A) Burn a tankful of gasoline
    • Pro: Every device you fix you'll know be functional correctly.
    • Con: A lot of your time and money will be wasted on gas and driving.

  • B) Fix 1 device nearby and make a tiny tutorial for those who got your devices, pay them to solder a pull up resistor, e.g. follow the tutorial. Yes, pay them because they will be doing some work, work that you failed to do during the testing stage of your product.

    • Pro: This will be cheaper, and whoever that has the devices might think less of you professionally, but higher of you in terms of trust.
    • Con: Some people... just fail with simple things, including soldering. So there's a chance that someone will just ruin their device and have to buy another one off you, which you will give away for free, which might be a huge loss.

  • C) Do the same thing as B, but instead of telling whoever that got your devices to do the job, hire some random people who live nearby and can do it for you.

    • Pro: Whoever that has the devices will feel that you're professional.
    • Con: Whatever random person that solves your problem now knows how to properly mess with your instrument.

  • D) Do the same thing as C, but use friends (who might live nearby) or some colleagues instead of some randoms.

    • Pro: Whoever that has the devices will feel that you're professional.
    • Con: Your friends will think you're unprofessional.

  • E) Do what the user DoxyLover proposes, "Fix some units locally and ship them to your users, along with pre-paid return shipping labels so they can ship the originals back to you."


If I were you I'd go backwards, start with E. If that is not an option then continue with D, if you can't then go with C, if you can't then go with B and lastly go with A.

Tags:

Sleep

Esp8266