On Mi, 2020-11-18 at 11:43 +0100, H. Nikolaus Schaller wrote:
Hi,
I'd like to pick this up again. I will start to ship Pyras to end customers this week, so it would be nice if we could at least get charging to work to some degree.
As mentioned in the other message, I'm working on the temperature-limit script that should prevent the system and battery to overheat.
I'm running into a few issues here though, which might be connected to the charging driver.
Here's what's happening:
1. The USB OTG port successfully recognizes the connected power supply and sets the limit accordingly. On my power supply, the limit (linked to /dev/usb_max_current) is being set to 3000000 (3A). On aTcs power supply, it's being set to 2000000 (2A). So far so good.
2. The USB FTDI port is always being set to 500000 (500mA), as it can't recognize the charger. Increasing /dev/usb_max_current manually works and you can charge at a faster rate.
However, here's the issue: Something resets that limit regularly. So if I want to limit the 3A input to 1A, it works - but 30 - 60 seconds later, there's a KERNEL UDEV event reported - and it's back to 3A.
It's the same for the USB FTDI port as well. I can increase the limit - but it's being reset.
The problem is: Charging the battery with 3A causes it to heat up really fast - so it stops charging after a few minutes until the battery has cooled off again. With 2A, this doesn't seem to happen (tested on aTcs unit), but I can't limit it to 2A.
So we need to find out what causes that reset. Is it the driver? What else could it be?
Does that happen on Letux OS as well? Or only on our OS?
Thanks for your help :)
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