dont you prototype your very first one and test it before you order production boards ?
If you would have searched this forum for boot mode or you may have found your issue. test a proto first. the information is there for the reading. On 4/23/2015 5:02 PM, Kenneth Martin wrote: > If they cause the BBB to not boot, by hooking an input to them, I > would argue they should never have been brought out to the header, and > that examples of how to handle this sensitivity while still making use > of the header pins should be more readily available. The documentation > on this sensitivity appears to be a single poorly written paragraph in > the SRM which only states they should not be driven (actually 3 lines > only in section 7.12.1 following Fig 58; to be specific: "/If you plan > to use any of these signals, then on power up, these pins should not > be driven. //If you do, it can affect the boot mode of the processor > and could keep the processor from //booting or working correctly/." I > can't see this addressed anywhere else in the documentation). It > should state that not even inputs can not be connected to these header > pins. There is no documentation that I can see on why they were even > brought out to the header. Issues like this make other alternatives to > using the BBB's look more attractive (such as the new PI). At a > minimum, this will cost us another 4 lost weeks and $2K for new > populated boards for another iteration on our cape. Very frustrating, > and I would argue both poor design and poor documentation. Looking at > the schematic, it appears the existing load on each pin is 2 100K > resistors? If this is correct, I would not call this "well loaded" > when a typical gpio output current is 4-6mA. > > On 15-04-23 02:08 PM, Gerald Coley wrote: >> 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] >> <mailto:[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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Gerald >> >> [email protected] <mailto:[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 a topic in >> the Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/kMTzEq_A_AY/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] >> <mailto:[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] > <mailto:[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.
