ANY load can affect how they are read. These pins are already well loaded as it is. If you want to use them, use a buffer to isolate them until after the processor is running.
Gerald On Thu, Apr 23, 2015 at 12:20 PM, Bit Pusher <[email protected]> wrote: > This is not clear as they are connected to other inputs which I would > normally think means they are not being driven. Is there a definition you > can give a link to defining what driven is? Also, can you supply a link of > how to control and what are the mux defaults before boot? Thank you. > > > On Thursday, April 23, 2015 at 12:29:26 PM UTC-4, Wulf Man wrote: > >> you are messing with the boot pins. its been stated here 100s of times >> you cannot do anything to these pins before board boots. >> check the BBB schematic and the using the bbb board guide., >> >> >> On 4/23/2015 9:09 AM, Bit Pusher wrote: >> >> I have found a reproducible boot freeze (on two boards); could someone >> else possibly check; it's very easy to try. >> No connections besides power plug and one (or two) wires from header P8 >> to P9 >> Scenario 1: connect P8-43 to P9-30, plug in power, only power light comes >> on and BBB does not boot up >> Scenario 2: connect P8-44 to P9-28, plug in power, only power light >> comes on and BBB does not boot up >> Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in >> power, power light and all 4 LEDs come on steady and BBB does not boot up. >> >> Discussion: >> 1) doing these tests numerous times on 2 BBB's did not hurt either one of >> the boards I have, but this behavior is so strange that it might be risky; >> please don't be upset with me if it hurts your board. >> 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 >> 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is Debian wheezy 7.8 >> 3) without wires connected, after booting and doing a >> >sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows >> ... >> pin 42 (44e108a8) 0000002f (this is P8-43 in mode 7 which should be >> gpio2_8) >> pin 43 (44e108ac) 0000002f (this is P8-44 in mode 7 which should be >> gpio2_9) >> ... >> pin 102 (44e10998) 00000027 (this is P9-30 in mode 7 which should be >> gpio3_17) >> pin 103 (44e1099c) 00000027 (this is P9-28 in mode 7 which should be >> gpio3_16) >> >> Therefore at boot, pins P8-43 and P8-44, without applying device trees, >> are both configured as inputs with pull-downs; >> pins P9-30 and P9-28, without applying device trees, are both configured >> as inputs with pull_up/pull_down's disabled. >> >> 4) making the connections after boot does not have any discernible >> effects >> >> 5) It seems to me that having two gpio's connected together with both >> configured as inputs and one having a pull-down should not cause the BBB to >> freeze at boot. >> 6) It is also interesting that having two connections as in 5) causes >> different behavior; that is the boot process goes further to light all four >> LED's and then freezes. >> >> Could someone check to see if they are getting similar behavior; I >> can't imagine that I am doing something real stupid with only a single wire >> connection; but I have previously done many rather stupid things so you >> never know (without verification). >> >> Would someone in the expert category have some suggestions how to get >> around this problem; if we can't find a work around, months and months of >> work will be thrown away. For example, if we configured the device tree >> that is loaded at boot up, would it take precedence before the default pin >> mux that causes the freeze (if this happens to be the problem, currently we >> have no insight into what is causing this behavior). >> >> Has anyone else seen similar problems (we may also have something funny >> with connections to P8-45 and P8-46 but have not tracked this down yet to >> simple scenarios. >> >> I'm open to suggestions as we are currently stuck. Thanks. >> -- >> 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/ http://circuitco.com/support/ -- 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.
