[AXP192] Lib init changed

[TD-er]

The AXP192 on the LilyGo T-beam 1.0 is behaving really unpredictable.

I believe there is some chicken-and-egg problem here as the display is not powered which may stall any I2C communications.

Not sure if there have been some recent changes here as I can't imagine this to never have worked.

If the power chip is somehow initialized correctly, the display is working fine and I2C scan does not give loads of errors.

Any ideas here what could be wrong here?

[TD-er]

Small progress... When I set the DCDC1 and DCDC3 channels as protected channel, the sleep/wake mode does work just fine. Still have to find out how to make the power-on cycle act predictable.

The voltage on the DCDC1 pin remains quite low (1.8V), so I guess the OLED display will then probably pull the SDA/SCL pins low via internal over voltage diodes to below its Vdd and thus the ESP32 will be unable to communicate with the AXP192 chip.

[TD-er]

OK, I've been reading just about any datasheet and library/repository available for this AXP192 and I think LilyGo did make a serious design error on the T-beam v1.0 at least.

Both pins labelled "3V3" and "3.3V" are wired to the same DCDC1 output of the AXP192. And contrary to what the datasheet suggests, the output voltage of this DCDC1 is set to 1V8 at boot/power on. So I guess LilyGo did somehow program this into the AXP192. Thus far I have not been able to find any info on how this can be programmed other than some reference in the datasheet to another document where this is described. Only this document is not available.

Problem is that the OLED is thus powered at 1V8 and the SDA/SCL will be pulled down to 1V8 + 0.3V This is too low for the I2C bus to work and thus you will see quite a few errors when scanning the I2C bus.

At some point the board may be able to read some info from the AXP192, like charging current and battery voltage. However the chip has not been initialized at boot. If at this moment you press the RST button, the AXP192 might be able to be setup.

Just to test this hypothesis, I added some standard diode (1N4001) between GPIO-0 and "3.3V" pin since GPIO-0 will be pulled up by some pull-up resistor to make sure the ESP will not boot into flash mode.

With this diode present, the OLED will be powered by some 3V3 - 0.5V = 2.8V and thus the SDA/SCL pins will be high enough to work properly.

I tried several times and the device now boots perfectly fine when I put it to sleep and wake up again using the PWR button.

N.B. I still have the DCDC3 and DCDC1 set as "protected channel", so I need to test if those are still needed to wake the device from 'light sleep' using the middle button.

I also have to check to see if this has a negative impact on power consumption during 'sleep' or 'power off'.

[TD-er]

I don't think this has any negative effect on power consumption during "power off", as GPIO-0 will also be 0V.

Since the DCDC1 output will remain enabled during light sleep, I doubt it will make any difference in power consumption during 'light sleep'.

I also removed the protected channel code and tested a bit using cold boot (USB and battery removed) and warm boot, light sleep, etc. It all works perfectly fine with this hardware hack.

So I guess it only may need some extra entry to the docs and no other code changes to work. @cyberman54 Do I need to make a PR for documentation changes for this? and if so, where?

[cyberman54]

@TD-er Thanks for your investigation on this. I remember i ran in the same chicken-egg problem with the i2c bus, while developing for T-Beam 1.0, after i added the OLED display. Same root cause. I thought i would have solved this by adding the AXP192_init(void) { ... } function in power.cpp. But your investigation shows, this is not enough. Thus, the hardware hack will be required to have a clean solution.

What about T-Beam 1.1?

You're welcome to add this to the doc. The doc is found here. It will be rebuild automatically by CI/CD after i merge a PR.

We need to figure out, where in the docs is an appropriate place to add the hint. Perhaps in section configuration.

[TD-er]

What about T-Beam 1.1?

I don't think I have the 1.1 version. I do have the 1.2 version, which has the AXP2101. I will add support for it in a separate PR.

Anyway I expect the 1.1 version to have the same issue as it is labelled to output 2.5V just as is done in the v1.0 datasheet.

[TD-er]

We need to figure out, where in the docs is an appropriate place to add the hint. Perhaps in section configuration.

Maybe this is a better suitable section: https://cyberman54.github.io/ESP32-Paxcounter/display-led/

[TD-er]

Just some idea about the power consumption. This is way better than expected....

I connected the Nordic PPK2 to the 18650 battery input terminals of the T-beam board

Complete cycle of power on, switching WiFi on (peak upto 367 mA) then normal operations with some short spikes when the LoRa was trying to send. Then 'light sleep' mode with a short press on the power button, followed by a short press on the action button. Board continues normal operation immediately. Then at last I long-pressed the power button to turn it all off.

Average power consumption while 'scanning' (thus normal operations) is 190 mA

Here zoomed in to the "light sleep" mode: Average about 1 mA.

And the power off: Average 57.49 uA

N.B. the voltage was set to 4.00 Volt.

[cyberman54]

Interesting findings, thanks. 1ma is still a lot for sleep mode. Could we combine the ESP32 deepsleep mode (as implemented in paxcounter) with light sleep mode of AXP192? Or does light sleep already include total cut off of ESP32 power supply?

[TD-er]

Light sleep does still keep the ESP32 powered so it can keep data in its RTC memory and some other stuff powered like the uBlox GPS backup battery. This way the board can continue within 10s or 100s of msec after pressing the button.

When keeping the power button pressed for a few seconds (whatever is set in the AXP192 as time by ESP32PaxCounter) the AXP192 does turn off everything so the ESP32 is also not powered anymore. GPIO-0 is pulled up to the 3V3 line of the ESP32, but this one is also 0V when the AXP192 is powered off like this.

N.B. this is just running the unmodified code of ESP32 Paxcounter (well it does have my other pending PR included)

[TD-er]

I added a commit to document these findings to the still open PR.

[cyberman54]

@TD-er The image links are broken. We need to relocate the image files to this repository, or modify the links.

[TD-er]

@TD-er The image links are broken. We need to relocate the image files to this repository, or modify the links.

I see, I will check with the other screenshot on that page. Probably forgot some ../