Sunday, August 28, 2016

Hacking the bq8030 with SANYO firmware

As mentioned in the previous article the bq8030 is the blank version of the bq20z90. If you bought some from Aliexpress they'd come up with the TI Boot ROM and you could use the flashing tool included in SMBusb to upload firmware and eeprom(data flash) to it.
Theoretically you could turn it into a bq20z90 by downloading the firmware from one and uploading that. (The procedure for accessing the Boot ROM on those chips is documented in datasheets and application notes.)



So how would you even start with a BQ8030 running proprietary firmware?

Google. Lots of Google.
Apparently they sell this tool for them::




Now with a SPECIAL! price of ONLY 3 THOUSAND US DOLLARS!! WHAT AN AMAZING DEAL!!!

I gathered everything I could find about this device and while it wasn't much it did provide clues that came in handy later on in the process. Especially this screenshot of the software that comes with it:




There was no way I could figure everything out based on just that but I did take notice of the function bar on the bottom.

Those could very well be SMBus commands right there.. would they have done that? Surely not.
Not really expecting much I tried a word write of 0x0214 to command 0x71 aand.. nothing obvious happened. So I moved on to poking at other things but eventually came back for a second look and that's when I realized:

Command scan starting at 0x70 before sending command

$ /smbusb_scan -w 0x16 -b 0x70
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.0
Scanning for command writability..
Scan range: 70 - ff
Skipping: None
------------------------------------
[71] ACK, Byte writable, Word writable
[72] ACK



And after


$ smbusb_comm -a 16 -c 71 -w 0x0214 
$ smbusb_scan -w 0x16 -b 0x70
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.0
Scanning for command writability..
Scan range: 70 - ff
Skipping: None
------------------------------------
[71] ACK, Byte writable, Word writable
[72] ACK
[73] ACK


So this actually unlocks an extra command which disappears again when an SBS command is issued (or when doing a full command scan starting from 0.)
The command however is not writable. Reading it returns:

$ smbusb_comm -a 16 -c 73 -r 2
023d

Interesting but insufficient.

Brick wall meet impatience

I couldn't really get any further with just that information so I started looking at the hardware instead. Having found slides from a TI presentation revealing the connection between the BQ8030 and bq20z90 I opened up the datasheet for the latter (since there's no public datasheet for the former).


Ok, nothing straightforward. No obvious BOOT pin as one would expect with a device that's not meant to be tampered with. But maybe pulling some pin high or low during reset will get me somewhere.

After the first pass no, not really. So maybe we have to set multiple pins into multiple states for it to work. Or maybe there's no such combination at all.
How about I try to abuse N/C pins instead. I have no logical explanation as to why I came to this decision. Maybe I saw a presentation somewhere about blackbox chips and N/C pins years and years and years ago but I could just be imagining things. Either way, about 5 minutes of poking at PIN #28 with a resistor connected to 3.3v in hand and triggering RESET at random intervals while running a continuous command scan:

$ smbusb_scan -w 0x16
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - ff
Skipping: None
------------------------------------
[0] ACK, Byte writable, Word writable, Block writable
[1] ACK
[2] ACK
[3] ACK
[4] ACK, Byte writable, Word writable, Block writable
[5] ACK, Byte writable, Word writable, Block writable
[6] ACK, Byte writable, Word writable
[7] ACK, Byte writable, Word writable
[8] ACK
[9] ACK, Byte writable, Word writable
[a] ACK, Byte writable, Word writable


Wow, that worked?
Umm.. ok.. let's just reset for now..

$ smbusb_sbsreport
SMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name:          ERROR
Device Name:                ERROR
Device Chemistry:           ERROR
Serial Number:              4294967287
Manufacture Date:           1980.00.00


Uh-oh.. Well that's not good!
It seems we're stuck in the Boot ROM. Is the chip fried? It's at this point that I coded up the flash tool to try and read the flash contents. (I wasn't really bothered by the chip dying as this was one of 2 sacrificial controller boards I kept just for messing around with.)
And the results? Apparently we can corrupt (ideally just) the first couple of blocks of flash if we bully PIN #28 while the chip is trying to start up. The good news though? (If we're lucky) We get 99% of the firmware, and thanks to Charlie Miller we have a disassembler(zip) for it.

Did messing with Pin #28 even have an effect? Could it just have been the erratic resetting of the chip that triggered the malfunction? Did I short VCELL+ to Pin28 while messing about? Was there high voltage on VCELL+? Was it just ESD?
No idea. But I did manage to reproduce the result on another chip using the same procedure. So when in doubt and you have nothing to lose, act like a caveman, I guess?
The only good thing about this method is that even if you have 0 knowledge about whether there even IS a method for entering the Boot ROM in the firmware let alone what it is there's still a high chance that you'll get in. How much of the firmware survives is another question.

Disassembly

A couple of hours of staring at unfamiliar assembly code later, here are the relevant parts for entering the Boot ROM with annotations:

cmd_handle_71
    ..      
    calls       smb_ACK
    ..
    calls       smbSlaveRecvWord
    move        a, (i3,0x1A)
    or          a, (i3,0x1B)
    jeq         check_71_pass
    move        r2, (i3,0x1B)
    add         r2, (i3,0x19) ; smb_word_LSB
    move        r3, (i3,0x1A)
    addc        r3, (i3,0x18) ; smb_word_MSB
    or          a, r3, r2
    jeq         accesslevel_oreq_40
    move        a, #0
    move        (i3,0x1A), a
    move        (i3,0x1B), a
   
check_71_pass:
    ..
    move        i1l, (i3,0x19) ; smb_word_LSB
    move        i1h, (i3,0x18) ; smb_word_MSB
    cmp         i1h, #2
    jne         wrong_pass
    cmp         i1l, #0x14  ; is 71 0214?
    jne         wrong_pass
    ..
    jeq         accesslevel_oreq_80


This is the first password check, seem familiar? It's the one that we saw in the screenshot above 0x0214 to 0x71. It sets an access flag that gets checked later on. Basically if (smbSlaveRecvWord(0x71) == 0x0214) { access_level |= 0x80 }; But wait.. It can set two access flags based on whatever (i3,0x1A) and (i3,0x1B) are. Hrmm.. Well I don't know what those are and can't find where they're set so let's assume the first jeq will not jump once we've given the correct first password because it would make sense. We can also see that it checks the word we send against those mystery bytes somehow and if it likes what it sees it sets access flag 0x40 and the mystery bytes to 0.

A little bit further up we find the entry point for the Boot ROM:

cmd_handle_70:
    *snip*
    move        r3, access_level
    and         r3, #0x40
    cmp         r3, #0        ; don't even bother if access
    jeq         cmd_handle_71 ; flag 0x40 is missing          
    *snip*   
    calls       smbSlaveRecvWord
    move        r2, (i3,0x19) ; smb_word_LSB
    move        r3, (i3,0x18) ; smb_word_MSB
    cmp         r3, #5
    jne         wrong_pass
    cmp         r2, #0x17      ; is 70 0517?
    jne         wrong_pass
    *snip* (prepare leaving the firmware safely)
    calls       bootrom_execute

So now we know pretty much what we need to do.

1. Send 0x0214 to 0x71
2. ???
3. Send 0x0517 to 0x70
4. Profit

And we've made the educated guess that Step 2 is really "Send 0x???? to 0x71" so we're pretty much done with the disassembly as 16 bits is way within the realm of bruteforceability and since I had another sacrificial board as well as a battery pack running SANYO firmware I had everything I needed to attempt it.
As it turns out there's another mandatory step between 1 and 2 and it was sheer luck that I left it in my brute force loop. 0x73, the command unlocked by sending the first password needs to be read before entering the second password. Which is...*drumroll*

0xFDC3

After realizing that the first unlocked command is important (why else would they have made it mandatory otherwise) it's not that surprising that when adding the number returned by it (0x023d) to the bruteforced value we get a nice round result: 0x10000 which is probably what the adding in the assembly and the mystery numbers are all about.

So to sum it all up:

1. Send 0x0214 to 0x71
2. Read Word X from 0x73
3. Send (0x10000 - X) to 0x71
4. Send 0x0517 to 0x70

Actually, sending the correct word in Step 3 will unlock several extra commands not just 0x70 for the BootROM entry but they all disappear as soon as you send an unrelated command much the same way as 0x73 does with the first password.

We don't really care about those though because we already have what we wanted:

$ smbusb_comm -a 16 -c 71 -w 0214
$ smbusb_comm -a 16 -c 73 -r 2

023d
$ smbusb_comm -a 16 -c 71 -w fdc3
$ smbusb_comm -a 16 -c 70 -w 0517

$ smbusb_bq8030flasher -p prg.bin -e eep.bin
------------------------------------
        smbusb_bq8030flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
PEC is ENABLED
TI Boot ROM version 3.1
------------------------------------
Reading program flash
.............................................................
.............................................................
*snip*
.................................................
Done! 
Reading eeprom(data) flash
...................................................
Done!

$ xxd eep.bin
0000000: ffff 0031 076c 00c8 ffff 11f8 19e0 0355  ...1.l.........U
0000010: 0853 414e 594f 0030 3820 20ff ffff 0407  .SANYO.08  .....
0000020: 0b49 424d 2d34 3254 3532 3531 2020 2020  .IBM-42T5251   
0000030: 044c 494f 4e20 ffff ffff ffff ffff ffff  .LION 

*snip*


Huzzah!


Reset


To actually remove the permanent failure flag we need to look at the eeprom area.
The file is 2048 bytes and it has two sections.

The first 1024 bytes contains the static data (the beginning of which you can see in the hex dump above). It contains all the data set by the manufacturer that never changes during the lifetime of the battery. Design capacity/voltage, serial and model numbers, default settings, etc.
This part is protected by a checksum somewhere which you'll need to find and fix if you want to modify anything in there.

The second part contains the dynamic data. Basically the "log" of the battery with current remaining capacity and similar things that get updated as the battery is cycled.  Also, the failure flag.

You pretty much just need to start mapping out the values and then zeroing or FF-ing out the ones that you can't map to anything to see if that fixes it or breaks something else. There's no checksum on the dynamic area so you are free to modify this section all you want. Repeat until desired outcome is reached. That's what I did.
Some helpful tips:
  • On my specific battery the log starts at 0x500 and has several entries that all need to be modified (mostly duplicate data)
  • Battery capacity is stored as the remaining capacity reported through SBS divided by 2.
  • Cycle count is stored as CycleCount-1 (eg.: SBS value: 223, Eeprom byte: 222)
  • Remaining Capacity Alarm is stored as-is. A good place to start mapping.
  • It's a good idea to reset the cycle counter. I don't want to start conspiracy theories but... at least with this specific model there's been a lot that died inexplicably around the 200 cycle mark. Coincidence? Probably, but it can't hurt.
  • Please don't ask me to fix eeprom dumps :-) 
  • Good luck!
And the result:


It took the estimate a charge cycle to normalize. This particular battery lasts 2 hours on constant high CPU load after external recharging and clearing of the fail flag. Not bad for a 10 year old battery in a 12 year old machine and since the other choice was THROW IT AWAY AND BUY A NEW ONE  I consider this a win :)

PSA: DO NOT WRITE PROGRAM FLASH. You don't need to rewrite the firmware to recover a battery and there's an issue affecting some platforms/boards that WILL result in a brick if you do, especially if you're using the outdated Windows builds. https://github.com/karosium/smbusb/issues/10
You just need to read/write the data/eeprom flash.

