Laptop batteries and the smart chips in them annoy me, they often fail for no reason and refuse to charge or power the notebook. After the battery for my HP G62 died after I forgot the computer in suspend to ram, I tried to repair it…

First, I made holes on the ends and the cell voltage, which was around 9,8V, so more than 3,2V per cell. This should be should be enough to not trigger a undervoltage lockout. I also tried to charge the cells but it did not reactivate the circuit inside…

I then cracked the parts open where the electronics are:

The only chip I can see so far is a bq20Z45 (datasheet), since it connects to the cells, the mosfets (F8736) and the SMBus according to the datasheet, there is most likely no other relevant IC that locks the pack.
I measured the mosfet, they were switched off, and the fuse, which was also intact. Since simply bypassing the mosfets will not enable communication between the pack and the laptop, and therefore no charging, I need to convince the bq IC to reactivate the battery.
I searched around for some hours, going from specific search terms about my battery model and the exact management IC to more general ones. I did not find anything particular helpful until I came across a PDF about firmware hacking on apple batteries.  I just skimmed through the document, but did not read it fully. Later I also found the defcon talk about the very same topic, which I watched:

Also, the slides are available.

Inspired by the mentioned document sluu276 i searched for a technical reference for the bq20Z45 and got this.
Following this forum post, I hooked up the battery to the I²C interface of my VGA port. Graphical I²C pinouts for VGA, HDMI and DVI can be found here.

That worked great and I could send commands to the IC:

~ $ sudo i2cget -y 1 0x0b 0x0006 b 0xff

This queries the Manfuacturer Status and the result means:

  • CHG FET is on, DSG FET is off.
  • FET failure
  • Battery Removed

Fet failure is set when a current flow >20 mA is detected when the mosfets are switched off, but I measured the fets and they were good…
To clear the permanent failure flag, one needs to go from sealed mode to unsealed mode. This requires a 32 bit code, which HP obviously changed since the default code does not work.

I could try to get a new IC and solder it on the board. I then can use the default unseal key to make any changes I like and use the battery. Since this particular chip costs around 9 euros, I also thought of searching for the cheapest battery management IC, laying out my own board und using that.
This would work since the SMBus specifications are standardized and the commands to query remaining runtime etc are the same for all controllers that are SMBus v1.1-compliant.
On the other hand there could be a sort of authentication implemented in a custom firmware running on the internal microcontroller, that would block me from using another or a new chips which will then fail the authentication. I doubt that HP did this on this laptop, but I found a case of a lenovo thinkpad.
The latter one seems not to be the case since I can apply 12V to the battery terminals of the laptop and run it from that without the BIOS complaining. I had to start it on the mains since it does not even turn on without a proper SMBus talking device on the battery bus. I also got the schematics for my laptop and can tweak the charging controller if I need to.

Batteries for about 20-60 Euros seem mostly to be pretty bad, and fail after some months according to customer reviews… The orginal start at over 100 Euros, so maybe stay tuned for an article about hacking more batteries and an alternative controller into my laptop…