Sleep & Detecting Battery Power

GoogleGroups
1

Is there a way to tell the Beagle Board that it is on battery power
vs. being plugged into the wall. I'm reasonably sure, by looking
through the group mail, "power management" is not built-in yet. I'd
like to be able to send a simple input to the board to tell it to
either go to sleep and automatically wake up when power is restored
_or_ be able to turn off peripherals and video output until power is
restored. The backup battery source should be able to last a long
time if there is minimal power drain.

So the question comes down to these 3 items:
1) What's the best way to send a signal to the board. (Ideally a
simple HIGH or LOW signal)
2) If I put the machine to sleep, how do I wake it back up?
(preferably in not requiring human input)
3) Is there a way to temporarily disable USB peripherals and video
output and re-enable them without restarting the machine?

Now that you've read this far, if you're interested, here's my project
and the reason I'm trying to figure it out:

I want to use the Beagle Board for a car entertainment system that
will include music from Pandora, Google Maps/Navigation, Local search
and other useful features behind a touch screen (S-Video & USB). I'm
hoping to pull internet either from a Linux compatible EVDO/3G card,
Bluetooth tether my cellphone or Wifi from a stombox (http://
www.stompboxnetworks.com/).

When I turn off the car I don't want the board to shutdown because
that will mean it'll have to boot back up before I can enjoy it
again. I'd rather put the board to sleep, or at least in a very low
power state, and keep it powered from the car battery or backup
source. Ideally I could set a timer and if power doesn't resume
withing X hours, the board goes into hibernate or shuts down.

I also plan to use Google Android as the OS, since it seems like the
perfect platform for this type of interface.

2

There is no battery power on Beagle. It is either powered via the USB or the DC input. There is no means of detecting one condition versus the other.

If you were to supply an external battery, say on the DC input, then you could use a pin on the expansion connector that could be detected by the OMAP3530 to indicate that you are on a battery. This would be done via a GPIO pin on the expansion connector.

There are many levels of sleep that the system could be put in. If you were to go to a total sleep sate, then the only means currently to wake it up would be to push the user button as it is in the makeup domain of the processor. I won’t attempt to try and explain all of this in an email. My suggestion would be to read through the Technical Reference Manual for the OMAP3530 to get a better feel.

Video output can be turned of via a control signal from the processor which will reduce the board current by 100mA. You can also turn off the USB power via the TWL4030. But, if you have perpherals connected that means you have an external hub atached. This would require using a GPIO pin to control the power to the hub to get to the lowest possible footprint. On the Rev C board, the USB host power, not the USB OTG port, can be removed by setting a control pin from the processor which if you were using a USB powered hub, would turn off the perpherals as well.

No more power than the Beagle takes, I don’t think you need to get too fancy. I would figure out my power footprint that I could live with, the maximum current I can draw while asleep, while in the low power state. A car batteyr has a lot of juice in it and I would look at turning off perpherals, reducing the core voltage, and using frequency scaling, slowing down the processor frequncy, to put the board in a low power mode. Each block inside the OMAP3530 can be shut down to save power and the DDR can be put into a self-refresh mode…

I am not familiar enough with Android in this area, but I am sure you should have what you need to reach that low power mode without too much difficulty. It will take some driver modifications as needed.

Check the following links:

http://www.beagleboard.org/uploads/BBSRM_6.pdf
http://focus.ti.com/docs/prod/folders/print/omap3530.html

I hope this helps a little.

Gerald

3

Thank you, this helps a lot! I will start tinkering with it as soon
as I get my Beagle Board. Right now I'm just lining up resources and
information so I can hit the ground running.

4

I am interested learning about any backup battery power supply you
found or built.

I am actually building something like what you describe, and I am
sending off the first rev for PCB fabrication later this week. The
board is designed to supply a regulated 5V at up to 1A from a
rechargeable 3.7V Li-Ion battery, and it is actually a bit more
involved than what you describe because of what I am planning to do
with the setup, but if there is something out there that is close
enough, then I might be able to do a prototype with less out of pocket
costs. Without going into all of the details, the board I am building
will act as a rechargeable battery based power supply for the Beagle
Board with a micro controller (MSP430F2254) monitoring and controlling
the power.

