[SOLVED] help interfacing FTDI with existing project

[anishkgt]

Hi All,

i am trying to interface an FTDI found herehttps://www.sparkfun.com/datasheets/DevTools/Arduino/FTDI%20Basic-v21-5V.pdf. I've eliminated PIN 17 as the FTDI would be power by the USB port.

Would somebody please verify if the schematic i've put up is correct.

[Ian.M]

Your schematic shows an external power supply and 5V regulator feeding the 5V rail and the same 5V rail directly connected to the device's USB Vbus.  That is strictly forbidden by all revisions of the USB standard, and risks damaging any host port connected to it.   However from your text above, I understand you actually intend to power the FTDI chip separately from USB Vbus and *NOT* link it to the main 5V rail.
That can have problems with one power domain feeding parasitic power to the other (see https://www.eevblog.com/forum/blog/eevblog-831-power-a-micro-with-no-power-pin!/) which could damage or cause incorrect operation of the FTDI chip or the ATmega8 if its ever operated without both power sources connected (USB and external).   The easiest fix is to insert a dual supply level translating buffer that supports partial powerdown isolation, in each data or control line e.g. 74LVC1T45, with separate supplies to the buffer's two power pins, each fed from the same power domain as the signal connected to it.  That way, if one side is powered down, the buffers are tristated and don't pass signals from the still powered side.   As you are using Arduino style capacitive coupling for RTS to RST, you don't actually need a buffer on that line (though it may reset when the USB is connected/disconnected without one), so, as CTS is grounded, you only need to buffer the data lines.

[anishkgt]

Thank Ian.

I was just using the FTDI break out as a reference while designing. I am not sure i get it what you. Though you would be clear to the experienced. I think may have posted on the wrong thread. Maybe beginners would be the one for me.

Your schematic shows an external power supply and 5V regulator feeding the 5V rail and the same 5V rail directly connected to the device's USB Vbus

if i understadn what you meant, are the two 5v supplies the same ? The Atmega is powered by its on power supply from the mains named +5v and the FT232RL is powered by the USB power  named as 5v.

And yes whenever i connect the breakout board to my existing project it resets several times and then stabilizes, how can i fix it here ?

[rstofer]

All of the legitimate power schemes are described starting on page 23 of the datasheet:

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

What you can't do is have 2 sources for 5V tied together.

[Ian.M]

Ah! I didn't spot the subtle naming distinction between '5V' and '+5V'. 
Ignore my first sentence.  Also, consider renaming the USB '5V' as '5V_USB' or '5V_Vbus' to avoid future confusion. 

The problem with resetting when connected is more difficult.  The Arduino reset circuit capacitively couples a negative transition on RTS to the MCU reset pin so AVRDUDE can reset it, with the capacitor preventing a a sustained low level holding it in reset.  However, when RTS goes back high, the capacitor is now charged to 5V so briefly drives the reset pin to 10V, discharging to 5V via the reset pullup resistor.  This is very close to the 12V HV programming voltage of an AVR so it may effectively reset it again by briefly entering HV programming mode.   Also, what happens to RTS while the USB plug is being inserted or removed?  Unless it transitions cleanly between hi-z and logic high, a reset is almost certain.

To avoid this behaviour is quite difficult - the easiest option is a manual switch to connect RTS and enable programming.  If you want to automate it, you need to drive reset from an open drain buffer fed by a non-retriggerable monostable fed by RTS to limit the reset pulse duration, gated with a power good signal form a PSU supervisor IC monitoring USB Vbus to provide a power on delay before enabling RTS reset, and disabling it immediately on power off.

Depending on the terminal or comms software used on the host, opening the USB comm port without briefly pulsing RTS low can be even more problematic.  . . . .

[anishkgt]

The problem with resetting when connected is more difficult.  The Arduino reset circuit capacitively couples a negative transition on RTS to the MCU reset pin so AVRDUDE can reset it, with the capacitor preventing a a sustained low level holding it in reset.  However, when RTS goes back high, the capacitor is now charged to 5V so briefly drives the reset pin to 10V, discharging to 5V via the reset pullup resistor.  This is very close to the 12V HV programming voltage of an AVR so it may effectively reset it again by briefly entering HV programming mode.

ahmmmmmmm........FRENCH FRECNH. i guess i'll just stick to how it is now.

what happens to RTS while the USB plug is being inserted or removed?

That is what is happens i have an LCD connected and it just blinks 3 or 4 times and continues to initialize.


So theoretically this would be ok to etch, correct ?

[Ian.M]

So theoretically this would be ok to etch, correct ?

You haven't made any provision to isolate the TX and RX signals when the USB isn't connected.    In each data line I  strongly recommend adding an unpopulated footprint for a 74LVC1T45 buffer and also pads next to it for a 1K resistor between its input and output bridged by a thin jumper track you can easily cut with an Xacto knife.  If you encounter any problems with back-powering, you can cut the jumper track, and populate the resistor.  If a simple resistor to limit back-powering isn't good enough, you can remove it and fit the 74LVC1T45 to provide proper power domain isolation.

For the RTS line, I'd simply put a footprint for a pair of jumper pins, again bridged by a track you can cut.  If, later on, you need the AVR to run uninterrupted by USB connection events you can cut the track and populate the jumper or hook up a switch.

Also I didn't check your RX/TX hookup, so double check its input to output, as due to the RS232 DTE/DCE signal naming confusion, its a classic and common mistake to connect two outputs together and two inputs together.

[anishkgt]

Also I didn't check your RX/TX hookup, so double check its input to output, as due to the RS232 DTE/DCE signal naming confusion, its a classic and common mistake to connect two outputs together and two inputs together.

I am sure i've connected the RX of the MCU to the TX of the FT232RL and TX from MCU to RX of FT232RL.

So what really happens when without a 1K or the 74LVC1T45 ?

i appreciate your advise on the FTDI thing but I am not sure how the 74LVC1T45 can be applied to my circuit basically i do not understand it, google says adding 1K each to Rx and Tx would be recommended
http://electronics-diy.com/FT232RL_USB_to_Serial_Adapter_for_PIC_AVR_ATMEGA_ARDUINO_MCUs.php

[rstofer]

If you just use the "Self Powered" configuration where the FTDI chip is powered by the system and not by USB, all these problems disappear.  See page 24 of the datasheet.

It's still a good idea to have resistors in the Tx and Rx lines, especially early on, because the fact that Tx means transmit and is therefore an output is not universal.  I always go to the datasheet and/or schematics and verify that outputs are talking to inputs.  It's amazing how many times this hasn't been intuitive.

[retrolefty]

If you just use the "Self Powered" configuration where the FTDI chip is powered by the system and not by USB, all these problems disappear.  See page 24 of the datasheet.

It's still a good idea to have resistors in the Tx and Rx lines, especially early on, because the fact that Tx means transmit and is therefore an output is not universal.  I always go to the datasheet and/or schematics and verify that outputs are talking to inputs.  It's amazing how many times this hasn't been intuitive.

 

Only when one has learned about 'naming problem' (the hard way) could one expect success  wiring up a RS-232 cable between any two different pieces of equipment.

[Ian.M]

So what really happens when without a 1K or the 74LVC1T45 ?

i appreciate your advise on the FTDI thing but I am not sure how the 74LVC1T45 can be applied to my circuit basically i do not understand it, google says adding 1K each to Rx and Tx would be recommended

Did you watch EEVblog #831 I linked to?   Possible malfunctions include failure of the FTDI chip or the AVR.  Generally you'll get away with it if you limit the current, hence the 1K resistors.   1K is the *MINIMUM* isolation solution and may not be sufficient.  It allows up to 5mA leakage from a high TX pin on the AVR back to the unpowered FTDI chip.   10K would be safer as long as you aren't using baud rates above 115Kbps but reduces the noise immunity.  Minimise the track length (and capacitance) on the input pin side of the isolation resistor.

Think of the 74LVC1T45 as a switch that opens if either side looses power in series with the output of an ordinary buffer.   Its a bidirectional buffer with separate Vcc connections to its A and B sides. (The DIR control pin is on its A side.)  When either side's Vcc pin is at 0V it *GUARANTEES*  the opposite side's data pin is tristated (Hi-Z) if the opposite side is still powered.    If you are only using it for power domain isolation you'd tie DIR to Gnd or VCC_A to fix the direction as required. 

Another approach is an AND gate, powered by AVR Vcc, with the AVR TX fed through it and its other input driven by USB Vbus via a 10K resistor, with a 100K pulldown.   When Vbus is removed the 100K resistor ensures the AND gate output is disabled so the TX line cant leak power to the FTDI chip.  You can also use a gate with a tristate output and active high enable in place of the AND gate, with EN controlled by Vbus, or you can simply use an open drain buffer with a pullup to Vbus on the FTDI side.

Or use the FTDI 'Self Powered' configuration as others have suggested.

[anishkgt]

If you just use the "Self Powered" configuration where the FTDI chip is powered by the system and not by USB, all these problems disappear.  See page 24 of the datasheet.

It's still a good idea to have resistors in the Tx and Rx lines, especially early on, because the fact that Tx means transmit and is therefore an output is not universal.  I always go to the datasheet and/or schematics and verify that outputs are talking to inputs.  It's amazing how many times this hasn't been intuitive.

So if i understand "Self Powered configuration" correctly, the FT232R would be powered by the existing power supply that powers the Atmel meaning from the mains. correct me if am wrong, the FT chip should only be powered when connected to the PC as it is just used upload code and when the USB is disconnected the FT chip would be powered off.

[retrolefty]

If you just use the "Self Powered" configuration where the FTDI chip is powered by the system and not by USB, all these problems disappear.  See page 24 of the datasheet.

It's still a good idea to have resistors in the Tx and Rx lines, especially early on, because the fact that Tx means transmit and is therefore an output is not universal.  I always go to the datasheet and/or schematics and verify that outputs are talking to inputs.  It's amazing how many times this hasn't been intuitive.

So if i understand "Self Powered configuration" correctly, the FT232R would be powered by the existing power supply that powers the Atmel meaning from the mains. correct me if am wrong, the FT chip should only be powered when connected to the PC as it is just used upload code and when the USB is disconnected the FT chip would be powered off.

 As long as one uses the two series resistors connecting to arduino D0 & D1 there is no danger
of electrical problems. It would be best in minimum current draw applications to power the FT to use USB power only as there would be less current draw when not connected to PC.

[rstofer]

So if i understand "Self Powered configuration" correctly, the FT232R would be powered by the existing power supply that powers the Atmel meaning from the mains. correct me if am wrong, the FT chip should only be powered when connected to the PC as it is just used upload code and when the USB is disconnected the FT chip would be powered off.

It CAN be done as you describe but it doesn't HAVE to be done that way.  It is perfectly legitimate to keep the FT232R powered up with the MCU.  Doing so eliminates a bunch of problems, that's why the alternative is shown in the datasheet.  Why worry about resistors or level shifters or other reactions to the USB cable being plugged and unplugged when you don't have to?

If the entire device was going to be powered by USB then, sure, the FT232R would be powered by USB.  But that isn't the case.

There's nothing wrong with using resistors on RX and TX.  I would use something less than 1k but that's because I usually only worry about short circuit.

BTW, the cost to operate the chip 24-7-365 is about $0.46/yr at $0.35/kWh.  So, 50 cents per year!  Nevertheless, it would be considered a vampire load.

FWIW, the USB gadget (ATMEGA8U2-MU) on the Arduino UNO is powered off system 5V - it runs constantly.  They do have a neat way to select between USB power and wall-wart power.

https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

Why not use what works?  BTW, they use 1k series resistors.

[NorthGuy]

BTW, the cost to operate the chip 24-7-365 is about $0.46/yr at $0.35/kWh.  So, 50 cents per year!  Nevertheless, it would be considered a vampire load.

Doesn't it have the ENABLE or SLEEP pin? The chip in low-power mode will consume nearly nothing.

[Ian.M]

There's nothing wrong with using resistors on RX and TX.  I would use something less than 1k but that's because I usually only worry about short circuit.

Another advantage of using resistors is: if you arrange them so the pads form an exact square, with each chip connected to a diagonally opposite pair of pads, if it turns out you've got the receive and transmit data pins mixed up, you can simply remove the resistors and refit them at right-angles bridging the two adjacent footprints to swap the data lines over, and unless you look closely at the silkscreen, it wont even look like its bodged!

[anishkgt]

If you just use the "Self Powered" configuration where the FTDI chip is powered by the system and not by USB, all these problems disappear.  See page 24 of the datasheet.

It's still a good idea to have resistors in the Tx and Rx lines, especially early on, because the fact that Tx means transmit and is therefore an output is not universal.  I always go to the datasheet and/or schematics and verify that outputs are talking to inputs.  It's amazing how many times this hasn't been intuitive.

i've omitted the supply from the USB and added 1k resistors to tx and rx pins and a 1M resistor parallel to pin9 and 10 of the Atmega. It was there in the schematic of the Arduino Uno https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf Why is a 1M resistor used in parallel ?

[retrolefty]

It was there in the schematic of the Arduino Uno https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf Why is a 1M resistor used in parallel ?

 It's there to insure prompt oscillator start-up. More commonly seen used with ceramic resonators (if they don't have one internal). I've rarely seen it used with crystal resonators.

[anishkgt]

Thanks for clarify that. I won't be needing that then.