Fair enough. 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. On Tuesday, May 3, 2016 at 2:29:23 AM UTC-4, William Hermans wrote: > > *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. > > > > On Mon, May 2, 2016 at 3:55 PM, William Hermans <[email protected] > <javascript:>> wrote: > >> *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/interrupts >> CPU0 >> 16: 2671562 INTC 68 Level gp_timer >> >> . . . >> >> 179: 20 INTC 7 Level tps65217 >> Err: 0 >> >> 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. >> >> On Mon, May 2, 2016 at 11:55 AM, Yiannis Papelis <[email protected] >> <javascript:>> wrote: >> >>> As someone already posted, this is a bit more complicated than that, but >>> I get the idea. >>> >>> On Monday, May 2, 2016 at 2:09:44 PM UTC-4, William Hermans wrote: >>>> >>>> *Use a super capacitor.* >>>>> >>>> >>>> Ok, a little abstract . . . >>>> >>>> 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. >>>> >>>> On Mon, May 2, 2016 at 10:47 AM, William Hermans <[email protected]> >>>> wrote: >>>> >>>>> *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.* >>>>>> >>>>>> *Any suggestions would be greatly appreciated.* >>>>> >>>>> >>>>> Use a super capacitor. >>>>> >>>>> >>>>> >>>>> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Any suggestions would be greatly appreciated. >>>>>>> >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> Main reason for the shutdown process is the corruption of the Linux >>>>>> file system. >>>>>> >>>>>> If you have power on any signal when the processor is shutdown, then >>>>>> you are asking for trouble. >>>>>> >>>>>> >>>>>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage >>>>>> >>>>>> >>>>>> Gerald >>>>>> >>>>>> [email protected] >>>>>> http://beagleboard.org/ >>>>>> [email protected] >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BergZ8%2BPd5zBdxsHqJDzQphgPXKXF0oayzjV1PVHPY8kw%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BergZ8%2BPd5zBdxsHqJDzQphgPXKXF0oayzjV1PVHPY8kw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> -- >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/20708452-03c7-4c66-9e22-bd0cdd009806%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/20708452-03c7-4c66-9e22-bd0cdd009806%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/716c3ab5-5ea6-40c8-96d2-2c60b5077a2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
