BeagleBone Black SRM Version C.1 Section 6.7 Boot Configuration Design, Page 67.
See Page 68, Figure 38. Yes, DNI means Do Not Insert. Or some time the term NP , meaning No Pop or "do not populate" is used. Section 6.8 Default Boot Options, Page 68. It is covered again on page 106, Section 8.3 Pin Usage Considerations. --- Graham == On Fri, Apr 24, 2015 at 1:04 PM, Bit Pusher <[email protected]> wrote: > I totally understand their are many compromises in designs; I just wish > there was documentation; in this case, I find it sadly inadequate. Finally, > the input is another GPIO header pin that has a reset defaultof input with > a pull down which I believe is about 23K (it took me 2 hours to find > documentation on reset defaults - one statement in a very large TRM table > describing registers stating to look at data sheets, about 1 hour to find > and understand in data sheet where the mux reset defaults are given) . If > the pull-up and pull-down resistors on the board had been chose to be > something like 4.7K this error would not have happened, and I don't believe > this would have any impact on power except maybe 0.7mA additional current > just during the time the boot button is pushed at power up, which is > insignificant. > > On Thursday, April 23, 2015 at 11:28:53 PM UTC-4, Graham wrote: > >> Kenneth: >> >> There are fifteen lines, and a field of 100 K Ohm resistors that tell the >> Sitara how to boot. >> There are locations for a pull up and a pull down on each of the boot >> instruction lines. >> Only one of those resistors is populated for each line. Read the SRM. >> >> Any load that would cause a logic state established by a 100K resistor, >> pull up or pull down, to change logic state, will modify, and likely kill >> the boot process. >> >> If your "input" was a CMOS gate, it would probably have worked. >> If your "input" was one of those Panasonic driver transistors with the >> built-in resistors to ground, you are changing the boot instructions by >> attaching it. >> >> --- Graham >> >> == >> >> >> On Thursday, April 23, 2015 at 9:23:08 PM UTC-5, 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]> >>> 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 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.
