I have been building embedded systems for a while now and I am considering using the beaglebone (BBB) for an upcoming project, but I am confused by everything I read regarding the shutdown requirements. As an embedded system the only way to turn it off is to simply shutdown the power with a switch, yet my preliminary research indicates that this is a no-no as it may damage the BBB and/or corrupt the file system. I also read a lot of comments regarding voltage on the pins after a shutdown; in my case, very likely there will be a CAT5 cable with live activity connected even after power down; assume the magnetics should protect the BBB, but just checking.
I have used quite a few micro controllers and various self-standing systems, but am fairly new to the BBB - still mostly reading about it. Am I missing something? How can a device meant to be used in embedded systems not be tolerant of power loss and be so finicky about power?
By the way, I can see there is a battery backup circuit but I do not want to use a lithium battery for safety/temperature/cost reasons. Using a large capacitor also seems tricky as the shutdown may take a few seconds so I don’t see how that will work.
I have been building embedded systems for a while now and I am considering using the beaglebone (BBB) for an upcoming project, but I am confused by everything I read regarding the shutdown requirements. As an embedded system the only way to turn it off is to simply shutdown the power with a switch, yet my preliminary research indicates that this is a no-no as it may damage the BBB and/or corrupt the file system. I also read a lot of comments regarding voltage on the pins after a shutdown; in my case, very likely there will be a CAT5 cable with live activity connected even after power down; assume the magnetics should protect the BBB, but just checking.
This is true of any system running an OS that is not red only. If you unceremoniously yank the power, you’re asking for trouble.
I have used quite a few micro controllers and various self-standing systems, but am fairly new to the BBB - still mostly reading about it. Am I missing something? How can a device meant to be used in embedded systems not be tolerant of power loss and be so finicky about power?
It sounds like you’re missing a lot. It sounds like you’ve had a lot of experience with small micros, that run bare metal, but have have no, or limited experience with using an embedded OS.
Then if you stop and think of the cost of this board, and what the goal of beagleboard.org was when the board was created. Perhaps then it become clear as to how / why we’re where we are in this context. You can fix all of this yourself, using external hardware, and custom software.
By the way, I can see there is a battery backup circuit but I do not want to use a lithium battery for safety/temperature/cost reasons. Using a large capacitor also seems tricky as the shutdown may take a few seconds so I don’t see how that will work.
Use a super capacitor, and if using a console image . . . sudo apt-get install acpid
Then the board will automatically shutdown when 5V input goes missing. I’d make sure you pick a super cap that can sustain the beaglebone for ~30 seconds, even if not needed. Just in case. Typically though, here, we see that the board shuts down within 5 seconds or so. Maybe slightly longer.
You cannot just use a supercap. You have to use a boost switching regulator to keep the voltage on the processor constant while the supercap discharges.
This is a lot more complicated than you suggest. You also have to deal with the case of brown outs where the power is only off for fractions of a seconds or cases where the power comes on and then off again before the board has fully powered up. This requires a power monitor and a state machine to only power the board on once the supercap is fully charged. Also, if you don’t recycle the power after a power fail, the BBB has the potential to lock and remains locked until the power is recycled.
Very much agree with you - even though I don’t want to use a battery, it seems more and more than a battery is a necessity for field use of the BBB, which would explain the existing connector.
Thank you for following up - I appreciate the responses.
I have been building embedded systems for a while now and I am considering using the beaglebone (BBB) for an upcoming project, but I am confused by everything I read regarding the shutdown requirements. As an embedded system the only way to turn it off is to simply shutdown the power with a switch, yet my preliminary research indicates that this is a no-no as it may damage the BBB and/or corrupt the file system. I also read a lot of comments regarding voltage on the pins after a shutdown; in my case, very likely there will be a CAT5 cable with live activity connected even after power down; assume the magnetics should protect the BBB, but just checking.
This is true of any system running an OS that is not red only. If you unceremoniously yank the power, you’re asking for trouble.
Everyone keeps using the same sentence “you’re asking for trouble” but without any more details on why that is the case. I get the file system corruption issue, just wanting to make sure there isn’t anything else.
I have used quite a few micro controllers and various self-standing systems, but am fairly new to the BBB - still mostly reading about it. Am I missing something? How can a device meant to be used in embedded systems not be tolerant of power loss and be so finicky about power?
It sounds like you’re missing a lot. It sounds like you’ve had a lot of experience with small micros, that run bare metal, but have have no, or limited experience with using an embedded OS.
I have used quite a few ‘small micros’, SBCs, DSPs with anything from bare metal, VxWorks, Linux and all kids of things, including a hardened laptop pretending to be a stand-alone SBC. But that’s not the point, most devices targeting embedded computing aren’t as fragile, or if they are, they include embedded circuitry to ensure orderly shutdown in case power is yanked, which is how you turn off a stand-alone system. In my lab, we have several robots using the Edison and logging process writing to SD card with no external power management electronics other than a switch. Over a couple of years of heavy use, there has been no issue.
Then if you stop and think of the cost of this board, and what the goal of beagleboard.org was when the board was created. Perhaps then it become clear as to how / why we’re where we are in this context. You can fix all of this yourself, using external hardware, and custom software.
By the way, I can see there is a battery backup circuit but I do not want to use a lithium battery for safety/temperature/cost reasons. Using a large capacitor also seems tricky as the shutdown may take a few seconds so I don’t see how that will work.
I have no problem handling this with external electronics (although it tilts the cost-reward curve a bit), I am just making sure that it is indeed necessary.
In my work, the solution was to use a read-only filesystem with a tmpfs overlay. I mount the boot and root partitions read-only, and configure /etc/sysconfig/readonly-root with READONLY=yes and TEMPORARY_STATE=yes. (This system runs Fedora.)
Permanent file writes are not frequently needed, but the filesystems can be temporarily re-mounted as read/write when they are required.
Also, I use a Swissbit SD card, which is more robust (and expensive) than normal SD cards, because it contains additional power-down protection.
I haven't experienced any filesystem corruption since switching to this approach.
I did use supercaps as pseudo-battery-backups for a while - the program would switch the filesystem to readonly as soon as a powerfail circuit was tripped - but the readonly+overlay approach is simpler and more robust in practice.
As someone already posted, this is a bit more complicated than that, but I get the idea.
I did not see anyone other than you, I, and Gerald post on your discussion here. But I do not get every post to this group…
But, sure . . . it is not as simple as that because while the board is still being powered, a shutdown now -h will keep one from being able to reset the board remotely. This applies to being powered by battery too.
In this case, where the board is being powered by a battery, super cap, or whatever. You need an external “device” to break VIN to the board. Or this would be a perfect example of why having a hard reset tied to a test point, or header pin would be beneficial. But we do not have this feature, so externally is a must.
As for the software. Everything is already in place except for one small piece. A userspace app that monitors the systems interrupts, particularly for the PMIC. Something similar to acpid( a daemon ), or whatever you prefer.
william@beaglebone:~$ cat /proc/irq/179/spurious
count 0
unhandled 0
last_unhandled 0 ms
Is pretty straight forward, and obvious. Things get a bit more complex, and interesting where the external solution is concerned. It is solvable though, we have solved it.
Robert has had 1 or more Beagleboard’s running a read only file system since . . . What Robert ? 2011 ? But you can search this group, and find him talking about them in a few different posts.
Very much agree with you - even though I don’t want to use a battery, it seems more and more than a battery is a necessity for field use of the BBB, which would explain the existing connector.
Having a battery still does not solve two other problems.
Does not solve situations when a powered halt occurs.
Does not solve situations where USB is required.
A “powered halt” is something akin to issuing shutdown now -h while there is still power coming in through the barrel jack, USB, or battery. I suppose while coming in over the header too, but I’ve not tested this. Anyway, when the board is “local” this is easily fixed by pressing the reset button on the board. Or, sometimes removing power - completely. When remote however . . . this proves to be a serious problem, which is only, and currently solvable by using an external device to “press” the button for you. A “smart watchdog” of sorts.
As for the USB, only a power cycle will solve this situation. When powered by battery only and the input voltage is less than 5V. You lose the USB in software, and it will not come back until at least a reboot occurs. In situations when the system must stay up, a UPS may make the most sense.
Then to be 100% clear. There is no battery connector. There are 4 test points, were soldering 4 pins can make a connector possible.
Other situations where the power goes away, and comes back quickly. Or where power comes back, and goes away quickly are problems too. Which can easily be solved as well . . .
Everyone keeps using the same sentence “you’re asking for trouble” but without any more details on why that is the case. I get the file system corruption issue, just wanting to make sure there isn’t anything else.
I think Gerald already stated this, but I think it’s worth repeating. You can burn out the processor if pins are in certain states and then removing power. I’ve been lucky myself and have done this with no harm to the two beaglebones I have physical access too. But several people here, on the groups have been “bitten” by this.
I have used quite a few ‘small micros’, SBCs, DSPs with anything from bare metal, VxWorks, Linux and all kids of things, including a hardened laptop pretending to be a stand-alone SBC. But that’s not the point, most devices targeting embedded computing aren’t as fragile, or if they are, they include embedded circuitry to ensure orderly shutdown in case power is yanked, which is how you turn off a stand-alone system. In my lab, we have several robots using the Edison and logging process writing to SD card with no external power management electronics other than a switch. Over a couple of years of heavy use, there has been no issue.
You can not compare the beaglebone to anything else out there. It’s that simple. Most things simply can not compare in cost, but if they do; these systems can not compare in shear volume of peripherals, or GPIO externally exposed. This is where most other similar SBC’s in the wild fail to compare. However, there are a few, even in the same price range that do surpass this board as well. They have other issues though . . . such as limited or poor community software support, or other problems related to drivers, or other such problems. Lastly, nothing in this price range have anything like a PRU.
I have no problem handling this with external electronics (although it tilts the cost-reward curve a bit), I am just making sure that it is indeed necessary.
If you need bullet proof certainty. Then yes, it is necessary. On both sides of power loss. Going, and coming.
I think what I am leaning on doing is providing 5V directly to the VDD_5V connector with a diode fused battery+external power through a controllable regulator, and then using a tiny micro (most likely a PIC) to monitor power loss and then trigger an interrupt on a pin to cause the shutdown, then wait for the shutdown and then turn off power. If power comes up during this process, the front end can halt powering the BBB until it is fully down.
I’ll get a couple BBBs to experiment and if this works, I’ll post what I came up with.
just use the bbb battery connector.
it works fine
then use a small micro for the watchdog/power monitoring
my hardware does this and then after a power down cuts the battery
with proper timing the bbb can stay up for ever
I think what I am leaning on doing is providing 5V directly to the VDD_5V connector with a diode fused battery+external power through a controllable regulator, and then using a tiny micro (most likely a PIC) to monitor power loss and then trigger an interrupt on a pin to cause the shutdown, then wait for the shutdown and then turn off power. If power comes up during this process, the front end can halt powering the BBB until it is fully down.
I’ll get a couple BBBs to experiment and if this works, I’ll post what I came up with.