Those pins are the LCD pins also. Please read the tables for the pin outs and you will see signals labeled LCD. That is why they wee brought out.
Sorry for the poorly written sentence. Sorry for your bad experience. I would have been happy to review your design before you went to that expense. I will not take credit for designing the processor. I leave that to TI. If you think the design is bad, I respect that. But I did not design the board for your application or your circuit. Gerald On Thu, Apr 23, 2015 at 7:02 PM, Kenneth Martin <[email protected]> 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]> > 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 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]. > 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.
