yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] joenathane:
LOL

Whats also strange is, I was looking for HC to report a different battery level than what was being reported in CM7 .32 before shutdown and it didn't... the only thing I can think of that makes any sense out of this is there must be some calibration or setting somewhere that's not directly writable that influences this...

Or it wasn't HC that fixed the issue for me and others but some other change that we've neglected to account for....
[Nook Color Android Development] TJNooker:
EDIT: Sorry, I didn't understand all the issues when I put up my first report. I'm posting a new one at the end of the thread.
[Nook Color Android Development] fattire:
So wait-- is this using the standard cm7 kernel or the 5/13 oc'd kernel?

Also-- another BN 1.2 mlo/uboot. Beta 3.1 didn't include any of my u-boot/mlos... nor did any nightly before 86. I really think we can eliminate it as a factor. Aside from the logo change, the addition of the menu, support for alt boot and u-boot.device via the kernel args, and some changes by dalingrin to load the kernel a little later + verygreen's support of SD, this is a recompile of BN's 1.2 source. As far as I know, there's nothing new added to anything having to do with setting up power that isn't in 1.2 from BN.
[Nook Color Android Development] angomy:
TEST CONFIGURATION:

BOOT DEVICE: eMMC

MLO: BN 1.2 built by fattire

U-BOOT: BN 1.2 cyan build by fattire

KERNEL: nightly 87

OVERCLOCKED?: 925

GOVERNOR: conservative

SYSTEM: CM7 Nightly 87

PBD: yes

TEST COUNT: 1

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: yes (prior to PBD)

DID IT WORK? no

PREVIOUSLY INSTALLED:

☐ Stock 1.2 unrooted

Notes: PBD @ 21%. Was reading when it just went blank and dead. No response to n or any other keys, would not turn on with power button tapped or held for a while.

When plugged in, it booted CM7. Battery was @ 22%, 3651mV

Was a first-time CM7 install of nightly 87 over EMMC stock -- wiped caches and data during install and once again after install. Updated 1.2 uboot included in nightly 87 with fattire's cyan build 1.2 uboot after the second cache/data wipe.

Going to charge to 100% and run Battery Calibration and drain it down again to see how low it goes this time. (Shouldn't battery be dropping lower than 3600mV before PBD? :x seems quite a bit off)
[Nook Color Android Development] MedLine:
utterly confusing. did you get crash log at /proc/last_kmsg?
[Nook Color Android Development] Narfx:
It definitely was HC. I was getting the PBD at 2X%. So I charged the nook and started monitoring voltages:

95 4081

94 4060

92 4045

91 4031

90 4025

89 4012

88 4003

87 3989

86 3977

85 3959

84 3950

82 3933

80 3913

78 3898

74 3865

71 3847

66 3790

61 3781

At this point I ran this from the SD card (just 5 minutes), rebooted to CM7 and:

42 3765

41 3759

I'll continue to monitor voltages, but I bet I don't get the PBD now. Somehow running HC (maybe any other rom?) is adjusting the battery level.
[Nook Color Android Development] xxiworld:
I didn't re-flash anything. I was running the same (5-13) o/c kernel before and after the fix. I literally just popped in a HC SD card, booted it up, and the battery stats were 20% lower in HC than they were in CM7. Then I powered off, popped out the SD, booted it up in CM7, and the battery stats were fixed. The new, accurate battery percent showed up in CM7, and the PBD was gone.
[Nook Color Android Development] Narfx:
Same here. I didn't touch the eMMC. I powered off, swapped my usual SD card by a bootable HC one, booted to HC, powered off again (after basking 5 minutes in the awesomeness of honeycomb :o), replaced the old SD card and booted CM7. My battery stats are above: ~18-20% lower than before.

(edit) I'm running the OC kernel, BTW.
[Nook Color Android Development] fattire:
This is great stuff. I wish dalingrin were around to talk this through. Blah. He knows more about what pm stuff was replaced in the new kernel than I do.. (which is zero).

Question for anyone running plain ole BN 1.2 stock-- do you get abrupt shutdowns?

Also-- when were these PBN shutdowns first reported? What was happening then?

Medline-- can you think of any reason why running HC temporarily could possibly fix this problem?
[Nook Color Android Development] Animec:
TEST CONFIGURATION:

BOOT DEVICE: eMMC

MLO: BN 1.2 built by fattire (I think)

U-BOOT: BN 1.2 cyan build by fattire

KERNEL: uImage 2.6.32.9 from Nightly 87

OVERCLOCKED?: to 1200

GOVERNOR: Performance

SYSTEM: CM7 Nightly 86

PBD: Yes?

TEST COUNT: 2x

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: YES

DID IT WORK? NO

PREVIOUSLY INSTALLED:

☐ Stock 1.0

☐ Stock 1.1

☐ Stock 1.2

☐ Nookie Froyo (any)

☑ Honeycomb (any)

☑ CM7 2.29 (any)

☑ CM7 2.32 beta 3

☑ CM7 nightlies > 84 (or whenever .32 appeared)

NOTES: After flashing the first .32 kernel, but prior to flashing the new uboot, I had no problems. After flashing the first most widely distributed version of the 1.2 uboot, I experienced PBD at around 30%. Later, having flashed fattire's uboot with the MLO change I experienced PBD at ca. 20%. With the latest nightly, low battery warning came on just fine at 15%. "PBD" at 8%. First build flashed with battery below 90% (don't recall exact figure) and charger disconnected. Later flashes, following unsuccessful attempts at calibration, with charger connected and battery reported at 99-100%.

