Part Number:BQ27425-G2A
Tool/software: Linux
I am developing a patchset for mainline Linux drivers/power/supply/bq27xxx_battery.c to enable configuration of the following gauge DM fields from a devicetree entry: DesignCapacity, DesignEnergy, TerminateVoltage.
I was referred to the following code by Andrew Davis at TI, who maintains the driver. It reads the checksum for the DM block after writing it, to verify that it matches the checksum sent: http://git.ti.com/bms-linux/bqtool/blobs/master/gauge.c#line330
THIS CODE CAN DESTROY THE GAUGE.
I applied the above bqtool logic to my patchset, which we'd already tested successfully on two devices nearly 100 times. I made the mistake of using a smaller delay after write(BlockDataChecksum, v) than bqtool has. This caused corruption to the DM in question (subclass 82, block 0). Even after resetting that DM to system defaults from the following doc, the gauge no longer measures the battery correctly. http://www.ti.com/lit/ds/symlink/bq27425-g2a.pdf
I noticed another DM field out of range (subclass 105, offset 0), but I was unable to reset it to cpu_to_be32(0x3ef1205c), hex from: perl -e 'printf("%08x\n", unpack ("I", pack ("f", 0.47095)))'
I plan to document this hardware bug in the the mainline driver as follows: https://github.com/networkimprov/linux/blob/anvl-v4.9-bq27x-dt-8.1/drivers/power/supply/bq27xxx_battery.c#L880
I would like to know:
1) Why am I unable to reset subclass 105, offset 0? (Note: prior to the corruption, I was unable to reset subclass 82, offset 36.)
2) Do other gauges in the BQ27* family have this bug? Some of them keep DesignCapacity and TerminateVoltage in different DM blocks, so the driver may write(BlockDataChecksum, v) for the first block, then immediately write(DataClass, id) write(DataBlock, n) in order to read/modify the next block. As of today, the only way I have to isolate two such updates is by a long delay.
Thank you.