Switch off devices attached to board to save energy

That makes it sound like your pins are stuck low. Might be the ESP, might be something else holding them down.

One debugging trick can be to insert small series resistors in the bus. Then, by seeing (ordinarily with a scope, in this case even with a meter) the direction of voltage drop across them, you can see if it is the processor or peripherals holding the lines down.

sorry… I googled ’ esp32 after deep sleep i2c ’ and forgot the link

seems to be a problem … hope I find the work around again :upside_down_face:

think it was this one

’ I need to reconfigure the SDA line upon recover from deep sleep:

Code: Select all

rtc_gpio_deinit(SU_HARDWARE_I2CSDA)

It’s exactly problem i have now, after recover of deep sleep, i2c bus is down
I put this lines in setup but nothing,
rtc_gpio_deinit(GPIO_NUM_21);
rtc_gpio_deinit(GPIO_NUM_22);
Shows error:
rtc_module.c:155 (rtc_gpio_deinit):RTC_GPIO number error

I tried adding before rtc_gpio_deinit, this lines, but nothing
pinMode(SDA,INPUT_PULLUP);
pinMode(SCL,INPUT_PULLUP);

That article is related to using the ESP32 as I2C slave (to be controlled by a different MCU/device which acts as I2C master), where they want to wake-up the ESP32 when the same GPIO that is used for SDA goes low (SDA goes low).

My assumption is that this is different from (not relevant for) normal use where ESP32 is the master.

Wake-up from deep sleep is actually a special case of booting after a reset and using the Arduino framework will require Wire.begin() to be called again after waking up from deep sleep. Any lower-level ESP32 stuff should be handled by Wire.begin() just like for a power-off reboot.
(Assuming a normal situation where I2C GPIO’s are not used to trigger a wake-up from deep sleep.)

So what causes the I2C issues after deep-sleep?
Could this be a bug in the ESP32-IDF / ESP32 Arduino Core?
Is it hardware related?

Those appear RTC related API’s but the GPIO’s specified are not RTC_GPIO numbers but regular GPIO numbers. The error in that case is correct and the API probably expects proper RTC_GPIO numbers.

But if calling that API will solve the issues I don’t know.
I assume that that would only be useful if the RTC_GPIO('s) were specially configured (non-default) for deep-sleep (e.g. waking up / generate interrupt when the SDA line goes low) which is probably not the case when ESP32 uses the I2C bus only as master.

@Verkehrsrot Are the ESP32 I2C issues described in this topic caused by what is described here:?: TTGO T-Beam V1.0 & OLED & deep sleep needs proper power design

In that case the I2C issues are not ESP32 related at all, but caused by an ill-behaving external OLED display.

probably , if you google on ’ esp32 after deep sleep i2c ’ … :thinking:

My problen is solved. Reason because i2c not wake up after deep sleep was quite simply. (I’m stupid) I was using same pins in wire.begin to control AXP and accelerometer, I created two objects for each wire connection
TwoWire I2Cone = TwoWire(0); //pin 21,22 AXP
TwoWire I2Ctwo = TwoWire(1); // pin 4,23 GY-521
I2Cone.begin(21, 22);
I2Ctwo.begin(4,23,400000);

Then AXP can switch on/off DCD1, powering on/off GY-521:

AXP20X_Class pmu;
pmu.begin(I2Cone, AXP192_SLAVE_ADDRESS)
pmu.setDCDC1Voltage(3300);
pmu.setPowerOutPut(AXP192_DCDC1, AXP202_ON);

And GY-521 can start

I2Ctwo.begin(4,23,400000);
I2Ctwo.beginTransmission(MPU_addr);
I2Ctwo.write(0x6B); // PWR_MGMT_1 register
I2Ctwo.write(0); // set to zero (wakes up the MPU-6050)
I2Ctwo.endTransmission(true);

Thanks a lot!!!

Hi, I have seen that while the board is in deep sleep mode, the GPS LED is blinking. I have deactivated the LDO2 and LDO3 channels afterwards and the LED does not turn on, but I think it is excessive consumption of 20mA on LDO1 to maintain the GPS calendar,
it’s only can maintain 4 days of battery approx.
Is this consumption even in deep sleep mode? I have to try with a multimeter better than mine

Hello,
On my side the consumption does not go below 15mA, even with ESP32 disconnected. I did not test LD01 disconnection, but I don’t think it use so much current. Did someone manage to reach µA consomption on the TTGO T-Beam Rev& ?

In this video


Consumption appears is below 0,0001A
Author uses this code

Display appears to show 0.00000A

Less than 10uA ?

Hi!
I used the same code as in the video. With the same board (except an additional screen), I have 17mA even in deep sleep. Can this be an issue with OLED?

Hi, have you tried to stop wifi and bluetooth on setup void?

WiFi.mode(WIFI_OFF);
btStop();

In a couple of days i’ll try read consumption too with new multimeter

In deep sleep mode, my multimeter shows 0.990 mA (0.00099 A)
image

In this video, board runs reading gps and accelerometer along 25 secs, consumption is 110-130mA (i think is a lot) and after that, goes deep sleep

Am i interpreting it well?

Hi again!, i’m back with new t-beam board. I put this boards in cows… :slight_smile:
This board added a red led IO4, and always is on, (very low light) but even deep sleep mode. With old boards i have 1mA of current in deep sleep, and 20mA with newer board. And in new board is needed to disconnect SCL pin of devices before uploading, if not, connect to COM port is impossible…

I put board in deep sleep as follows:
AXP20X_Class pmu;

pmu.setChgLEDMode(AXP20X_LED_OFF);
pmu.setPowerOutPut(AXP192_DCDC1, AXP202_OFF);
pmu.setPowerOutPut(AXP192_DCDC2, AXP202_OFF);
pmu.setPowerOutPut(AXP192_LDO2, AXP202_OFF);
pmu.setPowerOutPut(AXP192_LDO3, AXP202_OFF);
pmu.setPowerOutPut(AXP192_EXTEN, AXP202_OFF);

Anyone knows how to switch-off IO4 LED?
Thanks!

image
image
image

This works for me:

#define LED_PIN         04
...
pinMode(LED_PIN, OUTPUT);
digitalWrite(LED_PIN, LOW);
...

Thanks it works, but with
digitalWrite(PIN_LED, HIGH);
if i set it to “LOW” it lights on harder, as a Vader’s lightsaber. :slight_smile:

Many thanks again!

True :slight_smile: less energy drain with HIGH.
(note to myself: don’t write code snippets from memory before caffeine kicks in)

Use a soldering iron!