Can the BBB get damaged due to a hard power down?

I read over at another forum that the BBB could get damaged if it recieved an unexpected “hard” power down…, is this true, what can we do about this?

Seems like a serious design flaw to me. One can’t expect a power source to be 100% stable and especially with a development board which is likely to used for embedded appliances this is a reall issue…

Thanks,

What happens, or can happens when you just yank the power on a PC running Linux ?

  1. You can make teh file system read only.

  2. You can design or create a power cape that shutdown gracefully when power goes missing.
    …) ???

This is why there is a power button. I suggest that you go to your PC and yank the power cord. Whether it is running Linux or Windows, I suspect it won’t like it.

If you can’t use the power button, then yes you can design a cape that will let it gracefully shutdown properly. When I designed the board I felt that a button was less expensive that all the other stuff you would need to put on the cape. Not to mention the small form factor of the board made it tough to fit all that onto the board. And yes, in a small number of instances, we have seen that yanking the power may cause damage to the processor because the PMIC does not have enough time to power down the processor in the correct voltage sequence. So, use the power button.

Gerald

Hi Gerald, Look I’m sorry if you took offence by my comment. It’s an awesome board, don’t let anybody convince you otherwise It’s just that I’ve not seen it being mentioned anywhere that a correct power down procedure is required. If it was a deliberate design choice not to provide some kind of fail-safe, I personally would have definitely made this clear to every buyer. I work hands-on with computer equipment of various makes and models on a daily basis and I honestly can’t remember the last time a box got bricked due to a power outage. I myself, and as I suspect many others, am thinking about turning the BBB into an embedded appliance which makes the power button inaccessible.

Can you suggest how we can extend the powerbutton of from the board?

The power button signals are on the expansion header.

Gerald

"look" into read only file systems. I have a solar powered web cam on
the roof using a Beagle-xM for wifi/xbee access. It's been running
Debian Squeeze for the last 5 years just fine on the same base
microSD/image.

Regards,

A solution would be to design a cape with a small battery to provide
enough power to enable the Beagleboard to gracefully power down when
it detects that external power is gone. That is probably the quickest
solution.

A second solution would be to audit the code to ensure the the file
system is not left in an unstable state during a power outage.
Companies like Red Hat and Google have spent $10's of millions on this
problem. It is even more interesting for cloud people as virtual
machines tend to be started and stop very frequently.

Both of these are really interesting problems. My guess is that if
anyone wanted to work on these as personal projects or 'value adds'
for their devices Robert, et. al. would be very interested into
pulling them into main line once the kinks were worked out.

To provide some perspective, the ardunio is a really rugged, low
powered device. The BBB is a fragile, high powered device. Both have
pros and cons... and their place.

There's a good readme here:
https://wiki.debian.org/ReadonlyRoot

One of the problems, some applications don't like everything read
only, so you need to boot at-least once as rw. This was the case with
Squeeze, haven't investigated it lately with wheezy.

Regards,

I think Gerald was actaully saying the processor might get damaged. I don’t see how a read-only filesystem would solve this a battery powered cape for a graceful power-down might be option. I don’t have the knowledge to design/build one (relatively) easily.

I’ll use the power button as much as possible as recommended and take my chances.

Nope, re-read his message, it's with regards to the file system on the
(powered at time) media device (eMMC/microSD). The "processor" can
handle power drop's just fine, as it's all ROM inside it.

Regards,

A battery powered
cape for a graceful power-down might be option. I don't have the
knowledge to design/build one (relatively) easily.

On the BeagleBone white, I use a 5F supercap on the "battery" terminals. When my hardware detects failing prime power it flags an input that my software watches for. My software then immediately uses the magic-sysrq to sync disks and remount as read-only, to protect the filesystem. The supercap provides just enough power/time to do that.

Also, I use full data+metadata journaling on the filesystem (ext4).

It's been very robust so far.

- Mike

Sounds cool and easy to implement hardware-wise.
Can you share the code for that?

Florian

Nope, re-read his message, it's with regards to the file system on the
(powered at time) media device (eMMC/microSD). The "processor" can
handle power drop's just fine, as it's all ROM inside it.

But Gerald wrote:

And yes, in a small number of instances, we have seen that yanking the power may cause damage to the processor because the PMIC does not have enough time to power down the processor in the correct voltage sequence.

I can see how that could happen, even if rarely. It reminds me of the
power circuit failures that happen when you manage to plug or unplug
the circuit at exactly the wrong point of the AC cycle. An example is
a surge current-related failure when the power supply caps are
discharged, and you plug in exactly when the AC cycle is at the
maximum---it's hard to test for and therefore sometimes missed by PS
designers.