227 comments:

  1. It was such a pleasure to read this! Thanks for posting it.

    Secret hacking recipe: "How about I try to abuse N/C pins instead."
    :o)

    ReplyDelete
  2. I've always wondered how boot ROM is loaded onto these chips in the first place. If one can overwrite the gauge chip with a custom boot ROM, wouldn't that allow loading arbitrary firmware?

    Also, do these chips have a JTAG interface that will allow for easy uploading/downloading of the firmware?

    ReplyDelete
    Replies
    1. There wouldn't be a need to mess with the boot rom if this low-level programming access was available. Could just use it to manipulate the other parts directly :-) But for all we know the boot rom could be stored in actual mask ROM on the chip, never to be changed.

      I wouldn't be surprised if there was some sort of hardware-level programming interface that they use to upload the boot rom in a manufacturing step but there's no way of knowing what/where it is or whether it was permanently disabled afterwards or not (that I know of).

      Delete
  3. Hi. Good job. I would like to ask You, maybe someone knows how to unlock charging in dell batteries with external power supply ? I know dell batteries must have 100 ohm resistance from GND to SYSpress pin, discharge works, but charge not. Maybe someone knows smbus command to unlock charge ?

    ReplyDelete
    Replies
    1. No clue, sorry. I haven't worked on them and Dells seem to be one of those packs that have "special" firmwares based on screenshots from payware battery hacking software. Honestly if you're not hell bent on not paying a cent to anyone like I was you're probably better off finding a local re-celling business. Good luck!

      Delete
    2. Hi. It is possible. Just send to manufacturrer access comand 0x108 in hex

      Delete
  4. Hi,

    I found this blog using Google after scratching my head over a few days.
    My ThinkPad T430 battery has gone kaput. I disassembled the battery. The cells is good, each holds a charge of 3.9V but there is no output on the battery header (7 pins).
    My guess is the controller chips seem to think that it's time to declare death to my battery.
    How to reset this controller chips? Is it even possible to write a new firmware to these chips so they will accept to work again?
    I see a bd8030A and bq29330 chip.
    Below is pictures of my actual battery, disassembled.
    imgur.com/a/8IJi2

    ReplyDelete
    Replies
    1. The method described in the article above should work with that pack, yes. Some experience with electronics and reverse engineering binary data files is required. The article about fuses (sidebar, 2016, September) is also relevant. I can't offer any assistance beyond that. Good luck!

      Delete
  5. Very good job!
    I have here battery from Thinkpad Edge E520 which is working, but have low capacity. I want to try change cell for new Sanyo NCR18650GA 3500mAh and change FW to the right capaity.
    I hope that it will be success, I never tried play with laptop batteries chips :)

    ReplyDelete
    Replies
    1. I hope so too! Let me know how it turns out.

      Delete
  6. Hi, nice guide; I'm trying this out on some old X61 batteries
    I read out the eeprom and flash areas successfully, but when I do sbsreport subsequently I'm stuck with the error messages (with the date at 1980 etc, as you had above). How do you reset that?

    ReplyDelete
    Replies
    1. Hi,

      Did you try "smbusb_bq8030flasher --execute" ?

      Delete
  7. Hi Victor.
    I try to recover my dell battery. It has bq8050 on a board. And I have a question, how do you able to get a software from Bq8030 before disassembling a code? I don't understand, how do you know about 0x0214 password and I fully not understand 0xfdc3... Thank you!

    ReplyDelete
    Replies
    1. I have no clue about the bq8050 so keep in mind that it may not be compatible with the tool I've released. Also keep in mind that this bootrom entry method is SPECIFIC to the Sanyo firmware. Dell likely has their own custom firmware even if the cells used in the pack are Sanyo based on what I've seen in payware battery hacking software so this method is unlikely to work.

      On to the questions:
      It was possible to glitch the bq8030 into clearing the first block of program flash hence ending up in the boot rom "permanently". The method is written in the article. You will not be able to recover the chip after this without an intact firmware image so I wouldn't try it if you only have one battery and also YMMV. I had several controller boards to sacrifice so I didn't care. Once you're in the boot rom you can read the (corrupted, first block missing) firmware and since you're only missing initialization code at the start you can still disassemble this to extract the password(s) that you can then use on other batteries. Password #3 was brute-forced as I've also written. This was done with a one-off tool that isn't included on github. From there it was guesswork to arrive at the significance of the value read from 0x73 and the final password but the correctness of this has since been confirmed by others.

      Delete
  8. Hi Viktor,
    You have done amazing work! Also very well presented!
    I'm waiting for the adapter board to try to mess around with my battery :)
    Thank you very much for sharing it!

    ReplyDelete
    Replies
    1. Hey, glad you found it interesting!

      Delete
    2. Hi Viktor,
      I received the adapter yesterday and managed to patch capacity and cycle counts in my battery.
      The problem with my battery is that I installed 4.2V cells instead of 4.3V. There're values in the first 1024 bytes of the eeprom that looks like 4300 and 12900 and I would like to try to adjust them, but I need to figure out where is the checksum and how to recalculate it. I would be easier to do having several eeprom dumps. Can you share your eeprom dump?

      Delete
    3. Shoot me an email :-) (search for "Contact" on the page)

      Delete
  9. I was just wandering is it possible to communicate with the battery using internal laptops i2c (SMBus)?
    Linux has userspace utilities i2c-tools. Is it possible to access installed battery's rom/eeprom from a running system?
    Thanks!

    ReplyDelete
    Replies
    1. AFAIK you can't access the EC's SMBus through the machine. The EC manages the bus by itself and only provides an abstracted interface that's accessible to drivers. It might be technically possible but ECs are similar to battery controllers in that you'd have to find and reverse engineer this functionality on each and every one of them and I don't see EC i2c bus drivers in the linux kernel tree. I could be wrong though but that's my understanding :-)

      Delete
  10. Hello how are you. Congratulations on the post.
    I have a lenovo battery with two IC (1: BQ8030BT, 2: BQ29330). When replacing the cells, the cali bration data and the serial number were lost. The computer recognizes it, but even though it has a load it says "0% and loading".

    I am programmer and I have done things in electronica, I have eeprom programmers, I would be grateful if you could tell me how to recover the firmware data.

    thank you very much, Diego

    ReplyDelete
    Replies
    1. Hi,

      The serial/model number and basic factory calibration are usually in the static area. There really isn't a way for them to go away unless your data flash area is corrupted but then the whole pack would just stop working.

      I can't help with individual cases I'm afraid. I could give you a couple of hints if you posted an smbusb_sbsreport of the pack but that's about it.

      Good luck!

      Delete
  11. Hi, I'm working on a DELL battery with TI chip BQ30423. Do you think if it can be hacked? With this tool? Or I have I2C analyzer.

    Thanks in advance.

    ReplyDelete
    Replies
    1. No clue, sorry. I haven't worked on them and Dells seem to be one of those packs that have "special" firmwares based on screenshots from payware battery hacking software. Honestly if you're not hell bent on not paying a cent to anyone like I was you're probably better off finding a local re-celling business. Good luck!

      Delete
  12. Hi Viktor, interesting article and good job carried out!

    You mentioned about series cases with that kind of batteries where they failure to work after reaching 200 cycles of charges. It was just an assumption.

    After you make possible to modify dinamic area of eeprom, Did you play around with that counter value? You mentioned that you just reset it, but if you set it to 195 for example and making 5 to 10 discharge cycles it become possible to confirm or not a manuf.consp theory;)...

    Can you do this trick and share us the output...

    ReplyDelete
    Replies
    1. Hello,

      Glad you found it interesting!

      I didn't do anything like that, no. That particular pack was fairly weird in that it was basically two batteries in one and the firmware "bank-switched" between a 4cell 18650 and a 4cell flat-cell (which had an obscure model number which I forgot) pack. I was pretty much joking about the the conspiracy stuff ;-) If anything it's way more likely that 200 cycles is about where this whole bank-switching business catches up with the amount of cleverness they had to put into the firmware to make this pack work.

      I no longer own the machine or the battery so I can't do any more experiments on it unfortunately.

      Delete
  13. did you replaced battery elements as well, or just cleared PF and CC flags?

    in case elements replacing its required to do calibration for new elements by changing some data flash fields like battery chemistry, design capasity and so on. Its quite easy with TI bq Evaluation Software using their EV2300 usb board. But how to do this using SMBusb? how to find (map) eeprom fields relevant for that calibration?

    Thanks for replies

    ReplyDelete
    Replies
    1. I recharged the original cells externally and cleared the fail condition, no re-celling.

      It sounds like you're talking about the calibration values in the static area. I don't think they're as much for the cells as they are for the board/pack configuration. If you replace the cells with new, identical capacity ones then you can leave the static calibration alone and just raise the Full Charge Capacity values in the dynamic area back up to the Design Capacity(+~15% since with new cells you'll probably be over the design capacity and the controller likes adjusting downwards more than up). The controller should then re-learn the actual capacity in a charge cycle or three.

      If you want to re-cell with different capacity cells than what the pack was designed for THEN you'd need to poke at the static calibration. That area is checksum protected and I haven't really looked into it.

      Delete
  14. Have you encountered with 4s delay while brute force the unknownhalf of password. It's not clear in the disassembly any related code for delays.
    Or Sanyo doesn't implement this technique?

    Me now trying to get into bq20z90 controller but chip is sealed. Default unseal key found on TI support page seems to be changed by pack manufacturer. On one freek forum me found suggestion to use external trigger/multivibrator on reset pin of bq chip to increase brute force attempts. How do you think is it good idea ? And have you ever deal with sealed bq20z90 with ti firmware? Are their bqStudio and EV2300 able to unseal their own sealed micros? Thanks

    ReplyDelete
    Replies
    1. I was able to run bruteforce loops on the bq8030 without needing to add any delay. Once I got the sequence of commands right it "just worked". That said, as you know, that isn't the TI firmware. I actually never worked on that at all.

      Resetting them is pretty safe in my experience though so if I was dealing with a delay I'd probably try going that route. Maybe hooking up the reset to a GPIO on the SMBusb board and adding the functionality to the library.

      I think bqStudio would just prompt you for the password as well.

      Delete
  15. do you remember, after resetting bq's chip, whether controller goes into active status or so called shutdown one? the latter require applying external source voltage to '+,,,-' output pins of pack to bring it into operational status again. It's need for correct implementation of 'bruteforce loop with reset'.

    ReplyDelete
    Replies
    1. I don't think any of the batteries I've worked on required me to do that. Once the firmware started up with the correct data they just started working.

      Delete
  16. Hello, I am new in this programming. After couple of evenings I managed to build the libraries. But I dont understand how to put the firmware to the cypress board. I also get an error seen below.

    $ smbusb_scan -a
    ------------------------------------
    smbusb_scan
    ------------------------------------
    Error Opening SMBusb: libusb error: -1

    How to figure out with this error?
    I am using Linux ubuntu.

    ReplyDelete
    Replies
    1. Hi, Firmware is uploaded automatically to the ram of the microcontroller. -1 error pretty much translates to "can't find/open interface". What you do get for lsusb?

      Delete
  17. Lsusb, i will get "Bus 001 Device 010: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit"

    ReplyDelete
    Replies
    1. Looks correct. Any errors in dmesg? Did you build the latest commit or the release? Did you try running the tool as root to rule out permission issues?

      Delete
    2. Got it to communicate. Problem was with permissions. Tried with root and it works. Thank you for your help.

      Delete
    3. How to bruteforce the value I get with "smbusb_comm -a 16 -c 73 -r 2". Because I will get the value 062f.
      So the third step command will be different I guess?

      Delete
    4. Quote: "3. Send (0x10000 - X) to 0x71"
      0x10000 - 0x062F = 0xF9D1 so:
      smbusb_comm -a 16 -c 71 -w f9d1
      smbusb_comm -a 16 -c 70 -w 0517
      If that doesn't work then your firmware has a different protection scheme...

      Delete
    5. It worked. Got the bin files from battery. What kind of hex editor do you use? Seems that mine does decode it different. There are lots of dots and symbols, only few words similar with what i see with smbusb_sbsreport.
      Txt file what I see - https://www.upload.ee/files/7714349/eeprom_hex.txt.html
      eeprom file - https://www.upload.ee/files/7714360/eep.bin.html

      What for is the prg.bin ?

      Delete
    6. Good to hear! The file seems correct to me. It's not the hex editor. You should look into how computers store numbers. Binary and hexadecimal numbers, byte order and so forth. There are resources out there but unfortunately I can't help you with that, Google is your friend.

      prg.bin is the firmware

      Delete
  18. I accidentaly deleted the firmware from the chip, but flashing prg.bin there comes an error
    Erasing program flash
    Done
    Flashing program flash
    Error:-11

    Is there any place where are all the smbus error codes?

    ReplyDelete
  19. For unknown reason I wanted to flash eep.bin and prg.bin together. It deleted the firmware from the chip and got an error -11. Now scanning gives me result [16] ACK [17] ACK
    smbusb_scan -w 0x16
    [35] ACK, Byte writable, Word writable
    [37] ACK, Byte writable, Word writable, Block writable
    [39] ACK, Byte writable, Word writable

    nothing above 70 anymore. Is the chip bricked now?

    ReplyDelete
    Replies
    1. Do the flashing tools still work? If yes then you're stuck in boot-rom. Try flashing the firmware again. If not then pretty much yes. Error -11 there is a libusb error. The weird thing is that it's LIBUSB_ERROR_NO_MEM = -11 so.. Insufficient memory... I have no idea how that could've happened.

      Delete
    2. Unless you legit ran out of ram at the worst possible time because maybe you installed everything in a live environment? That may or may not have happened to me before :-)

      Delete
  20. May be USB board is of simplified version?

    It was reported "CY7C68013 EZ-USB FX2 USB 2.0 Development Kit" by lsusb,
    so without index 'A' and 'P' for the chip and board accordingly.

    ReplyDelete
  21. And some new command reaveled? [35],[37],[39]
    Seems like intermediate access level.
    Viktor, did you saw these commands while got in bootrom?

    May be trying to read them will show some interesting?

    ReplyDelete
    Replies
    1. No idea whatsoever, I haven't saved scan results :-)

      Delete
  22. Hi Viktor!

    coming back to our discussion regarding resetting the bq controller,

    /q
    >Resetting them is pretty safe in my experience though so if I was >dealing with a delay I'd probably try going that route. Maybe hooking >up the reset to a GPIO on the SMBusb board and adding the >functionality to the library.
    /q

    me have some questions about implementing that in practice.

    In order to add this functionality to FX2LP it is required to add new function to bitbang the output pin i.e. PB0.
    Is it sufficient to edit/modify some sources/header files from project package, or it will require redesigning firmware from thescratch using Cypress SDK?

    Another question is about so called 'partial reset' of the controller.
    I found in the datasheet for bq20zxx small quantity of information about this kind of reset, and even dedicated counter in the dinamic eeprom field allotted for this. May be you know some idea on how to triger that one without a full reset. May be buffer overflow or other tricks will work? Just to check which kind of reset will perform faster for bruteforce loop.

    ReplyDelete
    Replies
    1. FX2LIB should provide that functionality in the form of having a #define for the port's registers. You may want to set that port's pin to an input when you don't want to keep it at a certain state (ie. you just want to let the controller run) and set it to an output with a low state asserted to reset it. This should all be simple bitwise manipulation of the control registers. The datasheet of the micro should help. (Note: I haven't actually tried any of this, it just usually works like this)

      I have no idea what a "partial reset" is according to TI, unfortunately... and the public datasheet isn't helping :/

      Delete
  23. Viktor, have you figured out how much bytes of firmware was corrupted after playing with pin 28 levels? May be comparing with another image..

    Is it really possible to recover in such way bricked chip with a new intact firmware of same version, say got from another source?

    ReplyDelete
    Replies
    1. It triggered a clear on the first 192 bytes (64 instructions) in the program flash. As noted by Charlie Miller, the program flash rows clear to FFFF3F which is a NOP instruction in CoolRISC, likely a feature of the chip. When the first instruction is a NOP I'm guessing the chip thinks it's blank and enters the boot-rom.

      I did reflash a valid bq8030 firmware image onto the chip I did this to and it started right up. Although note that I didn't test it at all aside from running an sbsreport (which worked).

      Delete
  24. These bytes should likely happen to corrupt in the very beginning for this described method to work? If they do somewhere in the middle the BootLoader will be able to pass boot vector next to corrupted firmware and the method will not work?

    ReplyDelete
    Replies
    1. Not entirely sure since I don't know how the clear occurs exactly. Do note that I've managed to do this twice though, so it's either very likely that the clear will occur at the beginning or if you corrupt the flash elsewhere you might end up in the boot-rom just the same. I don't remember if I read the second chip out or not, could've just checked whether it was in the boot-rom and left it at that.

      Delete
  25. > ' I did reflash a valid bq8030 firmware image onto the chip I did this >to and it started right up. Although note that I didn't test it at all >aside from running an sbsreport (which worked)'

    It's good news! Thanks

    ReplyDelete
  26. c:\karosium>smbusb_bq8030flasher -w eep1.bin
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    TI Boot ROM version 3.1
    ------------------------------------
    This will erase and reprogram the eeprom(data) flash on the microcontroller.
    If you're sure add --confirm_delete and try again.

    c:\karosium>smbusb_bq8030flasher -w eep1.bin --confirm_delete
    smbusb_bq8030flasher: unknown option -- confirm_delete
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    options:
    --save-program= , -p = save the chip's program flash to
    --save-eeprom= , -e = save the chip's eeprom(data) flash t
    o
    --flash-program= , -f = flash the to the chip's progr
    am flash
    --flash-eeprom= , -w = flash the to the chip's eepro
    m(data) flash
    --execute = exit the Boot ROM and execute progra
    m flash
    --no-verify = skip verification after flashing (no
    t recommended)
    --no-pec = disable SMBus Packet Error Checking
    (not recommended)

    c:\karosium>

    ReplyDelete
    Replies
    1. Ah yes, that message was fixed quite a while ago but the windows binary release is a bit outdated. It's -, not _ so --confirm-delete :-)

      Delete
  27. Thank You.. I looked at the source and understand, that's good. So can You some share with where can I find a PF (permanent Failure) flags.. A EEPROM is quitely the same with Yours?

    ReplyDelete
    Replies
    1. Can't help there are at all, sorry. I just hacked away at it until it started to work. Haven't made any notes or anything :/

      Delete
  28. Oh I Find it is somewhere between adresses 0x600-0x65F. I copied a block from EEPROM above and MOSFETS are open and battery begin to charge.
    Great thanks, Viktor! Very nice work, and good base for projects.
    Another one question that I seems to erase one bq8030 it is indicating only ACK on 0x0 and 0x1, can I download there a software from another BQ8030 or me to waste it out?
    Thank You!

    ReplyDelete
    Replies
    1. Great to hear you got some use out of it :-)

      Not sure what could be going on with that second chip. If you did a full erase it should default to the boot-rom. Only two commands ACKing is weird. It is possible to flash firmware between chips but you need to be in the boot-rom otherwise the tool won't work.

      If you have a corrupt (but mostly intact) image on the chip it could be failing the checksum test and locking you out. In that case you'd probably have to try the pin28 glitching method I described in the post to get into the boot-rom first. If it's not that then I have no clue.

      Delete
    2. Tried to send image directly with address 0x00 so now it is a brick.. Nothing bad, I have many controllers to game now:-)

      Delete
  29. that is the link to EEPROM file https://yadi.sk/d/vbB1AqXL3QjTFf

    ReplyDelete
  30. Some success over here :)
    In my battery (Sanyo Lenovo 42T4644) start of log area (0x500) is kind of duplicated at 0x600 and only fiddling with bytes at the later offset takes an effect. Quick memory map:
    0x600-0x601 - cycle count as seen in SBS report. (exact, not -1 like in author's case)
    0x602-0x603 - Full Charge Capacity

    Then there was some values up to 0x61F, then all 0xFFs.
    And then some 01 00 00 at 0x640..
    Fiddling with this reveals the error flag bit is at..
    * 0x641 *
    Changing 00 -> FF makes battery report "charging current (SBS cmd 0x14)" as non-zero (5000mA).

    Now time to restore that weird fuse, recell, and $profit$. I'll force my X250 to swallow some 2008 T400's battery right at the end of 2017 :)

    ReplyDelete
    Replies
    1. Nice! Glad you could put it to good use :-)

      Delete
    2. But no. Despite bridging the fuse battery don't want to take nor give any current. I started to mess with the bytes even more, and then.. I locked it out. I can't flash the eeprom anymore. The only clue: sbs command scan gives this distinct result: https://gist.github.com/amateusz/3308986e843e8745f58535c6d89d68ac

      Disconnecting and reconnecting the cells doesn't help either.

      Delete
    3. Well you seem to be stuck in the "bad eeprom data"/recovery mode of the Sanyo firmware. I haven't released any code for this but I've actually ended up there at one point and I did code a tool to flash eeprom data with the available commands. I don't remember much about it so YMMV but here it is: https://pastebin.com/ZNPDXqZ9 Probably nothing will work besides flashing eeprom data.
      Let me know if you manage to get any use out of it. Good luck!

      Delete
    4. I don't know if it is still actual for the author of the post but I leave this note for those who has got the same problem.

      1) Erase eeprom (it must be done before writing):
      smbusb_comm -a 16 -c 46 -w 30
      30 is eeprom row number (0x30 * 0x20(32) = 0x600)
      One row is 32 bytes.
      This command (0x46) erases 64 bytes (2 rows: 0x600-0x63F)!

      2) Write data to first row of eeprom:
      smbusb_comm -a 16 -c 44 -w 3001...32
      30 - eeprom row number.
      01...32 - 32 bytes from your eeprom dump (0x600-0x61F)

      3) Write data to second row of eeprom:
      smbusb_comm -a 16 -c 44 -w 3101...32
      31 - eeprom row number.
      01...32 - 32 bytes from your eeprom dump (0x620-0x63F)

      4) Restart:
      smbusb_comm -a 16 -c 49 -w 0502
      0502 - password.

      I found these when had been looking over the disassembled firmware of LNV-42T4791 (SANYO).

      Delete
  31. For make MOSFET's open after burning a fuse I found in BQ20zXX docs what is happened when controller burns a fuse:
    The Charge FET, Discharge FET, and Pre-Charge FET are all opened. 2. [TCA] and [TDA] in Battery Status is set 3. Charging Current and Charging Voltage is set to 0. 4. Data Flash Writes is disabled 5. if A and [XCFETF] or B and [XDFETF] in Permanent Fail Cfg then – 0x3672 is programmed to the Fuse Flag. – The Safety Output pins is activated which is intended to blow a fuse
    BQ8030 working is the same. So we need to set a charging voltage and current to desired value. Can controll it by SBS REPORT tool.

    ReplyDelete
    Replies
    1. I'm pretty sure this is what you meant but just to clarify: When we find and clear the fail flag it sets the charging current and voltage in the SBS report to the normal values (instead of 0) indicating that the pack is ready to take a charge. (ie. we're not setting the values directly, they change to the normal ones once we clear the flag)
      I might've forgotten to mention it in the article but yes, that is probably the quickest way to know whether you've found the fail flag.

      Delete
  32. Denis Serik, are you sure that this procedure will be the same for bq8030/Sanyo? It's firmware specific and bq20z90 running TI native firmware.
    Me have one sample battery with bq8030 and one with bq20z90 inside and I already accertained how they are different in operation just with few measurements. For example, elements in battery with bq8030 have about 700mV imbalance and battery continues operation without any PF flags set. For bq20z90 in that case it would be triggered the fuse as 100mV is deemed already critical. And I still not even found where that threshold is mapped in bq8030 eeprom. Another difference for bq8030 that battery output voltage is present at pack socket when battery removed from laptop in comparison with bq20z90, where this depends on SYSTEM_PRESENT signal at some socket pins.

    ReplyDelete
  33. I think that BQ8030 is a simplified firmware that one is used by ti in BQ20xxx.
    Ti gives an extra protection algorithms and more complicated.Sony/Sanyo enhansed an operating range of battery, allow battery to work to the bitter end, enhanses a battery life and makes it a cost-effective with enough protection. It is my opinion. PF flag set is another algorithm so if You are lucky, You may to avoid to set it for a very long time.

    ReplyDelete
  34. how did you interface the bq chip with the cypress dev board? did you take out the chip and connect with wires or otherwise?

    ReplyDelete
    Replies
    1. Through the main connector of the battery pack.

      Delete
    2. did you use an oscilloscope to find which pin is the clock, and which one is the data?

      Delete
    3. I just googled "thinkpad battery pinout" but you can also take the bq20z90 datasheet and follow the traces on the board.

      Delete
    4. i got the board. lsusb reports it with string "0x0925,Ox3881" and running "smbusb_scan -a" returns error -1. By looking at the sources it seems your code is pointing to device "0x04b4,0x8613". So I modified the code to point to what i have, and it seemed to work but once the firmware was loaded the device string changed and i had to go back to the previous version. From this point i could start working with. Is there any command i had to run before using smbusb_scan?

      Delete
    5. It sounds like you got an unusual board. Most of the cheap FX2LP devboards that I know of thus far have used 04b4/8613. You can modify firmware/dscr.a51 and all the tools to your board's vid/pid and everything should work seamlessly as it was meant to or you could use Cypress's tool to modify the vid/pid in the eeprom on your board.

      Delete
  35. have noticed on the above 'RsCont' screenshot one more interesting command 'F2: 400C00' (i.e. -c 0x40 -w 000C).
    Viktor, have you played with it or may be have any idia on it?

    Me checked on one sample of bq8030dbt, that this command [0x40] has same attributes as 'privilege escalation' command [0x71], i.e. it's 'word writable ONLY command'. Nothing can be read from both as error is returned.

    So supposed it may be another access level related command. Probably to work with online parameters modifying (in firmware mode, like [0x77],[0x78] commands are used for SubClasses reading or editing in bq20z90).

    as well noticed that BootROM entry subcommand on same screenshot is different from actually used for bq8030, (-c 0x70 -w 0502) vs (-c 0x70 -w 0517), do you brute forced it to get into BootROM too?

    ReplyDelete
    Replies
    1. I haven't really looked into them since the 0x71 lead got me to the bootrom which was all I wanted so I didn't go back for a second look.

      0517 came from the firmware disassembly and it's the one that leads to the bootrom entry call. 0502 it also checked but it does something different. Not really sure what but it might be a full erase or some sort of reset or it might put the chip into the proprietary calibration(?)/recovery mode that I posted a pastebin link for further up.

      Delete
  36. Viktor, so at what address did you find the permanent flag in your battery? I've soldered LED on fuse heater pins, and it always lights up, despite the fact that the charging current and voltage have good values.

    ReplyDelete
    Replies
    1. Sorry, no clue since it's been a couple of years now but it varies greatly which is why I didn't include it in the post. You'll find it if you keep trying.

      Delete
    2. You have to do something with cells, making them to have the same voltage, better to replace with a new ones

      Delete
    3. The difference between cells was 11 mV. I've tried to put three equal value resistors as voltage divider, making the difference no more than 2 mV. No success, heater pin is always powered, laptop does not charge the battery.
      Everytime I enter BootROM Remaining Capacity (as well as other related values) drops to zero. Is it normal? I'm thinking this could be a reason because zero is always less than Remaining Capacity Alarm (562 mAh).
      Now I can confirm than zeroing [0x540-0x542] and [0x640-0x642] values sets Charging Current to 3600 mA (otherwise 300 mA).

      Delete
  37. I managed to repair 85Wh battery. Addresses 0x640,0x641,0x642 must be all "00"
    My battery was "01 00 00".
    Making 0x641 to FF as suggested by Mateusz was making battery current reporting non zero but it does not work with laptop. All zeroes works.
    Controlled fuse is blown. Ordered from aliexpress. Meanwhile it is jumper. I do not know if it is neccessary but I soldered about 30 Ohm resistor to controlled fuse blow heater terminals when I investigated this battery.

    ReplyDelete
  38. Hi. I have managed to copy flash and eeprom from ba8030, but somohow i cannot longer access the chip. By sending smbusb_sbsreport i get some rubish inforamtion (Manufacturer Name: ERROR etc.). smbusb_scan.exe -w 0x16 only gets me 35, 37, 39 ACK, and by sending „smbusb_comm -a 16 -c 71 -w 0214“ i get Error -9. I have tried manipulating the reset pin (pin 24 to gnd) and NC pin 28 (with 10k resistor to 3.3v) to get in to BootRom but it had not worked. Is it somehow possible to reflash the chip?

    ReplyDelete
  39. Hello! I have a live board with this chip in an old Lenovo battery pack. I am also the guy which posted the following comment in Hacking the R2J240 with LGC firmware:
    http://www.karosium.com/2016/08/hacking-r2j240-lgc.html?showComment=1540069292836#c4522228090994528052
    Suffice to say I do not have means of reprogramming these chips, and after blowing up another aftermarket battery pack board with a SH79F329AX controller trying to make a live board transplant, I'd first like to know if this BQ8030 board would be happy if I power it down (from V− to V+), move it and then reconnect again (from V+ to V−).
    Thanks a lot and best regards.

    ReplyDelete
  40. Yes, bq8030 could be happy with power down because it's EEPROM-based chip, provided you will follow correct disconnecting procedure. The one you mentioned is wrong and could lead to PF condition.
    Correct sequence is opposite,
    Power down: from V+ to V-(GND);
    Power up: from V-(GND) to V+;

    p.s.
    regarding your post about r2j240 it's possible to clear PF if you have fx2lp board and tools created by Viktor.

    ReplyDelete
    Replies
    1. Following advice from the Battery EEPROM Works guy ( http://be2works.com/forum/viewtopic.php?f=3&t=369#p2876 ) proceeded with V− to V+ BQ8030 board power down, and powered it back up from V+ to V−. Worked.
      Makes me think once the board is disconnected from either V− or V+ the remaining pins' sequence is inconsequential, as what powers the microcontroller is V+ and V−. What this means is:

      • Disconnect first from either V− or V+, then proceed with the remaining.
      • Reconnect all but either V− or V+, then proceed with the latter.

      I've come to this conclusion because if the microcontroller were to be powered from any of the battery segments it would cause some sort of unbalanced pack discharge.

      Delete
  41. Could someone share eeprom data together with the program flash from a working battery? I have no other ideas what can I do with my battery

    ReplyDelete
  42. I posted it yet https://www.karosium.com/2016/08/hacking-bq8030-with-sanyo-firmware.html?showComment=1513628538536#c4264743727778090460

    ReplyDelete
    Replies
    1. Thanks, I've found it, but I need program flash too, because mine is too restrictive. It always restores permanent flag after about half a minute

      Delete
    2. Did You replace a cells? Permanent flag restores because Your cells are old and disbalanced

      Delete
    3. Also look for voltages on cells during charging, may be they are vary a lot

      Delete
    4. Notification emails were put to spam, so I didn't notice your messages. No, I didn't replace the cells, because they are fine. Usual difference of voltage is less than 10 mV. I've tried to put resistor dividers to middle pins (resulting in 0-1 mV difference), nevertheless permanent flag is restored always, even without charging (actually I can charge the battery bypassing the MOSFETs only).

      Delete
  43. 0K fellows, I now have a nicely balanced recelled pack with a BQ8030 controller who allows the pack to work BUT has some inherited quirks in its EEPROM which prevent correct operation. The list of offenders is short but if I am to reprogram the controller, I guess I could do it fully:

    • Full load capacity (energy): 2.81Wh (!) Just this parameter makes the pack unusable. Will raise it to 0xFFFF/0x7FFF or whatever LoL.
    • Number of cycles, manufacturer, date, first use, design capacity and design voltage could/should also be changed.

    I am missing full battery maximum voltage parameter, unless it is inferred from “design voltage”, that is. This is because the pack is recelled with 4.35Vmax cells, although I do not really mind this thing. Loading the cells only up to 4.2V renders life cycle benefits for just a small capacity/energy penalty.

    So, what do I need to start? I guess the FX2LP dev board ( http://www.karosium.com/p/smbusb.html ), and once I have it I'll just need to connect it to the battery pack bus pins SFT, SDA and SCL, is this right? And then execute some software on a PC with the FX2LP dev board USB connected to it, am I following?
    Thanks.

    ReplyDelete
  44. reprogramm a controller is a great work, whitch is not any people can do. First thing that nobody know all the passwords or algo's of BQ8030 protection. A small chance that You pull off into default password.
    Another chance is to accurately try to repack a battery insensibly to a controller, then calibrate a battery (take full charge-discharge cycles with no turn-off while computer consider that it has a low percent of capacity)

    ReplyDelete
  45. The main steps to 'reset' bq8030 controller after recelling are to clear PF-lock (if any) and to restore FCC.
    Cycle count, Manufacture Date, First usage date in no respect concern gauging algorithms. So these parameters basically used for information and for warranty cases.
    Design voltage and Design Capacity are located in checksum protected Static Area. Changing them without recalculation checksum could make the gauge not working.
    The best practice to avoid changing Static Area is to recell with same-same cells. Of course some of them not produced already. In such case it's required to find best matched equivalent by chemistry, min, max Voltages, Capacity etc.

    ReplyDelete
    Replies
    1. The issue here, as I said above, is the pack received a BMS transplant.
      Restore FCC? Restore the Federal Communications Commision? LoL!
      I guess you mean Full Charge Capacity, isn't it? No problem. Since it is an energy value I'll attain a compensated figure considering the slightly higher voltage of the newer cells and the corresponding lesser capacity when charged up to just 4.2V. This is no problem I am quite experienced with this stuff. Of course the value will be higher than that of “design capacity”.
      It'll take a few weeks for me to get the FX2LP board, anything worth telling me in advance? Thanks.

      Delete
  46. FCC stands for Full Charged Capacity if related to battery area what we all talking about here.
    The one more issue with 4.3V->4.2V replacement besides one you mentioned is some underdischarging below permitted low voltage threshold. For 4.2V cells it's normally 3.0V for 'Terminate Discharge Alarm' and 2.8V for 'Cell UnderVoltage Alarm/Condition'. These values stored in Static Area of eeprom and not easy to change. 4.3V cells usually have slightly higher those values and you can refer to datasheet of your specific cells for correct data.

    ReplyDelete
  47. FCC confirmation, thanks.
    The other thing you say is a no issue. As far as my wisdom and expertise goes discharge cut-off voltages are usually selected as the highest voltage value which allows the cell to deliver most of its capacity at its highest specified discharge rate. On top of this I have the Samsung 30B datasheet and it specifies 2.75V, whereas I've never seen laptops, tablets or smartphones allowing their cells to go below 3.1V. Most other cells' cut-off values go down to 2.5V, and some down to 2V. My other name is “The Battery Whisperer”, by the way LoL.
    Once the FX2LP board is in my I'll come back to see how to rewrite the Full Charge Capacity. Damned software they set inside those chips for the love of God, that of course is to milk the cows. Muthafuckas LoL… :-D

    ReplyDelete
  48. Let's suppose why you have never seen cells going below 3.1V.

    The one reason is that laptops, tablets and smartphones normally running OS which has its own energy saving settings which will switch off (hibernate) devices at predefined early power levels thus preventing full discharge of the cells. For laptops batteries this is main reason of losing gauging accuracy and raising up RELEARN FLAG in BatteryMode() that means recalibration at QUALIFIED DISCHARGE required. Just run laptop in BIOS only (where no any power saving modes) or on external equivalent load, say 12V 1.5A car bulb and continiously measure cell voltages (under load) and you will notice real level at which battery controller permits discharging.
    Another reason is you probably take measurements when load is disconnected and due to fast voltage build up the measurements are always higher.
    For example 3S2P laptop battery pack discharged to 3.0V/cell under load 1.5A after disconnecting the load will show 3.2V/cell in few seconds and voltage will exponentially raising to about 3.5V/cell during next 3...5 hours. The more load and cell's impedance the more voltage build up.
    The best practice to see what really going on at the pack/cells is to use SMBUS logger/analyzer during charging/discharging/relaxation. You will notice then much interesting information about your battery especially if collected data put to the plotting application.

    ReplyDelete
  49. My FX2LP board will likely be home soon (shipped with tracking). I have never messed with this sort of microcontroller stuff in my life, but I know what hexadecimal editing is and even did some x86 and MIPS assembler programming back in the MS-DOS days.

    Will come back and read this fully later but I already have a few questions:
    • When Viktor says “to map values” I guess this means to identify which addresses store whatever values, ¿🤔? Yes, long time without messing with this stuff and non-native speaker. Just in case.
    • What is “SBS”? Looks like some sort of shell command but that is as far as I know in this regard.
    Any worthwhile tutorial for me out there?

    ReplyDelete
  50. Yes, mapping is constructing a chart of BatteryParameter->EppromOffset relationship. For single repair you should focus on dynamic area and just locate a few parameters like FCC and PF-flag. Optionally you can map CycleCount and ManufactureDate. You can check the similar posts from users above.

    SBS is a Smart Battery Specification.
    The docs to start diving are SBS and SMBus pdfs,

    http://sbs-forum.org/specs/sbdat110.pdf
    http://smbus.org/specs/smbus110.pdf

    and very nice tutorial from Texas Instruments covering practical aspects

    www.ti.com/lit/an/slua475/slua475.pdf

    ReplyDelete
  51. Mmmkay, downloaded SMBusb binaries and installed Zadig USB driver both on an old and tweaked XP machine (with Zadig 2.2) and on a Windows 7 one. On first execution "libusb-1.0.dll" missing. After downloading libusb-1.0.dll and setting it inside the tool's folder, on second execution "libusb_set_auto_detach_kernel_driver function entry point not found in libusb-1.0.dll dynamic link library" or something of that sort (sorry, my Windows versions are spanish so that is my translation). Any hints besides trying to do this in some Linux machine? :-/

    ReplyDelete
  52. Me only working on Windows 7 64 bit.. try https://yadi.sk/d/ppA4HxT-Z003_w

    ReplyDelete
  53. Thanks for that Denis Serik, the commands work. However, now I am getting an "libusb error -1", something referenced in these places:
    http://www.karosium.com/2016/08/smbusb-hacking-smart-batteries.html?showComment=1505192669962#c7709621990549116873
    https://github.com/karosium/smbusb/issues/3
    Gosh! So I need to figure out a way to upload some sort of firmware (where is it?) some way.
    At this point I don't know what to think in this regard, LoL unLoL. I think if I can at least stablish connection with the BQ8030 hope there still is but, I still do not even know if this BQ8030 will be accessible. And my knowledge of these commands is still, let's say primitive. Example:
    smbusb_comm -a 16 -c 73 -r 2 -> This is used above by Victor
    That means: do something (command=73, -c 73) at hex address 16 for a lenght of 2 bytes (-r 2, word).
    By the way, I remember having seen some sort of detailed SMBusb command description and usage somewhere in GitHub but now all I can say is, where is it?

    ReplyDelete
    Replies
    1. dear friend, don't panic! I notified You that it is a complicated creative process.
      "libusb error -1" is a FX2LP board connection error, You must check a driver/port settings. When You first set a command, some seconds must go to download software inot a boart, then You will hear a board disconnect and then connect again.

      Delete
  54. You should check which VID&PID your FX2LP has. You can look for it in Device Manager.

    ReplyDelete
  55. VID 0925, PID 3881. Onboard AT24C128 EEPROM. Looks normal I'd say.
    Can I play the piñata with this stuff yet? x-D

    ReplyDelete
    Replies
    1. I've compiled a version for you (assuming VID and PID was is hex): https://drive.google.com/open?id=190yoZAvG7ikVD7M_MkXaHs5-aIaI4SSe

      Delete
  56. Thanks a lot Mykolas. I executed the smbusb_sbsreport command in those tools folder and something happened (I guess there was some firmware upload to the FX2LP board). After it the device started being recognized as something different with VID 04B4 and PID 8613, and Windows complained of no driver found for it. So, launched Zadig and installed WinUSB driver for this new "SMBusb Interface" device and, after this came back to the tools which Denis Serik provided me up there Dec 22 and ran smbusb_sbsreport (guess I had it all well wired):
    https://imgflip.com/i/2pqkpv

    Enough for now. Guess I will have to download the BQ8030 EEPROM with the smbusb_bq8030flasher command after doing the above password tinkering (?) consisting in 4 smbusb_comm commands. Is this right? As far as I understand I have to replicate the above procedure, doing the "2. Read Word X from 0x73" and "3. Send (0x10000 - X) to 0x71" with my own values. Any help appreciated here in this regard. O:-)

    Merry Christmas ;-)

    ReplyDelete
    Replies
    1. I don't think any of these tools uploads firmware. You should hear the sounds of finding new hardware after disconnecting, reconnecting USB cable, and running any tool.
      If smbusb_report works, the wiring should be OK.
      You're right, you need to enter the BootROM mode with smbusb_comm, read or write the flash with smbusb_bq8030flasher, then exit the BootROM with ..flasher --execute. On my battery the sequence of commands looks like these (the password never changes for the same battery):
      smbusb_comm -a 16 -c 71 -w 0214
      smbusb_comm -a 16 -c 73 -r 2
      smbusb_comm -a 16 -c 71 -w fda0
      smbusb_comm -a 16 -c 70 -w 0517
      smbusb_bq8030flasher -w eeprom.bin --confirm-delete
      smbusb_bq8030flasher --execute

      Merry Christmas :)

      Delete
  57. FX2LP firmware uploader located in libsmbusb.dll and uploads binaries directly to the RAM of devboard CPU (and not to 128k eeprom) once any smbusb tools started. It provides a sounds of fx2lp board reconnecting and only once for the session, any next tool not give sounds as firmware already uploaded.
    So Barcuti is right.

    As to the report from the battery, FCC is too low, but PF-flag probably not present, as battery requests charge by setting values to Charging Voltage and Charging Current sbs commands.
    To dump eeprom for editing, you should use -e switch for flasher tool.

    And Merry Christmas!;)

    ReplyDelete
    Replies
    1. Thanks for the explanation орион орионВи.
      Will soon dump that EEPROM and also the program flash (guess I should also do a "smbusb_bq8030flasher --execute" after 😅 that). I guess the code should give hints as to where it is storing certain variables. Full Charge Capacity and Remaining Capacity seem to me the only figures this pack needs changed to work normally. The Remaining Capacity should be set at 0x0064, hope it is arond the former FCC as looks it is 0x0000 right now.
      See all of you later LoL! :-D

      Delete
  58. You should not care about Remaining Capacity at all. This variable is living in the RAM not eeprom and calculated by bq8030 during firmware running.
    Just edit FCC (optionally CCnt and MnfDate too), reflash and carry out one charge discharge cycle (pref in BIOS) to make GGauge to relearn (update) new parameters.

    ReplyDelete
  59. Weelp, couldn't wait LoL. "smbusb_bq8030flasher" returned -9:
    https://imgflip.com/i/2prmal

    Cheers

    ReplyDelete
  60. Try first to read only eeprom, don't use -p switch for the first time.
    On TI gauges Programm blocks are returned in 96bytes strings which violates SMBUS/i2c specification, so sometimes fx2lp's i2c hw engine is little bit surprised with such portions of juice. Eeprom blocks instead are read in 32 bytes long blocks which is Ok.
    Sometimes I've encountered similar errors during reading, just resend request and next read is Ok.

    ReplyDelete
    Replies
    1. Hello!
      Got another -9 after just doing "smbusb_bq8030flasher -e eeprom.bin", by the way. ¯\(°_o)/¯

      Delete
  61. then do the following, go to boot rom, if you did't left out before,
    and issue these command sequence

    >\smbusb_comm.exe -a 16 -c 0d -r 2
    >\smbusb_comm.exe -a 16 -c 01 -r 3
    >\smbusb_comm.exe -a 16 -c 02 -r 3
    >\smbusb_comm.exe -a 16 -c 03 -r 3
    >\smbusb_comm.exe -a 16 -c 0c -r 3
    >\smbusb_comm.exe -a 16 -c 0e -r 2

    then make screenshot what you get, or just copy paste your shell window...


    ReplyDelete
  62. This is what I got, орион орионВи:

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 0d -r 2
    0302
    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 01 -r 3
    3fffffffb433
    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 02 -r 3
    Error -9
    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 03 -r 3
    Error -9
    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 0c -r 3
    Error -9
    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 0e -r 2
    Error -9

    Cheers (✿´‿`)

    ReplyDelete
  63. Definitely something wrong with your tools. While WORDwise transactions are Ok, BLOCKwise are not.

    From your sbs report Manufacture Data [0x23] gives abnormal output 'fffffff7', it's not that what Sanyo firmware based chips for Lenovo batteries should return.
    Next your bootROM sequence revealed the similar issue.
    Step 1 which is WORD read passed Ok.
    But Step 2 which is BLOCK read should return just 3 bytes, not 6 like in your case. Me can suppose correct answer from Step 2 should be '3fb433' and not '3fffffffb433', so there is odd 3 bytes present in the report.
    It's most probably you are using outdated version of SMBUSB tools. To confirm this, try debugging with verbose output.
    Do following steps

    In bootROM
    1. >\smbusb_comm.exe -a 16 -c 0d -r 2
    2. >\smbusb_comm.exe -a 16 -c 01 -r 3 -v
    3. >\smbusb_comm.exe -a 16 -c 01 -r 3 -v // repeat step 2
    4. >\smbusb_comm.exe -a 16 -c 02 -r 3 -v
    5. >\smbusb_comm.exe -a 16 -c 0d -r 2 -v // repeat step 1
    6. >\smbusb_scan.exe -w 16 -e 05

    7. >\smbusb_bq8030flasher.exe --execute // Exit from Boot mode
    8. >\smbusb_comm.exe -a 16 -c 20 -r 3 -v
    9. >\smbusb_comm.exe -a 16 -c 21 -r 3 -v
    10. >\smbusb_comm.exe -a 16 -c 22 -r 3 -v
    11. >\smbusb_comm.exe -a 16 -c 23 -r 3 -v

    And show what you get.





    ReplyDelete
  64. Mmmkay, here I go:

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 0d -r 2
    0302

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 01 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 3 bytes
    ffffffffffffffa30e

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 01 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 3 bytes
    ffffffefffffffff33

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 02 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    Error -9

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 0d -r 2 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK
    0302

    C:\Users\BART\Downloads\karosium>smbusb_scan.exe -w 16 -e 05
    ------------------------------------
    smbusb_scan
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    Scanning for command writability..
    Scan range: 00 - 05
    Skipping: None
    ------------------------------------
    [0] ACK, Byte writable, Word writable, Block writable
    [1] ACK
    [2] ACK
    [3] ACK
    [4] ACK, Byte writable, Word writable, Block writable
    [5] ACK, Byte writable, Word writable, Block writable

    C:\Users\BART\Downloads\karosium>smbusb_bq8030flasher.exe --execute
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    TI Boot ROM version 3.2
    ------------------------------------
    Exiting Boot ROM and starting program flash! Good luck!

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 20 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 8 bytes
    53414e594f003131

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 21 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 11 bytes
    4c4e562d34325434373531

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 22 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 4 bytes
    4c494f4e

    C:\Users\BART\Downloads\karosium>smbusb_comm.exe -a 16 -c 23 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 14 bytes
    5600ffffffb7030000610e650e620e0607


    I was yesterday going to comment in that (-r 3) regard, but decided to avoid bloat. (^̮^)

    ReplyDelete
  65. As you can see number of bytes reported for certain block reads not correspond with what is printed and there is odd 'ffffff' in that cases.
    So you should download the latest sources from github project page, then patch them for your specific VID&PID, and compile according to instruction.

    How to patch.
    Replace all instances of string 'SMBOpenDeviceVIDPID(0x04b4,0x8613)' with 'SMBOpenDeviceVIDPID(0x0925,0x3881)' in the tools/*.c with any advanced text editor or even by hand;)...

    After all it should rectify one issue, but you have two. The other one is that flash content block reading is rejected at all.
    The reason is unclear for the moment. But with your tools updated we could investigate deeper.

    ReplyDelete
  66. Thanks орион орионВи. Tad green in these matters, I'll see what can I do.
    Will ask for some gcc for Windows compiler recommendation to a friend first but, if there's something you may find worthwhile to advise please do so.
    Guess after replacing the VID and PID in the code my board will straight work without need to first execute what Mykolas uploaded for me on Dec 24.
    We'll soon see.

    For now, Happy New Year everyone in advance. (-:

    ReplyDelete
    Replies
    1. What VID and PID do fx2lp report now after plugging it? As far as I remember, I have compiled tools with different VID and PID, now they always stay 0x04B4 and 0x8613. If your case is the same, try the tools I'm using (the source was downloaded on 6th May). I see there are minor changes since then, but it's more about status. I'm using tdm-gcc compiler.
      https://drive.google.com/open?id=1tAWmLaqDBA8tDWARpNfITWrxN2jM3FtW

      Delete
    2. Board is reported as 0x0925 & 0x3881 on cold start Mykolas (after booting Windows).
      Upon executing the “smbusb_sbsreport.exe” you uploaded Dec 24th here:
      https://drive.google.com/open?id=190yoZAvG7ikVD7M_MkXaHs5-aIaI4SSe
      … an device unplug/replug sound is played, the FX2LP starts being recognized as 0x04B4 & 0x8613 and there's a driver swap (!).
      At this point what starts working is what Denis Serik submitted up there on Dec 22th when he said “Me only working on Windows 7 64 bit.. try https://yadi.sk/d/ppA4HxT-Z003_w”, and these are the tools I've used above for my submitted tinkering.

      Delete
    3. I've tried the tools compiled by Denis, I'm having similar problems as you (except that the block read works). Try the tools compiled by me.

      Delete
  67. Mykola, your tools is compiled for only VID&PID 0x0925/0x3881, so they work until driver swap. After that moment it should be used another (original) tools, which Barkuti has, but they compiled from outdated sources.

    ReplyDelete
    Replies
    1. The first link was for the tools with 0x0925/0x3881 (I've compiled specifically for Barkuti). The second link was for the tools I'm using normally, mine fx2lp is 0x04B4/0x8613 (at least currently)

      Delete
  68. Tried with "tools_8613" uploaded by Mykolas. Block transfers work right, did the above checks, but I still get a -9 after executing "smbusb_bq8030flasher -e whatever.bin". Tried many times, with and without paquet error checking just for the sake of it:

    C:\Users\BART\Downloads\tools_8613>smbusb_bq8030flasher -e eep.bin
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    TI Boot ROM version 3.2
    ------------------------------------
    Reading eeprom(data) flash
    Error:-9

    C:\Users\BART\Downloads\tools_8613>smbusb_bq8030flasher -e eep.bin --no-pec
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is DISABLED
    TI Boot ROM version 3.2
    ------------------------------------
    Reading eeprom(data) flash
    Error:127

    C:\Users\BART\Downloads\tools_8613>sanyo -e eep.bin
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.0
    PEC is ENABLED
    ------------------------------------
    Reading eeprom(data) flash
    Error:-9

    C:\Users\BART\Downloads\tools_8613>sanyo -e eep.bin --no_pec
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.0
    PEC is DISABLED
    ------------------------------------
    Reading eeprom(data) flash
    Error:-9

    Error 0x7F up there on 1.0.1 without PEC LoL.
    Hope this is not being too burdensome for you at this point, sorry.

    ReplyDelete
  69. As per above individual block transfer checks, are all they Ok?
    What you got on '-c 02 -r 3' and 'c 0c -r 3' block reads while in boot?

    ReplyDelete
  70. Let me say, could it be some sort of driver problem or whatever? Before driver change my VID 0x0925 & PID 0x3881 FX2LP device is listed as "Unknown Device #1" in Universal Serial Bus devices>. After executing Mykolas' compiled smbusb_sbsreport.exe, FX2LP board is recognized as "SMBusb Interface" with VID 0x04B4 & PID 0x8613.
    Wellp, here's the above орион орионВи submitted 11-step diagnosis report with the newer tools in tools_8613 folder from Mykolas:

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 0d -r 2
    0302

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 01 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 3 bytes
    3fb433

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 01 -r 3 -v
    *** SAME AS ABOVE ***
    OK. Read 3 bytes
    3db433

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 02 -r 3 -v
    *** SAME AS ABOVE ***
    Error -9

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 0d -r 2 -v
    *** SAME AS ABOVE ***
    OK
    0302

    C:\Users\BART\Downloads\tools_8613>smbusb_scan.exe -w 16 -e 05
    ------------------------------------
    smbusb_scan
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    Scanning for command writability..
    Scan range: 00 - 05
    Skipping: None
    ------------------------------------
    [0] ACK, Byte writable, Word writable, Block writable
    [1] ACK
    [2] ACK
    [3] ACK
    [4] ACK, Byte writable, Word writable, Block writable
    [5] ACK, Byte writable, Word writable, Block writable

    C:\Users\BART\Downloads\tools_8613>smbusb_bq8030flasher.exe --execute
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    TI Boot ROM version 3.2
    ------------------------------------
    Exiting Boot ROM and starting program flash! Good luck!

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 20 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    OK. Read 8 bytes
    53414e594f003131

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 21 -r 3 -v
    *** SAME AS ABOVE ***
    OK. Read 11 bytes
    4c4e562d34325434373531

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 22 -r 3 -v
    *** SAME AS ABOVE ***
    OK. Read 4 bytes
    4c494f4e

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 23 -r 3 -v
    *** SAME AS ABOVE ***
    OK. Read 14 bytes
    5600b7030000620e650e620e0607


    Am I seeing two consecutive reads from same address with different output? That doesn't seems very right, does it?

    Cheers and have a lot of fun tonight everyone

    ReplyDelete
  71. You can unsolder pin8 of fx2lp external eeprom IC to check where your VID & PID come from. If they will change to 0x04b4/0x8613 just upon plug-in before running any tools then your 0x0925/0x3881 preset at factory in the external eeprom. You then can backup and erase its content or just leave unpowered.
    Regarding consecutive reads from 0x01. It's Ok due to autoincrement of IF segment adress index.

    Reprogramming of your bq8030 from bootROM currently not possible.
    Block read of EEPROM content is refused. To Know what is the reason you should debug at low level with logic analyzer.

    By the way you can try to fix FCC through NORMAL mode, try following steps
    1. Exit from boot to normal running mode.
    2. Get full access with both passwords but not go to boot mode.
    3. >\smbusb_scan.exe -w 16 -b 40 -e 50
    4. >\smbusb_comm.exe -a 16 -c 45 -r 3
    5. >\smbusb_comm.exe -a 16 -c 40 -w 0000
    6. repeat step 4

    Show output of steps 3,4,5,6.

    ReplyDelete
  72. guys, my battery is a dell WR050, i managed to find the three pins for SMBus communication, though i've no guarantee. I get errors with smbusb_comm and smbusb_bq8030flasher. Below is a copy paste of some smbusb_scan, smbusb_comm, and smbusb_bq8030flasher commands.

    # 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
    [42] ACK
    [43] ACK
    [50] ACK
    [51] ACK
    [52] ACK
    [53] ACK
    [54] ACK
    [71] ACK, Byte writable, Word writable
    [72] ACK

    # smbusb_comm -a 16 -c 45 -r 3 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    Error -9

    # smbusb_bq8030flasher -e wr050.fw
    ------------------------------------
    smbusb_bq8030flasher
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    Error communicating with the Boot ROM.
    Chip is not in the correct mode, has hung or there's an interface issue

    ReplyDelete
  73. This is what I've done, орион орионВи:

    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 71 -w 0214
    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 73 -r 2
    04dc
    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 71 -w fb24
    C:\Users\BART\Downloads\tools_8613>smbusb_scan -w 16 -b 40 -e 50
    ------------------------------------
    smbusb_scan
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    Scanning for command writability..
    Scan range: 40 - 50
    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
    [50] ACK
    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 45 -r 3
    Error -9 -> Ouch! (>ლ)
    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 40 -w 0000
    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 45 -r 3
    Error -9 -> To be expected, doesn't it?

    (¬_¬)

    ReplyDelete
  74. I swear I sent this a few days ago, but got lost somehow (maybe it was not approved?).
    Here it goes full version:

    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 71 -w 0214

    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 73 -r 2
    04dc

    C:\Users\BART\Downloads\tools_8613>smbusb_comm -a 16 -c 71 -w fb24

    C:\Users\BART\Downloads\tools_8613>smbusb_scan.exe -w 16 -b 40 -e 50
    ------------------------------------
    smbusb_scan
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    Scanning for command writability..
    Scan range: 40 - 50
    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
    [50] ACK

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 45 -r 3
    Error -9

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 40 -w 0000

    C:\Users\BART\Downloads\tools_8613>smbusb_comm.exe -a 16 -c 45 -r 3
    Error -9


    🙄🤔😵

    ReplyDelete
  75. Ok, now better but still not that what I expect to see ;)
    try following in Full Access mode, you can bypass step 3

    4. >\smbusb_comm.exe -a 16 -c 43 -r 3
    5. >\smbusb_comm.exe -a 16 -c 40 -w 4600
    6. repeat step 4

    show only steps 4,5,6

    ReplyDelete
  76. Well, see what I am getting right now:

    C:\Users\BART\Downloads\tools_8613>smbusb_sbsreport
    SMBusb Firmware Version: 1.0.1
    -------------------------------------------------
    Manufacturer Name: ERROR
    Device Name: ERROR
    Device Chemistry: ERROR
    Serial Number: 4294967287
    Manufacture Date: 8390587.15.23

    Manufacturer Access: fffffff7
    Remaining Capacity Alarm: 4294967287 mAh(/10mWh)
    Remaining Time Alarm: 4294967287 min
    Battery Mode: fffffff7
    At Rate: -9 mAh(/10mWh)
    At Rate Time To Full: 4294967287 min
    At Rate Time To Empty: 4294967287 min
    At Rate OK: 4294967287
    Temperature: -274.05 degC
    Voltage: 4294967287 mV
    Current: -9 mA
    Average Current: -9 mA
    Max Error: 4294967287 %
    Relative State Of Charge 4294967287 %
    Absolute State Of Charge 4294967287 %
    Remaining Capacity: 4294967287 mAh(/10mWh)
    Full Charge Capacity: 4294967287 mAh(/10mWh)
    Run Time To Empty: 4294967287 min
    Average Time To Empty: 4294967287 min
    Average Time To Full: 4294967287 min
    Charging Current: 4294967287 mA
    Charging Voltage: 4294967287 mV
    Cycle Count: 4294967287
    Cell 0 voltage: 0 mV
    Cell 1 voltage: 0 mV
    Cell 2 voltage: 0 mV
    Cell 3 voltage: 0 mV

    smbusb_comm.exe commands return a -9 now.
    This thing was working the last time I tried, maybe I did something stupid but right now don't really now LoL.
    On the other hand, FX2LP board had a jumper close to the EEPROM IC which after removal caused it to be recognized as a 0x04B4/0x8613 VID/PID device.
    I've also lost motivation to continue with this so, unless you want to try something else, I'll end up dismantling the battery.
    Thanks a lot anyway.

    ReplyDelete
  77. try reconnect usb-cable to fx2lp board, and look in device manager if board is recognised

    ReplyDelete
  78. I have news! Among my tinkering I replaced the board driver to "libusbK", this makes the board to be listed under "libusbK USB Devices" in device manager. Replugged the wires to the battery connector, replugged the board... it works again.
    Here it goes the last 4, 5 and 6 steps' result:

    C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 43 -r 3
    0300000000026e026e03000018db6600024d93010d1d2d021401190080000000

    C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 40 -w 4600

    C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 43 -r 3
    0214011900800000004e08fea50002ff3e820e0510123e00989f406900040001

    Cheers орион орионВи

    ReplyDelete
  79. By the way, in that last block read I see both number of cycles and full charge capacity: 532 cycles (0214) and 2.81Wh (0119).
    Big endian architecture?

    ReplyDelete
  80. Very well!
    Now you can proceed with programming.
    In Full Access Mode do following:

    4. >\smbusb_comm.exe -a 16 -c 40 -w 4600
    5. >\smbusb_comm.exe -a 16 -c 44 -w 00000FA00080 -v
    6. >\smbusb_comm.exe -a 16 -c 70 -w 0502
    7. wait a little
    8. >\smbusb_comm.exe -a 16 -c 10 -r 2

    show step 8 only,
    Then you can try to insert battery in laptop and check how it works.
    Also tell condition of your present Lion cells, are they new or weared?
    May be some correction to FCC should be done.

    ReplyDelete
  81. Very well!
    Now you can proceed with programming.
    In Full Access Mode do following steps

    1. >\smbusb_comm.exe -a 16 -c 40 -w 4600
    2. >\smbusb_comm.exe -a 16 -c 44 -w 00000fa00080 -v
    3. >\smbusb_comm.exe -a 16 -c 70 -w 0502
    4. wait a little
    5. >\smbusb_comm.exe -a 16 -c 10 -r 2

    show steps 2 and 5.

    Then you can insert battery in laptop and look how it works.
    In dependency of condition of your cells it may be necessary some correction to FCC.


    ReplyDelete
  82. Out of the above 16 word block reads I can discern 0x0214 (number of cycles: 532) and 0x0119 (remaining full charge capacity: 281/2.81Wh).
    Sent this more than half a day ago, what is happening with updates here?

    ReplyDelete
  83. C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 44 -w 000015ae0080 -v
    ------------------------------------
    smbusb_comm
    ------------------------------------
    SMBusb Firmware Version: 1.0.1
    PEC is ENABLED
    -----------------------------
    Block-Writing 6 bytes to addr 0x16 cmd 0x44

    C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 70 -w 0502

    C:\Users\BART\Downloads\tools>smbusb_comm.exe -a 16 -c 10 -r 2
    15ae

    I inferred you aimed to write 4000 (40Wh) in the FCC field, thus I took the liberty to fix it with the proper 1/5C value for my cells when charged at 4.2V (≈5550 or 55.5Wh, source https://www.lygte-info.dk/).

    So far so good, battery is charging and reports the right values. I guess it needs a recalibration cycle now.
    Right now I can only say TONS OF THANKS!
    May come back ;-) later.

    ReplyDelete
  84. Out of curiosity I must say the laptop's battery manager software is already reporting "2 cycles" and 55.45Wh (5545 FCC) and it has not completed the calibration run yet. WTF?
    Also, seems most of the sites out there tell you to "fully charge, full discharge and then fully recharge" the battery for calibration. In my book, however, for calibration I only see need for "full charge then full discharge". After that I'll charge the battery to where I feel like, $%#@%@ @&#@+$$€$. LoL! O:)

    ReplyDelete
  85. It now reports ¯\(°_o)/¯ 62.53Wh FCC, the battery is charging. Before this it wouldn't bump the FCC value, this may have to do with the amount of cycles figure (?).

    ReplyDelete
  86. You can experiment with Cycles Counts but as from my experience they does not affect FCC at all (means at software level, cause actually they directly affect phisical capacity of the cells).
    To figure out the reason of such increased FCC value it's required battery analyser or at least precision ammeter and 1.5...2A load.
    But now the following could be the reason
    * if your cells are brand-new then they could have some more extra capacity especially if made by well-proved manufacturer
    * if they some hundred cycles served before then most probably Coloumb-counter of your bq8030 is not properly calibrated.

    By the way how long does your laptop work from battery now?
    Does it correctly go to hibernate at low power level?
    Is it FC-bit set in BatteryStatus (SBS [0x16]) at charge completed?


    ReplyDelete
  87. Thanks for the clarifying comments, орион орионВи.
    Cells are like new, bought long ago but barely cycled and always slept at maintenance voltage range (Samsung ICR18650-30B). I assembled the pack myself, having previously binned the cells to attain perfectly balanced 1+6, 2+5 and 3+4 pairs. Spare time and learning as you may guess.

    Laptop works many hours, more than 4 even with high screen brightness.
    FC bit not checked with tools but it should be working because battery calibration, done with Lenovo's Power Manager application, worked without complaints (which means the program detected Full Charge and Out Of Fuel conditions, either this or it couldn't have completed calibration at all or without a blackout).
    Hibernation? No idea, may check soon. 😄

    ReplyDelete
  88. according to specification, you cells are of

    3.1 Nominal Capacity 2950mAh (0.2C, 2.75V discharge)
    3.4 Nominal Voltage 3.78V
    3.3 Charging Voltage 4.35 ±0.05 V

    So pack's new design capacity/power is

    C = 2950*2 = 5900 mAh
    P = 5900*3.78*3 = 66906 mWh = 66.9 Wh

    Assuming that you installed high voltage cells instead of standard ones, which now require 4.35*3 = 13.05 V (!) of Charging Voltage (SBS [0x15]), which most probably is not that what your bq8030 requests from Smart Charger (you could recheck it's 12.6V), which in result will undercharge the cells, so relearned FCC of 62.53 Wh is quite feasable value.

    About hibernate, or sleep, I meant it should go to there at low power level without loss of any unsaved docs or currently running applications. Also remaining power level gauge in the Windows notification bar should be decreasing smouthly and without significant jumps, especially at the end of discharge. It's a sign that new cells more or less are liked by controller.

    ReplyDelete
  89. the same as the one in the photo at the top of this page, bq8030dbt. I didn't see that my post was passed and you replied earlier.

    ReplyDelete
  90. It's been long time that the computer has been warning that the battery should be replaced, now it disabled the battery and for some time, by pressing the battery level button on the pack i could see three leds blinking for a few seconds. But now even this feature is not working and smbusb_scan's output, with the same options as previously, is like the board was not connected to the battery. Is there any soft method to solve this problem or should i shunt the board by soldering a wire from the battery "+" end to the "+" pin of the pack for a full recharge once? I have read a web page where the author did it and could use his computer back on battery.

    ReplyDelete
  91. heavytull that battery pack you speak of at the very least needs cell diagnosis and nearly for sure cell replacement. If the controller raised the permanent failure flag and the battery was barely working prior to this be sure there are reasons behind. Bypassing the controller board to recharge the unbalanced pack blindly is asking for trouble, it is quite likely you'll overcharge some stage(s). Take care.

    ReplyDelete
  92. HELLO everybody what a nice hacking u guyz doin,have been reading this forum for past two years reading all day all nights,but got stuck all the time,then it wasnt well xplained and well elaborated like this,now my first problem is that where exactly the scl sda gnd would be solder to,to battery connector or on the chip bq8030 pins.secondly i have same problem like mr BAKUTI and his problem solved by Mr kolas by giving a site https://drive.google.com/open?id=190yoZAvG7ikVD7M_MkXaHs5-aIaI4SSe.but sorry cant download.can somebody please give a good site please.THANKS IN ADVANCE

    ReplyDelete
    Replies
    1. You should connect SDA and SCL to battery pins (probably connecting to chip pins should work also). You can find these pins by looking near the connector, they must be pulled up through zener diodes.
      Both links I've provided works for me

      Delete
  93. and this ttps://drive.google.com/file/d/190yoZAvG7ikVD7M_MkXaHs5-aIaI4SSe/view?usp=drive_open

    ReplyDelete
  94. MykolasDecember 30, 2018 at 12:13 AM

    What VID and PID do fx2lp report now after plugging it? As far as I remember, I have compiled tools with different VID and PID, now they always stay 0x04B4 and 0x8613. If your case is the same, try the tools I'm using (the source was downloaded on 6th May). I see there are minor changes since then, but it's more about status. I'm using tdm-gcc compiler.
    https://drive.google.com/open?id=1tAWmLaqDBA8tDWARpNfITWrxN2jM3FtW

    ReplyDelete
  95. thnx so much,i will do it and give feed back

    ReplyDelete
  96. I spent the whole day trying all the methods u guyz metioned but still smbus libusb error -1 appeared after 3senconds with this command smbusb_comm,despite that my computer recognised cypress as unknown devise 1,thanks in advance again Mykolas

    ReplyDelete
  97. deepasabbyss, look in device manager and make sure what is your device VID & PID on cold start, quite likely it will be 0925 & 3881 but the tools require the proper 04b4 & 8613 figures (all hexadecimal numbers). If your board has a jumper by the right side next to its AT24C128 EEPROM removing it will unpower the EEPROM and fix the VID & PID problem. You'll need to install a driver again for the new VID & PID. Check related messages above here, Dec 21st and up:
    https://www.karosium.com/2016/08/hacking-bq8030-with-sanyo-firmware.html?showComment=1545442986469#c1307946355280808540

    ReplyDelete
  98. actually i replaced the cells about 4 or 5 months before the controller raised the failure flag. I could use the laptop about 10 min. with the original cells, and it jumped to one hour with the new batteries, but the controller was raising the "low battery" state after about 10 min. of use. When the battery reached its real "low power" state, the laptop abruptly shut down. Normally the cells are very good. By bypassing the controller i was thinking to do that for only a one hour charge time to put back the cells in good condition and be able to communicate with the controller.

    ReplyDelete
  99. Your battery controller needs reprogramming heavytull, this is sure. Wait for the experts to chime in. There's a lot of information here already, take a good peek upwards if you haven't fully done so in the meantime.
    I would also open the pack to check out how the cells are doing, rebalance it if needed, etc.
    Take care. :-)

    ReplyDelete
  100. i opened the pack and i noticed that one of the three cell pairs had dropped slightly below 3 V while the two others are about 4 V. These cells were new, so it's something that i was not expecting. I will have to try recharging this pair externally.

    ReplyDelete
  101. Greetings,
    Does someone know how we can find the Emf(EDV0)value that is stored in the memory of bq8030? I think it should be somewhere in the first 1000 bytes of the EEPROM.

    Regards

    ReplyDelete
  102. On many 3.7V Li-Ion batteries EDV0 is 3000mV (0x0BB8), so hex search through the binary would point to that location. But you should consider that first EMF constants is inside static area and checksum protected, so simple editing the values could not init the gauge.

    ReplyDelete
  103. Reading this article I'm still kicking myself for disposing of 2 or 3 SANYO batteries for a ThinkPad T60 that could of been revived by your method.

    I think the only thing that I guess I can't seem to figure out is whether or not the batteries need to be disassembled or which pins to use on a battery. I'll probably reread the articles later.

    ReplyDelete
  104. Back to my battery pack as i was telling that three leds blink when checking the charging level and among the 3 pairs of cells inside, one is showing a voltage below 3 V. I recharged all the cells with an appropriate charger and they show about 4 V each of the 3 pairs. I'm surprised to see that once back with the circuit, when checking the level it's still 3 blinking leds. The difference is that now when out of the laptop the led level tester works. Previously it stopped working. I will later check with smbusb to see what i can learn furthermore.

    ReplyDelete
  105. Stage balancing in a battery pack is of utmost importance, heavytull. Prior to in series assembly charging all cells in parallel is an easy way to balance them. Post assembly, stages can be independently charged with a CC/CV power supply, for example.
    When time and tools are available a way to classify all the cells to be used in a battery pack is attained charging all of them in parallel to a given voltage, which does not need to be maximum, this attains perfect cell balancing. Next step is discharging all of them in series down to some cut-off voltage point where cells start showing off differences, taking note of their final voltages which classify them in the same order capacity wise.

    ReplyDelete
  106. Oh! Nothing is random heavytull, if one of the cell stages in your battery pack got out of balance it at least was for a reason. I advise you to track it.

    ReplyDelete
  107. I am looking for working eeprom dumps (data flash) for bq8030 with SANYO firmware. Did not remove the dump before replacing the cells. After replacing the cells, Windows does not see the battery, and only editing FullChargeCapacity and CycleCount does not solve the problem. I wanted to compare the bytes with the working eeprom. Who can share please throw on Iuriy758@gmail.com. Thank you in advance. I found at offset 0x000040F0 bytes responsible for the status of INIT: 03 1E FF FF 0F A0. If all bytes are FF, then the status of INIT is not set.

    ReplyDelete
  108. Denis has shared his firmware, look for the comment posted on December 22, 2018. Keep in mind that the dumps are different on different firmwares.

    ReplyDelete
  109. barkuti, don't really know what you're trying to say. I'm just trying to know whether the controller would reset the permanent failure flag if the batteries are back up and well.

    ReplyDelete
  110. I said what I said for you to make sure the cells in your battery pack are really in good condition, i.e. no abnormal self-discharge level, etc.
    If an in-series battery pack is correctly balance assembled the cell stages will barely drift apart until aging really sets in.
    No, unfortunately the controller won't reset the permanent failure flag. Reprogramming is due if you need that.

    ReplyDelete
    Replies
    1. Barkuti "the controller won't reset the permanent failure flag" was all i wanted to know. For the rest, you can read back my 8th march input, i described what i did and the final result about recharging the cells and their voltages.

      Delete
  111. guys, i was able to download the eeprom and firmware. I modified the eeprom little by little with reflashing the board with the modified version between changes. Would modifications of the the second half of the eeprom lead to risks of getting the chip hung? For my latest reflash, though everything seemed to have run normally, now it seems the board is not working at all. Laptop says no battery installed when inserted and the level leds don't work. smbusb_scan -w 0x16 dumps more than ten addresses with writable byte, while before only 2 like this were showing up. Only those registers without the "Byte writable..." mention are readable. For the others smbusb_comm reports "Error -9". smbusb_bq8030flasher --execute reports : "Error communicating with the Boot ROM.
    Chip is not in the correct mode, has hung or there's an interface issue". I forgot to mention that previously this command needed to be executed after a flash otherwise no charging level leds working, and laptop says "battery not installed".

    ReplyDelete
  112. Do you remember your last modification to eeprom?
    Which eeprom offsets did you revised?

    Generally if eeprom is broken bq8030 Sanyo firmware could detect it and goes to safe mode, provided firmware itself is intact. In safe mode it's still possible to recover the situation by rewriting the eeprom with correct data. But tool for recovery not included in SMBUSB repository. Viktor has written it for private use and shared via pastebin. You could look earlier conversations.
    But first its need to be sure your IC is really in safe mode.
    Show output of "smbusb_scan.exe -a", "smbusb_scan.exe -w 16".

    ReplyDelete
    Replies
    1. yeah i remember the modifications i made to the eeprom. In the file when edited in vim and xxd, i modified to FFFF all words in lines 0480, 0490, 0500, 0510, except the two last columns for the latter which were 0000 and left as that. Below is the output of the commands you asked:


      root@mycomp:~# smbusb_scan -a
      ------------------------------------
      smbusb_scan
      ------------------------------------
      SMBusb Firmware Version: 1.0.1
      Scanning for addresses..
      Scan range: 00 - ff
      Skipping: a0 a1
      ------------------------------------
      [16] ACK
      [17] ACK
      [a2] ACK
      [a3] ACK

      root@mycomp:~# 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
      [49] ACK, Byte writable, Word writable
      [4a] ACK
      [50] ACK, Byte writable, Word writable
      [51] ACK
      [52] ACK, Byte writable, Word writable
      [53] ACK
      [54] ACK, Byte writable, Word writable
      [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

      Delete
  113. You are likely man!) It's safe mode here.
    So there is a chance to recover.

    Did you saved the last working eeprom dump?
    Or at least subject 0480, 0490, 0500, 0510 rows...

    ReplyDelete
  114. additionally show output of following cmds:
    >\smbusb_comm -a 16 -c 48 -r 2
    >\smbusb_comm -a 16 -c 4a -r 3
    >\smbusb_comm -a 16 -c 72 -r 2

    ReplyDelete
    Replies
    1. yes i have a working eeprom. here is the output you're asking:
      root@mycomp:~# smbusb_comm -a 16 -c 48 -r 2
      ad48
      root@mycomp:~# smbusb_comm -a 16 -c 4a -r 3
      451008845659
      root@mycomp:~# smbusb_comm -a 16 -c 72 -r 2
      1111

      Delete
  115. print content of 0480, 0490, 0500, 0510 blocks from the very first dump,alternativly you can upload your dump to pastebin,

    also show an output of steps 2,4,6,8,10:
    1. >\smbusb_comm -a 16 -c 40 -w 4480
    2. >\smbusb_comm -a 16 -c 43 -r 3
    3. >\smbusb_comm -a 16 -c 40 -w 4500
    4. >\smbusb_comm -a 16 -c 43 -r 3
    5. >\smbusb_comm -a 16 -c 40 -w 4520
    6. >\smbusb_comm -a 16 -c 43 -r 3
    7. >\smbusb_comm -a 16 -c 40 -w 4540
    8. >\smbusb_comm -a 16 -c 43 -r 3
    9. >\smbusb_comm -a 16 -c 40 -w 4600
    10. >\smbusb_comm -a 16 -c 43 -r 3

    ReplyDelete
  116. then try following:
    11. >\smbusb_comm -a 16 -c 40 -w 4480
    12. >\smbusb_comm -a 16 -c 44 -w 100400107c10850e8e00002e380c072f -v
    13. >\smbusb_comm -a 16 -c 40 -w 4490
    14. >\smbusb_comm -a 16 -c 44 -w 8f0439014002000d0010100e0100ffff -v
    15. >\smbusb_comm -a 16 -c 40 -w 4500
    16. >\smbusb_comm -a 16 -c 44 -w 00c304b4005310040dfc0526a5000fff -v
    17. >\smbusb_comm -a 16 -c 40 -w 4510
    18. >\smbusb_comm -a 16 -c 44 -w ffffffffffff040bffff4e6400000000 -v

    if steps 11-18 will pass without errors, then repeat steps 1-10 and show 2,4,6,8,10 again.

    ReplyDelete
    Replies
    1. no error for steps 11-18. here is the output of steps 2, 4, 6, 8, 10 done afterwards: http://vpaste.net/lYlqk

      Delete
  117. actually for the output you want, shouldn't i use -w 4480, 4490, 4500, 4510 instead? i.e. the same addresses to which write command was sent in steps 11-18? if yes, here is the corresponding output for the 4 read commands: http://vpaste.net/8qJF4

    ReplyDelete
  118. Actually [0x43] register returns 32bytes block in length, i.e. it's covered both 0x4480,0x4490 16-bytes block.
    But what I see there were no changes to eeprom and I really did not explore safe mode very well on my sample. Just remember it was possibility to jump into BootRom from there but in your case [0x71] and [0x70] registers not accessible for the moment.
    Try reconnect power to bq8030 PCB. For that you should correctly disconnect cells from it (from top of cells stack to the ground), then reconnect in reverse order.
    Also you can temporary use resistors stack instead of cells (3x470 Ohms), and apply power 9...12VDC to the top. Sometimes momentary pulse on battery Pack+ terminal may be necessary to wake-up the gauge.
    Then recheck if [0x71] is become available in the commands scan list.

    ReplyDelete
  119. i disconnected the board from the cells and reconnected them and now there is no more any sign that the cypress board is communicating with the battery board. smbusb_scan -w 0x16 doesn't output anything below "Skipping: None" and the dashes line underneath. Any read command outputs "-9".

    ReplyDelete
  120. After power-on, bq8030 goes to sleep mode, to wake-up it you should shortly apply external voltage to battery Pack+ pin at its connector, or alternatively, momentary short-circuit Cell3+ to Pack+ with a jumper.
    Then try smbusb_scan -a to check adresses first.

    ReplyDelete
  121. in my battery pack i have 3 pairs of 3.7 V cells in series. Your alternative solution implies shorting the board "+", i.e. the wire meant to be connected to the pack "+", with the cell2 "+"?

    ReplyDelete
  122. as for your initial suggestion i only connected the board "+" to the pack "+" shortly. The three pairs are above 4V each. I though it should be enough as it is above 3.3 V.

    ReplyDelete
  123. if count from zero, then yes it's cell2, if from 1 then cell3.
    Actually you should bypass FETs and Fuse with this procedure.
    Not sure if 3.3V is enough to wake-up.
    Sometimes if there is no communication with gauge it could be useful to reconnect power to fx2lp itself.

    ReplyDelete
  124. What do you mean by Pack+? If this is the + of the whole pack of cells then what is Cell3+?

    ReplyDelete
  125. It's battery connector output pin which supplies power to laptop.
    Below is schematic for example.

    -> Fuse -> DsgFET -> ChgFET -> Pack+ -> (to laptop)
    I
    I
    Cell3
    I
    I
    Cell2
    I
    I
    Cell1
    I
    I____________ Pack- (Gnd)

    ReplyDelete
  126. now i understand. Now i can communicate with the chip. When doing "smbusb_scan -a" or "smbusb_scan -w 0x16" the result is exactly as in my post on 16th march, the first one. I still can't re-flash it, nor i can run "smbusb_bq8030flasher --execute" I get
    "Error communicating with the Boot ROM.
    Chip is not in the correct mode, has hung or there's an interface issue"

    ReplyDelete