[Nook Color Android Development] fattire:
A theory... (warning: technical)

This is interesting.... and after some discussion and inquiry has lead to a theory.

scotty2 of HTC Vision/gfree fame is looking at this with me tonight, which is good news as he's a genius, as you are about to see... :)

He indeed thinks that the max17042.bin file contains heuristics that may not being updated correctly in cm7.

The max17042.bin file contains 19 16-bit registers that are dynamically adjusted to calculate the battery's heuristics. This file needs to be updated at regular intervals so that the battery's actual charge can be determined at any particular point in time. Such calculation involves taking the heuristics and doing some calculus-based curve analysis which is beyond the scope of this discussion-- but let's just say that if the stuff in that file isn't right and up to date, you won't get an accurate determination of charge.

In the case of CM7, the driver appears to be polling the file fine, but the file isn't being properly updated in real-time. In fact, it doesn't EVER seem to be updated in CM7. At all. And from looking at u-boot and the kernel driver source, there is no code in either to write to the heuristics file-- only to read it.

That leaves userspace for where the update should be happening. It wouldn't be hard to accomplish. In fact, it would just look like this:

cat /sys/bus/i2c/drivers/max17042/1-0036/histdata > /rom/max17042.bin

where /rom is the mount point for p2

So what would we expect to see if this file isn't updated regularly? Reading a bad or old heuristics file over-and-over would likely result in jumps and general weirdness in the apparent battery charge level. And probably (as it's been dubbed) PBD.

Which is exactly what people are reporting.

Some people have reported that going back to 1.2 stock "fixes" the problem. Well, if going back to 1.2 stock would refresh the file with something sane, it could explain why this problem appears to be "fixed" by returning to 1.2. At least for a while.

The reports of "run HC on SD and that fixes everything" just doesn't make much sense on this theory however.

Still, according to this theory, mounting p2 to /rom (or wherever) and then setting up a service in init.encore.rc which essentially does a cat /sys/bus/i2c/drivers/max17042/1-0036/histdata > /rom/max17042.bin at regular intervals may be an interesting experiment.

So how often to update /rom/max17042.bin? Well one way to guess how often it should be written is to look at how frequently it's read by the driver.

max17042_battery.c in the kernel contains the following:

// refresh history at least this often: might be written to file less frequently
#define HISTORY_REFRESH_INTERVAL 60

Answer: It polls every 60 seconds. But it doesn't have to be written so often.

So-- while this may not be a full explanation of the problem, scotty2 is confident that if those values are not being updated regularly, then it will become a problem, because without this file, the controller loses its ability to adapt to the battery.

So I asked-- why do we see this issue now and not in previous cm7 builds? After all, no previous version of cm7 has a daemon running that updates max7042.bin. Well, and again this is speculation, but it may be that the sanity checks in the new u-boot are getting tripped up by the old heuristics data, and so are setting "factory floor" values to replace the outdated ones. And this could later be leading to odd calculations of charge values.

So perhaps the next step might be to set up a custom uRamdisk with a refresh-heuristics-file service that updates every hour or so and see if it fixes anything.

If it does, everyone get ready to send scotty2 some love. And thanks to keyodi for bringing this to everyone's attention.