We can do that. Nothing pending that calls for a design update. So, it will be a while.
Gerald On Wed, Dec 2, 2015 at 7:58 PM, evilwulfie <[email protected]> wrote: > 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 <[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]> >> [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]> >>>>> [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]>[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]>[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]>[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]> >>>>>>>>>>>> [email protected]. >>>>>>>>>>>> For more options, visit <https://groups.google.com/d/optout> >>>>>>>>>>>> https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Gerald >>>>>>>>>>> >>>>>>>>>>> <[email protected]>[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]> >>>>>>>>>> [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> >>>>>> 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> >>>> 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]> >> [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. > > > -- > 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.
