Hi, I think everything is now working as expected:
I have charged a partially emtpy pandora battery (carefully placed on the spring contacts because there is no case yet :). And I could monitor the capacity level go up from ~40% to 100% and in parallel the voltage. The charger driver also reported “charging” and at 100% it reported “full”. I have just now tested the OTG DC/DC converter and also could switch on/off the 5V at the OTG port.
To do all this, I had to hack the kernel drivers in a way that I am able to test if the chip and the system is working as expected. So let me describe and document some findings:
Charger is bq24297 * I have hacked a driver I had found on the web until it works well enough for hardware bring-up [1] * this chip responds on I2C only if battery or USB power is available - so it is “missing” if we power the board only from the EVM (which will never be the case in production devices) * it should be possible to hot-swap the battery as long as an external charger is connected * charging and OTG only works if battery temperature is between -10°C and 60°C (measured by battery NTC) * a missing battery is reported as -20°C * it presents itself as /sys/class/power_supply/bq24297 * the driver has some /sys nodes: /sys/devices/platform/44000000.ocp/48072000.i2c/i2c-1/1-006b * battparam: shows all register values for debugging * max_current: specifies the max current drawn from USB energy source * otg: specify the current limit (uA) of the OTG driver (0, 1000000, 1500000) * to switch to OTG: echo 1000000 >otg * to switch off again: echo 0 >otg * id: this should be removed (I had thought that the charger monitors the ID pin to be able to auto-switch to OTG but it doesn’t) * the driver detects VBUS availablility and battery presence * the driver will need extensions to make OTG automatically work on cable-plug-in (maybe with help from some udev rule) * it will need a lot of polishing to get it upstream * what I was not yet able to test is how the charger behaves with a completely drained battery - it should silently charge at low current without CPU intervention…
Fuel gauge is bq27421 (but I am thinking about switching to bq27621) * driver is available in Linux: compatible = "ti,bq27425" * it automatically reports voltage, charging level, chip temperature * but it needs battery power to respond on I2C * so it will fail and loose all data on battery hot-swap * a new modprobe bq27xxx_charger might solve that issue * there are patches flying around to better support the bq27421 * e.g. setup some battery parameters like battery capacity by design (currently reports 1340mAh for any battery) * it does not report real battery temperature by NTC * I have also planned to connect the NTC to one of the twl6040 ADCs on the CPU board so we will be able to read the real battery temp - but I don’t know if this conflicts * the OTG ID pin also goes to the CPU board * there was a bug in the schematics/placement list which could have damaged the chip in the prototype, but it has “survived” this extra stress * why not bq27200 like in Pandora? the bq27200 would be the only chip to limit the I2C2 speed to 100kHz
USB-Hosts DC/DC is a tps2505 * operation is simple and has no driver * it has a general enable GPIO which starts the DC/DC * if enabled, the HDMI and the VBUS of the 3G/4G modem are driven with 5V * both host ports have additional switches with two more GPIOs controlling them * Overcurrent on the host ports is detected and reported by driving the red indicator LEDs - it can also be detected by CPU
BR, Nikolaus
[1]: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq2429x_...
Hi,
On Tue, Mar 24, 2015 at 10:24 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Charger is bq24297
- I have hacked a driver I had found on the web until it works well enough for hardware bring-up [1]
- this chip responds on I2C only if battery or USB power is available - so it is “missing” if we power the board only from the EVM (which will never be the case in production devices)
- it should be possible to hot-swap the battery as long as an external charger is connected
- charging and OTG only works if battery temperature is between -10°C and 60°C (measured by battery NTC)
- a missing battery is reported as -20°C
- it presents itself as /sys/class/power_supply/bq24297
- the driver has some /sys nodes: /sys/devices/platform/44000000.ocp/48072000.i2c/i2c-1/1-006b * battparam: shows all register values for debugging * max_current: specifies the max current drawn from USB energy source * otg: specify the current limit (uA) of the OTG driver (0, 1000000, 1500000) * to switch to OTG: echo 1000000 >otg * to switch off again: echo 0 >otg * id: this should be removed (I had thought that the charger monitors the ID pin to be able to auto-switch to OTG but it doesn’t)
- the driver detects VBUS availablility and battery presence
- the driver will need extensions to make OTG automatically work on cable-plug-in (maybe with help from some udev rule)
- it will need a lot of polishing to get it upstream
- what I was not yet able to test is how the charger behaves with a completely drained battery - it should silently charge at low current without CPU intervention…
Hmm so like pandora, the device will appear "dead" while charging a flat battery? That is confusing a lot of pandora users, we still occasionally get people posting in the boards about "dead" pandoras, which really have very discharged batteries.
Does the charger work without any driver at all? What about charging while device is off? Not being able to do that confused a lot of pandora users too.
Fuel gauge is bq27421 (but I am thinking about switching to bq27621)
- driver is available in Linux: compatible = "ti,bq27425"
- it automatically reports voltage, charging level, chip temperature
Hmm so pretty inaccurate estimation based on voltage, right? We'll lose battery time estimation and system current draw measurement (the later is extremely useful IMO).
- but it needs battery power to respond on I2C
- so it will fail and loose all data on battery hot-swap * a new modprobe bq27xxx_charger might solve that issue
- there are patches flying around to better support the bq27421 * e.g. setup some battery parameters like battery capacity by design (currently reports 1340mAh for any battery)
- it does not report real battery temperature by NTC * I have also planned to connect the NTC to one of the twl6040 ADCs on the CPU board so we will be able to read the real battery temp - but I don’t know if this conflicts
Because you think bq24297 is inaccurate or just as an extra? I don't think anyone used battery temperature measurements for anything useful on pandora.
* the OTG ID pin also goes to the CPU board
- there was a bug in the schematics/placement list which could have damaged the chip in the prototype, but it has “survived” this extra stress
- why not bq27200 like in Pandora? the bq27200 would be the only chip to limit the I2C2 speed to 100kHz
Updated variants (bq27500-v130 and bq27510-g3) claim to support 400kHz. Do we really need high i2c speeds on that bus anyway?
We somewhat failed to make good use of bq27500 on pandora, if you keep the pandora plugged the most time, the battery meter miscalibrates wildly. But if it's used more like a phone (fully charge, unplug until it reports low battery and only then charge), it seems to be quite accurate. I think it's still useful for most people.
bq27500's accurate current draw measurement was really nice though, I would not want to lose that. It's not only for power saving development and good battery time left estimation, _wb_ made nice graph tool which even estimates how much current various components draw: http://repo.openpandora.org/files/pnd/sysinfo.wb/screenshot-plot.png
Gražvydas
HI,
Am 24.03.2015 um 14:03 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Tue, Mar 24, 2015 at 10:24 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Charger is bq24297
- I have hacked a driver I had found on the web until it works well enough for hardware bring-up [1]
- this chip responds on I2C only if battery or USB power is available - so it is “missing” if we power the board only from the EVM (which will never be the case in production devices)
- it should be possible to hot-swap the battery as long as an external charger is connected
- charging and OTG only works if battery temperature is between -10°C and 60°C (measured by battery NTC)
- a missing battery is reported as -20°C
- it presents itself as /sys/class/power_supply/bq24297
- the driver has some /sys nodes: /sys/devices/platform/44000000.ocp/48072000.i2c/i2c-1/1-006b * battparam: shows all register values for debugging * max_current: specifies the max current drawn from USB energy source * otg: specify the current limit (uA) of the OTG driver (0, 1000000, 1500000) * to switch to OTG: echo 1000000 >otg * to switch off again: echo 0 >otg * id: this should be removed (I had thought that the charger monitors the ID pin to be able to auto-switch to OTG but it doesn’t)
- the driver detects VBUS availablility and battery presence
- the driver will need extensions to make OTG automatically work on cable-plug-in (maybe with help from some udev rule)
- it will need a lot of polishing to get it upstream
- what I was not yet able to test is how the charger behaves with a completely drained battery - it should silently charge at low current without CPU intervention…
Hmm so like pandora, the device will appear "dead" while charging a flat battery? That is confusing a lot of pandora users, we still occasionally get people posting in the boards about "dead" pandoras, which really have very discharged batteries.
Does the charger work without any driver at all?
What about charging while device is off? Not being able to do that confused a lot of pandora users too.
I hope so and the data sheet promises. But I wasn’t able to test it yet.
Fuel gauge is bq27421 (but I am thinking about switching to bq27621)
- driver is available in Linux: compatible = "ti,bq27425"
- it automatically reports voltage, charging level, chip temperature
Hmm so pretty inaccurate estimation based on voltage, right?
No. It has a resistor and a coulomb counter (the bq27621 uses a different method without shunt resistor).
Since they are pin-compatible we might swap it on one or two boards and compare in real life.
We'll lose battery time estimation and system current draw measurement (the later is extremely useful IMO).
It reports the current flow. But precision is something we still have to find out.
All that is a little difficult to test with a bare board w/o case and the battery just placed on top…
- but it needs battery power to respond on I2C
- so it will fail and loose all data on battery hot-swap * a new modprobe bq27xxx_charger might solve that issue
- there are patches flying around to better support the bq27421 * e.g. setup some battery parameters like battery capacity by design (currently reports 1340mAh for any battery)
- it does not report real battery temperature by NTC * I have also planned to connect the NTC to one of the twl6040 ADCs on the CPU board so we will be able to read the real battery temp - but I don’t know if this conflicts
Because you think bq24297 is inaccurate or just as an extra?
It is an extra (not needed for operation).
The bq24297 has only temperature thresholds (too cold / ok / too hot), but no ADC. So you can’t find out if the battery is close to shutdown.
I don't think anyone used battery temperature measurements for anything useful on pandora.
* the OTG ID pin also goes to the CPU board
- there was a bug in the schematics/placement list which could have damaged the chip in the prototype, but it has “survived” this extra stress
- why not bq27200 like in Pandora? the bq27200 would be the only chip to limit the I2C2 speed to 100kHz
Updated variants (bq27500-v130 and bq27510-g3) claim to support 400kHz.
Ah, I should take a look into that.
But it uses the same algorithms („Impedance track“) as the bq27421.
Maybe they mainly differ in package which might have been the reason to choose the bq27xx1 chips. I simply don’t remember.
Do we really need high i2c speeds on that bus anyway?
Yes. We have quite some devices sitting on that bus. At least when connected to the EVM (which provides only I2C2 and I2C4 to the outside world).
We somewhat failed to make good use of bq27500 on pandora, if you keep the pandora plugged the most time, the battery meter miscalibrates wildly.
I hope the newer bq27421/bq27621 does not show such effects. The bq27500 was introduced in 2007 and TI might have improved something…
Maybe the bq27500 is essentially a bq27421 in the bigger package.
But if it's used more like a phone (fully charge, unplug until it reports low battery and only then charge), it seems to be quite accurate. I think it's still useful for most people.
bq27500's accurate current draw measurement was really nice though, I would not want to lose that. It's not only for power saving development and good battery time left estimation, _wb_ made nice graph tool which even estimates how much current various components draw: http://repo.openpandora.org/files/pnd/sysinfo.wb/screenshot-plot.png
We have had similar tools for the GTA04 which uses a bq27000 inside the battery (HDQ connected) and it is really useful for power management optimizations.
BR, Nikolaus