Having gone deep down the rabbit hole of researching smart laptop Battery controllers I've ended up reverse engineering a couple of them used in ThinkPad batteries. Looking around there's very little software available out there for working with battery controllers in general and most of them cost hundreds or even thousands of dollars. Usually the chips' datasheets aren't even publicly available. (Aside from a few outtakes from chinese developer forums)


So why would you want to mess with a smart battery controller anyway?


Consider the case of one ThinkPad X100e I purchased a few months ago. Battery dead. Querying the controller reveals it's had 43 charge/discharge cycles so the cells are practically new! And yet the controller was in permanent lockout mode due to a single overdischarge condition getting logged. Trying to charge the battery in the laptop resulted in a rapidly flashing charge LED indicating charge failure.

Some people will say "Well that's by design, a single overdischarge turns Li-Ion cells into potential fire-bombs!"

If that was true there would've been a lot more cases of batteries setting houses on fire back in the early 2000s as "0V deep discharge recovery" used to be a feature in some laptop battery pack controllers back then.

It's not nearly as bad as some urban legends would have you believe. Take the battery pack I mentioned above for example. After recharging the cells externally while carefully monitoring their temperature and reprogramming the controller the pack was fine. It ended up with 100% the design capacity lasting 3.5 hours (it's a power hungry AMD system with an ATI GPU)

For the manufacturer, taking no chances from a legal standpoint is understandable but sometimes they can go a little overboard. A 3.5hr battery ending up in a landfill is not the best outcome.

Another reason would be for re-celling the pack. You have some options when the battery of your laptop dies: Replace the whole shebang because it's too slow anyway, replace the battery with a factory one for $100+, buy a chinese knockoff for $20-50 or re-cell with good brand cells for $20-50ish.

As demonstrated in my previous article about laptop batteries, keeping the original controller board has certain advantages such as temperature monitoring and an extra safety feature. It's also a good bet that brand cells will survive more cycles without capacity loss than ChangJiang ones. (I've actually recently tested a 6-cell LG pack at 540 cycles and it held a 1.5Amp load for 80 minutes.. a ChangJiang pack at 230 cycles petered out at 50 minutes. A sample size of two and the CJ pack was lower capacity to begin with (4.4AH vs 5.2) but still...)


Ok, so how do you talk to these controllers?


SMBus, which is I2C's impatient cousin with nasty hard timeouts and bulk transfer modes not standard in I2C along with a RESTART condition in addition to the START and STOP you normally deal with (... or just 1-Wire in more exotic hardware but let's not think about that).

How nasty are the timing constraints? You can implement I2C through a USB serial dongle's flow control pins. You can't implement SMBus because your code, the windows API, driver, USB stack and controller firmware response overhead added up is over the limit (especially if your serial thing uses only USB1.1). You can't keep the clock idle for over 35 milliseconds or the controller drops the conversation.


But don't go TOO fast because SMBus can't go over 100Khz (I2C can do 400). All that rushing and it can't keep up the pace in the long run, figures..

Unfortunately this makes it cumbersome to implement a dumb SMBus interface on a non real-time system like a PC alone.

Did I mention that different controllers seem to have slightly different timing requirements?

The most well supported interface for speaking with smart battery packs is the Texas Instruments EV-2300. It's a fairly expensive piece of kit but it has the advantage of being able to work with TI's own software which has a myriad of options for the publicly available TI battery controllers running the TI firmware but more on that later.


 
What's next?

Once reliable SMBus communication is established you will have access to a battery controller that talks the SBS Standard! It's a standard so we're basically done now. We just look at the standard documentation on how to clear any failure condition and reprogram the controller to our desired parameters, easy!

Ha! Yeah, no. The SBS standard only defines the very basic functionality for a smart battery controller. The controller will have something sometimes referred to as a "sealed" mode which is where it's only going to service the limited SBS standard requests. This will be the standard mode for the battery as that's all that laptops need. No touchy on any of the settings that really matter and certainly no clearing of any error conditions.

