FTDI USB interface to Propeller circuit variations

Don M

In a project I am developing I am looking to incorporate the FTDI FT232R series chip for a USB interface. I was looking at several circuit designs and I noticed several variations regarding the I/O voltage interface to the Propeller RX / TX pins.

In Ray's Logic PSB board he uses a FT232RL but according to his schematic does nothing with the 3.3 volt output from pin 17 but instead uses the USB 5 volt supply to feed the VCCIO pin 4 and then uses a 1K resistor to limit voltage to connect to the Prop on the RX and TX pins.

On the Propeller development USB boards they use a FT232RQ and utilize the 3.3 volt regulated output from the FTDI chip to drive the VCCIO so there can be a direct connection between the FTDI chip and the Prop without resistors. The same goes for the Prop Plug adaptor. Simple.

However on the Quickstart board they utilize the FT232RL and also tie the VCCIO to the USB 5 volt and instead use a 74LVC126A Quad buffer / line driver fed with the 5 volt serial signal from the FTDI chip but the VCC on the 74LVC126A is powered from the 3.3 volt regulator from the FTDI chip for direct connection to the Propeller RX / TX pins. Seems rather convoluted.

So is there a preferred way to do this? Have there been some issues in doing it one way versus another?

What am I missing here....

Don

Chris Savage

Don,

The VCCIO pin sets the output voltage level in theory. However in practive even when set to 5V the output pins seem to remain closer to 3.3V. I don't remember exactly what we measured, but there wasn't much difference between 3.3V on VVCIO and 5V on it. You could, however, test this yourself as I think our tests predated the "R" chip.

Rayman

I think copying the Quickstart would be the safest approach.
The thing to worry about is the Propeller powering up the FTDI chip and causing a reset.
The Quickstart uses a logic buffer to prevent that.

I use a 1k resistor to do the same thing and it seems to work.
I had a good reason for running the FTDI logic at 5V, but I don't remember what it was

Update: I just remembered... I have the FTDI logic at 5V so that I can use a simple p-channel
mosfet to allow the FTDI chip to control the +5V power as recommended in the datasheets....

Don M

I don't understand how the Prop could power up the FTDI chip. The only thing directly connected would be ground and the RX / TX lines. The reset line is isolated by the transistor and capacitor. The FTDI chip would be solely powered by the USB port and the Prop will have its own supply.

It would be the same as if you left the Prop Plug connected all the time to a dev board.

Has it been proven that can happen?

Phil Pilgrim (PhiPi)

If you copy the Quickstart board, be sure to add pullups to TX and RX (pulled up to Vdd, not VCCIO). If you don't need the extra handshake lines, my preferred circuit is this:



The 74LVC2G07 is open-drain and needs pullups on both outputs. Also, I neglected to add a pullup from A30 to Vdd in the above circuit. There needs to be one. For best performance at higher baud rates, I'd change all the pullups to 4.7K.

-Phil

Cluso99

There is a known issue if the FT232RL chip is unpowered (not plugged into the USB port) where power is derived from the serial output pin of the propeller (P30). In order to prevent this there are a number of solutions (series resistor, buffer the circuit with a chip incapable of supplying power via serial pin, ensure the prop code does not have the pin (P30) defined as an output when there is no USB power, provide a link on the pcb, etc). The problem manifests itself as causing the prop to continually reset after short durations.

I have always used the 3v3 for I/O power on boards with FT232RL. There is also a circuit in the FTDI datasheet which holds the FT chip in reset when there is no USB supply.

So the solution depends on the application.

BTW The prop provides power via the output pin and the protection diodes in the FTDI chip route this to the power rail in the FTDI chip. This is a common protection mechanism in many/most modern chips these days but is probably not seen because the power is usually derived from a single source. This is not always the case in USB devices.

Rayman

As Cluso says, a lot of people have had what seemed to be mysterious self-reset problems.

Turns out they were using FullDuplexSerial in there code that provided power to the Prop's TX pin.
This powered up the FTDI chip slowly (minutes) and as soon as it powered up, it reset the Prop....

Don M

Ok. I understand now. Thanks everyone.

@Phil- could you have found a smaller IC? ... I have to make this one in Diptrace.

Edit: So Phil just to be clear- you need pullups on both P30 & P31 to the Props VDD?

