AXP192 interrupt is not firing about firmware HOT 5 CLOSED

@geeksville - can you update this bug with a bit more detail - is the goal to get an interrupt on state changes on AXP192 and update the state?

from firmware.

sure, so the initial axp192 code was based on example code from ttgo which was of pretty low quality. i.e. when I got the datasheet I found some of their register settings were not even correct. I checked the datasheet into the git repo btw.

I'm not sure they picked properly for if the IRQ is even asserted high or low (I haven't looked carefully). Also related to that polling, I noticed that I also had to turn off leaving that IRQ enabled across light sleep (see doLightSleep()) because I was getting woken repeatedly, so I really think the level high vs low for that irq trigger might be wrong.

Probably just a good reading of the datasheet would be good.

from firmware.

btw: I think I might be actually sick with this corona thing (really surprising actually). I woke up last night with chills and a headache, took tylenol and I still have the chills. It isn't too horrible at all but def not a cold. So I'm going to be afk for at least today I think sleeping.

from firmware.

I looked at original t-beam sample and interrupts work in that sketch.

I made some changes to interrupts in main.cpp and they are working. After "Shutdown BT" appears in debug output interrupts stop working until you press middle button to wake it up again, then you get the interrupts which were delayed, so maybe light sleep or whatever state we go into needs to have interrupts enabled if we want to get interrupts immediately rather than delayed? I added some more interrupt events like pek button so I could test a few more things. I tested all the events I added and they are in the debug log attached. There are lots of interrupts available for all the events the axp192 does by itself. If you plug in vbus you get two interrupts, one for plugging in and another for battery fully charged or battery charging depending on if its already fully charged or not.

Changing INPUT_PULLUP to INPUT was one of the last changes I made and seemed to make it reliable, before that interrupts were intermittent. The pin is definitely pulled down for an interrupt so falling is correct rather than rising, in some documentation I found mentioned that host pulls it up again after its done servicing interrupt, it seems to work ok either way.

I dont know how git works to submit changes, rather than guess and do it incorrectly I'll just post it here instead.
irq2.zip

from firmware.

@spattinson DAMN. That's awesome. I'll pull this in and merge it tomorrow (I'm in (remote) class today).

from firmware.