TTGO T-Beam V1.0 & OLED & deep sleep needs proper power design

#15

To summarize, do I understand correctly that:

When power supply to the display is switched of by the PMU, that the display pulls the I2C lines low (which blocks the I2C bus) and this results in the PMU (in fact any device on that I2C bus) is becoming uncontrollable by the ESP32 and therefore power to the display cannot be switched on again by ESP32?

The ESP32 from that point would loose all control over the PMU?, including switching on/off power for other devices (e.g. GPS) and not be able to communicate with any I2C device on that bus anymore? And this dead-lock situation can only be manually reset with the power button?

#16

Thatā€™s the way it is.
But is possible to reconfigure AXP192 PMU to modify the ā€œlong pressā€ behaviour, even to move control over it to main cpu. Which then can result in devices which cannot be powered off in failure state - also sometimes known from smartphones etc. :frowning:

#17

Yes, that is exactly the situation, and even pressing reset will not resolve this dead lock. You need to cut off power source, to forece AXP192 fall back to itā€™s default configuration, which means (at least on T-Beam V10 hardware design) that ESP32 power is on and the device restarts without need of command to AXP192 on i2c bus.

#18

PS: a hardware solution to avoid this by decoupling i2c lines is suggested on github by github user @stickbreaker here

#19

IMHO, too much buzz for a faulty I2C device which costs around 2 Euro onlyā€¦

1 Like
#20

I have an older T-Beam V0.5 here but was somehow assuming that V1.0 has an integrated SSD1306 which is of course not the case. :blush:
(The TTGO and Heltec LoRa32 boards all have an integrated OLED display.)

So the whole issue is the result of an externally added OLED I2C display that does not behave nicely.
Not directly related to T-Beam V1.0 and itā€™s power design.

In that case the topic title needs adjustment.

1 Like
#21

Hi, my problem is with a accelerometer GY-521 instead a display, but iā€™m in the same case.
then, if i understand well hardware solution of @stickbreaker, i need to connect +3v3 and -3v3 connectors of BD-LLC in the image i uploaded to +3V3 and GND of T-Beam Board, and then is needed to connect LV1 to VCC of accelerometer.
GND of accelerometer is shared with GND of BD-LLC connected to GND of Board. Āæisnā€™t it?
Thanks!

s-l1600

#22

That picture is from a level converter, not GY-521.

If you are having similar issues with your accelerometer as the ones described for the display then only one of the solutions mentioned below (replace display with your I2C device) will solve the issue.

#23

Three possible workarounds for the I2C issues caused by (ill-behaving) external display:

  • Use a different OLED display module. Assuming this is an incidental and not a more generic (SSD1306?) OLED module related issue.

  • Use a separate/second I2C bus (with different IO pins) of the ESP32 for the display.

  • Connect the display via an I2C bus isolator like TCA4311A.

#24

Yes, picture is of a level converter, i mean that problem with oled display mentioned in this post is the same than i have with a accerometer connected to I2c.

#25

You donā€™t need a level converter to use GY-521 with ESP32.
ESP32 works at 3.3V and GY-521 should be able to work at 3.3V as well (VCC 3.3V).

#26

Gy-521 works well at 3.3V, but after TTGO T-BEAM board wakes up of deep sleep not works if i previously disconnect DCDC1 with AXP library: setPowerOutPut(AXP192_DCDC1, AXP202_OFF);
Problem mentioned in this post is that after wake-up of deep sleep i2c not work, and @stickbreaker posted that is possible to fix it with a BD-LLC isnā€™t it?

#27

It appears you are posting in the wrong topic nor are you providing any links.
Also @stickbreaker is not a user on this forum.

So you know very well that a level converter is not needed, but nevertheless confuse other users with a picture of a level converter wasting their time.

2 Likes
#28

I am sorry for the apparent confusion, it is not my intention to waste anyoneā€™s time, what I mean is that the i2c bus of the TTGo T-BEAM gets stuck after waking up, in this post you are talking about that it is not possible turn on the OLED screen again. I have an accelerometer connected to the 3V3 pin instead of an OLED screen. And my bus i2c get stucked after wake up from deep sleep too.
Github stickbreaker user in link posted previously by @Verkehrsrot (i donā€™t want to repeat urls previously posted) uses a BSS138 to avoid the problem. The image I uploaded is a 4 Channel Logic Level Shifter using BSS138.

#29

The issue described in this topic is that it is not possible to power up the display again after it has been powered down by the PMU (caused by the display incorrectly pulling the I2C lines low when powered off).

A different issue (ā€˜Bā€™) with problems with ESP32 I2C bus after waking up from deep sleep is described here: Switch off devices attached to board to save energy
That issue appears to be related to configuration of (role assignment) of ESP I2C GPIO pins.

Both issues seem to be unrelated (even while both are related to I2C and both issues become visible after waking up from deep sleep).
Your problem with the accelerometer seems to be issue B related (which is not the subject of this topic).

Actually, both issues may be exactly the same (but described in different topics).
See this post: Switch off devices attached to board to save energy

#30

Sorry for that! other post was created for me, and effectively, i was in problem to configure correctly GPIO Pins, because what i want was manage power with AXP202 library. Finally i did it, now i can choose voltage on DCDC1 pin, and connect/disconnect Lora/GPS etc. thanks to @Verkehrsrot, but, then i think ran in problem of this post. If i include this line before deep sleep:
setPowerOutPut(AXP192_DCDC1, AXP202_OFF);
bus i2c not recover from deep sleep, and is impossible to power up DCDC1 pin again. So i think my problem is the same described above in this post, if not, sorry again for that.

1 Like
#31

I can understand that the problems look similar and they actually may be the same (see above). Both are ESP32 and I2C related and both become visible after waking up deep-sleep.

If your problem is the same as the subject of this topic it can be solved by using one of the three mentioned solutions (using the MOSFET solution described in the GitHub article is actually just a variation of using an I2C bus isolator chip).

The simplest of the three alternatives is to define a second I2C bus for the display (and/or other I2C devices) on different GPIO ports/pins. That solution does not require any additional hardware and will use only little additional memory.

#32

Ik think the issue still needs further testing before real conclusions can be drawn.

#33

Just to add in something we have noticed at least with our V1.0 Tbeams. The 3.3V power rail exposed on the headers actually only outputs 1.8Vā€™s on startup. We had to then communicate with the PMU over I2c to actually give us the required voltage of 3.3V. No massive biggie, but we had a bunch of students using Xbeeā€™s that appeared non-functional at first, until we located the source of that issue!

1 Like
#34

Using accelerometer in another bus, AXP can now switch on / off my GY-521.
Thanks a lot!!!

1 Like