> > > > *Gerald, I do not have this setup yet, but perhaps in the future may have > the means. Is this something that might be easily checkable via JTAG ? I've > never used JTAG before, and do not have the header in place, but do have a > JTAG emulator.* > *One thing that has been stopping me from seriously considering this as a > debugging option, is that I do not know if there is an open source ( gcc - > as in GNU compiler collection - Not the compiler its self ) tool. Passed > that, it's all new to me, and probably a steep learning curve initially.* >
I'll take the "sound of crickets" reaction as this is too complicated a question to answer ;) I'll look into it on my own at some point . . . On Wed, Dec 2, 2015 at 5:27 PM, William Hermans <[email protected]> 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 >>>>>>>> --- >>>>>>>> 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. >>>> >>> >>> -- >> 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.
