Sanyo Tool Reset Bq8030 Datasheet

• Sanyo Tool Reset Bq8030 Datasheet Tool

Sanyo Tool Reset Bq8030 Datasheet Tool

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.0/SLUU225 datasheet, cross reference, circuit and application notes in pdf format.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.Cummins Insite Password Keygen Generator Software. 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 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.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! 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?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. ( did a LOT of work on this including making a (zip) for IDA to disassemble the proprietary Xemics CoolRISC core and modifying the TI firmware.

(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. The interface. Introducing SMBusb, a USB SMBus interface based on the Cypress FX2LP CY7C68013A 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.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). 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 'smbusbscan -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, 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! 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' VendAx.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, 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!You 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. As 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:-) I'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.Hi again Viktor, Me 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. Having received one FX2LP now doing first steps in learning the SMBUsb tools. While polling the battery controller with SBS command all working nice but command 0x23 (Manufacturer Data) which returns some odd bytes.smbusbcomm.exe -a 0x16 -c 0x23 -r 14 -v - smbusbcomm - SMBusb Firmware Version: 1.0.1 PEC is ENABLED - OK. Read 14 bytes 00000000ffffff there is in fact 17 bytes long output returned although reported as 14. While I am novice to C, have looked through the sources (smbusbcomm.c) and found that char buf256; 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 buf256 me received correct output with same command smbusbcomm.exe -a 0x16 -c 0x23 -r 14 -v - smbusbcomm - SMBusb Firmware Version: 1.0.1 PEC is ENABLED - OK.Read 14 bytes 012e0000 So odd 3 bytes 'ffffff' missing now in the output and its length is correct. Post navigation.