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. -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/664236e5-c6fd-b8f1-c7bc-7ed326580fa2%40longlandclan.id.au. For more options, visit https://groups.google.com/d/optout.
