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:
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)
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
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
------------------------------------
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 *
* 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
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
Any reason for choosing this specific board? Would an msp430 be enough for this task?
ReplyDeleteNo 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)
DeleteYou 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.
DeleteThanks for your quick reply, and congrats on your awesome work!
Hi Elias,
DeleteAny 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?
Hi Victor, amazing job you have done. Thank you for sharing!
ReplyDeleteI 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.
Hi,
DeleteGlad 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!
Hi Viktor, thanks for the quick reply.
ReplyDeleteI 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
Hi,
DeleteSorry 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!
I got a new battery for my ThinkPad X250 that's broken. Unfortunately they used a TI bq9000 and that has no datasheet. I tried scanning the bus with an Arduino but without success so I ordered the USB interface.
ReplyDeleteUnfortunately I've heard that they've added improvements to the BootROM entry protection in the bq9000/Sanyo firmware so you probably won't be able to get in using the method in the 8030 article. The flasher tool might still be compatible but someone has to reverse engineer the new protection first.
DeleteThis comment has been removed by a blog administrator.
Delete@орион орионВи: People can google payware solutions if they wish, I see no point in advertising them here. Most of them are aimed at businesses and priced accordingly just like the one you pointed out. This project is aimed at people who want to fix their own batteries and they're unlikely to be interested in buying a $800 license (cheapest that would work with the bq9000/Sanyo if I'm looking at it right) :-)
DeleteYou are right, but that link was posted just to show that bq9000/Sanyo was reversed, so if somebody could do it, its possible to do that. Advertisement was not the aim of that post.
ReplyDeleteAs well as others me too want to restore my battery which has bq20z90 gas gauge controller. And me no wish to pay any penny for that third party commercial products which (by opionion of some users) are cracked, modified and recompiled versions of TI evaluation software, which is free. Will not pay even one day licence as it costs as half of new battery. And to use this one day license you should carry out major scope of job like dissasembly the batteries, buy and pack new elements, spot weld them before, read much docs and so on. And no warranty that you will succesfully carry out data flash correction.
The question is how that third party tools can bypass manufacture protection and go into unseal and full access mode for 5 sec without knowing actual password (they declare to work with almost any bq chip).
it seems like backdoor was left by TI and that guys found it or there is a leak from TI or even that soft is produced by TI subbranches.
Makes sense, no worries :-)
DeleteI've been in contact with someone who looked at the bq9000/Sanyo and had access to software that could enter the boot-rom on it. The firmware is definitely based on the bq8030. The first and last steps to enter the boot-rom are the same. It's the challenge(read from 0x73) & answer(send to 0x71) part that they've worked on. The bq8030 gives you a single fixed challenge and you just need to give it the proper answer to reach 0x10000. On the bq9000 it gives you a random challenge value and you're supposed to answer based on some sort of secret key/algorithm which if correct will increase the next challenge value by some amount and you need to do this repeatedly until you reach 0x10000. So that's nastier but could probably be solved based on firmware disassembly without TOO much difficulty.
I have no idea about the functionality/reliability of that software but the cheapest ($10/day) license doesn't seem to support too much other than already documented TI chips that would work just as well with the original TI stuff like you suggested (though maybe they added brute force or dictionary attacks for the passwords on the chips)
I don't think there's a universal way in, especially on the custom firmware chips. The guys developing the payware stuff likely run/ran battery re-celling businesses of their own and had access to TONs of batteries to experiment with. Also, if the entire bq line retains the CoolRISC core along with the electrical vulnerability I used to retrieve the firmware dump from mine with then it's just a matter of perseverance and struggle to understand obscure assembly code to crack protections on them.
got a broken acer tab battery, also using bq9000
Deletehere is the scan
pi@raspberrypi:~/smbusb $ sudo smbusb_scan -w 0x16
------------------------------------
smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - ff
Skipping: None
------------------------------------
[40] ACK, Byte writable, Word writable
[41] ACK, Byte writable, Word writable
[42] ACK
[43] ACK
[44] ACK, Byte writable, Word writable, Block writable
[45] ACK, Byte writable, Word writable, Block writable
[46] ACK, Byte writable, Word writable
[47] ACK, Byte writable, Word writable
[48] ACK
[4a] ACK
[50] ACK, Byte writable, Word writable
[51] ACK
[53] ACK
[55] ACK, Byte writable, Word writable
[56] ACK
[57] ACK, Byte writable, Word writable
[58] ACK, Byte writable, Word writable, Block writable
[59] ACK
[5a] ACK
[72] ACK
[73] ACK
[80] ACK, Byte writable, Word writable
I have deal with one bq9000 gas gauge, and it has both [0x71] and [0x72] accesible, and [0x70] in full access mode to enter bootloader,
Deleteprobably you have bq9000 with newer firmware, there is at least bq9003, bq9000_T1, bq9000_L1 subversions. Algo to gain full access may be different between versions. I have firmware of older version of bq9000 with Sanyo firmware, so if somebody like to analyse for which algo it used I can send in PM the binaries.
Could you please send me that firmware, maybe I'll try to find the algo
DeleteOk, give your PM.
DeleteThis comment has been removed by a blog administrator.
DeleteFeel free to let me know once you've established contact and I could censor the comment with the email address if you'd like.
DeleteFirmware sent, so you can delete the message.
DeleteIt seems like bq9000 is the new platform with custom RISC core. It's architecture and command system is not public. Some kind of BlackBox for now:(
DeleteHi again Viktor,
ReplyDeleteMe have USB-to-I2C board based on CH341A level converter (chinese development probably copied from FTDI ICs). It cheap enough (3USD at ali uncle) and very handy as it also support SPI, USART and EPP, and can be used for programming various kind eeproms and avrs.
It also used libraries libusb or libusbk (or Zadig driver) as well as FX2LP board. In this view is it possible to use some portion of SMBusb code to link it to libusb driver so that CH341A usb board could be used to work with SMBus. Chinese maker also gives SDK for that board so if it make sense could you please point me to the place in source code where itwouldbe possible to link it with ch341a driver to make functioning with SMBus. Thanks a lot for any suggestions on this..
The tools use a library called libsmbusb (/lib in the source tree) that exposes protocol-level functionality eg. SMBReadByte, SMBWriteBlock. The library talks to the firmware. You would need to reimplement that library using your own hardware. Note though, that if that chip doesn't have a hardware i2c peripheral and you have to bit-bang it from code running on the PC then it's probably not going to work (SMBus timing restrictions).
Deletehaving received one FX2LP now doing first steps in learning the SMBUsb tools.
ReplyDeleteWhile polling the battery controller with SBS command all working nice but command 0x23 (Manufacturer Data) which returns some odd bytes.
>smbusb_comm.exe -a 0x16 -c 0x23 -r 14 -v
------------------------------------
smbusb_comm
------------------------------------
SMBusb Firmware Version: 1.0.1
PEC is ENABLED
-----------------------------
OK. Read 14 bytes
00000000ffffff940100020000012e0000
there is in fact 17 bytes long output returned although reported as 14.
While I am novice to C, have looked through the sources (smbusb_comm.c) and found that char buf[256]; which used in status = SMBReadBlock(opAddress,opCommand,buf) is declared as signed variables
whereas it expected to be unsigned one, in the libsmbusb.h header.
May be I am wrong here, but after modifying it to unsigned char buf[256] me received correct output with same command
>smbusb_comm.exe -a 0x16 -c 0x23 -r 14 -v
------------------------------------
smbusb_comm
------------------------------------
SMBusb Firmware Version: 1.0.1
PEC is ENABLED
-----------------------------
OK. Read 14 bytes
00000000940100020000012e0000
So odd 3 bytes 'ffffff' missing now in the output and its length is correct.
Nope, you're right, that's a bug! And now it's fixed, thanks! Feel free to submit pull requests on github if you find and fix stuff. I merge them ASAP if they're valid and it's better to have all the code-related conversation in one place :-)
DeleteHi Victor!
ReplyDeleteHelp me please. I built a USB SMBus interface based on the Cypress FX2LP CY7C68013A. Everything works, smbusb_sbsreport gives the answer.
I can't figure out how to send the command "unseal" consisting of two words. Controller chip is Bq20z90. I need to send the command 0x60 with two password words as written in the datasheet. The 0x60 command is a part of the 0x00 Manufacturer access command. Default unseal password is installed on my controller.
What is the sequence of commands to send two words unseal code? Write an example, if not difficult.
Thanks in advance, Yuriy.
Hi Yuriy! Read carefully sluu264a datasheet, 0x60 is NOT a part of Manufacture Access command. It's separate EXTENDED SBS command available with Full Access to gauge ONLY. It intended for reading or modifying 'Unseal Key', and not for Unsealing procedure.
ReplyDeleteUse directly Manufacture Access to unseal your gauge, if you sure it sealed with TI defpass, try following:
1. wait at least 5s (no activity allowed on smbus before unsealing)
2. >\smbusb_comm.exe -a 16 -c 0x00 -w 0414
3. >\smbusb_comm.exe -a 16 -c 0x00 -w 3672
4. >\smbusb_comm.exe -a 16 -c 0x00 -w ffff
5. >\smbusb_comm.exe -a 16 -c 0x00 -w ffff
6. >\smbusb_comm.exe -a 16 -c 0x00 -w 0054
7. >\smbusb_comm.exe -a 16 -c 0x00 -r 2
last command should return two bytes of 'OpsStatus' register which contain 'FAS' and 'SS' bits, if it starts with '0' or '8', your gauge is unsealed with full access.
Thanks for your reply! It turns out that the two words are sent one after the other and without interval. I'm gonna try that.
DeleteYes, according to TI docs, both words should be sent to 0x00 within 4s interval, otherwise procedure failed and should be repeated after 4s delay. But!;) Me especially checked this concept and found that if first half is CORRECT, interval does not matter, and you could send correct second half even after 1 hour or even next day), provided no any commands being sent to Manufacture Access (you EVEN may send any number of another SBS commands to the gauge in this waiting period!)...
ReplyDeleteYou can check this at your gauge, hope you unseal it soon!;)
Hi. Very grateful for the help! I'm travelling now. I'll do it when I get back.
ReplyDeleteGreat work Viktor!!
ReplyDeleteSMBUSB here I come. Arduino land for me.. Just Lazy.
Saleae debugging is a breeze with i2c style stuff, even setting up your own protocol if you really must.
Have cypress stuff before 10 years ago. It is nice.
I have at least 3 battery packs to make happy, all with good cells.
As for the magic smoke? We shall see. Don't create it very often, anymore.
Memories: My first switchmode design was pre-1980 - 3KW plasma cutter.
Hi Viktor,
ReplyDeleteI download all files for SMBusb and install driver for FX2lp but when open build.bat nothing happen? Can you says how to install software?
I can not find anywhere step by step installation?
I would be very grateful to you!
Did you check the prerequisites for windows on the github page? You'll also have to apply the patch file manually by downloading a port of gnu patch for windows (although it might work without it). There is also an older windows binary package on the Releases tab though YMMV with it. That's all the help I can offer.
DeleteYes I check prerequisites for windows...I am install Tdm-gcc and download libusb-1.0...when I open flasherbq8030 abort dynamic link libusb.dll is not located...where I need to write the command smsbus_scan?
DeleteHi! I try scan by smbusb_scan with FX2LP, on each line I see "ERROR: -9". How I can find interpretation of errors?
ReplyDeleteAfter a lot of googling i came acors your blog, excellent articles, until i reached the part where you talk about SONY being... sony and using everything proprietary and guess what i have?, a SONY pack(that i changed the cells, it discharges but won't charge), guess i'll chuck it to the bin
ReplyDeleteNot sure what brands I had, but I ran BatteryMon V2.1 build: 1010,by www.passmark.com software and my almost battery new was a zombie. Had windows 7 ultimate, and told it to repair computer using and F8 key, and it repaired the battery too! I had given up on the battery and was just reviving computer after a serious defrag of tiny disk.
ReplyDeleteIn addition to above, my Toshiba laptop red battery light was off and not charging, and suing BatteryMon I discovered that the battery needed to dishcarg below 95% before charging would begin. Unplugged power, discharging a bit and once below 95% it all worked again. Previously had battery pack problems with 10 yo battery, and nothing in the Toshiba manual says I needed the below 95% charge level. Original battery seemed to have died due to not enough cycles, or was it too many?? Mysteries of marketing at work, I am sure, or was it once cells get below 3.7v, once, it declares the battery pack dangerous and dead. Manually charge cells carefully, and let win 7 ultimate do the repair?
ReplyDeleteTry to disassemble senc file but got this message:
ReplyDeleteProcessor module script failed to initialize.
File: bq20z80.ry
Processor module script: missing callback 'notify_emu'
Any ideas?
Try bin instead. Senc is encrypted image. bq20z80.py does not work with it.
ReplyDeleteHi guys.
ReplyDeleteSomeone tried to access the chip TI BQ30Z55?
I make a command -a 0x16 -c 0x00 -r 2 and get four zeros in response. (0000)
What does this mean?
Hi!
ReplyDeleteThis mean you should send ManufactureAccess() OpCode first.
Reading this register without prior request returns zeros or previosly requested information.
You could find basic OpCodes in the bq30z55 TRM, sluu852a, Chapter 11.
Some of them for example
0001 - request for Device Type
0002 - request for Firmware Version
0003 - request for Hardware Version
..., etc
While bq30z55 is sealed you have only limited access to MAC-register.
Some correction.
ReplyDeleteFor readback one should use ManufactureData() register [0x23] which uses SMBUS BlockRead protocol.
So requesting bq30z55 for its DeviceType info should looks like this
\>smbusb_comm.exe -a 16 -c 00 -w 0001
\>smbusb_comm.exe -a 16 -c 23 -r 3
0550
Thank you kind man.
DeleteWithout knowing the password, I can never read this register?
May I ask one more question.
DeleteI have the ability to unsolder the chip. There is a programmer MiniPro TL866 II Plus.
But I do not have an adapter in which to install this chip. Tell me which adapter to buy? Will I be able to read the firmware dump to find the password in the binary file, if I do not know the password?
You can read [0x23] register in Sealed mode too.
ReplyDeleteBut it has limited functionality. You can not read neither DataFlash nor Instruction Flash until IC is Sealed.
So you should first Unseal it using password.
Sometimes IC could be replaced with new one and reflashed.
Then DataFlash should be configured for your specific battery.
Otherwise battery will not work correctly.
Replacement method will not work if Equipment Maker has enabled Battery Authentication. It uses challenge-response sequence to check if battery is genuine. If this check not passed, equipment will not charge battery. You should programm another Key to battery known as Authetication Key to allow this check to pass Ok.
The programmer you mentioned is not suited for bq30z55.
You should use TI ev2300 adapter or EZ-USB to reflash bq30z55.
Thanks for the answer.
DeleteI will continue to understand.
I have a debug board here. But my knowledge does not yet allow me to penetrate the controller and reset the password. Like everyone, I naively thought that soldering banks to new ones would work. But no, it still doesn’t work and, moreover, check the alarm boxes.
I bought a new battery a long time ago and it works well.
I use the old copy battery for experiments and for self-education.
At the moment I'm trying to figure out the sequence of commands to replace the password, or at least to read it.
:)
And one more thing: as far as I understand, even ev2300 without a password is a useless adapter.
DeleteIn any case, thank you for the answers.
You are absolutely right.
ReplyDeleteNevetherless too much people still believe ev2300 is Battery Almighty, in fact it useless without passwords. The only case it come in handy when Maker for some reasons "forgot" to change default Security Keys.
Then you are free to do with IC what you want.
/qoute
ReplyDeleteAt the moment I'm trying to figure out the sequence of commands to replace the password, or at least to read it
/unquote
bq30z55 is custom IC with specific functionality in Security respects.
One of which is that passwords could not be read even with Full Access rights. The commands to read them is simply missing or undocumented.
According to datasheet one could only change them while device is in Full Access.
Can you help me I can't understand how to get unseal key where to find it ??
ReplyDeleteThank you
Deletehello! I got one Cypress fx2lp. i would like to reset and change fcc values on my battery control unit, it has a m37512 on it. i installed the winusb driver in zadig, but i always get an error that libusb-1.0.dll is not installed, try to reinstall app. The interface seems to be okay because its working in pulseview. did i made something wrong? if i want to smbusb_scan comes always the same libusb-1.0.dll missing. I already tried on 2 different computert one is with win 7 32 bit, and the other one is win 10 64 bit. can someone help me a little? :) thank you.
ReplyDeletepowy
allright, i got the smbusb_scan and report working. it communicates with the chip, i got battery info. i connected on m37512 pin 9,12,43 together and replaced cells with 470ohm resistors. when i try smbusb_m37512flasher -d, i got error communicating with boot rom, chip is running firmware. if pins connected it should be already in boot mode right !? :) how can i read it?
Deletethank you
powy
I am facing same DLL missing error. How did you fix it?
DeleteI managed to fix this issue.
DeleteDownload zip from https://sourceforge.net/projects/libusb/files/libusb-1.0/ and copy libusb-1.0.dll from MinGW32\dll or MinGW64\dll (depending on your OS) to smbusb_scan folder
hi! i downloaded the DLL and copied to the same directory where smbusb programs are.
ReplyDeletei already managed to dump the whole flash, and in hex editor to change full charge capacity and the charge cycle reset to 1. i cant find where is the remaining capacity, and it dont want to charge. My controller dont have the funny Fuse :) but still not charging, on DATA block A is the full charge capacity, cycle i cant find design capacity. I tried to erase block 0-3 now the laptop cant see the battery :D i will try now to flash back ori to these blocks.
I am struggling to read.. I get ACK on only 0 reset all are error.
DeleteMine is Thinkpad X220.. Hope I have connected correctly
Pin1: Gnd Pin3: SDA and Pin4: SCL
SMBusb Firmware Version: 1.0.1
Scanning for addresses..
Scan range: 00 - ff
Skipping: a0 a1
------------------------------------
[0] ACK
[2] ERROR: -9
[3] ERROR: -9
Hi! Im not sure where is sdl and scl on your board, i searched them with a multimeter, i searched for plus and ground, do Not put anything on plus :) ( my board has two plus contact) ground is easy to found the you just need to try the rest with scl and sda, if you found the right one sbsreport should read battery info. If you have m37512 chip on your board you have to connect on chip pin 9,12,43 together and put 470ohm resistors where the cells are. If your board have the weird fuse it can be burn trough if you disconnect cells.
DeleteThis comment has been removed by the author.
ReplyDeleteвсем привет. купил адаптер silicon labs cp2112ek и какое то время его видела be2works,
ReplyDeleteпотом что-то произошло и больше не видит. в чем может быть проблема? и если кто-то им пользуется дайте пример настроек cp2112ek в программе hit smbus example
Вы использовали народное B2W. Если Вы скачали плохую версию, то эта программа переписала Вам VID PID. :( Насколько я знаю, теперь нужно делать подмену в драйверах.
Deletehello, I have battery with unsealed chip A2168:
ReplyDeleteSMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name: SANYO
Device Name: NS2P3SZMP4WR
Device Chemistry: LION
Serial Number: 53052
Manufacture Date: 2019.05.30
Manufacturer Access: 0000
Remaining Capacity Alarm: 520 mAh(/10mWh)
Remaining Time Alarm: 10 min
Battery Mode: 6001
At Rate: 0 mAh(/10mWh)
At Rate Time To Full: 65535 min
At Rate Time To Empty: 65535 min
At Rate OK: 1
Temperature: 13.55 degC
Voltage: 11138 mV
Current: 0 mA
Average Current: 0 mA
Max Error: 2 %
Relative State Of Charge 3 %
Absolute State Of Charge 0 %
Remaining Capacity: 20 mAh(/10mWh)
Full Charge Capacity: 602 mAh(/10mWh)
Run Time To Empty: 65535 min
Average Time To Empty: 65535 min
Average Time To Full: 65535 min
Charging Current: 3000 mA
Charging Voltage: 12600 mV
Battery Status: 02d0
Cycle Count: 0
Design Capacity: 5200 mAh(/10mWh)
Design Voltage: 10800 mV
Specification Info: 0021
Cell 0 voltage: 41 mV
Cell 1 voltage: 512 mV
Cell 2 voltage: 43520 mV
Cell 3 voltage: 512 mV
I can change it without any problems: cycle count, desing capacity and more...
ReplyDeletebut I can't change FCC
In the datasheet it says that to change the data in bootrom I need FullAccessKey access
It's possible change access for this chip?
-----------------------------------------
# smbusb_comm -a 16 -c 60 -r 4
12345678
# smbusb_comm -a 16 -c 61 -r 4
22345678
# smbusb_comm -a 16 -c 62 -r 4
32345678
# smbusb_comm -a 16 -c 61 -r 2
ReplyDelete2204
The wierd self blowing fuses are evil. Maybe a series resistor to the fuse blower will work, or make a fake looking fuse (to the controller).
ReplyDelete???
DeleteFC543212AH3C fuse-Resistance protector made by CYNTEC CO. Amongst others.
ReplyDeleteCpu can melt the fuse and make the battery pack dead.
Battery works and charges, but only to 602 mAh,
ReplyDeleteso that's not resistor
Can you help me I can't understand how to get unseal key where to find it ?? BQ30Z55?
ReplyDeletehttps://www.karosium.com/2016/08/smbusb-hacking-smart-batteries.html?showComment=1569513518771&m=1#c6518960050135580596
ReplyDeleteThank you very much!
DeleteHi all, I need help wiring up my battery device to the board. I don't know which pins to connect to on the Cypress board from my battery. Help?
ReplyDeleteHello and thank you for this.
ReplyDeleteUnfortunately I only ever get the error:
Error: Unable to open device. (insufficient permissions? connection issue?)
when I sub smbusb_sbsreport. I'm on windows and have got the winusb driver via Zadig driver installed, the TDM-GCC pre-requisite and I've tried building both the 32 and 64 releases with the same results. I'm running as admin in cmd.
I've tried with and without the J2 jumper and multiple USB slots on 2 different PCs.
I've go the board running in Sigrok Pulseview just fine, so I'm really confused why I can communicate with the FX2LP board with smbusb.
Does anyone have advice on what to try next?
Thanks
same problem. any help?
DeleteReinstall WinUSB driver to libusbK driver by Zadik
DeleteI had to remove the jumper on the Cypress USB module....
DeleteDid anyone heard about BQ8055A battery ? any program that could reset this battery ?
ReplyDeleteHi, I'd like to share my success hacking a DELL/SANYO T54FJ with BQ8050. I can confirm that following set of very similar steps are needed to unlock the chip.
ReplyDelete1. Send 0x0214 to 0x71
2. Read static word from 0x74
3. Read challenge word from 0x73
4. Send ???? to 0x71
5. Send 0x0517 to 0x70
The difference is that step 4 is not a simple subtraction of X from 0x10000, but rather a dynamic value that I believe depends on the challenge that can be read from 0x73, which appears to be a timestamp that increments every 219ms. The good news is that the existence of this challenge does not change the expected time taken to brute force your way in.
Steps 1 and 2 only need to be performed once, but I believe step 3 needs to be done before each attempt of step 4. So in a loop, do a read of 0x73, followed by a write of a random value to 0x71, until 0x70 becomes available. You can copy and paste the following script into PowerShell and it will do the whole process.
With regards to probability, each guess has a 1/65536 chance of succeeding, and you can get through at least 5 attempts a second. This puts the theoretical average time taken at 1.82 hrs. YMMV.
Once you are in, read the EEPROM and zero out the bytes at 0x50C and 0x60C of value A5. This completely bypasses the need for steps 2-4, and in future you can re-enter the boot ROM with steps 1 and 5 only. (This hack also works on BQ8030, although it is less useful). Then zero out the words at 0x580-0x581 and 0x640-0x641 (valued 00 80 for me) to clear the permanent failure. Reflash the EEPROM and run ./smbusb_bq8030flasher --execute to exit out of boot ROM mode.
This comment has been removed by the author.
Delete$write_71 = .\smbusb_comm.exe -a 16 -c 71 -w 0214
Deleteif ($write_71) {
echo "Error: battery not connected or already in boot ROM"
} else {
$start = Get-Date
$read_74 = .\smbusb_comm.exe -a 16 -c 74 -r 2
$i = 0
while ($true) {
$hex = '{0:x4}' -f $i
$read_73 = .\smbusb_comm.exe -a 16 -c 73 -r 2
$write_71 = .\smbusb_comm.exe -a 16 -c 71 -w $hex
if ($write_71) {
echo "Lost communication with chip"
break
}
$write_70 = .\smbusb_comm.exe -a 16 -c 70 -w 0517
echo "challenge: $read_73, guess: $hex"
if (!$write_70) {
echo "WE'RE IN!!!!!!!!!!!!!!!!!!!!!!"
break
}
$i = Get-Random -Minimum 0 -Maximum 0xFFFF
}
$end = Get-Date
echo "Started: $start"
echo "Finished: $end"
}
Oops, I meant to post this on the BQ8030 page. Also, stupid Blogger removing whitespace from code.
DeleteYou can't. You'd have to rewrite everything in C. Just save yourself the effort and spend $5 on an FX2LP.
DeleteI'm not sure what you mean by mean by jump start method. Have you cleared the Permanent Failure flag? What are the voltages across each of the cells?
DeleteNo idea. Are you working on different batteries? Before you had a DELL0163DR, now you have an Acer AS07A31?
DeleteYeah don't use flash an EEP from another battery model - it will not work. And definitely don't flash a PRG from another model or you'll brick the battery.
DeleteAnyway glad you finally got it working. Care to share which values you had to change?
Start with your original EEP and zero out all the values in the second half of the file. The battery should charge in that state. Then keep adding back sections of the original file content until it stops working. That's how I figured out which values to change.
DeleteThis is stating the obvious, but I assume you tried unsealing with the default password before hacking the bootrom? Can't remember if Acer was one of the manufacturers that used the default keys or not.
Delete# Unseal battery - 36720414
./smbusb_comm -a 16 -c 00 -w 0x0414
./smbusb_comm -a 16 -c 00 -w 0x3672
# Full access mode
./smbusb_comm -a 16 -c 00 -w 0xFFFF
./smbusb_comm -a 16 -c 00 -w 0xFFFF
# Read PF Status
./smbusb_comm -a 16 -c 53 -r 2
# Clear Permanent Failure
./smbusb_comm -a 16 -c 00 -w 0x2673
./smbusb_comm -a 16 -c 00 -w 0x1712
# Seal
./smbusb_comm -a 16 -c 00 -w 0x0020
# Reset
./smbusb_comm -a 16 -c 00 -w 0x0041
oh, all my post's deleted!!!
Deletehi, i got an used battery (samsung) with bad cell's, with bq20z40.
did some modifications and now my battery (cell's) works again!!! :)
Is it possible to reset DELL battery with BQ30422 chip?
ReplyDeleteE:\>smbusb_sbsreport.exe
SMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name: LGC-LGC2.8
Device Name: DELL TVMVN19H
Device Chemistry: LION
Serial Number: 31677
Manufacture Date: 2011.09.17
Manufacturer Access: 8e00
Remaining Capacity Alarm: 560 mAh(/10mWh)
Remaining Time Alarm: 10 min
Battery Mode: 6080
At Rate: 0 mAh(/10mWh)
At Rate Time To Full: 65535 min
At Rate Time To Empty: 65535 min
At Rate OK: 1
Temperature: 25.25 degC
Voltage: 11751 mV
Current: 0 mA
Average Current: 0 mA
Max Error: 100 %
Relative State Of Charge 1 %
Absolute State Of Charge 1 %
Remaining Capacity: 0 mAh(/10mWh)
Full Charge Capacity: 244 mAh(/10mWh)
Run Time To Empty: 65535 min
Average Time To Empty: 65535 min
Average Time To Full: 65535 min
Charging Current: 122 mA
Charging Voltage: 13050 mV
Battery Status: 0ad0
Cycle Count: 106
Design Capacity: 5600 mAh(/10mWh)
Design Voltage: 11100 mV
Specification Info: 0031
Cell 0 voltage: 8224 mV
Cell 1 voltage: 8224 mV
Cell 2 voltage: 8240 mV
Cell voltages read incorrectly.
i have bq30420 how can unseal it
ReplyDelete