15% - 3600 mV

10% - 3335 mV

8% - ca. 2800 mV (?)

THEORY

CM7 is reporting percentages based on a starting point that is ca. 8% lower than the reported safe minimum voltage for these batteries (the maximum is also lower, mine's at ca. 4100 atm). Presumably, in my case, it was off by 20% before that and by ca 30% earlier still. The reference point must be stored outside all the android and linux kernel directories/files given that the "HC-fix" works even after the SD card is replaced. To my knowledge, that only leaves the files in the uboot package. This reference is either hardcoded or recalibrated from time to time (if the latter is not possible, then it must be the former, unless the "recalibration" takes place during replacement/update).

Does anything in the uboot package work with the nook's battery sensors?

The Nook charger doesn't always agree with android on whether or not the battery is at maximum capacity. How does the charger know?

Dal's kernels are overclocked and overvolted at some steps, iirc. If we use the regular old stock kernels at stock frequencies and no tricks, perhaps we can come even closer to a reported 0% without the omap SoC bugging out.

I'm hoping that my next flash, if done at 100% and with the charger connected, may take me below a reported 8%, but the problem remains that the zero point is far too low to be considered safe.

Okay, the last two paragraphs are probably complete tosh :o
[Nook Color Android Development] mutant13:
Yes I am running the 5-13-11 kernel, I like ondemand and so I just left it... I have not had much time to mess the Nook, been working alot, I will try the few fixes(PBD) suggested here and report back in the next few days....
[Nook Color Android Development] TJNooker:
I fixed the kernel mix up.

As for the mlo/u-boot, I didn't flash any of your custom u-boots/mlos, at least I don't think they were yours. After experiencing PBDs on whatever u-boot/mlo originally came with Dalingrin's Beta 3.1, I flashed the /boot from BN 1.2 which was posted in the CM7 Developers Thread here. I experienced PBDs on both the original u-boot/mlo (whatever came with Beta 3.1) and the BN 1.2 version.

This is news to me, but according to MedLine I'm still experiencing PBDs even though my Nook is shutting down at ~4-5%. Do you want me to fill out a form for my current set-up?

EDIT: Ok, paleh0rse broke it down for me. When I first started installed CM7.1 Beta 3.1 (Dal's build), I'm pretty sure I was using the u-boot & mlo from BN 1.1. After experiencing two PDBs, I flashed the u-boot & mlo from BN 1.2 which did not resolve this issue.

So I now understand and agree with your statement that the BN 1.1 vs. 1.2 u-boot/mlo is not a factor.
[Nook Color Android Development] Animec:
Is there any way to compare a complete dump of a system experiencing PBD with a clean just-compiled version?
[Nook Color Android Development] khaytsus:
PBD REPORT FORM

TEST CONFIGURATION:

BOOT DEVICE: eMMC

MLO: BN 1.2 built by fattire (MD5: a2c9a23efdbe05a40e0066500c5cfea1)

U-BOOT: BN 1.2 cyan build by fattire (MD5: c3db4062d1e67d50a382245471c1cef8)

KERNEL: uImage 2.6.32.9 from Nightly 86 (MD5: 9192c60a333c6ae32ab100c9eba16dca)

OVERCLOCKED?: No

GOVERNOR: Conservative

SYSTEM: CM7 Nightly 86

PBD: NO

TEST COUNT: 3x- once with stock 1.2.0 MLO/u-boot, once with "untimely" u-boot, once with cyan u-boot

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: NO

DID IT WORK? N/A

PREVIOUSLY INSTALLED:

☐ Stock 1.0

☑ Stock 1.1

☐ Stock 1.2

☐ Nookie Froyo (any)

☐ Honeycomb (any)

☑ CM7 2.29 (any)

☑ CM7 2.32 beta 3

☑ CM7 nightlies > 84 (or whenever .32 appeared)

Notes: So far I've ran it down 3 times (more probably) since going to .32, used the 2.6.32 Beta 3.1 for about a week. Both of those I was booted off SD using VeryGreen's awesome installer. I then installed to eMMC at Nightly 86 since the hour it was released. I've had no SOD, I've let it run down to 7% once, 10% once, last time I think was more around 12%.. Each time I was playing around with it watching to see what happened but it was late and needed to get to bed so I plugged it in. Given most people are seeing a 20% or more deviation, I'm assuming this is not a problem.

One interesting point.. I was using Dal's 5/23 OC kernel for about 4 days but was not overclocked, but I can't be sure I ran it down <15% when I was running it.

Something that would be interesting is seeing on a stock ROM the voltage vs percent from 100% to 0% in 1% steps. Battery Snap could record that data, and I think I've seen some others which do as well.

Also would be interesting to know where the battery percent comes from, and how it's determined. Generally the battery has nvram on it which has the battery stated capacity, last known capacity, probably other info.. In Linux this is generally found in /sys/class/power_supply/BAT0/status or such.

Another thing.. LiPo batteries are dead at 3V and full at 4.2V, and the discharge curve varies mostly based on temperature, not discharge rate. And generally it's pretty damn flat except at the beginning and particularly the end.

A graph of discharge curves based on temperatures... From google search.. Note that both of these indicate the capacity of the battery on a given charge, not voltages. They may or may not be directly related.

Graph of discharge rates.. Again, from google search..
[Nook Color Android Development] :
I think I reported the first one in the dev thread. I'll dig it up, but I shut down around 30
[Nook Color Android Development] :
Awesome work! So can we get b beta of this? I want that shutdown notification.l:-)
[Nook Color Android Development] TJNooker:
@MedLine

This is way over my head so forgive me if this is a stupid question. How certain are you that the battery voltages being recorded are accurate? Short of tearing a Nook open and hooking up a voltage meter, is there any way to be reasonably certain the voltages are on point?

I ask because if we drain our batteries too low on a modified BatteryServices.java and damage them we are SOL due to the Nook's lack of an easily removable battery.
[Nook Color Android Development] fr4nk1yn:
Sorry for my lack of documenting.

This has been driving me crazy. First happened last week while watching netflix.

I assumed the battery died but was confused when I plugged the nook in and it turned on with a reported 30% only to die minutes later after being unplugged.

Wiping stats did no good as well as restoring with nandroid back to 3.1 beta.

On CM7 #87, I cant write a bootable sd from OpenSuse for some reason at home, At work I created the hc sd, booted and went from 64% to 27%.

Rebooted into CM7 and it reads 27%.
[Nook Color Android Development] jared_c:
Power management chip and spec sheet

OK, according to this teardown:

http://www.chipworks.com/en/technic.../teardown-of-the-barnes-and-noble-nook-color/

Our power management chip is the TI TPS65921B.

Looking that up on the TI website here's the spec sheet and the application notes:

http://focus.ti.com/docs/prod/folders/print/tps65921.html

Haven't read them yet, but interestingly it has a "register manual", which may be the nuts and bolts info we need. What do you want to bet this is a driver issue?
[Nook Color Android Development] angomy:
No I didn't :\

Charged to 100%/4200mV and wiped battery and dalvik cache in CWR, going to see what happens when it gets low tonight. On the bright side, installed 5/23 OC kernel prior to wiping battery/cache and according to cpu spy it went to deep sleep for the entire time I put it to sleep, unlike other people who've been having issues with 5/23 kernel.
[Nook Color Android Development] jared_c:
...interesting...we're USB-OTG compliant...sorry, completely off topic
[Nook Color Android Development] Animec:
If I do a battery stat wipe in CWM shouldn't I see message confirming that it's worked?
[Nook Color Android Development] paleh0rse:
The PBDs seemed to arrive with the transition to .32 source -- I've personally had them since the first .32 beta.

Then again, since Medline pointed out that it's always supposed to shutdown gracefully at 0% -- per code -- perhaps we've had less severe cases (1-5%) for quite some time. Since I never ran the older .29 builds down that low, I never noticed. Maybe someone with a 7.02 stable SD could test?
[Nook Color Android Development] paleh0rse:
There were no uboot files included in the 3.1beta. If you didn't manually change uboot, then the 3.1 beta was using whatever you happened to have in place beforehand (likely stock 1.01, 1.1, or 1.2, depending on the highest stock version you had ever installed).

But, since simply adding 3.1 beta started your PDBs -- and mine -- then I would theorize that the problem lies somewhere in the base .32 port, not with any particular uboot.

Make sense?

I think the most interesting fact is that HC somehow "cures" this problem. Is there any particular section of battery-related code that we can compare between the HC build and n87? Also, has anyone confirmed whether or not the "HC Fix" is permanent? Does that cure also survive an n86 to n87 update?

Am I correct in assuming that the HC build does NOT include its own /boot partition?
[Nook Color Android Development] Ronin3178:
I actually believe it does.... I remember in the instructions for flashing eMMC v4 that it said to format boot also. I did that right after rooting my Nook back in March, and got the ANDROID_ for the boot screen after.

Read the Instructions http://xdaforums.com/showthread.php?t=947071
[Nook Color Android Development] jared_c:
OK, I've looked through the register manual, it doesn't look like it has a memory location on-chip to store things like depth of discharge, so that data must be stored somewhere else when we boot into HC then back into CM7.
[Nook Color Android Development] TJNooker:
Thanks, paleh0rse. I think I understand what you're saying now. I'll go back and edit my posts.
[Nook Color Android Development] paleh0rse:
Hmm... interesting, sure; but, since it's being run from SD when used to fix PBD, I still can't figure out how/why that could/would have any effect on the emmc boot partition (or any other emmc partition, for that matter).
[Nook Color Android Development] TJNooker:
PBD REPORT FORM

TEST CONFIGURATION #1

BOOT DEVICE: eMMC

MLO: BN 1.1 stock

U-BOOT: BN 1.1 stock

KERNEL: Dalingrin's 2.6.32 (5/13) OC kernel

OVERCLOCKED?: to 1100

GOVERNOR: Smartass

SYSTEM: CM7.1 Beta 3.1 by Dalingrin

PBD: YES

TEST COUNT: 2x; first PBD at 30%; second PBD at 27%

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: YES

DID IT WORK? NO

PREVIOUSLY INSTALLED:

Stock 1.0

Stock 1.1

Rooted 1.1

Nookie Froyo (any)

CM7 2.29 (any)

--------------------

TEST CONFIGURATION #2

BOOT DEVICE: eMMC

MLO: BN 1.2 stock

U-BOOT: BN 1.2 stock

KERNEL: Dalingrin's 2.6.32 (5/13) OC kernel

OVERCLOCKED?: to 1100

GOVERNOR: Smartass

SYSTEM: CM7.1 Beta 3.1 by Dalingrin

PBD: YES

TEST COUNT: 2x; first PBD at 16%; second at 13%

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: YES

DID IT WORK? NO

PREVIOUSLY INSTALLED:

Stock 1.0

Stock 1.1

Rooted 1.1

Nookie Froyo (any)

CM7 2.29 (any)

CM7 2.32 beta 3.1

--------------------

TEST CONFIGURATION #3

BOOT DEVICE: eMMC

MLO: BN 1.2 stock

U-BOOT: BN 1.2 stock

KERNEL: Dalingrin's 2.6.32 (5/23) OC kernel

OVERCLOCKED?: to 1100

GOVERNOR: Conservative

SYSTEM: CM7 Nightly 86

PBD: YES

TEST COUNT: 2x; first PBD at 5%; second at 4%

TRIED REVERTING TO OLDER HC/CM7: NO

TRIED WIPING CACHE/DATA?: YES

DID IT WORK? NO

PREVIOUSLY INSTALLED:

Stock 1.0

Stock 1.1

Rooted 1.1

Nookie Froyo (any)

CM7 2.29 (any)

CM7 2.32 beta 3.1

Stock 1.2

CM7 nightlies >84

NOTES: I used battery calibration after each of the three set-ups above. As you can see, the battery level at which PBD occurred lowered with each set-up. With Nightly 86, my PBDs are at a very low battery percentage. I cannot say for sure why that is. It could be battery calibration or it could easily be something else.

FWIW: Before flashing nightly 86, I wiped everything except /boot and flashed BN 1.2 Stock. Then I flashed n86 + gapps + OC kernel 5/23.
[Nook Color Android Development] jared_c:
Spec sheet review: Using Power IC for OMAP34xx to 36xx Family

Possible culprit:

The OMAP36xx family MPU can operate at up to 1 GHz. These new use cases increase 36xx current requirement. This document describes how to use the power IC with an OMAP36xx at 1 GHz.

Original device name: TPS65921B (VDD1 at 1.2A)

New device name: TPS65921B1 (VDD1 at 1.4A)

We apparently have the original device.

There are also changes required to the external schematic, i.e. more and bigger capacitors, and a larger inductor.

It may be that overclocking while using this chip is a bad idea...more details to follow...
[Nook Color Android Development] I Am Marino:
What would be the excuse then for those not having PBD.

Still rocking the Incredible with the XDA Premium App.
[Nook Color Android Development] Narfx:
Ok, this is weird. After running HC from the SD card and correcting the battery percentage (it went from 62 to 42), it's getting wrong again :confused:. While I was using it after the calibration, it was going down steadily (from 42 to 31). But I put it to sleep for one hour, and when I woke it up the percentage was 35!! I thought I was seeing things, but the battery graph confirms it: every time I put the nook to sleep for a while, the battery percentage GOES UP.

It's funny seeing the graph go up while the "Charging" graph is empty...
[Nook Color Android Development] crandy2:
One thing I haven't seen tracked or discussed is the number of sleep and resume cycles from a full charge to a PBD. Either a count or an estimate.

The only PBD I have had was before this thread started, I was running A nightly, it was probably 82. What was different for me was not so much the bootloader - build - kernel combo, but the fact that it was the only time I have made it two full days on a charge. During that time, I had more times where it went into and out of sleep than any other day, and sure enough, I got a PBD at 35%.

Maybe there is some calculation that is associated with going into or out of sleep that is just a little off, and the more cycles you have, the worse it gets.
[Nook Color Android Development] derekr:
I think Narfx and Crandy2 may be saying the same thing and maybe on to something. I'm going to start before and after sleep monitoring...
[Nook Color Android Development] jared_c:
Honestly, I haven't got a clue...I just figure that if other people are busy looking at the software and seem to be stumped then maybe it's something in the hardware that we've overlooked in our haste to track down the bug. I've seen too many software bugs turn out to be hardware bugs to just accept the hardware as perfect. And besides, I can puzzle through the spec sheets just as fast as the next guy, while if I start poking around in the code I'm just going to make myself look foolish.
[Nook Color Android Development] I Am Marino:
I'm thinking the deep sleep issue has something to do with this.

Still rocking the Incredible with the XDA Premium App.
[Nook Color Android Development] crandy2:
Yes, I had a lot of deep sleep before the PBD.
[Nook Color Android Development] deadbot1:
In the overclocking world, not all chips are created equal. Likely some are just a bit more stable. The part that really throws it off track is that PBD happens to non OC systems.
[Nook Color Android Development] verygreen:
I guess I can chime in a bit here too.

I did a diff on he kernel battery driver between the original .29 driver and the new one in .32.

About the only difference is the way temperature is calculated.

Now the u-boot init is measurably more different. Battery-reported values are put under much more scrutiny and if the new more strict constraints are not met, the entire previous history is thrown out (there is a special message that is printed in this case that you only see if you have serial console or a special u-boot that outputs messages to the screen).

Also some more battery registers are initialized in the new u-boot.

Originally I planned to produce a version of 1.2 u-boot with the checks relaxed back to 1.1 levels, but if it is confirmed that 1.1 u-boot had the same problem, perhaps it's not worth it.

One more difference with .29 and .32 kernels is in the cpu init, the opp l3 table is setup for 1ghz case. (and the new u-boot also inits the memory to 200Mhz instead of the old 166Mhz speed apparently)
[Nook Color Android Development] :
The more I think about it, the more I think it may be the 2.3.4 base.

Seeing how I went from nightly +1.1 bl to 1.2 b&n bl, which gave me the PBD (around 30%). Went back to full stock 1.2 after wiping everything on all partitions (inc. boot), let it die (gave me a 15% warning and a shutting down warning), then install beta and 5/23 kernel. Now get PBD ~4%.

Then again, some people report this happening on phiremod roms (2.3.3 base), but let's just ignore those guys :P
[Nook Color Android Development] basrawi:
Deleted....
[Nook Color Android Development] angomy:
Well, I got a worse PBD today. Nook died at 43% (3913 mV, temp: 27C) after I had charged to 100% and wiped battery and caches in CWR. Would not turn on without being plugged in.

Running fattire cyan boot 1.2, nightly 87 with 05/23/2011 OC kernel @ 1200 Mhz. I had been running videos and games all day to run down the battery and it died while in deep sleep sometime after I stopped at 51%. :(
[Nook Color Android Development] TheMainCat:
Interesting. Running the same as you and I haven't had a PBD since I reset my device back to the B&N 1.2 ROM (CWM version). My Nook is currently at 21% and I fully expect to get the low battery warning at the 15% mark. After that it will drop dead around the 3%-4% mark. The only thing I am seeing now is that the battery seems to run down faster. Could just be my imagination.:confused:
[Nook Color Android Development] jared_c:
git tree

I guess I have to go grab the git tree to really look this up, but it looks like there's an analog to digital converter on the TI chip that I would guess is the one that's used to measure the voltage of the battery. Verygreen, since you've looked over the driver, do you know if it is measuring the battery voltage to estimate state of charge, or is it counting coulombs? Coulomb counting is usually more accurate, but it needs some sort of current sensor...I'm going to go stare at the pictures from that teardown again and try to see if there's any obvious current sensor setups there. They usually have a sense resistor and a very small voltage booster in order to send the voltages over to the A-to-D.

If it's using raw voltages then there's something that's just not connecting in software, as the data from a number of people is showing that the voltages don't correspond to % charge at all.