PocketBeagle GPIOs and external peripherals

[Stuart Longland]

Hi all,

I have one silly question to start off with… I have a PocketBeagle
coming, hopefully next week, and a Lattice IceStick FPGA development
board with which I'll be teaming it up with.

The plan is to produce a logic analysis and stimulus tool. I'll be
using GPIOs on both the PocketBeagle and the FPGA to control and monitor
some arbitrary logic circuit constructed on a bread board.

The project is detailed here: https://hackaday.io/project/28513

One question I have though regards the following warning:
> NOTE: Do not connect 5V logic level signals to these pins or the board will be damaged.
>
> NOTE: DO NOT APPLY VOLTAGE TO ANY I/O PIN WHEN POWER IS NOT SUPPLIED TO THE BOARD. IT WILL DAMAGE THE PROCESSOR AND VOID THE WARRANTY.
>
> NO PINS ARE TO BE DRIVEN UNTIL AFTER THE SYS_RESET LINE GOES HIGH.
--
https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#71_Expansion_Header_Connectors

Now point one is fine. It's a 3v3 device, and I plan to put a voltage
clamp circuit (two resistors, a 3V3 zener and a Schottky diode) in front
of the GPIOs anyway just to prevent accidents.

Point two worries me a bit from two points:

1. UART0 connection to a TTL-UART interface
2. Pull resistors

In the former case, it'd be nice to have access to the actual console of
the PocketBeagle. Whether I hard-wire a USB-TTL serial adaptor or
TTL-RS232 driver chip, or whether I just expose the headers for
something to be wired up later I'm not certain, but the fact that TTL
UART always idles high, means that any driver or adapter IC I wire up to
these pins, is *going* to be presenting a voltage on the UART0 RX pin.

In the latter case, it's common for particular signals to have
pull-resistors attached. Notably I²C, chip select lines, interrupt
lines and reset lines. Again, the moment power is applied, a voltage
will appear on those pins.

A workaround might be to hook a MOSFET switch up to the aforementioned
SYS_RESET line (which I'm guessing is *actually* called NRST on pin
P2.26; or even a software-driven GPIO), and have that switch turn on
power to the FPGA and other peripherals.

The FPGA boots up on its own right now, but I plan to remove the EEPROM
on it so that I can just load the SRAM on it directly. I notice though
when the EEPROM is erased that there's a slight glow of the user LEDs on
the FPGA board, which suggests to me that other pins may present a
voltage too.

12 pins of the FPGA will be hooked directly up to PRU0 pins exposed on
PocketBeagle, the thinking being this will give me a nice high-speed
8-bit wide comms link, with PRU0 providing the interface between the CPU
and FPGA.

How have others handled this requirement of not supplying voltages on
the GPIO pins during power up?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[Graham]

An FTDI 3.3 Volt USB to UART0 connection will not blowup or hurt anything.

You an hook it up and leave it hooked up, and not have to worry about damaging the Pocket Beagle,

A 10K pullup to +3.3 V is also OK, but not actually required for the FTDI cable to work.

Something like the   TTL-232R-3V3-WE   for wire pigtails.

The damage warning is for things that will try to drive pins with currents high enough to damage semiconductor circuits and/or ESD protection circuits.

Or, in the case of the boot pins, something that will over-ride a 100K resistor.

--- Graham

==

[Stuart Longland]

On 17/12/17 00:34, Graham wrote:
> An FTDI 3.3 Volt USB to UART0 connection will not blowup or hurt anything.
> You an hook it up and leave it hooked up, and not have to worry about
> damaging the Pocket Beagle,
> A 10K pullup to +3.3 V is also OK, but not actually required for the
> FTDI cable to work.
>
> Something like the   TTL-232R-3V3-WE   for wire pigtails.
>
> The damage warning is for things that will try to drive pins with
> currents high enough to damage semiconductor circuits and/or ESD
> protection circuits.
> Or, in the case of the boot pins, something that will over-ride a 100K
> resistor.

Ahh okay… yeah I used UART here as it's an example of something that
would be generally wired up continuously and has the property of
presenting a voltage when idle using push-pull logic. I'd likely use
the MAX232 for a console port.

By the sounds of things, the problem is more down to inrush current than
voltage alone, and clearly the AM3358 doesn't have its pins in
high-impedance mode at boot-up or else it'd be impossible to achieve
those current levels. 3v3 in series with a megohm or more is never
going to produce more than 3µ3A, and GPIOs in "input" mode often have a
resistance in that ballpark. A GPIO driven as a low output however,
could get nasty.

The plan was to have a series resistor, so this should be sufficient to
prevent catastrophe.

[Graham]

Worst case is prior to the chip being powered up, or while the rails are being sequentially raised.

In that case, internal power can be a low as zero, and ESD diodes on each pin can conduct at 0.7 Volts.

You damage individual pins or can avalanche the whole chip if you can drive enough current.

--- Graham

==