Re: [beagleboard] Re: PocketBeagle GPIOs and external peripherals
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 == On Saturday, December 16, 2017 at 3:08:43 PM UTC-6, Stuart Longland wrote: > > 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. > -- > 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/0d7c8b93-fe86-4ba1-993a-fc137424f498%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PocketBeagle GPIOs and external peripherals
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. -- 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/61a7950d-69e7-5383-2bd0-aa1e37d582f1%40longlandclan.id.au. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: PocketBeagle GPIOs and external peripherals
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 == On Saturday, December 16, 2017 at 12:19:28 AM UTC-6, Stuart Longland wrote: > > 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/e48dd7b9-d342-41ce-910e-809a7105c358%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: i2c bus speed
Following your example I'm trying to set 400KHz on my i2c-1 too. I have a
Beaglebone Black WIRELESS that loads am335x-boneblack-uboot.dtb as overlay.
UBOOT: https://pastebin.com/hA4RbNUm
1) Decompilation: dtc -I dtb -O dts -o am335x-boneblack-uboot.dts
am335x-boneblack-uboot.dtb
2) Actually my i2c-1 is disabled. *WHY*?
i2c@4802a000 {
> compatible = "ti,omap4-i2c";
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> ti,hwmods = "i2c2";
> reg = <0x4802a000 0x1000>;
> interrupts = <0x47>;
> status = "disabled";
> linux,phandle = <0xa6>;
> phandle = <0xa6>;
> };
I edited it with
status = "okay";
> clock-frequency = <0x61A80>;
>
3) Compiling: root@beaglebone:/boot/dtbs/4.4.91-ti-r139# dtc -I dts -O dtb
-o am335x-boneblack-uboot.dtb am335x-boneblack-uboot.dts
4) Reboot
> i2c-2 still 100KHz. Why?
debian@beaglebone:~$ dmesg | grep i2c
[1.617222] omap_i2c 44e0b000.i2c: could not find pctldev for node
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c0_pins, deferring
probe
[1.618167] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[1.619474] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[2.341082] i2c /dev entries driver
[2.572081] input: tps65217_pwr_but as
/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/input/input0
[2.598709] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
--
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/24e3e6bb-0701-4dee-b55e-1aba149b3656%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Flir Lepton 3 and I2C
Actually seems that the mCciPort (first parameter in LEP_OpenPort) doesn't stand for the I2C bus but for a user-defined id number for the camera. So actually the problem moves to "How do tell the SDK to read from I2C-2 instead of I2C-1"? The SDK uses libmpsse, I think. In order to test the problem, I tested a BMP sensor that uses Adafruit_GPIO.I2C python library: it creates a Device instance where I can set Adafruit_PureIO.smbus.SMBus(busnum). In fact if I don't set busnum=2, it uses I2C-1 and dmesg reports "timeout waiting for bus ready". If I set busnum=2 I can read values from the sensor. Any idea? -- 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/efb59730-a354-448a-a539-65f63fd5ceb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
