The T-Beam V10 comes with enhanced power management features. It has a AXP192 pmu chip which can cut off power for display, lora, gps and esp32. The pmu chip is controlled via i2c bus. The display is using the same i2c bus. So far, so good. But if powering off the display, it is blocking the i2c bus by pulling SDA and SCL low. In this state the AXP192 is alive, but unreachable for the esp32, thus there is no way to switch the display on again…
…that’s bad news for using T-Beam V10 in deep sleep mode.
Are you sure?
I am using softRF with it and there are two modes. When pressing the powerbutton longer then 10sec or so the display goes off as well and the t-beam with display starts normally when pressing it again for 1 sec.
I didnt notice a malfunction on that.
Sounds like a true dead-lock situation (not exactly funny).
So everything can be safely powered down by pmu except for the display?
Any idea what the impact is on the amount of display current in deep sleep because it cannot be switched off (and on again) by pmu?
If display and pmu are tied to the same I2C bus (same GPIO pins), defining/using a seconds I2C bus is not an option because that wil require different GPIO’s (with different pull-ups) to which the pmu is not connected.
Correction:
I was incorrectly assuming that V1.0 has an integrated OLED display which is of course not the case.
So connecting the (ill-behaving) display to a separate I2C bus should solve the problem.
Pressing the power button is a manual action that triggers the pmu while waking up from deepsleep occurs automatically triggered by RTC timer of the ESP32 (unrelated to pmu).
On the V1.0, power to pin7 of the pin header is delivered over DCDC1 channel of AXP192. They call it VCC_2.5V but actually the output voltage is controlled by AXP192’s registers and typically is set to 3.3 Volts.
Pins 9 and 10 of the pin header (IO22 and IO21) are typically associated with “I2C bus” and since that, the T-Beam designer has added two pretty much standard 10K pull-up resistors on each of these lines.
The circuits above are kind of typical and there are no design flaws there.
If a particular I2C device pulls down the bus lines to the “ground” so hard that it even counters external pull-up resistors - it is definitely bug of the I2C device, not the T-Beam. So, just get rid of the device and plug a good one.
If a firmware developer wants to keep using this I2C device by some reasons - there are options to apply a workaround. One of them is to keep supplying 3.3V I2C power voltage over DCDC1 of AXP192 in ESP32’s “deep sleep” state but put the display itself in a sleep mode instead.
According to this video, “sleep current” of this or similar display is around 10-20 uA.
Okay, that’s right, the problem is caused by the SSD1306 display, not by the T-Beam. I bought both in a set, and used pin 7-8-9-10 to connect it directly on the header, but allright, this was my decision. Better solution is perhaps to have display and AXP192 on two separate i2c buses. This would be possible when the display is connected to some other GPIOs which are used for 2nd i2c bus.
I will now try to apply the 10 uA display sleep mode workaround, hopefully this does not block the i2c bus.
EDIT: it works. While the display is in sleep mode, i2c bus is usable and not blocked. So we have a workaround.
What happenes when pressing the “power” button (which actually is not a power cut off but a key on an input pin of AXP192) depens on how the AXP192 is configured. It’s possible to realize the above on/off function by hardware of AXP192, but also can be under control of main CPU. I don’t know how it is realized in Soft RF. Default setting of AXP192 is, that a long press cuts off power.
Full “power off” function is a mandatory requirement for every PMU IC design on the market. It simulates operation of traditional (mechanical) power switch.
Depending on the PMU implementation, it is typically necessary to press and hold power button down for few seconds. Smartphones, tablets and other stuff - all of them are operating in a similar manner. As an example, my tablet needs 10+ seconds hold to ensure full power off for it’s motherboard circuit state.
For the T-Beam V8-V10 6+ seconds are typically sufficient. It is default value stored in AXP192 registers.
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?
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.
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.
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. (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.
Did you take a look on the link?
