Deep sleep power consumption with connected SPI device

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Deep sleep power consumption with connected SPI device

Postby Laetterman » Mon Jun 25, 2018 8:41 pm

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
Attachments
WP_20180625_22_29_19_Pro.jpg
WP_20180625_22_29_19_Pro.jpg (343.4 KiB) Viewed 5751 times

ESP_Sprite
Posts: 4396
Joined: Thu Nov 26, 2015 4:08 am

Re: Deep sleep power consumption with connected SPI device

Postby ESP_Sprite » Tue Jun 26, 2018 3:15 am

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.

mikemoy
Posts: 494
Joined: Fri Jan 12, 2018 9:10 pm

Re: Deep sleep power consumption with connected SPI device

Postby mikemoy » Tue Jun 26, 2018 3:40 am

a schematic of how you have things connected would help.

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Re: Deep sleep power consumption with connected SPI device

Postby Laetterman » Tue Jun 26, 2018 7:16 pm

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().
Attachments
sketch_ESP+Paperino.png
sketch_ESP+Paperino.png (226.14 KiB) Viewed 5677 times
schematic_Paperino.png
schematic_Paperino.png (78.5 KiB) Viewed 5677 times

mikemoy
Posts: 494
Joined: Fri Jan 12, 2018 9:10 pm

Re: Deep sleep power consumption with connected SPI device

Postby mikemoy » Wed Jun 27, 2018 3:05 am

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.

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Re: Deep sleep power consumption with connected SPI device

Postby Laetterman » Wed Jun 27, 2018 6:21 pm

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?

ESP_igrr
Posts: 1690
Joined: Tue Dec 01, 2015 8:37 am

Re: Deep sleep power consumption with connected SPI device

Postby ESP_igrr » Thu Jun 28, 2018 5:02 am

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

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Re: Deep sleep power consumption with connected SPI device

Postby Laetterman » Fri Jul 06, 2018 6:39 pm

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. :roll:

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?

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Re: Deep sleep power consumption with connected SPI device

Postby Laetterman » Sat Jul 07, 2018 9:16 pm

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?

Laetterman
Posts: 12
Joined: Mon Jun 25, 2018 8:11 pm

Re: Deep sleep power consumption with connected SPI device

Postby Laetterman » Sun Jul 08, 2018 9:31 am

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.

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot] and 68 guests