[CM7] Help Track Down PBD (premature battery death)

Search This thread

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
WHAT IS PBD?

Some have reported issues with recent CM7 builds > 86 and premature battery death. This is being called PBD ("Premature Battery Death"). The main feature is a sudden loss of power at 30% or less without any warning.

Associated symptoms may include misreporting battery charge, where it suddenly jumps up (or down) 20% or more.

To get a hold on what might be the cause, let's collect info on whether people are having problems and with what configuration. Maybe we can figure this out together. For example, maybe everyone who's experiencing this problem is using the same combination of system/kernel, or maybe a certain configuration or procedure may make it go away.

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?: to 925
GOVERNOR: Performance
SYSTEM: CM7 Nightly 86
PBD: NO
TEST COUNT: 2x- once with "untimely" u-boot. Which should be functionally the same. Both did not have BPD
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: I did have premature-battery death a week ago with the b3 system, the original 1.0 u-boot & MLO (built from BN source), and an overclocked kernel. Can't remember which one. Here is an image of 3% battery from Tues night (5/24/11).

snap20110525005905.png


THEORY

If you have a theory on what's going on, put it here.
 
Last edited:

GabbleRatchet

Senior Member
Dec 1, 2010
66
14
Katy, TX
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?: to 1200
GOVERNOR: Conservative
SYSTEM: CM7 Nightly 86
PBD: NO
TEST COUNT: Twice with current setup, each time nc shut off at 2%. Working on 3rd test now.

TRIED REVERTING TO OLDER HC/CM7: NO
TRIED WIPING CACHE/DATA?: NO
DID IT WORK? N/A
PREVIOUSLY INSTALLED: All of the below at least once

☑ 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: I HAD PDB starting the night beta 3.1 was released. Shut down at 21% every time on every build from beta 3.1 through nightly 85. This plagued me through multiple data/system/cache wipes, different kernels, etc. When I went to do my full wipe for n86, I made a rookie mistake & formatted something I wasn't supposed to. The road to recovery led me to restore stock 1.0.1, upgrade to stock 1.2, ManualNooter, install clockwork recovery, full wipe, then install my current configuration. (I know, in a perfect world, that was way unnecessary, but I was at work & those were the only files I had access to. On the bright side, I was on the clock while doing this. Sorry boss.) I know others have had success flashing stock, discharging, charging fully, and back to cm7. I did not discharge & charge. I did all of this with about 60% battery, & on that charge I made it to 2% for the first time since .32 beta 1.

EDIT: I also wiped battery stats while flashing at full charge to try & fix. No dice there.
 
A

ace7196

Guest
PBD REPORT FORM

TEST CONFIGURATION:

BOOT DEVICE: eMMC
MLO: BN 1.2 built by fattire
U-BOOT: BN 1.2 cyan build by fattire
KERNEL: uImage 2.6.32.9 from 5/23 OC kernel
OVERCLOCKED?: 1.2 GHz
GOVERNOR: conservative
SYSTEM: CM7 beta 3.1
PBD: YES*
TEST COUNT: 3x*
TRIED REVERTING TO OLDER HC/CM7: YES*
TRIED WIPING CACHE/DATA?: YES
DID IT WORK? N/A
PREVIOUSLY INSTALLED:

☑ Stock 1.1
☑ Stock 1.2
☑ CM7 2.29 (any)
☑ CM7 2.32 beta 3

NOTES: Installed beta 3.1, updated bootloader 1.2 grabbed from stock image (after wiping EVERYTHING [cache, boot, system, data, dalvik]). Upon flashing 1.2 and letting battery run down to 2x%, had PBD. Repeated twice more.

I FIXED IT by flashing full 1.2 stock, running battery down until it shutdown (~4%), then flashed fresh copy of beta, 5/13 kernel. Fixed it. Since then I get down to 3%, and this is after installing the cyan edition of fattire's bootloader.

Something in the stock 1.2 is not being carried over.
 

mutant13

