If I am applying a 5V power supply to the Vin pin (P1-1) of a Pocket Beagle
(say from an expansion board that includes a power supply), is it safe to also
plug in a [powered] micro-USB cable? That is, does the Pocket Beagle have a
power protection / isolation circuit?
Robert,
If you have a look at the Pocketbeagle schematic, you can see what happens with the USB connector, which comes in on page 2. Power on that pin goes to VIN.USB, which goes straight to (page 3) the Octavo OSD3358 VIN_USB pins.
You can look at the Octavo datasheet [1] - it’s for the OSD335x_SM - they tell you almost nothing. The only partly useful thing they tell you is “The OSD335x-SM may be powered by any combination of the following input power supplies. Please refer to the TPS65217C datasheet for details.” The smartest thing to do would be to map the pins to the chips they are connected to using Octavo’s tool [2] and the TI datasheets. I’m certain there’s no isolation, but there is a switch to enable one or the other inputs (perhaps you had a looser definition of isolation in mind). Figure 11 on page 27 of the TPS65217C datasheet [3] should show you what that looks like. These are configured by the PPATH register in [3], which I am not precisely certain how it is configured in the first place, but you should be able to modify it on I2C0 (I think).
All that said, it looks to me like it’s fine to do. But I feel like I’ve done this and had some weird results, I just can’t remember exactly what they were. I think the results included unplanned reverse power flow (USB charging other things connected to the same VIN power supply), the device not shutting down exactly as I expected, and similar behavior. I don’t think we smoked anything, though, so there’s that. Worth looking through that data sheet a little to make sure you’re happy first.
I would be quite interested to know precisely where PPATH is configured, beyond its default settings. It may be in the uboot source which is not [I think] in the BB distributions. That stuff isn’t bad to look at, and I was going to, but for the life of me I can’t remember where I built that and I can’t find it right now. Robert also has a few scripts in /opt/scripts/boot which configure a LOT of things, I’ve only scratched the surface trying to understand them.
[0] - https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf
[1] - https://octavosystems.com/docs/osd335x-sm-datasheet/
[2] - https://octavosystems.com/app_notes/osd335x-family-pin-assignments/ (search for VIN_USB)
[3] - http://www.ti.com/lit/ds/symlink/tps65217.pdf
Hope that helps. I have nothing to do with the pocket beagle but I did spin a couple boards based on it and the octavo RED board.
Best,
Jim
Robert:
It has been a while, almost a year since I did any testing with the PocketBeagle.
But I don’t think anything has changed relative to my comments below.
Maybe someone can correct me if I am wrong, and some things have been fixed.
P1-Pin-1 is Vin, and is equivalent to the Barrel Jack input on the Beaglebone Black, it
is a separate power supply input, and is isolated from the microUSB connector power.
P1-Pin-7 is hardwired to the +5 pin on the microUSB connector, USB Port 0.
It is not clear from the schematic, but is visible if you view the PCB board plots.
Or check it with an Ohmmeter.
I found that the PocketBeagle, when powered exclusively by P1-Pin-1 would randomly
crash about once every 24 hours of operation, without any apparent reason, or
any clue in the logs. I hope that this has been fixed, but I have seen other reports
since I initially reported it, and nothing since that reported a fix.
The only workaround I found was to power P1-Pin-1 and P1-Pin-7 in parallel, in which case
it does not crash, but now there is no isolation between USB +5V and your independent
PB power supply, and, as you are concerned about, all kinds of cross-feed and back
powering can occur.
I suggest you read the email thread “PocketBeagles are Unstable” started 11/24/2017
— Graham
Robert,
If you have a look at the Pocketbeagle schematic, you can see what happens
with the USB connector, which comes in on page 2. Power on that pin goes to
VIN.USB, which goes straight to (page 3) the Octavo OSD3358 VIN_USB pins.You can look at the Octavo datasheet [1] - it's for the OSD335x_SM - they
tell you almost nothing. The only partly useful thing they tell you is "The
OSD335x-SM may be powered by any combination of the following input power
supplies. Please refer to the TPS65217C datasheet for details." The
smartest thing to do would be to map the pins to the chips they are
connected to using Octavo's tool [2] and the TI datasheets. I'm certain
there's no isolation, but there is a switch to enable one or the other
inputs (perhaps you had a looser definition of isolation in mind). Figure
11 on page 27 of the TPS65217C datasheet [3] should show you what that
looks like. These are configured by the PPATH register in [3], which I am
not precisely certain how it is configured in the first place, but you
should be able to modify it on I2C0 (I think).All that said, it looks to me like it's fine to do. But I feel like I've
done this and had some weird results, I just can't remember exactly what
they were. I think the results included unplanned reverse power flow (USB
charging other things connected to the same VIN power supply), the device
not shutting down exactly as I expected, and similar behavior. I don't
think we smoked anything, though, so there's that. Worth looking through
that data sheet a little to make sure you're happy first.
OK. The reason I want to know is that I have an expansion board that supplies
power (and does other things). It does have a serial console header, so I can
connect a TTL serial<=> USB cable for debugging, but unless I really want to
raise XModem (from the dead?) there isn't any way to do something like
download a fresh executable program ("cross" built on a RPi). I just wondered
if it is "safest" to just unplug the Pocket Beagle from the expansion board
and tether it to my laptop and use the Tcp/Ip over USB to do the "large"
transfers of things like exe files, etc. This is what I have been doing and
was wondering if I really have to do it that way or if I can plug in the USB
while the Pocket Beagle is still being powered by the expansion board.
Robert:
It has been a while, almost a year since I did any testing with the
PocketBeagle.
But I don't think anything has changed relative to my comments below.
Maybe someone can correct me if I am wrong, and some things have been fixed.P1-Pin-1 is Vin, and is equivalent to the Barrel Jack input on the
Beaglebone Black, it
is a separate power supply input, and is isolated from the microUSB
connector power.P1-Pin-7 is hardwired to the +5 pin on the microUSB connector, USB Port 0.
It is not clear from the schematic, but is visible if you view the PCB
board plots.
Or check it with an Ohmmeter.I found that the PocketBeagle, when powered exclusively by P1-Pin-1 would
randomly
crash about once every 24 hours of operation, without any apparent reason,
or
any clue in the logs. I hope that this has been fixed, but I have seen
other reports
since I initially reported it, and nothing since that reported a fix.
Well, I am not expecting an application that would run 24/7. I am working on
model RR control circuits. It does not sound like this should be an immediate
problem.
The only workaround I found was to power P1-Pin-1 and P1-Pin-7 in parallel,
in which case
it does not crash, but now there is no isolation between USB +5V and your
independent
PB power supply, and, as you are concerned about, all kinds of cross-feed
and back
powering can occur.
That does not sound like a really good idea.
Question: if the board was powered from P1-Pin-1 *and* the USB will there be
problems? Right now, that is my main concern. Jacking in the USB (for file
transfer mostly, since I can use the serial console for debugging) while the
board is being powered via P1-Pin-1 is something I'd like to be able to do,
but don't want to fry anything.
I suggest you read the email thread "PocketBeagles are Unstable" started
11/24/2017
Will have a look.
As I said, P1-Pin-1 and the microUSB connector power are two different inputs to two different power supplies. Having power on both of them is not a problem, and in fact, will prevent the problem of instability I was concerned about.
So, no problem powering both.
The concern with the random crashes is just that, it could take three days, or could happen in the first hour.
I would power the unit from both pins, if it is doing something at all important.
Of course, my crashing experience is from 18 months ago, and there have been a lot of software releases since then.
I would encourage you to run some endurance tests on your board, before putting it in service.
— Graham
As I said, P1-Pin-1 and the microUSB connector power are two different
inputs to two different power supplies. Having power on both of them is
not a problem, and in fact, will prevent the problem of instability I was
concerned about.So, no problem powering both.
The concern with the random crashes is just that, it could take three days,
or could happen in the first hour.
I would power the unit from both pins, if it is doing something at all
important.Of course, my crashing experience is from 18 months ago, and there have
been a lot of software releases since then.
So you believe it was some sort of software issue, rather than a hardware
design problem?
I would encourage you to run some endurance tests on your board, before
putting it in service.
OK, I can do that at some point.
Ahhh. I’ve had some of this pain. I did actually raise xmodem from the dead, but had enough problems that I just got a secondary USB port working and put a wifi dingle on it. Anyway what you want to do, sounds like it will work.
What I would do is some minor surgery on the PocketBeagle, disconnecting the +5V lead coming in the microUSB connector.
The easiest way to do this would be to remove FB1 (ferrite bead in series with USB +5).
Easy with “hot tweezers”, or a pair of small soldering irons.
To restore the Pocketbeagle to factory configuration, solder FB1 back in.
Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever you are going to power it with at +5V.
No issues with instability.
Now you can plug in USB for programming and anything else you want/need to do, at any time. It just won’t take power through the USB cable any more.
— Graham
Is there more information on this problem ?
I am working on an OSD335x board that is similar to a PB or a BBBW - it has eMMC.
I am experiencing random crashing often taking as long as 18 hours, but sometimes as frequently as 30 min.
But the problem does not occur on a BBBW with almost identical hardware/software.
I am looking for clues.
I will try powering from USB and the standard +5 input concurrently.
Dave:
I have never seen any clues in the logs.
It just randomly spontaneously reboots about once a day.
I suspect that running it from the USB Port-0 power input (P1-Pin-7) does not have the problem.
Running it from Vin (P1-Pin-1) does have the problem.
Running it from both in parallel does not have the problem, since the P1-Pin-7 always seems to work.
The only other clue I can offer is that back in 2015, the BeagleBone Black had a problem with identical
symptoms, that was fixed by Robert Nelson. He never said what he did to fix, but I am pretty sure he had
to dig into the kernel.
See thread:
“BBB intermittently rebooting.” Started 7/17/2015.
— Graham
What I would do is some minor surgery on the PocketBeagle, disconnecting the +5V lead coming in the microUSB connector.
The easiest way to do this would be to remove FB1 (ferrite bead in series with USB +5).
Easy with “hot tweezers”, or a pair of small soldering irons.
To restore the Pocketbeagle to factory configuration, solder FB1 back in.
Whatever instability problems you are seeing, I don’t see this addressing it. The PMIC is designed to dynamically switch between the P1.1 (“AC power” in PMIC terms, which always bothers me because it is never AC, but instead DC assumed to come from an AC-powered wall-supply). If somehow there’s not enough capacitance to make the switch cleanly, I’d suspect you are doing something rather odd with the load you are putting on it. What else do you have connected?
Anyway, I put both “AC” (P1.1) and “USB” (P1.7) on the headers on purpose and the full expectation is that if you are putting a power supply in (and it isn’t a battery), you’ll use P1.1. If it is battery, I also give you that option at P2.14 (BAT).
Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever you are going to power it with at +5V.
No issues with instability.
OK, now you are just asking for trouble. There’s no justification for doing that.
If the design isn’t working as intended, then, let’s talk about that and details, such as what you are seeing on a scope and P2.13 (VOUT), which is the output of the power mux on the PMIC, also referred to as SYS_5V on BeagleBones. Ultimately, this is used to provide the power to the regulators for the other subsystems. Perhaps your problem is drawing too much current from it?
It can be argued I put too many power options on the header, but I tried to keep it flexible for people embedding it onto something. You have a lot of flexibility and I don’t see any need to encourage people to alter the board.
Hi,
The past year i have to power 3 pocketbeagle from Vusb because of the random reset when connecting to Vin. This was the only thing that worked for me. Did a lot of testing adding capacitance and non work.
Jason:
The PocketBeagle will do this, when powered from a serious Lab-bench power supply running into P1-Pin-1, with added capacitance on the pin, without added capacitance on the pin, without any other accessory or cape drawing power from the PocketBeagle. I reported this in November 2017, and there have been three or four other reports by other users since then. It makes the PocketBeagle unusable for any serious application, where it is not powered from the microUSB connector.
— Graham
Hi,
Could this be related to random reboots on BBB ?
See this thread for more details: https://groups.google.com/forum/#!msg/beagleboard/RMOTnQBgIo8/q5vzpFPLlhgJ
We found out the issue / causes are still present on a 4.1 kernel.
I am near certain I am seeing the same problem on a board based on the Pocket Beagle Design.
Though that board is more of a hybrid of the BBBW and the PB as I have eMMC an LCD nearly idenitcal to the 4.3 cape but no P1/P2 P8/P9
I did preliminary code development on a BBBW and BBB and had not problems.
On the production boards I am seeing random reboots anywhere from every 30 min to as long as 24hours apart.
I now have nearly idenitical code running on the BBBW - same linux (5.1.18) almost the same devicetrees,
I am not seeing these random reboots on the BBBW.
There are very slight differences in the power schematice between the PB and the BBBW, but I am not an EE and I can not see a meaningful difference.
Further the ball numbers on the schematics are different - I thought the BBBW and the PB both used the same OSD chip ?
As I have noted in a previous post, I am seeing this problem on a board with a design derived from the pocketBeagle.
Based on the information here we have managed a workaround - tying VIN_USB to VIN_AC, and as a consequence have several boards that have been runing for over 48hours, when we could not reach 18hrs before and often had resets every 30min.
I have run the same software with nearly the same devicetree and the same linux(5.1.18) on a BBBW without any failures.
I have compared the schematic of the BBBW which also uses that OSD335X SOC with that of my board and the pocketBeagle and can not see a meaningful difference in the input power design.
Does anyone have any input as to why the PcketBeagle design fails and why the BBBW works ?
Also if Tying VIN_USB to VIN_AC works, would the problem go away if a battery was connected to VIN_BAT ?
Any thoughts would be appreciated.
Though atleast we have a workarround now.
Thank you.
Does anyone have any input as to why the PocketBeagle design fails and
why the BBBW works ?
Robert Nelson is really the right person to answer that.
From what I understand, during boot, uBoot examines the configuration
EEPROM and decides which files/modules to load. Even though the hardware
is identical, it could load different modules, if the configuration
EEPROM is different. So, one load has the bug, the other doesn’t.
Or, you are actually running different revision levels of silicon, and
one has a bug.
Also if Tying VIN_USB to VIN_AC works, would the problem go away if a
battery was connected to VIN_BAT ?
I have never tried that, but definitely worth a try. It is a third
separate isolated power input. I assume with different management software.
Any thoughts would be appreciated.
Beagleboard.org needs to decide if this is a serious enough problem that it
is worthy of being fixed. So far, they have decided that we don’t know what
we are doing, and are inducing a spurious problem; or that it is not serious
enough a problem to spend the time fixing. I personally think it prevents
the PocketBeagle from being used for any serious application.
Robert,
On my derivative board, I am only powering via the AC1-3 inputs on the OSD3358 part.
Octavo suggested that I ground the VIN_USB pins and tie one of the VIN_BAT pins to PMIC BAT SENSE.
I believe that VIN_USB1-3 are shorted internally in the package as well as VIN-BAT1-3.
So you should only have to use one of those pins for each group.
I so far have not experienced any startup or continuous running issues.
Hope that helps,
Matt
Hi,
Adding to this discussion a bit, hope you are all still there now and then…
I had some stability issues with a WiFi dongle on the PocketBeagle. I am running it with a USB cape. It used to run stable on battery power with P1,1 and P1,7 connected with each other. Only problem I had, I did not see an ip address from my wifi dongle (connected to the standard micro USB connection).
I really needed to have a fixed ip address and decided to accomplish that using connmanctl. After successfully changing the connmanctl settings though the connection wasn’t stable anymore. Using the micro USB on the micro USB connection it would sometimes connect, stay on for a few ping’s and then disconnect. Once it stayed up for a whole minute!!! Connecting it to a USB port on the cape it would drop out, come back up for a ping, drop out again for about 10 to 20 pings, etcetera.
When using the micro-USB connected to the computer though and powering the cape with the (powered) USB-dongle in it, the connection stayed stable. Which suggests a power issue. While using battery power I did connect VIN, VBUS and VIN-USB to a 5V stepDown board (from a LiPo, two cells) the only power input I had not connected yet was Vbat. While connecting Vbat, it seemed my board fried (power blinks about once a second now, further no response). I have had these PIN’s connected before so it seems unlikely that that is the reason. I probably made some other mistake. My system still comes up on another PocketBeagle.
My questions / requests:
- Could wiring P1,1; P1,5; P1,7 and Vbat together on a 5V input pose a problem? (probably better not to connect a micro USB cable to the computer at the same time)
- Could the instability of the WiFi dongle connection be caused by not connecting Vbat? (I have not been able to test it since the board fried while doing that)
- Any suggestions for checking my boards demise or a recipe for possibly reviving it would we welcome.
Best, Hans.