I know I have stated this several times on this list already, but be
careful when you test the suspend feature under Linux on the Beagle
Board. I tested this under an OE build on my board, and when the
suspend failed, current consumption jumped from 240mA (console only)
to peaking over 800mA before settling to consume around 710mA. I
repeated the experiment two more times, and the same thing happened
each time. I was trying to suspend to memory.

Koen suggested looking at a pm branch, but I have not taken the time
to do that yet.

-Preston

5

Hi,

I am interested in these features too. I also want to monitor the
battery charge state. I know on most laptops, there is some standard
interface for reading battery charge state.

This could be as simple as an ADC reading across the battery.. but how
to report it correctly? Is there an i2c driver that normally does
this stuff and there is an appropriate part to use? I would like to
build the correct hardware and use existing drivers if possible. Any
information on this is appreciated.

Sean

6

With the board that I am building I did the simple thing. I put a
100K / 100K voltage divider on the battery voltage and ran the divided
voltage (VBAT/2) to an ADC pin. I looked at using a battery fuel
gauge part (several of them), and the cost was not that bad ($2.00 to
$3.00US in Qty 100), but I suspected I would not have room on the
board and keep all of the components on one side, which is a goal for
this first rev. The battery fuel gauges I looked at required a lot of
external passives. Even without the gauge part, I had to remove a
some of jumpers I put in to make the configuration flexible.

That said, the boost I am using has a low battery indication, but it
is binary, and has a trip point set by external resistors. I tied the
low battery out signal from the boost to an interrupt pin on the
msp430.

I don't know what the correct way to report the information is yet,
but I am going to look at that while the boards are being fab'd. I
suspect I will be writing something to interface with hald(8), but
that is just a guess at this point.

I will let you know if I find out the official way of reporting the
battery level.

-Preston

7

I did a little digging, but not near enough to come up with a complete
answer.

It looks like battery driver lives here: drivers/acpi/battery.c

-Preston

8

> ...
> I don't know what the correct way to report the information is yet,
> but I am going to look at that while the boards are being fab'd. I
> suspect I will be writing something to interface with hald(8), but
> that is just a guess at this point.
>
> I will let you know if I find out the official way of reporting the
> battery level.

I did a little digging, but not near enough to come up with a complete
answer.

It looks like battery driver lives here: drivers/acpi/battery.c

That is for x86 using ACPI.
Take a look at the stuff in drivers/power/*

The other OMAP3 boards that have the battery stuff brought out use
twl4030_bci_battery.c in that directory.

Regarding your earlier comments, if you are using batteries, chances are you
will need a regulator. A lot of the regulator ICs have a LBO signal that can
interface with the GPIO. I think some of them even have them as open
drain/collector so it may even directly interface with the 1.8V GPIO's
provided you use a suitable pull up. I threw together a Li Ion supply a while
ago for another board and the chips I used had a LBO signal exactly like
this. All it takes is a divider to set the threshold and it has an internal
comparator. Eventually, I'll get around to wiring it up to the Beagle but
right now the raw buck/boost regulated 3.8V from the LiIon cell seems to be
working fine. This is the Li supply on my projects page.

9

> > ...
> > I don't know what the correct way to report the information is yet,
> > but I am going to look at that while the boards are being fab'd. I
> > suspect I will be writing something to interface with hald(8), but
> > that is just a guess at this point.

> > I will let you know if I find out the official way of reporting the
> > battery level.

> I did a little digging, but not near enough to come up with a complete
> answer.

> It looks like battery driver lives here: drivers/acpi/battery.c

That is for x86 using ACPI.

That makes sense.

Take a look at the stuff in drivers/power/*

The other OMAP3 boards that have the battery stuff brought out use
twl4030_bci_battery.c in that directory.

Thank you for the pointer. That will help!

Regarding your earlier comments, if you are using batteries, chances are you
will need a regulator. A lot of the regulator ICs have a LBO signal that can
interface with the GPIO. I think some of them even have them as open
drain/collector so it may even directly interface with the 1.8V GPIO's
provided you use a suitable pull up....

I am using Linear's LT1308A, which has an LBO signal that is an open
collector. That is what I previously, and some what vaguely, referred
to as the low battery indicator on the boost.

-Preston