> > *My next step was actually to watch /proc/interrupts, which actually I > think I'm still going to do. In order to see if there are in fact any > interrupts happening from all this pin toggling im doing.* >
No dice. But before I give up I'm going to switch form a TI kernel to a bone kernel and see if any of this changes. Because I know that tje reset btn works, and is sometimes especially useful after a Linux "halt". On Tue, Jul 5, 2016 at 12:30 PM, William Hermans <[email protected]> wrote: > AM335x is the TRM name. But I was afraid I would get jumped because that >> is not the processor used, instead it is the AM3358. >> >> Look up AM3358 and select the TRM listed on that page. >> >> Gerald > > > I don't think anyone would get on your case over saying "AM335X". But I > was starting to wonder if there was an additional "tome" I was unaware of. > I've actually had a copy of the TRM for years now on disk. Including the > original with the PRU information in it :) > > Thanks for the information ! > > On Tue, Jul 5, 2016 at 12:25 PM, Gerald Coley <[email protected]> > wrote: > >> AM335x is the TRM name. But I was afraid I would get jumped because that >> is not the processor used, instead it is the AM3358. >> >> Look up AM3358 and select the TRM listed on that page. >> >> Gerald >> >> >> On Tue, Jul 5, 2016 at 2:23 PM, William Hermans <[email protected]> >> wrote: >> >>> *In the AM3358 TRM. It is an interrupt input to the processor. The SW >>>> can cleanup before making it an output to reset the board. So, if the SW >>>> does not handle it, it does not reset anything.* >>>> >>>> *Gerald* >>>> >>> >>> Thanks Gerald. >>> I kind of figured already that about the software aspect. I'm toggling >>> the pin every 5 seconds ( 5, So I can check with a multi-meter ) from an >>> external MCU. And the board just sits there like a dumb brick . . .no >>> reaction. >>> >>> AM3358 TRM ? Is that in addition to the AM335x TRM ? The latter here is >>> what I've searched through. Which by the way for SYS_RESET no search hits >>> in the whole 5k pages of document . . . That's a bit frustrating. The SRM >>> actually turned up several hits, but did not really discuss anything >>> definitive. Then, as Charles pointed out after your post . . . I always >>> forget about the datasheet . . . but forgot that TI loves spreading >>> documentation out over several files . . . >>> >>> On Tue, Jul 5, 2016 at 12:04 PM, Charles Steinkuehler < >>> [email protected]> wrote: >>> >>>> On 7/5/2016 1:29 PM, William Hermans wrote: >>>> > @Gerald >>>> > >>>> > So hey where can I find good official documentation on SYS_RESETIN ? >>>> I've poured >>>> > over the SRM, and the TRM, and have not really found any clear >>>> documentation on >>>> > the subject matter. Also, what little the documentation does mention >>>> anything, >>>> > names are confused between SYS_RESET, SYS_RESETIN, RESET_OUT, or RSTn >>>> . . . How >>>> > does one make sense of all this ? >>>> >>>> Section 8.1.7 of the TRM "Reset Management", with some additional >>>> details in the data sheet (sprs717). It can be confusing, since the >>>> physical reset pin (nRESETIN_OUT) is both an input and an output, but >>>> the individual RESET_IN and RESET_OUT signals are "broken out" on-chip >>>> and have various sources/destinations which are discussed individually >>>> in the TRM. >>>> >>>> Figure 8-20 "External System Reset" in the TRM (and the nearby related >>>> text) might help. >>>> >>>> -- >>>> Charles Steinkuehler >>>> [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/f47f8869-670e-1c6a-7627-194bbd5f5e2f%40steinkuehler.net >>>> . >>>> 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/CALHSORqLBUz8S61-4iRfqyOAhgsfFxrRsyX1H8KVkJiaQuLSjQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/beagleboard/CALHSORqLBUz8S61-4iRfqyOAhgsfFxrRsyX1H8KVkJiaQuLSjQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> 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%2Bd6O9yabydHjUAJ2yBm7tAwHknYFiV-hbTbTWj6Kxnesg%40mail.gmail.com >> <https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Bd6O9yabydHjUAJ2yBm7tAwHknYFiV-hbTbTWj6Kxnesg%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORopoh%3Dd%2B-pu8WHkQmCZP8mziaQU-SUWYVx3b9UOrdDzNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
