Hi Nick,
please reply to all.

Am 17.11.2020 um 21:41 schrieb Nick Elsmore <nicholaselsmore@gmail.com>:


If I remember correctly the driver only starts charging if USB becomes plugged in but not
if it *is* plugged in.

But what happens if USB remains plugged in and the charger stops charging after the
battery is fully charged.

Or what happens if USB is already connected while boot? Is this detected as a "plug in"
event?

I think there is no code that looks and decides when to trigger charging a second or
third time to keep the battery full (which may drain during operation).

Can someone review the code for this?

I don't understand why we need to use the watchdog timer on the charger.  The hardware state machine in the charger can handle all that is required to safely charge the battery without runtime interaction from the host CPU.

That is what I assumed the past years until the Pyra prototype convinced me of the opposite.

  The host should just configure the required settings at startup and leave the thing alone.  In this case, the watchdog should simply be disabled.  I have read some drivers for similar charger chips which behave this way as well.

Yes, that is how we do it.


However, one feature of the bq24 I am not particularly familiar with is the OTG support, perhaps this affects this behavior (I need to read up more on how this works in the bq24).

OTG wasn't used or enabled and involved in my tests so it is unlikely to be a factor. It does not automatically enable and can be enabled only if the battery is not charging and not too cold/hot.

If the driver is not trying to handle the USB detection and control the bq24 manually, the bq24 will properly detect a valid supply on VBUS and enter the appropriate charge mode (precharge, fast, termination) depending on the battery voltage.

Maybe exactly this is the problem. It may choose an input current limit based on the USB charger detection protocol which is too low to run the Pyra and charge in parallel.  For example 500mA. Then, the battery must drain...

So to increase the input current limit to a non-standard value the host must detect USB events and increase input_current_limit.

 I see no reason to duplicate behavior which already exists in hardware.

IMHO we need more behaviour than already exists in hardware because the OMAP draws so much energy. Or am I wrong?

  In fact, I think this is the cause for a lot of the existing issues in the driver.

So what would be your hypothesis of the bq24297 being in a state where you have to remove the battery for a moment before it automatically starts charging again?

BR and thanks,
Nikolaus