Senior Member
Dec 27, 2010
1,338
1,064
RALEIGH
I know this said cm7(im on stock withMN) but... it happened to me just last night @ 20% very strange

BOOT DEVICE: eMMC
MLO: BN 1.2stock(MN 27)
U-BOOT: BN 1.2 stock
KERNEL: emmc 2.6.32.9 from 5/13 OC kernel
OVERCLOCKED?: 1.2 GHz
GOVERNOR: ondemand
SYSTEM:stock froyo bn1.2
PBD: YES*
TEST COUNT: 1x*
TRIED REVERTING TO OLDER nope*
TRIED WIPING CACHE/DATA?: nope
DID IT WORK? N/A
PREVIOUSLY INSTALLED:1.0.1 AN
 

dim_adr

New member
May 24, 2005
1
0
PBD report

PBD REPORT FORM

TEST CONFIGURATION:

BOOT DEVICE: eMMC
MLO: BN 1.2 built by fattire
U-BOOT: BN 1.2 cyan build by fattire
KERNEL: uImage 2.6.32.9 from 5/13 OC kernel
OVERCLOCKED?: 1.2 GHz
GOVERNOR: smartass
SYSTEM: CM7 beta 3.1
PBD: NO
TEST COUNT: 2x
TRIED REVERTING TO OLDER HC/CM7: NO
TRIED WIPING BATTERY STATS?: YES
DID IT WORK? YES
PREVIOUSLY INSTALLED:

☑ Stock 1.2
☑ CM7 2.29 (any)
☑ CM7 2.32 beta 3

NOTES:

Contrary to public belief that PDB only occured in latest CM7 nightly/beta, I first experienced PDB in phiremod6.2 (based on CM 7.0.2) using dalingrin's OC kernel 04/24 when NC suddenly died at batt level 30%. I noticed that when connected to USB, the battery level suddenly jumped from >70% level to full 100% (it didnt jump when batter level is below 70%. It ). I strongly believe this causes PDB, as the battery calibration is incorrect.

I solved the incorrect battery indicator by wiping battery stats in CWM recovery boot from SD card (Wiping battery stats from CWM recovery in eMMC did not work for me). It worked and NC showed correct battery indicators. I regularly wipe battery stats whenever I encountered jump in battery indicator and I did not experience PBD.

This week I flashed CM7 2.32 beta 3.1 with OC kernel 2.6.32.9 from 5/13. I still consistenly encountered battery indicator jump when connected to USB (always) and power adapter (seldom). I always wipe my battery stats after that, and until now have not experienced PBD. I managed to use my NC until 6% yesterday when I decided to charge it. To be honest, it's quite painful to wipe battery stats everytime battery level jumped to 100%.

I think this PBD is caused by incorrect battery indicator level when connected to USB/power adapter, my opinion.
 

greenmky

Senior Member
Aug 4, 2010
129
7
Midland, MI
I went from stock 1.2 -> CM7.0.2 stable -> CM nightly 87

BOOT DEVICE: eMMC
MLO: ?
U-BOOT: stock B&N 1.2 (I think? unless nightly 87 messed with it?)
KERNEL: .32
OVERCLOCKED?: to 1.1
GOVERNOR: Conservative
SYSTEM: CM7 Nightly 87 / OC Kernel 5/23
TEST COUNT: 1x
PBD: Died at under 4%. I don't think that counts, frankly - so I would so no problem here. I didn't see any funky percentage jumps either.
 
Last edited:

skwalas

Senior Member
Feb 22, 2011
259
56
Fattire, in the 1.2 update zip, there's a separate sub-zip labeled "charger". The updater script for that particular zip has a series of flags (0, 1, and 10) that appear to direct how the update will work based on the battery level when starting the update. Now, I've seen those flags elsewhere in the larger update zip and use in ways that don't appear to relate to installing the update directly. So, I am wondering if there is some call to a procedure that has been missed when isolating the uboot and mlo? Something that requires those flags to properly initiate certain activities when the battery hits milestones like 15%? But don't work properly if the flags or calls or whatever are absent?
 

