Monday, August 29, 2016

Hacking the R2J240 with LGC firmware


The second battery controller I looked at was the Renesas R2J240-10F020. It's a complete black box with very little information available except for some outtakes from the datasheet on Chinese developer forums. There is very little resemblance to the M37512, an older Mitsubishi/Renesas microcontroller used in earlier battery packs that's fairly well documented.


The first thing you notice is that this chip has the analog frontend integrated (unlike the M37512 or the bq8030) because there's no separate chip for measuring voltages and such. Cells are connected directly to this chip so it's a one-chip solution for building smart batteries.

SBS Report

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

 Manufacturer Access:        6001
Battery Mode:               e000
*snip*


Probing around



I started out by measuring voltages on all the pins. Just going by logic I was expecting some sort of differentiation on the various sides of the chip.

To summarize my findings after the first pass:
  • 1-12 is the "main microcontroller side" has the SMBus pins, VCC (and probably RESET and others)
  • 25-36  is connected to current sensing and exposes various built-in voltage regulators
  • 37-48  appears to be mainly unused with a couple of pins at 3.3v, GPIO side?
  • 13-24  has many pins connected directly to "high voltage" from the cells.
I took a 1k resistor connected to ground and started poking the pins with it to find reset. It should be possible to pull reset low through 1k resistor but unlikely on VCC and it shouldn't lead to a complete reset on an unrelated pin. It's also possible to rule out most pins through visual inspection and measurement. So long story short: Pin #12 is Reset.

Next I wanted to see if there's something like a Boot pin that's going to get me a different mode when pulled either low or high during reset so I started up a continuous command scan and started poking at the pins again.

Pulling Pin #4 (also connected to Test Point 1 on the other side of the PCB) low during reset gave me this:

$ smbusb_scan -w 0x16
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - ff
Skipping: None
------------------------------------
*snip*
[f0] ACK, Byte writable
[f1] ACK
[f2] ACK
[f3] ACK
[f4] ACK
[f5] ACK
[f6] ACK
[f7] ACK
[f8] ACK
[f9] ACK
[fa] ACK, Byte writable, Word writable, Block writable
[fb] ACK, Byte writable, Word writable, Block writable
[fc] ACK, Byte writable, Word writable, Block writable, >Block writable
[fd] ACK, Byte writable, Word writable, Block writable, >Block writable
[fe] ACK
[ff] ACK

The chip was ACKing on every command. A deliberate attempt at confusing any would-be attacker perhaps? The write scan however reveals that the chip is actually exposing some real functionality on some of the commands and that a couple of them violate SMBus protocol.

Pin #4 appears to be BOOT (active-low).



Mapping

Mapping out the protocol took a while especially because it doesn't correspond to standard SMBus protocol but I was eventually able to figure out how to read and write to RAM and erase blocks of memory-mapped flash.
Just writing to the appropriate address in ram (after the flash blocks have been erased) writes the flash memory which is convenient.

There are several partitions of flash mapped into RAM and I'm sure I haven't found all of them. The ones I did are included as address&length presets in the flasher tool.
$ smbusb_r2j240flasher -d eep2.bin -p df2
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Dumping memory 0x3400-0x37ff ...
Done!
$ xxd eep2.bin
0000000: 0000 0000 0000 0000 0000 ffff ffff ffff  ................
0000010: 4c4e 562d 3432 5434 3739 3700 0000 0000  LNV-42T4797.....
*snip*

 $ smbusb_r2j240flasher -d eep3.bin -p df3
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Dumping memory 0xc000-0xdfff ...
Done!
$ xxd eep3.bin
0000000: 0100 0700 b801 b801 1100 0203 0201 01e3  ................
0000010: e6fe e3ae 7000 e0e4 0cc8 0038 3150 14f0  ....p......81P..
0000020: 1530 2a4c 4743 0031 3100 0000 0000 0000  .0*LGC.11.......
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 004c 4e56 2d34 3254 3439 3131 0000  ...LNV-42T4911..
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 004c 494f 4e01 2d01 2d30 07fa 1031  ...LION
*snip*


In this particular battery pack the static information was stored in df3 and the dynamic in df2, df1 was empty.
Another battery stored dynamic info in df1 so this is going to differ between firmwares/packs.

