Well, by definition, the boot programming pins are going to have the pull-ups / pull-downs, so you know what they are going to be doing, until over-ridden.
Most processors start up with the programmable pins as inputs, then move to the configured state. Anything else can be dangerous to the pins. But, as Charles says, RTFM. If you are concerned, use the bus-isolation /transmission-gate chips, power them early, supply your own pull-ups/pull-downs, and switch the connection on when SYS_RESETn goes high. Then you are unconditionally safe, and in-control. --- Graham == On Mon, Sep 7, 2015 at 6:43 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/7/2015 6:26 PM, rattus wrote: > > This does beg one last question - as I am using expansion connector pins > to > > provide chip selects for numerous peripherals, what is the default state > of > > the AM335X pins at powerup, until the boot configuration is loaded? I've > > slogged through the TRM as best I could, but want to make sure we're not > > inadvertently enabling multiple chip selects that may drive competing, > say, > > SDOs (peripheral) into SDI (cpu) before the boot configuration is loaded. > > > > Ideally, they would be defaulted as inputs or tri-stated outputs, in > which > > case a weak pulldown on the peripheral CSn lines should keep things > quiet. > > Despite my best efforts at searching the 4K+ pages of the TRM, I have not > > found a clear answer as to the pre-boot load default pin configuration. I > > probably missed it, but my search-fu fails me. > > You want the AM335x data sheet (currently SPRS717H): > > http://www.ti.com/lit/gpn/am3358 > > Refer to section 4.2, starting on page 18. You are interested in the > "BALL RESET STATE" and "BALL RESET REL. STATE" (Table 4-1, pages > 20-50). These indicate the state of the various pins when reset is > asserted (at power up, or when being physically reset), and the value > once reset is released (this value will be held until application > software* changes it). The reset release state is _usually_ (but not > always) the same as the state when reset is asserted. > > NOTES: > * "Application software" can be anything from the on-chip ROM > boot-loader to U-Boot to the Linux kernel to your running user-mode > program. > > You have to also review the BBB schematics to see if there are any > pull-up/pull-down resistors or other drivers or loads connected to a > GPIO pin that might affect the state prior to specific configuration > of any I/O pin by software. > > -- > Charles Steinkuehler > char...@steinkuehler.net > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/g_gNimjfQhg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > 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.
