ESP32 Forum

Hi!

my setup contains a 3.3V powered ESP-WROOM-32 module on a component-free adapterboard, together with a SPI connected ePaper driver board (https://github.com/RobPo/Paperino, see attachment).

When putting the ESP-WROOM-32 alone to deep sleep it consumes about 5µA @3.3V, thats great!
When putting the ePaper driver board alone to deep sleep it consumes about 5µA @3.3V, thats great too!

However, when putting the ePaper driver board to deep sleep, and then afterwards the ESP32; the current appears to increase from 5µA to somewhere around 500µA... as if it is flowing somehow through the SPI GPIOs? Does anyone has an idea how to prevent this?

Thanks in advance.
Robert

Are you sure you don't have a pull-up or pull-down eating power somewhere? A resistor of 6.8K or so would eat the 500uA you're measuring.

a schematic of how you have things connected would help.

Below a simplified sketch of ESP and the SPI connected ePaper module (consisting of the UC driver IC & BMA250).

There are no external pull-ups connected and the USB2serial Programmer is disconnected.

I tried the following sequence and measured the current flowing into UC+BMA250 step by step (with delays):

Power-On - 500µA
SPI.begin() - 160µA (OK)
UC+BMA250.deepSleep() - 5µm (OK)
SPI.end() - 500µA (NOK)
ESP.deepSleep - 500µA (NOK)

So it seems the that 500µA are always flowing before definition of SPI.begin() and after calling SPI.end().

It's nice that you have this on a breadboard, because it will make it easy to isolate the problem.
The way I would first tackle this is first to bring UC's CSA pin to +3.3v. If no uA change then bring BMA's CLS to +3.3v. IF still no change, then then disconnect the MOSI line, then MISO, then CLK, to see which device or wire is causing the problem. From there you can get a game plane on what could be done.

Another thing you could try in software, is to turn all your GPIO's your using to inputs before going to sleep.
I have not looked to see if there is configurable pull-ups or pull-downs you can enable per pin, but if there is, make sure neither is active, basically HI-Z state.

OK here more results after trying different pinModes in combination with two deep sleeping SPI connected devices:

Power-On - 500µA
SPI.begin() - 160µA (OK)
UC+BMA250.deepSleep() - 5µm (OK)
SPI.end() - 500µA (NOK)
pinMode(pin_xy, INPUT_PULLUP) - 5µA (OK)
pinMode(pin_xy, OUTPUT) - 500µA (OK)
pinMode(pin_xy, INPUT) - 500µA (OK)
pinMode(pin_xy, INPUT_PULLUP) - 5µA (OK)
ESP.deepSleep - 500µA (NOK)

So by setting the GPIOs to INPUT_PULLUP I can measure the expected low current.
However, when enabling the ESP deep sleep mode, it seems as if the pinmode setting is lost.
So the question is whether it is possible to keep the pinMode state setting during deep sleep mode as well...?

The Technical datasheet describes on page 48 a Pad hold feature, meant to "retain the pad state through a core reset and system reset triggered by watchdog time-out or Deep-sleep events". Is this the needed feature and if yes can we enable it via the Arduino universe?

There doesn't seem to be an Arduino wrapper for this, but you can include "driver/gpio.h" and call the function directly:
https://github.com/espressif/esp-idf/bl ... #L539-L555

Thank you! But adding the function for all used GPIOs numbers (i.e. gpio_hold_en(GPIO_NUM_25); for GPIO nbr 25; I am using 15, 18, 19, 23, 25, 27, 33) prior setting the ESP to deep sleep does still not change the current consumption.

When adding external resistors to the ESP GPIO outputs the deep sleep power consumption works fine. However it would be really nicer doing this by software...

Is there anything I can do to check that the hold-function works fine in deep sleep mode?

OK when measuring the voltage level with a multimeter one can see the hold-function during deep-sleep works fine for all pins but pin 18, 19 & 23... these are the SPI pins!
So the question now is if it is possible to change the pin mapping in the Arduino world, or is there any other reason why the SPI pins cannot be hold (pulled_up) during deep sleep mode?

Got it finally working after changing the SPI pin mapping in "pins_arduino.h" to pins with rtc functionality (https://pcbreflux.blogspot.com/2017/02/ ... ample.html).

I think we could close this topic. Thanks for your input.