Gin1212

Senior Member
Jan 26, 2011
344
34
I think this PBD is caused by incorrect battery indicator level when connected to USB/power adapter, my opinion.

I have never received PBD (don't get excited) because I've never let my battery hit under 30% because of all of the reports.

However, last night for the first time ever, I couldn't be bother to get out the adapter for the usb cable, so I just let the computer charge it all night.

Well, I'm a Sub. Teacher and I find on certain days I have a lot of time to read books, so I turn off the wifi and lower the display brightness and get excellent battery. There are days that I spend just reading (8hrs), and I get only as low as 60-80% depending on how heavy I really get to read or if I'm reading something like manga.

Today however, I subbed for a Kindergarten class that did not let me read pretty much at all and by the end of the day I only had like 55% battery with 3 of the 8hrs being heavy reading of a pdf. (The other 5hrs the Nook wasn't even turned on for a second.)

What's my point? I barely touched my nook, and yet had 55% battery by the end of the day with very low display brightness and no wifi. No games were played, and I really only used Adobe Reader and Ezpdf reader.

Hell, I had a Snesoid/Gbaoid day the other day (almost all day because the kids had a field day and I was left with a small group of kids doing independent work) and still only hit 55-60% by the end of that day.

So just my thoughts on "Usb Charging" over the Wall socket charging.

Edit: My settings are N86 OC (5-23) (300/1200 Conservative)
Edit 2: I am now seeing reports of heavy battery usage issues in the CM7 Dev thread, so it may be even possible that it's just using up a ridiculous amount of battery as well... However, that seemed like quite a bit for only 3hrs of real use.
 
Last edited:

skwalas

Senior Member
Feb 22, 2011
259
56
Well I'll be damned. It is for sure a calibration issue. Somebody Googled these batteries and read that they could not go below 3050 mv safely. I got pbd repeatedly just a few minutes ago at 20%... and 3000 mv.

Put the charger in and juiced it up a couple percent (showed 3600mv with charger in), unplugged, and let it run down again. Shutoff at 20% and 3000mv. I was able to replicate this multiple times. I already know that my 100% of scale is always right around 4200mv so it seems as if the 0% of scale is out of alignment.

How to recal the 0%?
 

keyodi

Senior Member
Feb 3, 2011
133
476
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 OC 5/23
OVERCLOCKED?: to 1200
GOVERNOR: Conservative
SYSTEM: CM7 Nightly 86
PBD: NO
TEST COUNT: 2x- once with "untimely" u-boot and once with "cyan". Each time nc shut off at ~4%
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: I have dualboot setup on my nook with stock 1.2 installed on parts 9/10. Installation steps: Formatted /system(ext2), /data(ext2) and /cache, Installed stock 1.0.1 then updated to 1.2, setup dualboot partitions, moved 1.2 to dual boot parts, formatted /system(ext4), /data(ext4) and /cache, then restored CM from backup. I often switch between CM7 and 1.2.
 
Last edited:

I Am Marino

Senior Member
Mar 13, 2011
4,082
554
Winston-Salem, NC
BOOT DEVICE: eMMC
MLO: ?
U-BOOT: Whatever came with N87
KERNEL: 2.6.32.9 OC 5/23
OVERCLOCKED?: 1200
GOVERNOR: Conservative
SYSTEM: CM7 N87
PBD: No
TEST COUNT: 1x
TRIED REVERTING TO OLDER HC/CM7: No
TRIED WIPING CACHE/DATA?: No
DID IT WORK? N/A
PREVIOUSLY INSTALLED:

CM 7.0.3 Stable.
Stock 1.1

EDIT + NOTES: Battery finally died at 4%. I went near or below 3,000mv when it happened.
I had 13% with 3606mv. Voltage started free falling once I hit under 5% battery, I watched it go from around 3400 to 3060 all within the 4% range, right before it died, was trying to screencap when it died on me. I was a little over 12 hours off charger, I took it off at 96%-ish.
It seems 3000 to 3050mv is that cutoff point.
 
Last edited:

Narfx

Senior Member
Jul 23, 2010
227
13
A Coruña
Well I'll be damned. It is for sure a calibration issue. Somebody Googled these batteries and read that they could not go below 3050 mv safely. I got pbd repeatedly just a few minutes ago at 20%... and 3000 mv.

Put the charger in and juiced it up a couple percent (showed 3600mv with charger in), unplugged, and let it run down again. Shutoff at 20% and 3000mv. I was able to replicate this multiple times. I already know that my 100% of scale is always right around 4200mv so it seems as if the 0% of scale is out of alignment.

How to recal the 0%?
Yep, my pbd happened at ~3-3.2V. Seeing as some people are reporting only ~10%-20% at ~3.6V, seems like our batteries were SEVERELY depleted. I hope they were not damaged because of that :/

I'm letting it run down now. Will post my u-boot, MLO et al. when/if it reaches 3.3V.
 

Animec

Senior Member
Jan 9, 2011
109
6
This is odd, my 100% is now right around 4000 mV and I know for sure it's been closer to 4200 before :/
 

sinanju

Senior Member
Mar 13, 2006
337
87
This is odd, my 100% is now right around 4000 mV and I know for sure it's been closer to 4200 before :/

I have noticed that the meter will read 100% a while before the "n" light on the cable will go green, further pointing to a calibration issue. Perhaps that's your case?
 

Ronin3178

Senior Member
Oct 26, 2010
505
65
I think it would help if people starting finding our their voltages when or near their battery dies. Seems to be a pattern developing.

Here ya go, I got down to 4%, went to plug it in, and it shut down right before I got there. I got a screenshot of the 3041mV I believe. When my Nook comes back on (showing the charge screen right now) I will upload the shots.

Here is the datapoints I got 18-4%


18% 3568
17% 3573, 3566
16% 3563
15% 3538
14% 3562
13% 3557
12% 3565
11% 3505
10% 3508
9% 3501
8% 3499,3490
7% 3482,3475
6% 3390,3382,3356,3336,3321,3302
5% 3279,3256,3232,3198,3158,3123,3101
4% 3101,3041

A majority of this was sitting at battery booster screen watching at full brightness and with screen timeout set to never, so the cpu was pretty much idle.
 

Attachments

  • 3158mV.jpg
    3158mV.jpg
    36.1 KB · Views: 323
  • 3041mV.jpg
    3041mV.jpg
    36.2 KB · Views: 291
Last edited:

derekr

Senior Member
Mar 1, 2011
176
21
Boston
It's real scary (and it's not Halloween!) I just finished a battery discharge test where I monitored the voltage and percentage as the battery was used up. The plot as a pdf is below:

http://dl.dropbox.com/u/22355237/NookBattery.pdf

Look at the rapid drop-off in voltage below 40% to 2860 mV at an indicated 34%. No wonder we are seeing PBD if others have the same problem!

I was watching the voltage drop before my eyes. I actually shut it down at the 2860 mV, and I can't turn it on again (I'm at work) - no charger.

