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 <[email protected]> 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 <[email protected]> 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 < <[email protected]> >> [email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>>> 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 <[email protected] >>>>>>>> > 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 < >>>>>>>>>> [email protected]> 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> >>>>>>>>>>> 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]. >>>>>>>>>>> For more options, visit <https://groups.google.com/d/optout> >>>>>>>>>>> https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Gerald >>>>>>>>>> >>>>>>>>>> [email protected] >>>>>>>>>> http://beagleboard.org/ >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> For more options, visit <http://beagleboard.org/discuss> >>>>>>>>> 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]. >>>>>>>>> For more options, visit <https://groups.google.com/d/optout> >>>>>>>>> https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> For more options, visit <http://beagleboard.org/discuss> >>>>>>> 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]. >>>>>>> For more options, visit <https://groups.google.com/d/optout> >>>>>>> https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> For more options, visit <http://beagleboard.org/discuss> >>>>> 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]. >>>>> For more options, visit <https://groups.google.com/d/optout> >>>>> https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> For more options, visit <http://beagleboard.org/discuss> >>> 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]> >>> [email protected]. >>> For more options, visit <https://groups.google.com/d/optout> >>> 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]. > 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]. > For more options, visit https://groups.google.com/d/optout. > -- Gerald [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
