3v3 regulator bug

We are planning to build an IoT gateway based on a Beagle Bone Black.
Till now we were experimenting with the Beagle Bone Black Rev C.
Since we need to protect the filesystem, we want to use a battery so we can detect a power failure and nicely shutdown the system.

Unfortunaletly we encountered a problem.
After shutting down the system with a battery connected, the 3v3 regulator bug is triggered.
The BeagleBone Black is a good board for our purpose, so we really want to use this board.

A few questions come up in our minds.

  1. How bad is this bug? Is it really gonna damage the processor?
  2. Are there any other solutions than patching to an unified 3v3 rail?
  3. Are there any next revisions planned for the BeagleBone Black? And if they are planned, will this bug be fixed in the next revision?


Regards Jason

And what is the 3.3V bug?


3v3 regulator bug:


I have no plans to fix this. If you need battery operation, which the BBB does not really support as it needs 5V for the USB, then you need to modify the board design for your usage.


Thanks for your reply.

How does this issue damage the processor?


I don’t believe it does.Main cause of damage is separately powered devices that connect to the processor and are not powered at the same time.


As Gerald already said, I do not believe it does either. What does happen
however is that the board when in this state through the PMIC wont always
reset from the switch. Meaning, you have to completely disconnect the input
power, reconnect it, and then reset before the board will restart.
Additionally, some people claim that the board when in this state continues
to draw power. I don't doubt that, I've just never personally tested that.

Anyway, it's probably simpler to design a cape that deals with all this for
you. Either that, or use an external battery / charging system that
provides 5v directly to the board. In either case, you'll probably need /
want an external MCU involved . . .

In my experience, and external battery is the way to go. I designed a cape for that a log time ago. That let’s you support multiple types of battery chemistry and multiple configurations.


involved in a project where the hardware engineer though that was a
terrible idea. Added cost, and all that. So, he designed an MCU of my
choice onto the cape, with a few isolated pins coming back to the
beaglebone. For reset, power switch, and one for a watchdog feature I also
designed into the MCU's firmware. Problem solved, it works great.

I understand that an external battery cape is the best solution.

Do you know if the following is possible from linux perspective:

  • We run on battery and DC power
  • If we detect DC power loss, we close all running processes
  • Only kernel stays active
  • Kernel clocks itself down to a very low clockrate
  • Kernel checks periodically if power is restored
  • If power is restored, kernel gives itself a reboot
    Is something like this feasible or is this a very bad idea?


The problem is, no matter what, I think you're going to need some sort of
external interaction. I was the one who actually came up with the idea I
mentioned above around 3 or so years ago. I posted about it on the groups
here, and someone also implemented my same exact idea. Which I only
described at a high level.

Anyway, what you're asking *may* be possible, but a lot of thought, and
perhaps some testing would have to be put into the idea. So apparently,
soon, power management will be put into the kernel, for the beaglebones . .
.What this means is that you should be able to hibernate, or suspend to
ram. What I'm unclear on personally though. Is how do we wake from this
state that we put ourselves into ? With an x86/x86-64 we have wake on lan,
possibly wake on wifi, etc. But all that uses power, power that may not be
in abundance.

So I think the least complicated scenario is to use an external MCU, that
is able to detect when power is lost. The Beaglebone will also know when
the power is gone, and in fact, will either shutdown right away. Or if the
Debian package acpid is installed, the beaglebone will shut it's self down
in an orderly fashion. It then just becomes a case of having some form of a
battery(LiPO in our case connected to the battery test points ). If you
have an external battery that is able to provide 5v to the system. Then you
will probably want this MCU to check the AC input( or DC 5v if pre
regulated ), then connect a few isolated pins to the beaglebone for reset,
and a GPIO to initiate a beaglebone shutdown.

But once again, you will need to put some thought into your design. Test
it, and discuss is with a few fairly bright people. To make sure did not
leave something out. I actually had to redesign my own software a few times
as a few things I did not think about came to light after testing.

Ah, and I forgot to mention. Disconnecting power to the beaglebone is a necessity when shutting down the board. Otherwise, the beaglebone will occasionally be stuck in power limbo( what we talked about before ). Then will be unable to reset until someone physically disconnects / reconnects the power input to the beaglebone. Where the power is disconnected depends on whether you’re externally powering via Geralds, and mine( for that matter ) preferred method. Or via a LiPO connected directly to the beaglebone / PMIC.

Hi Jason,

Check out the Power Cape. It sounds like what you need.


Just be aware, you cannot recycle the power on the BBB because it lacks the circuitry necessary to ensure 3v3 - 1v8 never exceeds 2V. You will find this circuitry on the Octavo eval board. Without this circuitry, the processor will die eventually after cycling the power 100s of times.