Something is very wrong with the calibration... At an indicated 34% the battery is dead, deceased, gonzo, perished, pushing up daisies......

Edit: n87 - OC523 - data taken with Circle Battery widget.
If you can't see the plot - here's the data:
86 3917
84 3886
79 3839
76 3795
70 3758
67 3751
58 3696
46 3639
40 3604
37 3556
35 3503
34 3271
34 3172
34 2861
 
Last edited:

Ronin3178

Senior Member
Oct 26, 2010
505
65
It's real scary (and it's not Halloween!) I just finished a battery discharge test where I monitored the voltage and percentage as the battery was used up. The plot as a pdf is below:

http://dl.dropbox.com/u/22355237/NookBattery.pdf

Look at the rapid drop-off in voltage below 40% to 2860 mV at an indicated 34%. No wonder we are seeing PBD if others have the same problem!

I was watching the voltage drop before my eyes. I actually shut it down at the 2860 mV, and I can't turn it on again (I'm at work) - no charger.

Something is very wrong with the calibration... At an indicated 34% the battery is dead, deceased, gonzo, perished, pushing up daisies......

Edit: n87 - OC523 - data taken with Circle Battery widget.
If you can't see the plot - here's the data:
86 3917
84 3886
79 3839
76 3795
70 3758
67 3751
58 3696
46 3639
40 3604
37 3556
35 3503
34 3271
34 3172
34 2861

