Some time ago, there was a report that unscheduled power interruptions could cause damage to the CPU’s IO pins. The fix was to add a capacitor to the battery header location (TP5…TP8). There never was a spec on how big a capacitor was required.
I just got a Bone Black Rev C from Digi-Key. Is this still a problem? This Bone will be embedded inside a piece of gear that is powered by an equipment rack, and people sometimes cut off the rack power without shutting down the Bone first, although I advise them to do a shutdown properly. We know that the SD card’s file system can be corrupted by dropping power without warning, we know how to fix that. But, we are worried about hardware damage.
Any comments?
Thanks,
Jon
Use an inline battery, e.g. between “AC in” and the barrel jack or header power input. Or put a battery on the test points as you mentioned. Granted, if you put a battery on the test points, you’ll also need to occasionally( maybe always ?) toggle SYS_RESET before the power button will work.
And, what happens when the user just turns off the power? The battery drains, and then the Beagle Bone crashes and the battery is left totally drained, which ruins it, too.
Doesn’t sound like a solution.
Jon
Sounds like someone needs to design-in a front end to handle that... 
Regards,
Has somebody done this already?
Indeed, I see two separate issues that would need to be addressed here.
The first, that of an external system applying power to the BBB IO when the BBB is not powered up, can often be addressed with external series resistors and schottky clamping diodes. The alternative is system power sequence control.
The second, is that of power management. I am working on this right now for one of my projects. Requirements are:
- a reservoir of power for the BBB to do it’s shutdown housekeeping (battery or capacitor)
- an external controller to manage power when it sees the input start to sag – and control when it is allowed to power back up!
- a working ACPID system, or alternatively a home-brew equivalent using interrupt IO.
I’ll post my solution when available. I’m using an external PIC micro-controller and a P-channel MOSFET. If my solution is attractive to others, the Motorola purists out there will certainly be able to use something like an MSP430 instead…
Don
"Somebody" has But i guess some need things "spelled out" in detail ?
Basically, you need an MCU that detects power in, that cuts power to the
beaglebone from the battery after a set amount of time. *Or* that
communicates between it's self and the beaglebone, which "Says" "Hey buddy
battery is getting low you need to power down now!". The tricky part with
the latter part here is how does the MCU know when the beaglebone is
powered down ? I can think of a couple ways at least . . .
Secondly, you'll need to basically code watchdog functionality into this
MCU, so you know how to spot an improper power cycle, then toggle
SYS_RESET, and then toggle the "power button". To make sure the board does
in fact come up. Again, how does one do this ? By Being creative . . .
I've done this with an MSP430, and I know of at least one other
person(company ) that uses a PIC micro to do essentially the same thing I'm
doing. With a cape for sale, in the context of a "UPS" style cape. He's
posted a link to this cape before. We've(my buddy and I ) have been talking
about this for years, and finally implemented hardware and software about a
year ago. It works for us.
Ideally, I think the best solution is to design something like I think
Gerald was talking about some time ago, and something he actually made at
one point I think. A real UPS, that sits before the 5vdc input to the
board. This way if you need USB in your application, nothing gets
disturbed. Then the board need not be "worried" about "Hey the PMIC says
power went away, I need to shut down". In our own case we do have some
devices that do need USB for a3G/4G modem that doesn't cost one their first
born child. But in this case, the system they're controlling is also
powered by AC, and it's a moot point. So other than contacting an external
server to tell it the system is down. There's nothing left to do, but to
wait it out(by powering down ).
But honestly guys, come on, there about 5 billion ways to deal with this
situation Be creative.
Then of course, when "AC in " is not applied, you need to cut the connection between the beaglebone, and the battery. Then do not reapply that connection until after you’re sure power is back. Be it as simple as running some sort of debouncing algo, or some other kind of method is up to “you”.