Both are exhibiting random reboots, two to four times per day. No
indication in syslog as to any cause or problem. No pattern to
the reboots. Can happen while I an logged into the PB editing python
scripts with nano, or can happen in the middle of the night when
absolutely nothing is happening.
Both are powered from Vin, running from a trusted lab bench supply
with plenty of reserve current. I have added extra bulk capacitance on
the Vin input, and also switched lab bench supplies to make sure it
was not a power supply problem.
So, no USB-gadget interface running.
No modifications to hardware or kernel. No modifications to the
system software.
One is running the Oct 10 IoT release version
bone-debian-9.2-iot-armhf-2017-10-10-4gb.img
Linux PB1 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l
The other is running the Stretch IoT weekly snapshot from 11-19
bone-debian-9.2-iot-armhf-2017-11-19-4gb.img
Linux beaglebone 4.9.61-ti-r76 #1 SMP PREEMPT Mon Nov 13 20:24:26 UTC 2017 armv7l
Both are running USB2 to Ethernet dongles on USB Port1 so I can have
remote Ethernet access. To make sure it was not the USB-to-Ethernet
drivers, I ran one for a day, without the Ethernet interface, just
watched it on the UART0 Console Port, no programs running,
and it still does the same thing.
I think this should be easy to reproduce.
Same/similar symptoms to the random reboots we were having on the BBB a year or two ago.
Same ‘Stretch’ bone-debian-9.2-iot-armhf-2017-11-19-4gb.img
running on uSD card on a Rev C BeagleBone Black running on
the same power supply is stable like a rock.
The PocketBeagle, when powered only by the Vin input (P1-pin1) is unstable.
This is the power supply input, normally assigned to the barrel jack in the BBB, or the AC adapter input in the TI docs.
Not to be confused with the Vi input (P1-pin7) which is connected to Vusb0 and Vusb1 on the PocketBeagle.
I have found that when running with Vin and Vi inputs strapped together, the problem does not occur.
I will try a run with the power on Vi only and see what happens.
During both test runs, there was a USB2-to-Ethernet adapter on USB1, but to make sure that the Ethernet driver is not the problem, I have run a PocketBeagle, powered from Vin with nothing else connected than a serial cable on UART0 console, and the unit still behaves the same.
My opinion is that it is either a hardware or configuration problem with the PMIC.
P1-pin7 is the 5V power input normally associated with power coming in the USB connectors.
In the case of the PocketBeagle, it is the input from the USB0 connector.
It can be used as either a 5V input or, if there is power coming in USB port0, as a power output for USB port 1.
It is just a straight connection.
It happens to work fine, and does not seem to have the stability problem I am seeing on P1-pin1.
Can you generate a plot of the power applied on P1_1? I suspect some additional bulk capacitance might be required to keep it sufficiently stable. Monitoring the RESET# line at the same time as P1_1 would be ideal.
I’ll try to reproduce next week. I only ever tested with a bench supply and not for extended durations. Given the similarity to the BeagleBone Black circuit, it doesn’t seem so necessary, but let’s make sure the input is sufficiently stable as much of the capacitance that was there is now gone.
OK.
I’ll be glad to gather any data for you that I can.
I can grab some scope traces of what the power looks like.
I don’t have anything that will do 24 hour long captures.
The bench supply I have is well regulated, and quiet, 5 Amp.
I have run two PB (on Vin P1-pin1) from the same supply simultaneously.
The PBs are both rebooting at very different times, randomly, at the rate of three or four times per day.
I will bridge a BBB and some bulk capacitance across the feed, and re-run the experiment.
I am fairly sure this is not an input side power problem.
I have been unable to get your latest Stretch 9.3 IoT image to fail and autonomously reboot, when powered by Vin (P1-pin1)
ie.: " bone-debian-9.3-iot-armhf-2017-12-10-4gb.img"
I am starting an extended test today, and letting two PBs run for the rest of the week, on this version.
Same power supply, no added bulk capacitance on Vin.
Your recommended PB release version 2017-10-10 definitely does randomly reboot when Vin powered, as do all the Stretch 9.2 weeklies up to Dec 03.
that is,
bone-debian-9.2-iot-armhf-2017-10-10-4gb.img
through
bone-debian-9.2-iot-armhf-2017-12-03-4gb.img
As far as your questions about my bench power supply, noise/ripple on the supply is at floor of scope’s ability to measure, ie, < 12 mV.
Regulation of bench supply, less than 10 mV droop from 0.0A to 1.0A
Voltage set at 5.00 Volts, current limiter set at 5A, so out of the circuit.
Adding or deleting bulk capacitance (100 uF tantalum) at P1-pin makes no difference in the behavior.
I am convinced that this is not a supply side power problem, and is some kind of software issue, hopefully already resolved in Stretch 9.3.
Looks like I spoke too soon.
Both PB’s reset themselves overnight, running Stretch 9.3 IoT.
With the Stretch 9.3 IoT release, it is more like once per day, than the previous four times per day, but it is still happening.
Happens on both 4.4 and 4.9.
To answer Robert’s question.
I generally don’t touch the kernel on any of my installs, so whatever comes on the image.
bone-debian-9.2-iot-armhf-2017-10-10-4gb.img
Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux
When running from Vin, reboots three or four times (randomly) per day.
Linux PB2 4.9.61-ti-r76 #1 SMP PREEMPT Mon Nov 13 20:24:26 UTC 2017 armv7l
When running from Vin, reboots three or four times (randomly) per day.
bone-debian-9.3-iot-armhf-2017-12-10-4gb.img
Linux beaglebone 4.9.67-ti-r82 #1 SMP PREEMPT Fri Dec 8 02:39:42 UTC 2017 armv7l GNU/Linux
When running from Vin, reboots approximately once per day.
Graham,
I’m having the same behavior with the beaglepocket. Random resets and nothing in the logs. Have 3 boards soldered with a Meanwell IRM-20-5 (4 amps) to Vin pin 1.
The capacitor at this pin are an electrolitic 440 uf and three 22 uf ceramic.
At first i thought that the reset were because of the usb modem that was attached, but they persist without the modem. Lot of time spent in this issue.
Very happy to find the workaround of pin1 and pin 7 tied together. Will try it and come back with the results.
I use the green and the black. Too much capacitance and the ramp up of
the power supply is too much and the PMIC can decide not to turn on.
ITs what i noticed one 10uF cap seems to be fine
The PMIC has some timers, and as I remember, the rise time for the initial turn-on to get inside the valid Voltage window (4.5 to 5.5 Volts) is 50 milliseconds,
So the risetime and drive capability of your power supply is also involved in the choice or limitation on the added input capacitor.
If you have a power supply that can charge a 1000 uF capacitor in less than 50 milliseconds, then you can have 1000 uF on the input.
The stability problem is that the PocketBeagle, if only powered from pin 1, which is the same input used for the barrel-jack input in other designs, will spontaneously reboot a few times a day.
It does this with a “perfect” power supply and any added value of input capacitor you choose, so I don’t think the input side of the PMIC is involved.
After have tied the power pins p1 and p7 the board is running since 2 days straight at the moment without unwanted resets.
Consistent with Graham’s report.