Friday, August 26, 2016

SMBusb - Hacking smart batteries

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.
Clarification: True 0V discharge kills Li-ion cells and you shouldn't attempt to recover them. The old controllers tried to fix over-discharged cells and they succeeded in the majority of cases because you rarely have a true 0V scenario unless you have a shorted cell or something. The new controllers on the other hand happily commit suicide at over-discharge voltages where cells are still easily and safely recoverable with little to no capacity loss.
 
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 (not counting the actual interface between the EC/SMC and the SMBus devices in the system which is usually not accessible directly and/or isn't usable for more involved operations)

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:

Search for: FX2LP board
 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:

$ smbusb_scan -a
------------------------------------
             smbusb_scan  
------------------------------------
SMBusb Firmware Version: 1.0.0
Scanning for addresses..
Skipping: a0 a1
------------------------------------
[0] ACK
[16] ACK
[17] ACK

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

$ smbusb_scan -w 0x16
  * snip *
[2f] ACK, Byte writable, Word writable, Block writable 
[30] ACK 
[31] ACK 
[32] ACK 
[33] ACK 
[35] ACK, Byte writable, Word writable 
[37] ACK 
[38] ACK 
[39] ACK, Byte writable, Word writable 
  * snip *

and

$ smbusb_sbsreport
SMBusb Firmware Version: 1.0.0
-------------------------------------------------
Manufacturer Name:          LGC
Device Name:                LNV-42T4911
Device Chemistry:           LION
Serial Number:              41291
Manufacture Date:           2010.01.25

Manufacturer Access:        6001
Remaining Capacity Alarm:   561 mAh(/10mWh)
Remaining Time Alarm:       10 min
Battery Mode:               e000
At Rate:                    0 mAh(/10mWh)
At Rate Time To Full:       65535 min
At Rate Time To Empty:      65535 min
At Rate OK:                 1
Temperature:                23.05 degC
Voltage:                    21 mV (*)
Current:                    0 mA
Average Current:            0 mA
Max Error:                  0 %
Relative State Of Charge    0 %
Absolute State Of Charge    0 %
Remaining Capacity:         0 mAh(/10mWh)
Full Charge Capacity:       5616 mAh(/10mWh)
Run Time To Empty:          65535 min
Average Time To Empty:      65535 min
Average Time To Full:       65535 min
Charging Current:           0 mA
Charging Voltage:           0 mV
Cycle Count:                529
Manufacturer Data:          fffffff7


(*):  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)


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

8 comments:

  1. Any reason for choosing this specific board? Would an msp430 be enough for this task?

    ReplyDelete
    Replies
    1. No technical reason. I had nothing on hand to use so I would've had to buy something either way and I was curious about the Cypress chip itself as well as using libusb for USB communication. The direct usb to ram firmware upload feature also turned out to be amazing for quick iterative coding/hacking (1 second between tries instead of 20-60 with a microcontroller you have to hook up to a programmer and/or reflash every time) and it doubles as a logic analyzer which I also wanted to get. I'm pretty sure you could make an SMBus interface with an msp430 if you wanted to (although I have no experience with them myself)

      Delete
    2. You made me curious for that board too! I'll put an order for it, but currently I have a handful of MSP430 in my drawer, so I'll look into porting your code (most of it should be reusable, just a matter of changing pins and registers). I'll let you know about it when I find the time to do it.
      Thanks for your quick reply, and congrats on your awesome work!

      Delete
    3. Hi Elias,
      Any chance porting the code into MSP430?
      I want to do the same thing, just with a PIC18F2550 or PICkit2 laying around.
      They're all USB2.0 standard so maybe they're up for the job?

      Delete
  2. Hi Victor, amazing job you have done. Thank you for sharing!
    I bought recently this board for testing with some spare notebook battery packs, but I can't communicate with the board at all.

    The board is recognized (lsusb output: "Bus 002 Device 010: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit"), but then it disappears.

    Running "smbusb_scan -a" shows me "Error Opening SMBusb: libusb error: -1". Also, "dmesg" shows me "usb 2-1.1: device descriptor read/64, error -110". I tested with several computers and different ports with no lack (even crosscompiled the source for a Raspberry Pi).
    Some forum guys stated that could be related to bad USB cable or power, but the board is supposed to require less than 100mA. Of course, tested also with several cables.

    Also verified with sigrok-cli: the card is recognized, but when trying to output some samples, it fails ("fx2lafw: Device failed to renumerate", while run with "sigrok-cli -d fx2lafw --loglevel 5 --samples 8").

    Do you have some clue on how to solve this issue? I am a software guy with some knowledge about electronics. The board was bought brand new from eBay, I don't feel is damaged and handled it with special care.

    Thanks in advance,
    Exe.

    ReplyDelete
    Replies
    1. Hi,

      Glad you found it interesting!

      Someone contacted me through email a while ago and had pretty much the same issue. Quote: "the FX2LP board that I got first was duff. couldn't get it to work with any software. so I bought another one, and that works". So it could be that the chip or the board is defective in some way.

      That said, I've recently added a patch to fx2lib that changes some memory address configuration for two reasons: One being that sigrok uses those values by default and the other that someone bought a board off ebay and smbusb wouldn't work with it unless they set the addresses up like that. I've checked and both configurations worked fine with my board so I ended up changing it since it seemed to improve compatibility. You could try the old addresses by building the tree at commit dd19926fd2afa8d19ac7552db7ca02da48492fd4

      Now if that works I'll have no idea why... if it doesn't then bad chip/board would be my best guess.

      Good luck and let me know how it goes!

      Delete
  3. Hi Viktor, thanks for the quick reply.

    I tried the commit you mentioned (after manually checking out fx2lib submodule) with no lack.

    My assumption is that the board is fake: According to some tests, it can be able to upload some small firmwares (less than 4KB), but when I manually upload yours (or Cypress' Vend_Ax.hex), it fails in the middle.

    That's why I think this is just a "FX2" CY7C68013 version (with no ending letter A). This version has 8KB instead of 16KB that FX2LP has. Also the output of lsusb I've commented previously acts as a confirmation.

    I will try to get a new board. In the meantime, will try to fix the one I got.
    Maybe I can play with a Raspberry Pi, it apparently has support to I2C and SMBus, what do you think?

    Regards,
    Exe

    ReplyDelete
    Replies
    1. Hi,

      Sorry to hear :/

      You may be right though the lsusb output for my board is only "FX2" as well.
      Wouldn't be surprised if they were just using chips that failed factory testing making the board purchase a crapshoot even.

      I looked into it a bit and linux's libi2c-dev has SMBus transaction functions so that's 90% of libsmbusb right there. It looks like it would be fairly straightforward to port most of the tools to use it with the exception of scan and r2j240flasher because that chip doesn't use standard SMBus once in the boot rom but still uses the RESTART condition and I'm guessing that linux doesn't give enough control over the i2c peripheral to implement that.

      Let me know how it goes if you decide to tackle it!

      Delete