They'll sometimes have a command to "unseal" and enter full access mode where some or all settings are modifiable with a mixture of standard and unstandard commands. Most of the time this unseal command will be password protected or worse. Some TI controllers are like this while other controllers will only implement a sealed mode for SBS compliance and a completely proprietary bootloader mode to modify flash memory content directly (which may or may not also be entered in a similar way). It's really a mixed bag.

What's similar in all SBS microcontrollers is that getting into the Boot ROM where you can access and modify flash memory is hindered by the firmware that's already running on the device.


TI


Texas Instruments is a BIG player in the smart battery world. They sell their battery management microcontrollers and analog frontends to pretty much everyone making battery packs. Some companies buy the whole package that is, the microcontrollers with TI-developed firmware. The security model mentioned above (sealed/unsealed/bootrom) is actually used mostly by the TI firmware. These pre-programmed micros under the "bq"-line usually have a letter in their model number such az the bq20z90. What's somewhat less known is that the bq20z90 is also sold WITHOUT the TI firmware as the bq8030(DBT). At the very least SONY and Sanyo have opted to buy the bq8030 with the accompanying (super-secret) SDK and develop their own firmware for their battery packs with it.

Did they not trust TI's expertise? Was the firmware too expensive to license? Did the TI firmware not do everything they wanted? Who knows! But the fact is production bq8030s are pretty much complete black boxes as they run a proprietary firmware and don't work at all with TI's own software. Other bq series are sold similarly as both pre-programmed and unprogrammed versions. The bq8050 would be another example though I don't know what the pre-programmed counterpart's model number is.

The EV-2300 will still talk to the chips running 3rd party firmware but the TI software will not work for anything other than simple SBS reporting.
The ONE thing the pre-programmed and unprogrammed chips will always have in common though is the TI Boot ROM. The challenge? Actually getting into it if there's already firmware on the chip. With the TI firmware the method for doing so is fully documented: You need to send two passwords to two SMBus commands. You can even find default passwords that will work in case the pack producer forgot (or didn't care) to change it, such as one particular series of Apple MacBook battery packs. (Charlie Miller did a LOT of work on this including making a cpu module (zip) for IDA to disassemble the proprietary Xemics CoolRISC core and modifying the TI firmware. Go check it out (pdf))

With a Sanyo or SONY or other 3rd-party firmware however, you're on your own! The procedure to access the Boot ROM is not public and neither are the passwords (if there even are passwords). The latter would also be true for most battery packs using the TI pre-programmed chips as pack manufacturers tend not to use the default passwords

 
SMBusb


So the obstacles to hacking smart batteries are numerous but let's take it one step at a time. First up.. the interface. Introducing SMBusb, a USB SMBus interface based on the Cypress FX2LP CY7C68013A(datasheet) USB Microcontroller or more specifically the dev-board that's available all across eBay for around $5 shipped.

This one here:

But all FX2LP based boards should work as long their firmware isn't pre-programmed into the EEPROM.

It's open source as far as firmware and software goes, comes with a library so you can easily use it in your own projects and includes a few tools to aid SMBus and smart battery hacking such as:


Which allows scanning for available devices on the bus and analyzing the command set they expose:


and


(*):  This controller is just a bare board with no cells connected.

And also a couple of flashing tools for BQ8030 and R2J240 chips. (Note that there are NO passwords or methods included for entering the Boot ROM on already programmed chips. I may publish articles about how I got into these two at some point but be warned that it involves caveman methods and on-purpose flash corruption.)


Bonus: When you don't need the SMBusb (and you don't feel like learning fx2lib to do something interesting with the dev board) you can still use it as a 16 channel logic analyzer with sigrok. (You may need to compile sigrok from scratch with the VID/PID added in but it'll work)
And chances are you already have an FX2LP device laying around in your drawer in the form of an Altera ByteBlaster clone or one of the many USB logic analyzers that use it. You only need to access the hardware I2C pins for SMBusb to work and an easy point to get at those is the onboard EEPROM which is usually a nice big SO-8.

So where is this project?

Right here: http://www.karosium.com/p/smbusb.html