Power off not working at low battery voltage

dl5dla commented 3 years ago

I discovered a strange behaviour on my TTGo T-Beam (V1.1): Running the device battery powered, it is sometimes not possible to switch the device off by long-pressing the power button. Here are the steps:

Long-pressing the power button -> no reaction, the device stays running
Reset by pressing the reset button -> no reaction, the device stays running
connecting to USB power and long-pressing the power button -> no reaction, the device stays running
Reset by pressing the reset button and long-pressing the power button -> Device switches off

I am using a LiFePO4 battery for safety reasons. Although th nominal voltage is only 3.2 to 3.3 V, the device is working fine otherwise. After charging, the voltage starts and 4.1V and drops down to 3.5/3.4V very soon. Some tests showed that the power off switching works for voltages above 3.5V. But reviewing the datasheet I would expect that the AXP192 should work down to 2.9 or 3.0V.

This might not be software issue, but I would pretty much apreciate any ideas, comments or similar expiriences on this issue.

cyberman54 commented 3 years ago

Which code version are you using? The current 2.0.4 or an older version? In 2.0.4 the timing of tasks changed, more work is done on core 1 now. This could affect the interrupt handler (runs on Core 1). AXP192 button events are handled by the interrupt handler.

If you're using a version pre 2.0.4 interrupt timing should not be an issue.

dl5dla commented 3 years ago

I did the test with version 2.0.3, but moved today to 2.0.4. The problem stays to be the same.

dl5dla commented 3 years ago

I tested this behaviour by an simple (adapted) example code from the axp202 library. And it's the same as on the paxcounter code: As soon as the battery voltage drops below around 3.48V, no long press/short press interrupt is triggered anymore. So this issue is not related to the paxcounter code at all. Could instead be a HW problem. I will check again, when a second ordered T-Beam will arrive.

cyberman54 commented 3 years ago

Perhaps this is a circuit design fail of all T-Beam boards, i wouldn't be too surprised, if so. It's hard to get an english datasheet for AXP192, but it's easy to find some for the similary AXP202. I saw a reference design in it, maybe this helps further. Maybe it's not a hardware issue, just an improper configuration of the chip during initalization.

dl5dla commented 3 years ago

I have contacted the Lilygo support (btw, they were very responsive and tried to help). They sent me a simple test code to deal with the power off interrupt. I installed that, and it worked correctly on my two T-Beams. Surprising, after that I installed the paxcounter code again, and now a long-press of the power button works no matter how the battery voltage is.

During these tests, the battery was connected. So some settings/initialization which the test code did, might have survived. So next, I removed the battery for some seconds to remove those settings, and after that the problem occurred again (no power off by pressing the power button). Once again, I installed the test code and after that the paxcounter code, and everything is fine again.

So I assume, that the testcode initializes the APX192 (or some variable) in a different way as paxcounter is doing.

main.cpp.txt

cyberman54 commented 3 years ago

@dl5dla Thanks for these details. I made some changes in development branch. Could you please re-test?

dl5dla commented 3 years ago

Thanks for the changes. I installed them, and it seems to work up to now. Meanwhile I assumed that the display freezes, when I re-plug the usb cable, but I could not reproduce that. I will observe it furtheron.

Any idea, why the changes might have fixed the issue? I understand that "AXP202_PEK_LONGPRESS_IRQ" need to be enabled, but why did it work without for higher battery voltages? And why are the other additional code lines required? A little bit mysterious ;-)

cyberman54 commented 3 years ago

Power off by (very) long press is a hardwired fallback feature of AXP192 chip, according to it's datasheet and how i understand it.

dl5dla commented 3 years ago

I observed the initial problem again even with the fix in the dev branch, after I had temporarily flashed another sketch and then went back to the Paxcounter code. As before I could mitigate the problem by installing the Lilygo code main.cpp.txt (s. above) and reinstalling Paxcounter after that.

cyberman54 commented 3 years ago

@dl5dla Please try changing this line in power.cpp from false to true: pmu.setTimeOutShutdown(true);

dl5dla commented 3 years ago

Thanks for the proposal. I changed the code accordingly, and after a long press (6s) the unit switches off, but the blue LED is still on. So the hardwired power-off somehow works, but the software controlled power-off (2 sec button press) does not work. As mentioned before I can fix this by loading the test code "main.cpp.txt" and then the paxconter again. When I remove the battery, the problem in most cases occurs again. May be, some variable is not initialized by the paxcounter code, but is correctly set by the testcode.

cyberman54 commented 3 years ago

@dl5dla when you tested change from paxcounter to ttgo software, did you power off the board between, i.e. was the AXP192 chip reset? (USB cable unplugged AND battery taken out?)

dl5dla commented 3 years ago

I just did the test again now. Following steps done:

starting with a working paxcounter (after flashing the testcode and after that paxcounter again)
battery out and in again (=full reset)
paxxcounter not working (for 2s button press)
soft reset with reset button
not working
flash test code
soft reset with reset button
working (at least blue led changes its behavior as programmed in the test code)
battery out and in again (=full reset)
reflash paxcounter 12 working 13 battery out and in again 14 not working

