Just do it like the battery inputs allow a pin/hole for later population if required. I doubt anybody would give up any I/O pins without a fight.
On 12/2/2015 6:32 PM, Gerald Coley wrote: > We could do that. I just need some information on which pin to remove > from the expansion header. > > Gerald > > > On Wed, Dec 2, 2015 at 7:15 PM, evilwulfie <evilwul...@gmail.com > <mailto:evilwul...@gmail.com>> wrote: > > After reading all about the WDT inside the sitara the only way to > cold reset the processor is to power cycle it OR > pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC. > IT seems to me that there is some shortsightedness of TI not > allowing the cold reset to be pulsed from a WDT. > In case of a processor hang where a warm reset cannot allow the IC > to recover. > > So you may want to find that signal on the board and tie your > external WDT to it and see if this solves your problem. > Maybe in the next rev of the BBB this can be some how made > available for an external WDT. > > > > > > > On 12/2/2015 5:42 PM, William Hermans wrote: >> So just in case this is helpful to the whole process: >> >> william@beaglebone:~$ uname -a >> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 >> armv7l GNU/Linux >> william@beaglebone:~$ cat /etc/dogtag >> BeagleBoard.org Debian Image 2015-03-01 >> william@beaglebone:~$ pstree >> init-+-bluetoothd >> |-cron >> |-dbus-daemon >> |-7*[getty] >> |-rpc.idmapd >> |-rpc.statd >> |-rpcbind >> |-rsyslogd---3*[{rsyslogd}] >> |-sshd---sshd---sshd---bash---pstree >> `-udevd---2*[udevd] >> >> The output of pstree is just to show that I'm not running >> systemd, but instead sysv. >> >> On Wed, Dec 2, 2015 at 5:38 PM, William Hermans >> <yyrk...@gmail.com <mailto:yyrk...@gmail.com>> wrote: >> >> /Element14 revC./ >> /I think what you are describing is the power ramp issue. >> I don't think what I'm experiencing is the same thing. >> I've been through the power ramp issue and I just use my >> external KL16 to toggle the BBB pwr button a few seconds >> after power is applied, which kicks the board into boot./ >> /Jon/ >> >> >> Not trying to be difficult, or argumentative . . . but no, I >> think we're experiencing the same thing. Only because the >> board will not boot up Linux at all after it gets into this >> state. The LEDs will cycle on, then off, but then nothing. I >> have to physically remove the power from the board for a few >> seconds, before it'll boot again. Passed that, sometimes, the >> processes of removing the power may have to be repeated a few >> times before the board does finally boot. However this last >> part seems to mostly apply to our A5A's mostly. I do not >> recall the Element14 RevC's doing this. >> >> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross >> <jonr...@nephology.org <mailto:jonr...@nephology.org>> wrote: >> >> Element14 revC. >> I think what you are describing is the power ramp issue. >> I don't think what I'm experiencing is the same thing. >> I've been through the power ramp issue and I just use my >> external KL16 to toggle the BBB pwr button a few seconds >> after power is applied, which kicks the board into boot. >> Jon >> >> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, >> William Hermans wrote: >> >> Which board revision Jonathon ? This board I noticed >> this on last night is an Element14 RevC. But on our >> A5A's I never noticed the USR LEDs cycling like that. >> >> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross >> <jon...@nephology.org <mailto:jon...@nephology.org>> >> wrote: >> >> Got you on the script front. My issue is slightly >> different, when I get into my magic state, >> pressing the power button does nothing. >> >> On Wednesday, December 2, 2015 at 3:51:42 PM >> UTC-8, William Hermans wrote: >> >> /In my case linux is not booted at this >> time(none of the 4 user leds lit), so a >> script would not help. This is why I'm >> doing an external watchdog circuit. >> / >> >> >> Exactly. So here is what I mean. The USR LEDs >> cycle on for me *if* and only *if* I press >> the power button on the board. After that, >> nothing changes. Otherwise the LEDs are off, >> well the power LED is on, and the ethernet >> port lights are on too, and potentially blinking. >> >> The script, would just be to reboot the board >> in an attempt to put the board back into the >> bad state. For troubleshooting . . . >> >> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross >> <jon...@nephology.org >> <mailto:jon...@nephology.org>> wrote: >> >> In my case linux is not booted at this >> time(none of the 4 user leds lit), so a >> script would not help. This is why I'm >> doing an external watchdog circuit. >> >> On Wednesday, December 2, 2015 at 3:41:32 >> PM UTC-8, William Hermans wrote: >> >> /I didn't test the 8 second >> holddown of the power button but >> I doubt it would help, and >> unfortunately it's not a >> reproducible issue. I'll have to >> wait for it to happen again./ >> >> >> I know what you mean, e.g. this >> happens so erratically, it's hard to >> tell when it'll happen next. But, I >> could possibly whip up a script, and >> a means to automate resetting the >> system. Really, you could probably do >> the same as well. Just put "sudo >> reboot" in a bash script, and run it >> through rc.d >> >> With that said, I'm not 100% sure >> this is good for the board. >> >> >> >> On Wed, Dec 2, 2015 at 4:31 PM, >> Jonathan Ross <jon...@nephology.org >> <mailto:jon...@nephology.org>> wrote: >> >> I didn't test the 8 second >> holddown of the power button but >> I doubt it would help, and >> unfortunately it's not a >> reproducible issue. I'll have to >> wait for it to happen again. >> From my notes, I was seeing zero >> volts on power, 5V on reset. >> The zero volts on power was very >> weird. From the KL16 I'm >> "toggling" my own effective power >> button that is a transistor >> between the power pin on the >> header and ground. The KL16 pin >> was not driven high (I checked), >> so I don't think it was the >> transistor on the cape that was >> pulling pwr to ground on the BBB. >> And the physical button wasn't >> pressed in. It was as if the >> pullup at the PMIC wasn't active, >> yet the power LED was on. Is that >> possible? >> Wish I hadn't pulled the 5V power >> to reset, then I could do more >> testing. >> >> On Wednesday, December 2, 2015 at >> 2:11:58 PM UTC-8, Gerald wrote: >> >> I would start with your cape >> design and try and rule that >> out first. >> >> The reset is an input pin >> read by the processor, not >> actually a HW power reset. If >> the SW is locked up, this >> could happen. >> >> If you hold the power button >> for a 8 seconds or more the >> board should power cycle. >> >> When it is in this state, >> what do the voltages read? >> >> Gerald >> >> >> On Wed, Dec 2, 2015 at 3:54 >> PM, Jonathan Ross >> <jon...@nephology.org >> <mailto:jon...@nephology.org>> wrote: >> >> Once in a blue moon one >> of my beaglebones will >> get into a state where it >> has power (the power LED >> is lit), but it is not >> booted. Normally this >> would be fine, just hit >> the power button to >> reset. But in this weird >> state the power button >> does nothing. The reset >> button does nothing. >> I checked the power and >> reset button pins on the >> header, the power was >> low, the reset was high. >> The only way to get the >> board out of this state >> was to pull the 5V power. >> I'm using a KL16 on a >> cape to do a watchdog on >> the BB, and reboot it via >> power and/or reset >> buttons on the header if >> the BB stops sending >> checkins over uart. This >> has been working great, >> except for the rare case >> where the board ends up >> in this state where the >> power and reset buttons >> are not functioning. >> Any ideas how the BB >> could get into this >> state, and if there's any >> other way to force a >> reboot other than >> physically pulling the 5v >> power? >> Thanks, >> JR >> -- >> 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 >> >> <mailto:beagleboard...@googlegroups.com>. >> For more options, visit >> >> https://groups.google.com/d/optout. >> >> >> >> >> -- >> Gerald >> >> ger...@beagleboard.org >> <mailto:ger...@beagleboard.org> >> http://beagleboard.org/ >> >> -- >> 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 >> <mailto:beagleboard...@googlegroups.com>. >> 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 beagleboard...@googlegroups.com >> <mailto:beagleboard...@googlegroups.com>. >> 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 >> beagleboard...@googlegroups.com >> <mailto:beagleboard...@googlegroups.com>. >> 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 >> beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Gerald > > ger...@beagleboard.org <mailto:ger...@beagleboard.org> > http://beagleboard.org/ > -- > 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+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