The supercap method mentioned above does indeed sound interesting.Better than the idea I had( just briefly thinking about it ) Which was to use a battery to supply power to the BBB, and have something like an msp430 signal the BBB when the mains go down. Obviously it is more complex than this, but not by a lot.

A battery powered
cape for a graceful power-down might be option. I don't have the
knowledge to design/build one (relatively) easily.

On the BeagleBone white, I use a 5F supercap on the "battery" terminals.
When my hardware detects failing prime power it flags an input that my
software watches for. My software then immediately uses the magic-sysrq
to sync disks and remount as read-only, to protect the filesystem. The
supercap provides just enough power/time to do that.

I really don¹t see how this can work. First, the supercaps are 2.5v so you
need two in series which means you need an energy balance circuitry to
ensure one supercap doesn¹t receive more charge than the other. Also, the
PMC won¹t like a short circuit, which the supercap is when it is fully
discharged. I could go on, but this idea doesn¹t make sense to me.

Regards,
John

I really don¹t see how this can work. First, the supercaps are 2.5v so you

No:

http://www.digikey.com/product-detail/en/PHB-5R0V505-R/283-3520-ND/2770536

PMC won¹t like a short circuit, which the supercap is when it is fully
discharged. I could go on, but this idea doesn¹t make sense to me.

Same is true of an uncharged battery. The charger circuit is current-limited. (I pull it up with a diode drop + 10 Ohms to a +5V rail also, for faster charging.)

- Mike

Sounds cool and easy to implement hardware-wise.
Can you share the code for that?

Something like this:

// use plain old open to avoid any buffering etc
int enablefd = open("/proc/sys/kernel/sysrq", O_SYNC | O_RDWR);
int trgfd = open("/proc/sysrq-trigger", O_SYNC | O_RDWR);

// enable sysrq
write(enablefd, "1\n", 2);
close(enablefd);

// sync disks
write(trgfd, "s\n", 2);

// remount ro
write(trgfd, "u\n", 2);
close(trgfd);

// poweroff
system ("/usr/bin/systemctl poweroff -f");

exit(0);

As I mentioned, I use full data+metadata journaling on the filesystem, not just metadata.

The only issue is that the system doesn't restart if power is reapplied before the supercap is fully discharged. You have to wait 10 seconds or so before a restart is possible. I'm not sure how to fix that.

- Mike

Actually if you cut one of those open, it's two 2.5v supercap with a
balance resistor network.

Regards,

I really donšt see how this can work. First, the supercaps are 2.5v so
you

No:

PHB-5R0V505-R Eaton - Electronics Division | Capacitors | DigiKey

This is really two supercaps placed in series with a small resistor across
each to balance the charge. This is not a good solution because the
resistors discharge the supercaps with no load but for your application,
it probably doesn't matter.

PMC wonšt like a short circuit, which the supercap is when it is fully
discharged. I could go on, but this idea doesnšt make sense to me.

Same is true of an uncharged battery. The charger circuit is
current-limited. (I pull it up with a diode drop + 10 Ohms to a +5V rail
also, for faster charging.)

Batteries should never go to 0V or they will be damaged. Lithium Iron
shouldn't be discharged below 2.7V.

I'm not sure what happens to the battery charging circuit in the PMU, but
my guess is that is will go to some sort of a lockout for safety reasons
so I"m not sure if the switchers can run from this energy source. Have you
asked anyone at TI if it is OK to use the PMU like this? Perhaps you
should post a question on E2E.

If you are charging at 440mA, it will take 50 Seconds to reach full
charge. What happens when the power fails before that 50 Seconds? I would
recommend that you monitor the supercap voltage and wait until it is fully
charged before opening any files.

It is an interesting concept, but I'm still skeptical if this can really
work.

Regards,
John

Sounds cool and easy to implement hardware-wise.
Can you share the code for that?

Something like this:

// use plain old open to avoid any buffering etc
int enablefd = open("/proc/sys/kernel/sysrq", O_SYNC | O_RDWR);
int trgfd = open("/proc/sysrq-trigger", O_SYNC | O_RDWR);

// enable sysrq
write(enablefd, "1\n", 2);
close(enablefd);

// sync disks
write(trgfd, "s\n", 2);

// remount ro
write(trgfd, "u\n", 2);
close(trgfd);

// poweroff
system ("/usr/bin/systemctl poweroff -f");

exit(0);

As I mentioned, I use full data+metadata journaling on the filesystem,
not just metadata.

The only issue is that the system doesn't restart if power is reapplied
before the supercap is fully discharged. You have to wait 10 seconds or
so before a restart is possible. I'm not sure how to fix that.

You need a small state machine which you can implement with a GreenPAK.

http://www.silego.com/products/greenpak.html

Regards,
John