Topic: CHB won't fully boot after battery has lost it's charge

The Chumby Hacker Board goes into state in which it will not stay on if you do the following steps:
1) Attach 3.7v Lithium Ion Polymer battery to battery port
2) Power CHB with 5v regulated AC adapter
3) Once CHB has fully booted, unplug power from the 5v AC adapter
4) Let CHB run from the 3.7v battery until it shuts itself down completely... I let the CHB sit overnight to get this to happen.

At this point, the CHB is in a state in which it will boot, but it will shut itself down after it completes it's boot process. A log of this is pasted below. I have attempted to boot the CHB with the uncharged battery, with a fully charged battery, and with no battery, and in all cases, I get the same results.

I am going to assume that this is a software problem. I have found some battery-related scripts, but I not found where the logic is located that causes this shutdown.

What I have learned so far is:
a) You can query the battery state by "cat"ing the contents of the files in /sys/class/power_supply/battery/
b) The script "/usr/chumby/scripts/power_state_changed.sh" is related, but I don't think it is the culprit.
c) The battery driver is "stmp3xxx-battery"

My next step is to start looking at the boot scripts and the battery driver code, but if anyone can save me some time by pointing me in the right direction, I would appreciate it.

Thanks!

The following is the boot log:
======================
boot> linux 0x40008000 "console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p2 rootfstype=ext3 ro rootwait chumbyrev=** ssp1=mmc sysrq_always_enabled logo.brand=BBBBBBBBBBBB"
Going to run linux at offset 0x40008000 with cmdline console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p2 rootfstype=ext3 ro rootwait chumbyrev=09 ssp1=mmc sysrq_always_enabled logo.brand=chumby
Uncompressing Linux.............................................................................................................................................. done, booting the kernel.
[    0.000000] Linux version 2.6.28-chumby (builder@stormbuild) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #302 PREEMPT Wed Jul 28 14:40:46 PDT 2010
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: STMP378X
<snip>
[    0.300000] regulator: core version 0.5
[    0.300000] NET: Registered protocol family 16
[    0.320000] regulator: vddd: 800 <--> 1575 mV fast normal
[    0.330000] regulator: vddd_bo: 800 <--> 1575 mV fast normal
[    0.330000] regulator: vdda: 1500 <--> 2275 mV fast normal
[    0.340000] regulator: vddio: 2800 <--> 3575 mV fast normal
[    0.340000] regulator: overall_current: 0 <--> 2147483 mA fast normal
[    0.350000] regulator: stmp3xxx-fb-1: 0 <--> 2147483 mA fast normal
[    0.350000] regulator: stmp3xxx-bl-1: 0 <--> 2147483 mA fast normal
[    0.360000] regulator: stmp3xxx_ts-1: 0 <--> 2147483 mA fast normal
[    0.360000] regulator: stmp37xx-dbguart-1: 0 <--> 2147483 mA fast normal
[    0.370000] regulator: stmp3xxx_wdt-1: 0 <--> 2147483 mA fast normal
[    0.370000] regulator: stmp3xxx-rtc-1: 0 <--> 2147483 mA fast normal
[    0.380000] regulator: stmp3xxx-rotdec-1: 0 <--> 2147483 mA fast normal
[    0.380000] regulator: i2c_stmp-1: 0 <--> 2147483 mA fast normal
[    0.390000] regulator: stmp3xxx-persistent-1: 0 <--> 2147483 mA fast normal
[    0.390000] regulator: stmp3xxx-dcp-1: 0 <--> 2147483 mA fast normal
[    0.400000] regulator: stmp3xxx-battery-1: 0 <--> 2147483 mA fast normal
[    0.400000] regulator: mmc_ssp-1: 0 <--> 2147483 mA fast normal
[    0.410000] regulator: mmc_ssp-2: 0 <--> 2147483 mA fast normal
[    0.410000] regulator: charger-1: 0 <--> 2147483 mA fast normal
[    0.420000] regulator: power-test-1: 0 <--> 2147483 mA fast normal
[    0.420000] regulator: cpufreq-1: 0 <--> 2147483 mA fast normal
[    0.430000] stmp378x_devb.c - stmp378x_devb_init():388 - Adding 15 platform-specific devices
<snip>
[    1.060000] STMP3xxx RTC driver v1.0 hardware v2.0.0
[    1.070000] stmp3xxx-rtc stmp3xxx-rtc: rtc core: registered stmp3xxx-rtc as rtc0
[    1.090000] ddi_bc_Init: success
[    1.090000] stmp3xxx-battery stmp3xxx-battery.0: bc_sm_restart: no battery present
[    1.100000] power/linux.c - bc_sm_restart():982 - Returning from sm_restart()
[    1.430000] stmp3xxx-dcp stmp3xxx-dcp: DCP crypto enabled.!
<snip>
Parsing /etc/init.d/linuxrc.config
<snip>
Starting /sbin/init (cwd=/) (envcount=15)
<snip>
Portions copyright (C) 2005-2010 Chumby Industries, Inc.
Built for: falconwing; Features: Video ALSA ARM-optimizations
Build time: Wed 28Jul2010 1454
GetRegisteredInstancePid(/var/run/chumbyflashplayer.pid) returned 0 - no other instance is running
rcS completed at Wed Dec 31 16:00:46 PST 1969
killall: ntpd: no process killed
umount: none busy - remounted read-only
umount: can't remount none read-only
umount: /etc/mtab: No such file or directory
umount: tmpfs busy - remounted read-only
umount: /etc/mtab: No such file or directory
umount: /etc/mtab: No such file or directory

