The Argon/Xenon CHG pin:
I’m looking for a way to differentiate between “charging” and “no battery”. Is that possible to detect in firmware?
Similar questions have been asked and the combination of the state of the PWR and CHG pins should give you the info you need.
I used the test program in this post from @rickkas7 to produce the data listed below: Argon check power source?
| Scenario | PWR | CHG | vBATT |
|---|---|---|---|
| USB Power & Full Battery | 1 = USB Power | 1 = Not Charging | 4.0 to 4.1 |
| USB Power & No Battery | 1 = USB Power | 1 = Not Charging | 4.1 to 4.2 |
| No USB Power & Battery | 0 = No USB Power | 0 = Charging | 4.0 to 4.1 … 3.8 to 3.9 |
| USB Power & Weak Battery | 1 = USB Power | 0 = Charging | 4.0 to 4.2 |
Based on these data points, I don’t see a definitive way to detect the presence or absence of a battery when the PWR = 1 (top two scenarios).
I don’t know if this helps or not but I did something similar only to detect if there was USB power or not. I fed USB power into a digital pin that was pulled low with a pulldown resistor. As long as the digital pin had power going to it, it was in a high state. If power went out and now it was running on battery only the digital pin would go low and trigger an alert so I knew the power went out. I suppose you could do the same thing but get your power from BAT instead of USB. If there is no battery power - that pin would go low and trigger a function in the code to take some action.
This might not have been the best way to do this but it works great.
That would not be advisable on a Gen3 device - unless you make sure you get the USB power down to 3.3V as GPIOs on the nRF chip are not 5V tolerant.
But this is what the (internal) PWR pin is for (including the proper "level shifting") 
If your LiPo went into an under-voltage state there would also be no (straight forward) way to know whether you had a battery connected or not since the protection circuit in the battery would just cut the connection and only close it again when charging power was applied.
Can you elaborate why you need to detect the (physical or electrical) presence of the battery?
I now have a console to monitor the devices that I have deployed, but the firmware loaded on those devices was not written with monitoring in mind. That creates "an opportunity".
My plan is to develop a common set of code ( possibly a class, possibly a library ) that can easily be added to both my current and future firmware. Monitoring the batteries, on those devices that have batteries, is one of the goals.
@ScruffR - Yikes! You are right and thanks for reminding me. I forgot all the Feather stuff is 3.3v logic. It doesn’t appear that there has been any damage. I threw a 10K resistor in there. I was reading thru the Docs and Datasheets and could not find much on the PWR pin. Could you elaborate on that just a bit? Thx!
A single resistor won't protect you agains over-voltage on the pin. You'd need a voltage divider.
Since an INPUT pin does virtually draw no current you won't get any considerable voltage drop across a series resistor.
The only thing you need to know about the PWR pin is that you can digitalRead(PWR) and that will give you HIGH of VUSB power present and LOW when not.
I suppose you are right about the voltage divider. But sounds like I don’t need any of that. Just read PWR if it HIGH or LOW state. I came across something that mentioned in another thread doing that on an Argon but on a Boron you have to do something different. Does PWR work the same on both? I’m using a Boron in this case.
Thanks!
I think you are refering to reading the SoC and voltage of the battery since Argon and Xenon don't feature a fuel gauge while the Boron does.
I'd have to double check, but IIRC the /CHG and PWR pins should be available on Argon and Xenon, for Boron you'd use the better equiped PMIC and fuel gauge.
I got to messing with the PMIC and will need to work with that more in the future and figure it all out. For now I just went with the voltage divider route and that works great. Thanks!