Define "higher baud rates". Would 115K be considered high?

Kevin McCullough

Hi Don,

Indeed there are many ways to configure the FTDI chip to accomplish various design goals

I really strongly suggest using two 1-bit buffers (with enable) for the TXD and RXD pins. See the attached example image. If you are using the RTS and CTS pins, you would want two 2-bit buffers (with enable).

Not only do you have to worry about the Propeller powering the FTDI chip through the protection diodes on the I/O pin, but you also don't want the FTDI chip powering the Propeller and other circuittry through it's I/O pins (for example when USB is plugged in but the board is switched off).

For the buffers I really strongly suggest using the 74LVC series or devices with similar type of operation (the examples shown earlier are from this series). They have inputs which are tolerant to being driven while the device is off, and are commonly used for this kind of application and for level-shifting. In most other devices, if inputs are driven when the device is off, it will flow up into the supply rail through internal protection diodes and likely power the device on. The 74LVC devices are designed for this not to happen.

Also, I suppose you could use open-drain type buffers with pullups, but you could also use normal type buffers with enabled outputs (which is what is used in the attached schematic example). It doesn't hurt to have very large pull-ups in that case (maybe around 100k) just so it floats the line high when the outputs are disabled (when they become high-impedance). Using standard driving buffers will be slightly more power efficient, and will eliminate the concern over speed due to the pull-up value.

Really either type of buffer should work (open-drain versus standard drive) but I would really suggest having buffers going in both directions.

Cluso99

We typically download at 115200, so that circuit should be fine.

Phil Pilgrim (PhiPi)

I can see the advantage of using totem-pole buffers with enable inputs for transmission speed considerations. However, even with outputs driving high, you need pullups on both A30 and A31. The one on A31 will prevent the Propeller from seeing garbage data on its serial input when the USB is disconnected and there's no power to the buffer.

As a point of reference for the open-drain buffer, I wrote a short program to test the rise time of an open-drain output (pulled up to 3.3V with a 4.7K resistor, and driving a typical capacitive load -- in this case another Prop pin). It uses FullDuplexSerial in OPEN mode at 230400 baud:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

OBJ

  sio: "FullDuplexSerial"


PUB  start

  sio.start(31, 0, 4, 230400)
  repeat
    sio.str(string($55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55)) 

Here's what the output looks like:



Even at this baud rate, the rise time should not be an issue; but as Kevin points out, the power consumption will be somewhat higher (by about 350uA average per pin when running full tilt at 50% duty cycle).

-Phil

Don M

So here is the circuit I have put together. I went with Phil's suggestion of using the 74VLC2G07 buffer and used 4.7K pullups on P30 & P31. The buffer is powered from the 3.3V (USB power) of the FTDI chip and the pullups are sourced with the 3.3V from the main power supply.

The serial port speed would be maxed at 115K. So is there really a need to go with buffers with an enable or am I good to go with what I have?

john_s

@Don M

I'd include a 500mA USB VBUS protection (polyfuse) plus resolve a 'conflict' when applying both external and USB power supplies simultaneously.
Look at the elegant circuit variants used in various Arduino designs - see Netduino example below

Rayman

I also recommend a polyfuse... Mostly to protect the PC from something bad in the circuit...
Also, I use an inductor (or ferrite bead) in series with the fuse.

Phil Pilgrim (PhiPi)

Don M,

In your schematic, you also need a pullup from the buffer's "2Y" output to VCCIO. It should work fine at 115200 baud.

john_s wrote:

...plus resolve a 'conflict' when applying both external and USB power supplies simultaneously.

What "conflict" are you referring to? He's not powering the rest of his circuit from the USB port -- only the FTDI chip and the buffer.

-Phil

Rayman

Ok, right you don't really need the fuse either if you're not using the USB power to power your Prop circuit...

There can be a conflict if you try to accomodate both USB power and external power... In that case, it's a good idea to use diodes to make sure power only goes the way you want...

Don M

Thanks everyone for your critique and comments. Phil is correct, I'm only powering the FTDI & buffer from the USB port. I had considered a fuse but decided against as I figured I'm not powering the device from the USB port. If you look again at the schematic you'll see that I had already incorporated an inductor inline with the USB power.

@Phil- comment about resistor noted and changed.