The system is going down NOW!

Sent SIGTERM to all processes

Sent SIGKILL to all processes

Requesting system poweroff
[   54.980000] power/linux.c - stmp3xxx_bat_shutdown():1450 - Not shutting down battery.  Letting the battery charger run.
[   55.000000] Power down.
[   55.000000] >>> Detected power switch pressed.  Turning off.
[   55.000000] >>> A note to those of you watching at home:
[   55.010000] >>> We're going to kill all processes and unmount all filesystems.
[   55.020000] >>> Then we'll sit here charging the battery.
[   55.020000] >>> If you press the power button again, we'll reboot.
[   55.030000] >>> If you unplug this device, we'll power off for real.
[   55.030000] >>> But for now, we'll just make the device look like it's off.
[   56.140000] Error unmounting /mnt/storage: -2
[   56.150000] Error unmounting /psp: -22

Re: CHB won't fully boot after battery has lost it's charge

Have you tried pressing the power switch?

Re: CHB won't fully boot after battery has lost it's charge

Huh. Power switch. Does the Chumby Hacker Board have a power switch?

Re: CHB won't fully boot after battery has lost it's charge

> Have you tried pressing the power switch?

Yes. It does not solve the problem.

When I press the button labeled "S600" (which is connected to PSWITCH on the schematic), the Chumby Hacker Board repeats the same behavior -- it boots, and once it is finished booting, it shuts itself down.

The "Detected power switch pressed" message occurs no matter what... even if I remove power from the board, and then reattach the power without pressing any buttons.


=== LOG===


chumby-:/ #
chumby-:/ # ^[[24;13Rkillall: ntpd: no process killed


chumby-:/ # ^[[24;13Rumount: none busy - remounted read-only
umount: can't remount none read-only
umount: /etc/mtab: No such file or directory
umount: tmpfs busy - remounted read-only
umount: /etc/mtab: No such file or directory
umount: /etc/mtab: No such file or directory
The system is going down NOW!
Sent SIGTERM to all processes


Sent SIGKILL to all pro[   57.130000] power/linux.c - stmp3xxx_bat_shutdown():1450 - Not shutting down battery.  Letting the battery charger run.
[   57.140000] Power down.
[   57.140000] >>> Detected power switch pressed.  Turning off.
[   57.150000] >>> A note to those of you watching at home:
[   57.150000] >>> We're going to kill all processes and unmount all filesystems.
[   57.160000] >>> Then we'll sit here charging the battery.
[   57.160000] >>> If you press the power button again, we'll reboot.
[   57.170000] >>> If you unplug this device, we'll power off for real.
[   57.180000] >>> But for now, we'll just make the device look like it's off.
[   58.290000] Error unmounting /mnt/storage: -2
[   58.290000] Error unmounting /psp: -22

Re: CHB won't fully boot after battery has lost it's charge

More information: swapping the microSD card with one with a fresh disk image fixes the problem ... until the battery discharges fully again.  I would like to use the CHB in an embedded application that will potentially sit with no external power for a long period of time. I am going to change the power down mode so that it goes shuts itself off instead of just going into a low power state. But it would be very helpful to know how to fix this problem if the battery should fully discharge again.

Re: CHB won't fully boot after battery has lost it's charge

Some SD cards will corrupt blocks if you pull the power when you're writing.  They'll do this in a way such that journaling won't help.  We've found it most helpful to keep the filesystem in readonly mode for most of the time.  This only happens on some SD cards, however.

Most of the power management code lives in drivers/power/stmp37xx/linux.c.  It's severely hacked-up from the Freescale reference code, because the original driver assumed it would be powered off of a USB OTG port.

Because of that assumption, you actually can't power the device off as long as it has external power applied.  The actual command to power off the chip involves writing to HW_POWER_RESET.  You ought to be able to simulate this from the command line by running:

    regutil -w HW_POWER_RESET=0x3e770001

It could be you'll need to adjust the BROWNOUT_VOLTAGE value.  It's set to 2.88 volts by default, but you probably should set it higher to something like 3.2V depending on your application.  That'll make it turn off sooner, and leave more capacity in the battery.  We set it to 2.88V as an absolute lower-level limit and then used software in userspace to shut down the device when it reached something like 25%.

There is a udev rule under /var/udev/rules.d/ that executes /usr/chumby/scripts/power_state_changed.sh every time the power state changes.  That is, if the device is plugged in, unplugged, finishes charging, or if a battery is attached or removed, this script is triggered.  You can modify the rule to run your own script, or replace power_state_changed.sh to suit your needs.

Re: CHB won't fully boot after battery has lost it's charge

Thank you for the information, ChumbyLurker. I will post an update once I dig into this some more.