Just 'adding' because this battery controller is already public. You have the (pdf) which tells you the pin combination to enter the Boot ROM and most of the command set (how was the actual read command missed?

Then there are open-source flasher tools like. You can also use Google to find the passwords because you WILL need passwords (at least with this firmware) and that is after you set the correct pins to the correct states to enter the boot rom. Yeah, overkill. But since it's all out there it's just a matter of coding up a tool for. $ smbusb_scan -w 0x16 ------------------------------------ smbusb_scan ------------------------------------ SMBusb Firmware Version: 1.0.1 Scanning for command writability. $ smbusb_comm -a 0x16 -c 0xFF -w CDAB -b $ smbusb_comm -a 0x16 -c 0xCF -w 3412 -b $ smbusb_scan -w 0x16 -e 10 ------------------------------------ smbusb_scan ------------------------------------ SMBusb Firmware Version: 1.0.1 Scanning for command writability.

Scan range: 00 - 10 Skipping: None ------------------------------------ [0] ACK, Byte writable, Word writable, Block writable, >Block writable [1] ACK [2] ACK [3] ACK [4] ACK [5] ACK *snip* It still ACKs every command but it's exposing the documented Boot ROM inteface now. Just don't scan it too much because writing the wrong thing to the wrong command will hang the controller and/or the entire bus which the SMBusb won't like too much either. (The Boot ROM in this chip has zero error handling.) Some coding later. 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.

Sanyo Tool Reset Bq8030 Datasheet. Battery capacity is stored as the remaining capacity reported through SBS divided by 2. Cycle count is stored as Cycle. Count- 1 (eg.: SBS value: 2. Eeprom byte: 2. 22)Remaining Capacity Alarm is stored as- is. A good place to start mapping.

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.

With a bit of tweaking, even my oldie slides are nice and mostly clean. Vuescan ubratj vodyanie znaki.

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.