Just like the bq8030 the static area is protected by a checksum on this controller/firmware as well. I took a shot at it just for kicks and it was pretty simple so I included it in the flasher tool.
$ smbusb_r2j240flasher -w eep3_f.bin -p df3 --fix-lgc-static-checksum --execute
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Erasing flash block starting at 0xc000 ...
Done!
Fixing LGC static checksum..
Done!
Writing memory 0xc000-0xdfff ...
Done!
Verifying 0xc000-0xdfff ...
Verified OK!
Exiting Boot ROM and starting firmware.

$ smbusb_sbsreport
SMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name:          LGC
Device Name:                Karosium000
Device Chemistry:           LION
Serial Number:              41291
Manufacture Date:           2010.01.25
*snip*


Reset

Pretty much the same procedure as with the bq8030. Map and modify the dynamic area. Eventually you'll find the error flag. As with the bq8030 the dynamic area isn't checksummed in this controller/firmware either.

Helpful tips:
  • Again, multiple log entries. The number of 0x00 bytes at the beginning of the section determine the number. Patch the duplicated data in all of them.
  • You can decrease the number of log entries to 1 for the time of mapping which will make the job a lot easier.
  • The real cycle count is stored encoded. No idea how. With this particular firmware it was at 0x78-79. Zeroing out the bytes still decreases the cycle count to 5 but the precise algorithm/obfuscation? No clue.
  • Please don't ask me to fix flash dumps :-)
  • Good luck!
Notes

No disassembly/ler for this chip. I don't really know what architecture it's based on. If I had to guess I'd say an extended version of the MELPS 7700, an old Mitsubishi architecture that Renesas inherited because trying to load it up in IDA with that core seems to produce something that starts to make sense but fails on invalid instructions. I could be completely wrong though.

If anyone wants to tackle this they could probably find a nice, easy way of getting into the Boot ROM using just SMBus commands.
Posted by at
Labels: , , , ,

