3v3 regulator bug

289 views
Skip to first unread message

Jason van Belzen

unread,
Dec 21, 2016, 7:54:20 AM12/21/16
to BeagleBoard
Hi,
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?

Thanks.

Regards Jason

Gerald Coley

unread,
Dec 21, 2016, 7:55:57 AM12/21/16
to beagl...@googlegroups.com
And what is the 3.3V bug?

Gerald


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a3dea840-c1cf-4dad-a0dc-b19ba9936504%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Jason van Belzen

unread,
Dec 21, 2016, 8:03:08 AM12/21/16
to BeagleBoard
3v3 regulator bug:


The issue is the interconnection of the 3v3a and 3v3b power domains, resulting in significant leakage current between them (e.g. via protection diodes) whenever one is powered while the other is not. The 3v3b -> 3v3a leakage was of course exactly the reason for moving the enable-signal of the 3v3b regulator (U4) from 3v3aux (LDO2) to 3v3a. However, while this resolved the issue at boot, it did not resolve it at shutdown when running on dc power, and made it far worse when running on battery.

The problem is that when the 3v3a supply (LDO4) is disabled, the 3v3b regulator remains enabled until 3v3a drops below the threshold voltage of the enable-input of U4, which is far below 3.3V (specified to be somewhere between 0.4V (at 25 ͏°C) and 2V). As a result, current will start to flow from 3v3b to 3v3a, and apparently enough current to keep it logic-high in the opinion of the 3v3b-regulator (despite the ~375 ohm discharge resistor the PMIC applies when LDO4 is disabled!).

Thus, once turned on, the 3v3b regulator manages to keep itself enabled indefinitely as long as it is supplied from SYS_5V. When entering off-state, the PMIC automatically connects SYS to battery power rather than DC- or USB-supply. If there's no battery, then the capacitors on SYS will drain pretty fast hence the 3v3b shutdown is not delayed much. If there's a battery, then you're pretty screwed.

It is very important to note that this issue is not merely one of battery lifetime; this leakage current may damage the processor.



Op woensdag 21 december 2016 13:55:57 UTC+1 schreef Gerald:
And what is the 3.3V bug?

Gerald

On Wed, Dec 21, 2016 at 6:54 AM, Jason van Belzen <jasonva...@gmail.com> wrote:
Hi,
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?

Thanks.

Regards Jason

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

Gerald Coley

unread,
Dec 21, 2016, 8:08:47 AM12/21/16
to beagl...@googlegroups.com
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.

Gerald

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bbbedc74-a881-4c4e-84f5-0897b8ea8372%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Jason van Belzen

unread,
Dec 21, 2016, 8:26:30 AM12/21/16
to BeagleBoard
Thanks for your reply.

How does this issue damage the processor?

Jason

Op woensdag 21 december 2016 14:08:47 UTC+1 schreef Gerald:

Gerald Coley

unread,
Dec 21, 2016, 8:30:07 AM12/21/16
to beagl...@googlegroups.com
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.

Gerald


To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f4612892-76f9-4d83-bdbd-8072af11b172%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Dec 21, 2016, 8:37:46 AM12/21/16
to beagl...@googlegroups.com

On Wed, Dec 21, 2016 at 6:26 AM, Jason van Belzen <jasonva...@gmail.com> wrote:
Thanks for your reply.

How does this issue damage the processor?

Jason

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 .  . .

Gerald Coley

unread,
Dec 21, 2016, 8:42:25 AM12/21/16
to beagl...@googlegroups.com
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.

Gerald


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoLgJdptWzQ2hYQzpcDj0yT2vmzUMm-stxFori1LmbMig%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Dec 21, 2016, 8:48:44 AM12/21/16
to beagl...@googlegroups.com
On Wed, Dec 21, 2016 at 6:42 AM, Gerald Coley <ger...@beagleboard.org> wrote:
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.

Gerald

I think that is the best way to go as well. However,  was recently 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.

Jason van Belzen

unread,
Dec 21, 2016, 9:00:17 AM12/21/16
to BeagleBoard
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?

Jason

Op woensdag 21 december 2016 14:42:25 UTC+1 schreef Gerald:
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.

Gerald

On Wed, Dec 21, 2016 at 7:37 AM, William Hermans <yyr...@gmail.com> wrote:


On Wed, Dec 21, 2016 at 6:26 AM, Jason van Belzen <jasonva...@gmail.com> wrote:
Thanks for your reply.

How does this issue damage the processor?

Jason

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 .  . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

William Hermans

unread,
Dec 21, 2016, 9:15:03 AM12/21/16
to beagl...@googlegroups.com
On Wed, Dec 21, 2016 at 7:00 AM, Jason van Belzen <jasonva...@gmail.com> wrote:
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?

Jason

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.

William Hermans

unread,
Dec 21, 2016, 9:24:20 AM12/21/16
to beagl...@googlegroups.com
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.

Ron B.

unread,
Dec 21, 2016, 9:46:15 AM12/21/16
to BeagleBoard
Hi Jason,

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

-Ron

John Syne

unread,
Dec 21, 2016, 9:58:01 PM12/21/16
to beagl...@googlegroups.com
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. 


Regards,
John




Reply all
Reply to author
Forward
0 new messages