Just want to verify something… I an not using HDMI, McASP, gpmc, UARTs, the ADC or I2Cs. I am using the EMMC. Just SPI0 and a bunch of GPIOs.
Can I assume that any P8/P9 pins labeled as GPIO in some mode, and not labeled “allocated for EMMC2”* on Derek Molloy’s helpful P8/9 charts is available for GPIO purposes?
Are there any other preallocated P8/9 GPIO-potential pins I need to watch out for? Just checking before I commit the cape from Hell to fab.
Thanks,
Mike
= gpmc_be1n, gpmc_clk, gpmc_dat0-7, or P8 pins 3-6 and 20-25.
In addition to not driving the boot pins while reset is asserted
(unless you're intentionally trying to change the boot mode), you also
need to watch out for the cape EEPROM I2C lines (P9, pins 19 and 20).
These pins will be in I2C mode at boot-up, and will be twiddled by
the cape manager as it looks for any connected capes.
Thanks guys. I will not be driving anything at boot, as all the cape pins are initially configured as inputs.
Surprisingly, I did read sections 6.7 and 8.3. It would have been nice if the P8 pins had been referenced in those diagrams, rather than having to trace the schematics.
In the case of those boot programming pins, the definition of “not-driven” includes NOT LOADING the pins.
If you are using CMOS inputs on I.C.s that are already powered up, then O.K.
If the the “inputs” that you are hanging on the boot pins are ICs that are not powered up yet (because you
used the VDD_3V3B rail to power them), then the ESD diodes are putting a short to ground on the boot pins.
If the “inputs” that you are hanging on the boot pins are bipolar transistors, with pull down resistors
in the circuit, you could be over-riding the boot instruction “highs” and turning them into lows.
So you’re saying that VDD_3V3B does not come up quickly enough to power external devices before the boot configuration is read from the pins? You’d think we should have held off boot a little longer until supplies settle. Given there’s no P8/9 accessible way to prolong boot, short of driving a tiny solenoid to hold the reset button down a little longer, how might one isolate the input protection diodes until bot is safely started?
I think my answer lies in that the cape is also providing the 5V to the BBB, so I can delay that until my own 3.3V supplies stabilize. Seems a waste of the 3.3V regulator on theBB though. Perhaps manipulating the PWR_BUT (PB_IN signal on the TPS65217C PMIC) on P9 might solve this…
My loadings are a single LVC gate on each line, so basically nothing there.
Thanks for the advice. Do you think a delayed reset via the PWR_BUT signal would provide the answer?
So you're saying that VDD_3V3B does not come up quickly enough to power
external devices before the boot configuration is read from the pins? You'd
think we should have held off boot a little longer until supplies settle.
Given there's no P8/9 accessible way to prolong boot, short of driving a
tiny solenoid to hold the reset button down a little longer, how might one
isolate the input protection diodes until bot is safely started?
<snip>
My loadings are a single LVC gate on each line, so basically nothing there.
You can use parts specified and designed for hot-plug, which will not
load the bus until the supplies stabilize. Alternately, you can use
some of the FET isolation/voltage-translation parts (also commonly
used to make designs hot-plug safe) which will also not conduct until
the power rail is active.
...and the rest of the book for lots of part info. and other
application details.
Or you could just run your buffers off 5V (with TTL level inputs, like
an HCT series part) and not have to worry about loading the boot pins
before the 3.3V rail comes up. But I don't know what you're driving,
so that may not be an option.
I think the VDD_3V3B rail is deliberately held off until the unit has started booting,
and has already read the boot instructions. It is not a rise time issue.
I suspect it was done deliberately to help with the “don’t drive the rest of the pins” issue.
A little 5V to 3.3V regulator to power your LVC “input” IC will work nicely.
Provided that it is powered at the same time the BBB is.
That is, use VDD_5V if powered from the power jack.
Relative to power appearing at the power jack:
SYS_5V is delayed 50 ms.
VDD_3V3B is delayed 100 ms.
SYS_RESETn is delayed ~130 ms.
I have not measured power supply sequencing when powered by USB.
Or if you are dealing with both I and O on the boot pins, use something like
a 74CBTLV3126 bus switch / transmission gate to isolate your circuitry
from the BBB while it is booting. Just make sure the bus-switch / transmission-gate
You may have seen I mentioned that no signals would be driven onto the BBB expansion headers until enabled to do so (if I forgot to mention that, they won’t be); all other pins are inputs to the expansion card and thanks to Graham’s advice will be powered first to ensure protection diodes will not interfere with the boot configuration.
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.
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.
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.
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.
If it were so… but it seems with such an abundance of modes and pins, a number of the pins I am using are in a variety if input, output, hi-Z and I/O defaults at powerup, most often with pullup or pull-downs. The good news is, I’ve added enough gating and the additional fast-starting Vdd to avoid conflicts. SPI attached peripherals (powered early) all need commands shifted in to drive outputs, so that’s safe too.
Now for the next Beaglebone, innocuous I/Os would be a great feature…
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.
Completely understood; however, assuming one could meet board area and timing constraints, it might be possible to wrap the processor with a circuit prophylactic, as it were…
I’ve also been part of several ARM-based core silicon projects, and it would have been possible for that (i.e. consistent pre-reset I/O state) to have been addressed at the chip level.
...and actually, given today's near zero-load CMOS inputs, having an
assortment of I/O with pull-up and pull-down configured at reset makes
it possible to directly tie GPIO pins to important signals (like chip
selects or output enables) without having to add hardware inverters.
I made good use of this capability (and the assortment of AM335x ball
reset states) when designing the CRAMPS board, but it does take some
planning and quite a bit of care to not mess anything up.