54 comments:

  1. h4tr3dMarch 14, 2017 at 8:01 PM

    Hi! Do you know anything about 51F51 controller? It is single-chip solution for smart batteries. I found it in my Thinkpad T530 9-cell (94WH) battery. Google provide links to the AliExpress but there is no any Datasheets.

    ReplyDelete
    Replies
    1. ViktorMarch 15, 2017 at 9:06 AM

      No clue, sorry. It might be a later revision of this Renesas one but that's just a guess.

      Delete
    2. h4tr3dMarch 16, 2017 at 12:12 AM

      Thank for answer. Until wating for my FX2LP board: seems (http://ubrt.com.ua/main/built-in-program-modules/lgc-tools, in Russian, sorry) that 51F51 is a R2J240_51F51. So, R2J240 in another package (TSSOP38). Also, fiwmware LGC too.

      Viktor, could you please add info: where is pins 4 and 12 connected in your case? PCB elemetns and so on...

      Delete
    3. ViktorMarch 16, 2017 at 2:21 AM

      Good to know, thanks!
      Unfortunately I can't help you there either. The R2J240 pack I have is already back in service so I don't want to break it apart again and I haven't taken any detailed pictures of the controller board. The procedure I've mentioned in the post (though time consuming) could work. Step 1, measure all voltages Step 2, deduce different sides Step 3, try to find reset Step 4, keep resetting while pulling logic-level pins either high or low while running "watch -n 1 smbusb_sbsreport" and wait until all you get is ERROR scans, then do a scan to confirm that you're in boot rom (or that you've hung/fried the chip, if you're unlucky).

      Delete
    4. ВетаFebruary 5, 2018 at 12:14 PM

      I have LGC Think Pad battery it is pretty the same as described above. TP1 is bootloader

      Delete
    5. ВетаFebruary 6, 2018 at 10:33 AM

      I'm not changed anything but made a battery unblocked...
      Battery for ThinkPad X230 45N1025 LGC
      Controller is 51F51
      User have to calibrate a battery by PowerManager.
      Thats a EEPROM https://yadi.sk/d/nJM6Hbfk3S9qnL

      Delete
    6. h4tr3dFebruary 6, 2018 at 5:35 PM

      @Вета, thanks a lot for information!

      Delete
    7. khsealNovember 17, 2018 at 9:23 AM

      @Вета Thanks for the information. Did you just read the eeprom and the lock was reset?

      Delete
    8. danandrei96September 3, 2021 at 10:46 AM

      @Вета any chance you know which pin is reset on the 51F51 ?

      Delete
    9. VitaliyKJuly 12, 2022 at 5:46 AM

      Any update about this chip? What pins BOOT and RESET?

      Delete
    10. h4tr3dSeptember 4, 2022 at 5:15 PM

      Too late, but... Update about BOOT and RESET for TSSOP38:
      Pin 3 - VCC, 3.3V
      Pin 10 - BOOT, 4.7K pull-up to VCC. Active LOW.
      Pin 13 - RESET, 5.6K pull-up to VCC. Active LOW.

      I have two same controller for original and after-market battery (after market didn't charged, Thermal Fuse omitted. IC3 omitted also).

      On my board:
      BOOT routed to the TP1 (as mentioned above by @Вета) test point at the bottom of the front controller side
      RESET routed to the TP14 test point at the top of the back side

      (Need update) 51F51 revision has next founded mapping (all little endian):
      0x40, 2 bytes - Remain Capacity Alarm, in mAh
      0x44, 2 bytes - Remaining Time Alarm, in minutes
      0x48, 2 bytes - FCC. TBD: example dump above map this value as-is in mAh, but I need 6000 mAh multiply to 1.78 to gen ~6000mAh in the report output. Need investigate.
      0x46, 2 bytes - Battery Mode
      0x4C, 2 bytes - Cycle Count, maps as is (TBD)

      I have "Charging Current:" and "Charging Voltage:" set to zero. Worked dump shows 3500mAh and 13050mV accordingly.

      Delete
    11. h4tr3dSeptember 4, 2022 at 5:26 PM

      Also, I updated original Victor's tools to work with i2c-dev under Linux. Generally it work well with CP2112 :-) Functions SMBWrite()/SMBRead() can't work in such setup by design and must be reworked. Currently I implement SMBTransfer that work well with i2c-dev design. Will publish ASAP.

      Also, for 51F51 reading of register CMD_READ_CLEAR_STATUS_REG fails always with timeout. But erase works, just wait. Will do some WA.

      Delete
    12. h4tr3dSeptember 6, 2022 at 2:28 AM

      Last update: I start my controller! :-)

      0x60-0x63 - affect "Relative state of Charge", "Absolute state of Charge" and "Remain Capacity" in unknown way. Don't touch.

      0x6b - sounds like contains flag, that lock/unlock battery. My value is 0x17. Replace it to 0x03 change "Manufacturer Access" code from 1002 to 0018, switch "Charging Current" from zero to 3500 mA and "Charging Voltage" from zero to 13050 mV. Sounds like bit 4 is a lock bit.

      Also, FCC value must be filled as is and it in mWh, so, just multiply mAh capacity to the design voltage divided to 10: 6000 mAh * 1.11.

      Also, useful link for Linux users: https://www.buggycoder.com/thinkpad-battery-calibration/

      Delete
    13. h4tr3dSeptember 10, 2022 at 7:47 AM

      My changes adopting software for working with Linux i2c-dev: https://github.com/h4tr3d/smbusb, tested with CP2112.

      @Viktor, changes adopted to work both with FX2LP and i2c-dev: device can be pointed via command line `--device` argument. If omitted, FX2LP device tries to open by default. So, if you want, I can submit PR to you.

      Delete
    14. danandrei96October 9, 2022 at 9:11 AM

      Hi hope you are well, congratulations on your work and your findings, I was planning to document the pins of the 51F51 as well but you beat me to it. Do you know how to change the chemistry or cutoff voltage for the LGC firmware? I have a battery which had originally 4.3v cells, but I recelled it using 4.2v which are more commonly available. I can flash dumps from a 6-cell to adjust the voltages, but then the capacity is very, very wrong. Thanks

      Delete
    15. h4tr3dNovember 9, 2022 at 4:29 PM

      @danandrei96 sorry, I don't know. Sounds like, this information at the "signed" section. I didn't deal with it.

      Delete
    16. ladislavFebruary 3, 2023 at 5:27 AM

      Hi, everyone, thanks for the work!

      @danandrei96 I'm now in the process of replacing 4.3v cells and I found the address for the cell voltage in the static section / df3 - 0x2BE: 2 bytes (signed short)

      Here are my notes so far hope it helps someone:
      ```
      DF3:
      00000000: 0100 3600 0001 fb01 3600 0206 0201 02e3 ..6.....6.......
      00000010: e6fe e3a9 7000 e0ac 0dc8 0076 2fe0 1595 ....p......v/...
      00000020: 1f30 2a4c 4743 0031 3100 0000 0000 0000 .0*LGC.11.......
      00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
      00000040: 0000 0053 7469 6c6c 2041 6c69 7665 0000 ...Still Alive..
      00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
      00000060: 0000 004c 494f 4e03 3201 3290 07fa 1031 ...LION.2.2....1
      ...
      00000230: 0328 e9aa 053c 3ce8 1cf0 0aac 0d78 0578 .(...<<......x.x
      00000240: 0500 0000 0096 0088 136c 07be 0a78 0578 .........l...x.x
      ...
      000002b0: 6810 2c01 109a 102c 0164 6400 fa32 6810 h.,....,.dd..2h.
      ...
      00001ff0: ffff ffff ffff ffff ffff ffff f476 c939 .............v.9


      16-bit:
      0x017: ??? # was the same value as reported Charging Current
      0x01B: Charging voltage # Reported total value, no electrical effect
      0x01F: Design Capacity
      0x021: Design Voltage # Reported value
      0x023: Manufacturer name # (untested)
      0x043: Device name
      0x063: Device Chemistry
      0x23B: ??? # was the same value as reported Charging Current
      0x24B: Charging Current # Reported value (electrical effect untested)
      0x2BE: Cel Voltage # Actual cell charging voltage

      DF1:
      00000000: 00ff ffff ffff ffff ffff ffff ffff ffff ................
      00000010: 5374 696c 6c20 416c 6976 6500 0000 0000 Still Alive.....
      00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
      00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
      00000040: 3002 6e02 0a00 00e0 7d04 2a04 0200 ca42 0.n.....}.*....B
      00000050: 4b46 5333 334e 3032 5a00 0021 0014 00f6 KFS33N02Z..!....
      00000060: 5ee2 00e6 4114 00e4 e472 0003 203f 00e1 ^...A....r.. ?..
      00000070: 0201 0000 0000 c808 384e c841 8c8b 0700 ........8N.A....
      00000080: 0000 f910 8513 850c 1c01 0000 0000 0000 ................
      00000090: ffff ffff ffff ffff ffff ffff ffff ffff ................
      ...

      8-bit lock Flags at 0x6B: #Locks battery / changes Manufacturer Access
      0x6B = 0x03: OK #MF.Access: 0018 (same as working battery)
      0x6B = 0x07: seems OK #MF.Access: 0010 (not tested in laptop)
      0x6B = 0x17: Locked #MF.Access: 2002 (appears dead)

      0x16-bit:
      0x10: Device Name #no effect
      0x42: Remaining Capacity Alarm #idk
      0x44: Remaining Time Alarm #idk
      0x46: Battery mode #idk
      0x48: Full Charge Capacity #
      0x4C: Cycle count #works
      ```

      Delete
    17. danandrei96February 27, 2023 at 12:24 AM

      maybe ladisav has made more progress, but as far as I know you have to physically short the pins on the chip in order to enter boot mode, because we don't have the commands/password

      Delete
  2. UnknownAugust 17, 2017 at 5:27 AM

    Hello,
    I have Thinkpad x201 and i bought a 6 cell battery from AliExpress.
    I left it for charge the battery, it charges but when it reaches 100% charge with ac connected for a while, gauge suddenly drops %0 and the battery light charges from solid green to flashing orange, battery voltage stays (12,5v~) what it should be at %100. I could use the full capacity of the battery while the orange battery light flashing.
    The seller will send a new one but i want to repair the defective battery. Do you have an idea?

    ReplyDelete
    Replies
    1. ViktorAugust 17, 2017 at 6:29 AM

      No clue, sorry. The cheap aftermarket packs are unlikely to use any of these chips.

      Delete
    2. VitaliyKJune 22, 2022 at 7:31 AM

      Hi. Would you please explain how "You can decrease the number of log entries to 1 for the time of mapping which will make the job a lot easier." In dump of 55++ battery six similar (not identical) parts. It would be easy to work with 1 only.

      Delete
    3. ViktorJune 22, 2022 at 7:45 AM

      I don't really remember anymore but based on "The number of 0x00 bytes at the beginning of the section determine the number. " I probably FF-ed out all but the first one and then 00-ed out all but the first log entry.

      Delete
    4. VitaliyKJune 22, 2022 at 12:51 PM

      Hi. I do not realy understand what you mean. I have in df1
      00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 4C 4E 56 2D 34 32 54 34 39 36 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
      at the begining. Then 6 similat parts started not from 00. Could you explain in human language ? :) I'm not programmer. BQ8030A I fixed using your recomendations. May I send you my dump to see? Is it normal all 6 parts have differences?

      Delete
    5. ViktorJune 22, 2022 at 1:03 PM

      "FF-ing out": replace those 00s with FFs except for the first one, "00-ing out": replace all bytes in the log entry bytes after the first one with 00s. A log is a record of past events, in this case: of past charge cycles, conditions will be slightly different for each log entry of a charge, as you can imagine, so difference is normal. This is the most I can help you out, I wish you best of luck.

      Delete
    6. VitaliyKJune 23, 2022 at 4:19 AM

      I just "FF" 1-5 parts and worked with #6. Corrected all I needed. Now I will copy it to 1-5 and try on laptop. Do I need to change Battery mode and battery status? What do they show?

      Delete
    7. VitaliyKJune 23, 2022 at 4:26 AM

      What number should be "At Rate OK"?

      Delete
  3. UnknownAugust 19, 2017 at 9:45 PM

    Hello,
    Does shorting the pin12 to ground reset the circuit? I recharged my battery pack from dead to 11.5V(exernally), but it is not working. It says plugged in 0%, not charging. Before I recharged, the battery was not even showing up. But I am still not able to charge it. What is your advice? does flashing it after fixing crc reset it?

    ReplyDelete
    Replies
    1. ViktorAugust 20, 2017 at 4:09 AM

      It resets the microcontroller (ie. restarts the firmware). There's no simple way to "reset" as in clear the failure flag if it's been set which is why this project came to be.

      Reading the battery related posts from 2016 aug-sep could help get you started. Some experience with electronics and reverse engineering binary blobs is necessary.

      CRC fix is only necessary for modifying the static area. Failure flag is in the dynamic area. I can't offer any assistance beyond that. Good luck!

      Delete
  4. UnknownAugust 20, 2017 at 8:50 PM

    Thank you victor.
    I understand I have to setup a hardware to do this. Is there a way to access the battery using system smbus without using external hardware, with windows or linux? I am unable to setup the hardware on my own. I have a TI stellaris launchpad with me, but porting the code to it seems intimidating to me.

    ReplyDelete
    Replies
    1. ViktorAugust 21, 2017 at 1:49 AM

      Answered here: https://goo.gl/yLL1Dt
      FWIW there isn't really any hardware setup involved. It should just be plug and play if you have the required board. Though note that the windows binary release may not work with certain boards since it doesn't include this fix https://goo.gl/GJLNWC yet

      Delete
    2. h4tr3dFebruary 6, 2018 at 5:40 PM

      Suraj, FX2 demo boards that uses as programmer so cheap... Just wait it and found time to investigate (my problem...).

      Delete
    3. UnknownFebruary 5, 2020 at 2:04 PM

      first of all, thank you for your great work Viktor!
      and in fact i managed to talk to my dead battery via the vga port of my laptop and i2c-tools, like i litterally plugged 3 cables into the vga port and battery and this works (should work with other video ports too, just google "i2c vga diy adapter" or sth like this). unfortunately i don't know anything about what i'm doing, i just tried to fix my dead battery (bq8030) however, i was wondering if it would be possible to adapt your tools to work with /dev/i2c ? like, if i write those bytes to 0x71 with i2cset, i can see how it changes it's state and unlocks more commands/registers... and as you described, if i do something it doesnt like, i get kicked out, back into the first (sealed?) mode. if i write this final 0x0517 to 0x70 it again changes state. i found a program called eeprog, which i modified a bit, this gives me strange/wrong output but i could find the length you described, after 0x500 something is different, like, after 0x500 i see that first state again, but with 17's where there should be the data and ff where i2cdump shows XX. so, i guess that indicates that those bits are readable? or even writeable? or, since that modified eeprog most probably does not talk the way the chip likes to talk, am i just getting kicked out again when i start to read things i'm not supposed to read? as far as i understood, i would need to first write the address i want to read, and then i'd need to write a read command to another address, which then would return the address i specified in the step before? like, this sounds all a bit complicated, would be really nice if it was possible to adapt your tools for /dev/i2c, especially those flasher tools...?
      by the way, this is what i get with i2cdump in what i suppose to be the sealed state:
      sudo i2cdump -y 1 0x0b w
      0,8 1,9 2,a 3,b 4,c 5,d 6,e 7,f
      00: 4002 01e8 000a 8000 0000 ffff ffff ffff
      08: 0b92 249f 0000 0000 0000 0000 0000 0000
      10: 084d 0000 0000 ffff 0000 0000 03d0 0080
      18: 1314 2b5c 0031 3c3c 081e XXXX XXXX XXXX
      20: 5308 4c08 4c04 420e XXXX XXXX XXXX XXXX
      28: XXXX XXXX XXXX XXXX XXXX XXXX XXXX 310b
      30: 0d0a a910 c810 0018 XXXX XXXX XXXX XXXX
      38: XXXX XXXX XXXX 0b91 4c0a 0000 0001 0000
      40: 1717 XXXX 0003 0320 XXXX XXXX XXXX XXXX
      48: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      50: 4203 0b0a 0108 0007 000d XXXX XXXX XXXX
      58: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      60: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      68: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      70: XXXX 1717 0000 XXXX XXXX XXXX XXXX XXXX
      78: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      80: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      88: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      90: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      98: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      a0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      a8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      b0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      b8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      c0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      c8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      d0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      d8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      e0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      e8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      f0: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
      f8: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX

      Delete
  5. BarkutiOctober 20, 2018 at 2:01 PM

    Hello!
    Recently replaced all cells in a ThinkPad 42T4858/42T4814 battery, its inboard s̶m̶a̶r̶t̶ stupid R2J240-20F020 battery management logic blew up the 12AH3 fuse for some reason. At first I successfully made it work and re-calibrate, then left battery and computer sleeping for around 3 months. A few days ago I took the laptop to verify it, noticed it wouldn't boot into Windows with the battery. Once booted, the battery information tool told me the battery was at “0% charge” despite its voltage reading was well above 11V, and it was charging. I freaked out, thinking something went wrong somehow in my internal assembly. Disassembled the battery again and rebuild it in a more convincing way to me. My cell assembly, however, was not at fault. I just left in a low state of charge and this was the reason the system wouldn't boot on battery power. Nevertheless, upon reassembly I did not soldered the logic board terminals secuentially or whatever and I triggered the chip's fault flag. The laptop refused to boot on battery power and once it did the battery software reported a dead battery. :'(
    Sorry for the drama.
    Question is, ¿besides replacing the fuse what are my choices with regards to the R2J240?
    I contacted the guy at Battery EEPROM Works ( http://be2works.com ) to ask for a solution but after telling him I just needed to fix a single battery all he had to say (literally) was “Нщн”. :-/
    Thanks in any case.

    ReplyDelete
  6. 0r10nVOctober 24, 2018 at 2:43 AM

    Just compare dataflash before fault and after in your favourite hexeditor (hope you save copies), and you can easy locate where PF-flag resides, normally it uses 2bytes and if all ok they are in zero, in PF state they not, change them to zero and reflash.
    Good luck!

    ReplyDelete
  7. khsealJanuary 11, 2019 at 1:54 AM

    Thanks for working software! Everything works and was able to restore the batteries.

    ReplyDelete
  8. dupaOctober 8, 2021 at 12:42 AM

    I have toshiba batteries on this chip R2J240 with SDI:

    SMBusb Firmware Version: 1.0.1
    -------------------------------------------------
    Manufacturer Name: SDI
    Device Name: NS2P3SZMC4WR
    Device Chemistry: LION
    Serial Number: 5989
    Manufacture Date: 2012.03.10

    is it possible to reset it with this method?

    ReplyDelete
  9. dupaOctober 8, 2021 at 1:21 PM

    unfortunately it does not work, I only blocked working batteries
    and now I have a blind instead of a 1,5h battery :(

    ReplyDelete
  10. VitaliyKJune 15, 2022 at 8:46 AM

    Hi. I have Lenovo 55++ 9 cell battery. I used it in T530 laptop with modded embedded controller. Battery's capacity was dropped dramatically so I replaced cells.
    It is working but FCC remained same. Running Lenovo vantage battery reset did not change it. I can see it discharge stage voltage ~12.3v but it shows 0 capacity.
    Is it possible to change FCC?

    ReplyDelete
  11. VitaliyKJune 15, 2022 at 8:48 AM

    Here is battery info
    Manufacturer Name: LGC
    Device Name: LNV-42T4969
    Device Chemistry: LION
    Serial Number: 1793
    Manufacture Date: 2012.02.03

    Manufacturer Access: 0018
    Remaining Capacity Alarm: 936 mAh(/10mWh)
    Remaining Time Alarm: 10 min
    Battery Mode: e080
    At Rate: 0 mAh(/10mWh)
    At Rate Time To Full: 65535 min
    At Rate Time To Empty: 65535 min
    At Rate OK: 1
    Temperature: 22.35 degC
    Voltage: 12490 mV
    Current: 0 mA
    Average Current: -70 mA
    Max Error: 0 %
    Relative State Of Charge 87 %
    Absolute State Of Charge 0 %
    Remaining Capacity: 84 mAh(/10mWh)
    Full Charge Capacity: 97 mAh(/10mWh)
    Run Time To Empty: 65535 min
    Average Time To Empty: 9965 min
    Average Time To Full: 65535 min
    Charging Current: 3500 mA
    Charging Voltage: 12600 mV
    Battery Status: 0280
    Cycle Count: 1141
    Design Capacity: 8658 mAh(/10mWh)
    Design Voltage: 11100 mV
    Specification Info: 0031
    Cell 0 voltage: 4169 mV
    Cell 1 voltage: 4172 mV
    Cell 2 voltage: 4149 mV
    Cell 3 voltage: 0 mV

    ReplyDelete
    Replies
    1. h4tr3dSeptember 10, 2022 at 7:55 AM

      @VitaliyK, look into my research above. Maybe it will be helpful.

      Delete
  12. Man-Eating MonkeyOctober 14, 2023 at 5:02 PM

    Hi, I am not sure I understand the sequence to enter boot mode. Are the following steps correct?

    1. Pull Pin #12 low
    2. Pull Pin #4 low
    3. Release Pin #12
    4. Release Pin #4
    5. Send flash command

    ReplyDelete
  13. Man-Eating MonkeyNovember 22, 2023 at 2:57 AM

    For a Lenovo L09L6Y02 with an R2J240-20F020 BOOT is Pin #10. RESET is #Pin 12. Both normally high, need to be pulled low. Pull both down together, release RESET and then keep holding BOOT low for another second or two.

    My PF flag was at address 0x38B (with value of 17) that I cleared to 00.

    ReplyDelete
    Replies
    1. Man-Eating MonkeyNovember 22, 2023 at 3:00 AM

      I should clarify that's address 0x38B of DF2.

      Delete
    2. sl13January 27, 2024 at 1:12 AM

      Hi, I got here a power tool battery pack with the R2J240-10F020 in a QFN48 package. Unfortunately I have no clue to which pins I have to connect the smbus lines on the chip. Could you maybe provide the pin numbers for CLK and Data.

      Delete
  14. Man-Eating MonkeyNovember 22, 2023 at 3:03 AM

    For a Lenovo 42T4856 with an R2J240-20F020 BOOT is also Pin #10. RESET is still #Pin 12. My PF flag was at address 0x18B of DF1 (also with a value of 17) that I cleared to 00.

    ReplyDelete
  15. Man-Eating MonkeyNovember 22, 2023 at 8:38 PM

    This comment has been removed by the author.

    ReplyDelete
  16. solarisDecember 26, 2023 at 11:22 AM

    Hi VIktor, Does the smbusb_2021-01_windows release working with CP2112 Debug Board, please? I have R2J240-20F020 chip. *Ваша программа версии под windows будет работать с платой С2112 ? У меня пишет, что чип не найден. Pin #12 is Reset Pin #4 BOOT .

    ReplyDelete
    Replies
    1. Anandakrishna SudhakaranDecember 26, 2023 at 11:19 PM

      This comment has been removed by the author.

      Delete
    2. Anandakrishna SudhakaranDecember 26, 2023 at 11:20 PM

      No this support only linux, you can watch my video if you want to know more about the linux and cp2112

      https://youtu.be/7r17ZuEgyTU?si=k4uUCrl0DiQ83_du

      Delete
  17. VitaliyKJanuary 7, 2024 at 6:44 AM

    Hi. Have another issue with same battery (Manufacturer Name: LGC
    Device Name: LNV-42T4969). After I fix cell issue it was working for year and half and now Lenovo says battery is too old, cannot charge, replace it. That is all Lenovo :(
    What can be done to reanimate it?

    ReplyDelete
    Replies
    1. VitaliyKJanuary 9, 2024 at 4:03 AM

      Here is the report:
      E:\Battery unlock\smbusb-master\RELEASE_WIN64>smbusb_sbsreport.exe
      SMBusb Firmware Version: 1.0.1
      -------------------------------------------------
      Manufacturer Name: LGC
      Device Name: LNV-42T4969
      Device Chemistry: LION
      Serial Number: 1793
      Manufacture Date: 2012.02.03

      Manufacturer Access: 1002
      Remaining Capacity Alarm: 936 mAh(/10mWh)
      Remaining Time Alarm: 10 min
      Battery Mode: e080
      At Rate: 0 mAh(/10mWh)
      At Rate Time To Full: 65535 min
      At Rate Time To Empty: 65535 min
      At Rate OK: 1
      Temperature: 23.65 degC
      Voltage: 12528 mV
      Current: 0 mA
      Average Current: 0 mA
      Max Error: 0 %
      Relative State Of Charge 0 %
      Absolute State Of Charge 0 %
      Remaining Capacity: 0 mAh(/10mWh)
      Full Charge Capacity: 0 mAh(/10mWh)
      Run Time To Empty: 65535 min
      Average Time To Empty: 65535 min
      Average Time To Full: 65535 min
      Charging Current: 0 mA
      Charging Voltage: 0 mV
      Battery Status: 0690
      Cycle Count: 378
      Design Capacity: 8658 mAh(/10mWh)
      Design Voltage: 11100 mV
      Specification Info: 0031
      Cell 0 voltage: 4209 mV
      Cell 1 voltage: 4211 mV
      Cell 2 voltage: 4108 mV
      Cell 3 voltage: 0 mV

      Delete
    2. VitaliyKJanuary 23, 2024 at 7:27 AM

      Is it possible to change Manufacture Date: 2012.02.03 ?

      Delete
  18. solarisJanuary 20, 2024 at 1:08 PM

    Hi, I used a smbusb_2021-01 + FX2LP for windows XP/ Windows 10 to take a dump R2J240-20F020 microprocessor.

    Unfortunately, In a Boot mode: smbusb_r2j240flasher.exe -d eep2.bin -p df2, I received a * Error: libusb error: Pipe error *. Does any had the same and solved this error ?

    Thank you.

    ReplyDelete
    Replies
    1. DoriMay 23, 2024 at 12:21 AM

      Hi, i'm triying to reset my SAMSUNG notebook battery with the same IC R2J240-20F020 have you solved? Can you tell me how i can proceed? TU. Best regards. Doriano.

      Delete

Moderation temporarily re-enabled due to increased spam

Subscribe to: Post Comments (Atom)