If you look at my post above yours, yeah, def a calibration issue, mine dropped out @ 4% 3041mV

ps, I would switch axis on the graph 0-100% bottom to top, 4000mV to 2400mV left to right
 
Last edited:

derekr

Senior Member
Mar 1, 2011
176
21
Boston
If you look at my post above yours, yeah, def a calibration issue, mine dropped out @ 4% 3041mV

ps, I would switch axis on the graph 0-100% bottom to top, 4000mV to 2400mV left to right

As you wish :D :
http://dl.dropbox.com/u/22355237/NookBattery2.pdf

however, let's discuss this over a beer sometime - which is the independent variable here? I think the first plot shows the precipitous voltage drop-off in a more graphic fashion... But, as always, your wish is my command :D

BTW - MATLAB won't let me (simply) reverse the x-axis order...
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    A theory... (warning: technical)

    One of the source files for the u-boot (max17042.c) reads data from a file called max17042.bin, which is located on the 2nd partition (mmcblk0p2). Does this file also record battery stats? It may explain why the battery percentages change when booting with different roms.

    Additional info: It seems the file(max17042.bin) only gets updated when I boot with BN 1.2, but not when booting to CM(N86)...Maybe something in CM7 is preventing access to partition mmcblk0p2 in order to correctly update the file????

    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:

    Code:
    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:

    Code:
    // 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.
    6
    One of the source files for the u-boot (max17042.c) reads data from a file called max17042.bin, which is located on the 2nd partition (mmcblk0p2). Does this file also record battery stats? It may explain why the battery percentages change when booting with different roms.

    Additional info: It seems the file(max17042.bin) only gets updated when I boot with BN 1.2, but not when booting to CM(N86)...Maybe something in CM7 is preventing access to partition mmcblk0p2 in order to correctly update the file????
    4
    To update, the fix for this issue has been submitted for review by FatTire. Hopefully will be in the next nightly.
    2
    PBD REPORT FORM

    TEST CONFIGURATION:
    BOOT DEVICE: eMMC
    MLO: BN 1.2 stock
    U-BOOT: BN 1.2 from Nightly 86
    KERNEL: uImage 2.6.32.9 from Nightly 86
    OVERCLOCKED?: to 1200/300
    GOVERNOR: Conservative
    SYSTEM: CM7 Nightly 86
    PBD: NO
    TEST COUNT: 3x
    TRIED REVERTING TO OLDER HC/CM7: YES
    TRIED WIPING CACHE/DATA?: NO
    DID IT WORK? YES
    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: I don't have an explanation for PBD, but I've done some testing today and maybe can offer some useful observations. I had PBD as described here, which resolved after round-tripping through an SD installation of CM7 beta 3 as described here and here, reminiscent of what others had reported booting through HC, and it has not recurred since. Here are my observations:

    1. Technically, if you didn't drain to a reported battery level < 1%, you've had a PBD. That means most everybody who has posted here so far. This is because AFAIK, there are only 2 parameters for graceful low-power shutdown: battery level = 0%, and battery temperature > 68C. These are defined in "frameworks/base/services/java/com/android/server/BatteryService.java", viewed here at CM7 github. Basically you're getting PBD because battery level calibration is off and the Nook never reports a 0%. Even if your Nook died at 3% or 4%, it's still a PBD.

    For illustration, I've ran down my battery twice today, with Battery Monitor Widget reports posted at pastebin here and here, showing that I reached 0% (< 1%) at 3250mV and 3400mV. Importantly, rather than abrupt shutdown I got a "Power Off" warning dialog. This was accompanied by a logcat posted here that looked like a normal shutdown sequence. Some salient features from the logcat, obtained by issuing in terminal "logcat > /mnt/sdcard/logcat.txt" before shutdown and retrieved at reboot, are as follows:

    Code:
    I/ActivityManager( 1043): Starting: Intent { act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras) } from pid 1043
    I/ShutdownActivity( 1043): onCreate(): confirm=false
    D/ShutdownThread( 1043): Notifying thread to start radio shutdown
    I/ShutdownThread( 1043): Sending shutdown broadcast...
    I/ShutdownThread( 1043): Shutting down activity manager...
    I/UsageStats( 1043): Writing usage stats before shutdown...
    W/BatteryStats( 1043): Writing battery stats before shutdown...
    I/ShutdownThread( 1043): Radio and Bluetooth shutdown complete.
    I/ShutdownThread( 1043): Shutting down MountService
    2. If you didn't get this shutdown sequence and died at ~3000mV, does that mean that your Nook died fully discharged? I think so. To test this I removed the "shutdownIfNoPower" function from BatteryServices.java and recompiled CM7 from source as per the wiki, syncing the repo up to "settings: Updated Italian translations" and flashed to verygreen 1.2.1 SD. I ran down the battery and the Battery Monitor Widget report is posted here. I hit 0% at ~3350mV but, with no shutdownIfNoPower call, it kept going and didn't shut down until 6 minutes later at ~3050mV, abruptly and with no warning. Logcat, posted here, was similar to what sinanju had reported, stopping in the middle of garbage collection with no prior shutdown intent. To me this suggests that my Nook lost all battery power and just died at ~3050mV.

    3. In summary, I think PBD is widespread and looks to involve BN1.2 stock (all of you going that workaround route and shutting down at 4%) as well as CM7 (phiremod as well as 2.6.32). This is if you consider anything other than drain to a reported level of 0% and graceful shutdown a PBD, which we should, because that's how Android low-power shutdown was coded.

    THEORY: Obviously there's a problem in translation between voltage and current drain with calculated battery level, but in my research I've come up against a blank wall. This is an area that looks exceptionally well undocumented. I'm sure the CM7 devs will come up with a solution, but in the meantime I think everybody who gets PBD is shutting down with a fully discharged battery. This may not be desirable, and difficult to avoid when it hits unexpectedly at 20-30%. An immediate workaround is to add a function to shutdown for low voltage, ala what this fellow suggested here. I've tested one implementation of this by modifying the BatteryServices.java file, as shown posted here, and recompiled CM7 from source and flashed to SD. Basically I added the following:
    Code:
        private final void shutdownIfLowVoltage() {
            // shut down gracefully if our battery voltage is critically low and we are not powered.
            // wait until the system has booted before attempting to display the shutdown dialog.
            if (mBatteryVoltage < 3500 && !isPowered() && ActivityManagerNative.isSystemReady()) {
    	    Intent intent = new Intent(Intent.ACTION_REQUEST_SHUTDOWN);
                intent.putExtra(Intent.EXTRA_KEY_CONFIRM, false);
                intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
                mContext.startActivity(intent);
    A battery rundown with this custom CM7 build showed that graceful shutdown occurred after the voltage dropped to < 3500 mV, as intended, with battery level still 7%. Battery Monitor Widget report and logcat posted here and here. In existing installs, I think a modified /system/framework/sevices.jar file can achieve the same thing. Something like this should allow everybody to at least gracefully shutdown before complete battery discharge. In practice, a shutdown threshold of 3200mV might be more reasonable.

    hth
    1
    While the approach effective, the point is to determine a resolution that doesn't require a ROM hokey pokey and get it into an update.

    Completely understood. Having the additional circumstantial evidence may help establish a pattern and/or point toward the root cause if it proves too difficult to ascertain anything via a debugger.