[Xperia Arc Android Development] Bazoocaze:
More "Brainstorming"

I analyzed the source code for the controller driver bq27520, along with the system initialization proccess of Arc. I also read the bq27520 manual and datasheets several times, and here are my conclusions from the observation of the problem of other users (I dont have a faulty unit to be able to check the issue in details):

- The bq27520 controller firmware is updated on every restart of the phone. The call to the firmware updater is done from the initialization script /init.semc.rc

-----

hw_config service /system/bin/sh /system/etc/hw_config.sh

-----

In hw_config.sh, the firmware updater is called with no parameters:

-----

# IT BQ275xx firmware loader

bq275xx_fwloader

-----

- The firmware updater bq275xx_fwloader uses special files on directory /sys/class/power_supply/bq27520/fg* to communicate directly with the controller and update the firmware / flash data on the controller.

The firmware upgrader is in /system/bin/bq275xx_fwloader, and the firmware data files are in /system/etc/firmware/bq27520_fw*

- The source code of the kernel module driver for the controller is the file bq27520_battery.c.

It manages to communicate on the i2c bus address 0xAA (7bits 0x55) when operating in "fuel gauge mode", and at 0x0B (7bits) when operating in "ROM mode" to update the flash memory. During loading of the driver, it scans communication on both addresses - if none of the addresses responds, the driver is not loaded.

Also, the driver is responsible for the creation of special directories/files within /sys/class/power_suply/bq27520 containing, among other things, the current parameters of battery sensing, like voltage and percentage, plus the special files fg* necessary the firmware updater to communicate with the controller for an update.

My observation about the problem

It seems that the bq27520 controller is not responding to commands from the i2c bus in none of the expected addresses (0xAA/0x55 and 0x0B), so the driver is not loaded. The Battery Monitor on Android phones expects to read the value of the percentage battery through the information provided by the battery driver, in this case the bq27520 driver, which, as it was not loaded, results in a read error which eventually show 0% battery.

Moreover, as the driver was not loaded, is not possible to use the firmware updater to send a new firmware to the bq27520, because the updater uses special files in /sys/class/power_supply/bq27520 to communicate with the chip.

Probably the bq27520 controller presents a problem in the firmware or flash memory, so it does not respond in i2c predefined addresses.

Possible solution or outline of the situation

- [Hard] Remove the defective bq27520 chip and solder a new one.

- [Hard] Connect directly the bq27520 to an Arduino through two 10K resistors in i2c bus, communicate directly with the chip and try to force a firmware upgrade.

- [Medium] Change the bq27520 kernel driver to continue loading the driver in case of failure in communication, and verify if the firmware can be updated using the driver API.

- [Medium] Change the bq27520 kernel driver to continue loading the driver in case of failure in communication, and modify the procedures to report 100% battery. The phone will work normally until the battery runs out, then turning off the phone without notice.

- [Easy] Take the phone to exchange / warranty on Sony authorized workshop.

How can I help

I have experience in C and kernel modules, so I can try to make the suggested changes in the driver to attempt to circumvent the problem.

If you are interested, I can try to compile an Android Kernel using the modified driver and the sources provided by Kaled topic linking to he development page at Sony. I can not test on my own phone since the 0% problem did not occur to me and I'm still bootloader-locked for warranty issues, so those interested would have to unlock the bootloader and test the patched version of kernel to check the progress of the patching. It would be easier too if someone with experience in compiling Android Kernel assist in the process.

It is a procedure of trial and error without warranties, so if you have a phone under warranty, now is the time to request a replacement.