cyberman54 commented 3 years ago

@dl5dla i can't see any difference in the AXP192 inits, after i copy/pasted the settings from the testcode example. It maybe not an initialization issue, but long press IRQ handling issue. But i still did not find the bug.

hekopath commented 3 years ago

Perhaps it is just a meaningless typo in axp20x.h on line 337 axp_loonPress_time_t . Otherwise there could be some reference to the longpress issue. typedef enum { AXP_LONGPRESS_TIME_1S, AXP_LONGPRESS_TIME_1S5, AXP_LONGPRESS_TIME_2S, AXP_LONGPRESS_TIME_2S5, } axp_loonPress_time_t

dl5dla commented 3 years ago

@cyberman54 > I can't see any difference in the AXP192 inits, after i copy/pasted the settings from the testcode example. It maybe not an initialization issue, but long press IRQ handling issue. But i still did not find the bug

Thanks for your effort - with my "workaround" I can live so far.

cyberman54 commented 3 years ago

@hekopath axp_loonPress_time_t is defined, but this enum type is not used in APX20x libary. So doesn't matter.

cyberman54 commented 3 years ago

@dl5dla Once again i tried some modifications. PEK button on both my T-Beam v1.0 and v1.1 is working as expected, switching the board on and off. But i did not try with battery. Can you re-test?

dl5dla commented 3 years ago

Thanks. I will test it, but it will probably take some days.

dl5dla commented 3 years ago

Test results:

Flashed with new version
Battery out and in again -> not working (unit does not switch off)
connect to USB -> not working
reset by reset button -> working
if I disconnect from usb and reconnect, I have to reset before it works again if it stays connected for some time (charging the battery) and the battery voltage raises up to around 4.0V, it works again.
if I keep the unit running (without usb connection), it's not working when voltage decreases below some value (at least below 3.4V).
At this point I have flashed the test code and immediately followed by uploading the paxcounter code again. -> Battery voltage increases to 3.69V (due to a little bit charging meanwhile) and it works again.
When battery voltages decreases again: -> 3.38V -> working -> 3.28V -> working

So, unfortunately no improvement.

cyberman54 commented 2 years ago

@dl5dla with v3.3.1 i changed the library which controls the power management chip. Could you please re-test?

dl5dla commented 2 years ago

I will try, but currently having problems compiling the new version. I am getting compiler errors like

src/power.cpp: In function 'void AXP192_power(pmu_power_t)': src/power.cpp:71:28: error: 'XPOWERS_CHG_LED_DISABLE' was not declared in this scope pmu.setChargingLedFreq(XPOWERS_CHG_LED_DISABLE);

same for XPOWERS_CHG_LED_FRE_1HZ, XPOWERS_CHG_LED_LEVEL_LOW, XPOWERS_VBUS_VOL_LIM_4V5, etc.

Version of PlatformIO is 6.1.4.

cyberman54 commented 2 years ago

This looks like the XPower lib headers are not loaded by your toolchain. Please check that your (local) platformio.ini is matching the (online) template of the current platformio_orig.ini

dl5dla commented 2 years ago

I just made a "diff platformio.ini platformio_orig.ini":

17c17
< ;halfile = ttgov21new.h
---
> halfile = ttgov21new.h
20c20
< halfile = ttgobeam10.h
---
> ;halfile = ttgobeam10.h

so beside enabling ttgobeam10.h instead of ttgov21new.h, the files are identical.

dl5dla commented 2 years ago

I checked the compiler output again:

src/power.cpp: In function 'void AXP192_power(pmu_power_t)':
src/power.cpp:71:28: error: 'XPOWERS_CHG_LED_DISABLE' was not declared in this scope
     pmu.setChargingLedFreq(XPOWERS_CHG_LED_DISABLE);
                            ^~~~~~~~~~~~~~~~~~~~~~~
src/power.cpp:71:28: note: suggested alternative: 'XPOWERS_AXP192_CHG_LED_DISABLE'
     pmu.setChargingLedFreq(XPOWERS_CHG_LED_DISABLE);
                            ^~~~~~~~~~~~~~~~~~~~~~~
                            XPOWERS_AXP192_CHG_LED_DISABLE

When I follow the suggested alternative ("XPOWERSAXP192..." instead of "XPOWERS_...", compilation is successfull.

cyberman54 commented 2 years ago

Indeed there was a breaking change to the API of the XPowersLib without further notice :-( I updated the code. Now it should compile again. https://github.com/cyberman54/ESP32-Paxcounter/pull/891

cyberman54 commented 1 year ago

@dl5dla any news here? can we close this?

dl5dla commented 1 year ago

Hi [cyberman54], I start testing a couple of weeks ago, but it seems that the device is (somehow) broken now. Hopefully I have a chance to try it again later on, but for now I suggest to close this issue. Thanks a lot, Peter

cyberman54 / ESP32-Paxcounter

Power off not working at low battery voltage #674