FTDI module's leds blink, but no data is sent/received

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello AVR Freaks,

this is my first post, so I hope, that I'm doing it right.

I had projects with FTDI (FT232RL) chips, which were buit in training boards, but now is time, to create some simple schematics by my own, so I bought this chip on ebay. It seems to be campatible with FTDI Basic Beakout 5V from Sparkfun.

Connections:This chip provides 5V power supply to my ATmega644(pins Vcc and GND). Pins RX and TX are connected to MCU in crossover mode. CTS and DTR aren't connected.

Problem: I can't send/receive data from/to MCU by means of USART via this FTDI chip. At the same time, leds TX and RX on chip are blinking, when I'm trying to send data form MCU to PuTTY terminal or send characters to MCU from terminal.

Although, USART code is working fine when I'm sending data to another MCU (traning board) from my ATmega644. Same code works well with training board and PuTTY terminal. As I understand, something is wrong with this FTDI chip...

FTDI driver 2.8.28.0 is up-to-date.

I spent time making search in google, unfortunaly no results. Any ideas, please?

Thanks in advance!

Alexey

Last Edited: Thu. May 16, 2013 - 09:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As I understand, something is wrong with this FTDI chip...

...or maybe not.

-- When you configure and open the virtual comm port in Putty, what baud rate, character size, parity, stop bits settings did you use?

-- On the AVR side, what USART settings do you use?

-- What is your AVR's clock rate? Have you verified this?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch thanks for fast reply.

Quote:
When you configure and open the virtual comm port in Putty

Baud date 19200, Data bits 8, Stop bits 1, Parity none and flow control XON/XOFF.

Quote:
On the AVR side, what USART settings do you use?

UBRR 64 for 19200bps @ 20MHz, Asynchronous USART, 1 stop bit, 8 data bits, parity disabled by default.

Initialisation code looks like this:

void usart0_init(unsigned int baudrate) {
	/* Set baud rate */
	UBRR0H = (unsigned char) (baudrate>>8);
	UBRR0L = (unsigned char) baudrate;
	/* Asynchronous operation mode */
	/* Set frame format: 8data, no parity & 1 stop bits */
	UCSR0C = (0<<UMSEL00) | (0<<UMSEL01) | (0<<USBS0) | (0<<UCSZ02) | (1<<UCSZ01) | (1<<UCSZ00) ;
	/* Enable receiver, transmitter and receive interrupt */
	UCSR0B = (1<<RXEN0) | (1<<TXEN0) | (1<<RXCIE0);
}

Yes I verified and tried code with training board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Pins RX and TX are connected to MCU in crossover mode.

That indeed makes sense. But I'd double-check that with schematic and following the traces on the board.

Do you have a 'scope to look at the signals?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch I double checked wiring, it is right. If connection is wrong, then RX led don't lid when sending data from MCU to PuTTY via FTDI.

Quote:
Do you have a 'scope to look at the signals?

I don't have a scope, but I can try to find some with recorder function on next week. What I suppose to search for using scope? It seems, that MCU part is ok, baucause there is data exchange between MCU-to-MCU USARTs.

Maybe there is some problem in FTDI software? I couldn't find any info how to login to these kind of chips via terminal, maybe even there is no way how to do that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you send the signal between the two usarts are you using also XON\XOFF handshaking? I use these types of breakout boards all the time with no problem, but I set handshaking to 'none' and that's the way I write my code. Also, have you tired reversing the TX and RX signals just in case... ?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Smiley thanks for reply.

Quote:
When you send the signal between the two usarts are you using also XON\XOFF handshaking?

When I'm sending from MCU-to-MCU I'm not using handshaking. If only it is not set by default.

With communication MCU-to-PC on training board, data transceiving worked with 'XON\XOFF' or without 'none' flow controll set in PuTTY terminal. I checked both ways with this FTDI module and no results.

Quote:
Also, have you tired reversing the TX and RX signals just in case... ?

Yes, I tried. RX LED didn't even led on FTDI module, when MCU attempted to send data via USART. And no data was recieved at PuTTY terminal also.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Connect this FTDI board to the PC, run a terminal program like PuTTY, and jump the TX pin to the RX pin without connecting to the AVR. Are typed characters shown repeating on the terminal program (the sent char first, followed by the received char)? If yes, then the module is working.

Is the module putting out data in old formal RS232 voltage format (high logic is -9 volts, and low logic is +9 volts) or 'TTL' format (high logic is +5v and low logic level is 0V)?
Is the AVR board putting out the serial data in the same voltage format?

A cheap alternative to a real oscilloscope is a PC sound card oscilloscope program. These use the audio input of the PC as oscilloscope inputs. They are limited to a sample rate of 44100 samples per second, the inputs are AC coupled, and the signals should be reduced (with a pair of resistors) to about 1 volt peak-to-peak. But a sound-card-scope will show whether something is happening on the wires.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta thanks for your reply.

Quote:
Connect this FTDI board to the PC, run a terminal program like PuTTY, and jump the TX pin to the RX pin without connecting to the AVR. Are typed characters shown repeating on the terminal program (the sent char first, followed by the received char)? If yes, then the module is working.

Output shows nothig, but both leds blink when sending char. If setting Local echo to 'force on', then only once char appears respectively. As I understand, verdict - module is not working?.

Quote:
Is the module putting out data in old formal RS232 voltage format (high logic is -9 volts, and low logic is +9 volts) or 'TTL' format (high logic is +5v and low logic level is 0V)?
Is the AVR board putting out the serial data in the same voltage format?

Module uses 3.3V signal logics, but MCU TTL format. I saw tutorial, where this worked, of course without any guarantees, that module will last for a long time.

Thanks for idea of using sound-card-scope, saw this information couple years ago, but totally forgot about this one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you say nothing echoes, but in your post you do not mention that you actually connected XR and TX on the FTDI board together.
if you connect RX and TX together the terminal should always see the character comming back(1 or 2 chars depending on the echo being off or on)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp thanks for reply.

Quote:
you say nothing echoes, but in your post you do not mention that you actually connected XR and TX on the FTDI board together.

That is why I created my post. I didn't know, that there is a possibility to test module by shorting TX and RX pins and send a char from terminal.

But in my 5th post, I checked that, after Simonetta recommended me to do so.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok,
Did you try any other terminal program?
might it be another setting of hte terminal program.
I once messed-up the colors and thought nothing appeared on the display but the color was the same as the background color. Or perhaps some sort of setting to ignore data until a certain something is received.

did you try a restart of the PC?

if both RX and TX led on the FTDI chip go on the chip seems to work as it received data through USB. spit it out on its uart and received it again to be send back to the PC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I'd connected the RX and TX and nothing was returned, I'd first try another terminal as meslomp suggests, and if that didn't fix it I'd very carefully remelt all the joints. That is drastic, but if it ain't gonna work you can hardly kill it with drastic measures.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also check that the PCs serial port isn't configured to require CTS/RTS or DSR/DTR signals. Or perhaps even DCD..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR Freaks, thanks for ideas. I'll leave feedback after trying them all on next week.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No success with another terminal.
Tried MCU code with arduino UNO as USB-Serial module and it worked well.

Verdict: Dead module. I tried to save some cash, but as a result I need to buy a new one instead :(

But before doing it, I'll try to remelt all pins, as Smiley recommends.

Thank you guys.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, 

 

I have been facing a similar issue. It took a while to figure out and update my FTDI. I uploaded a serial transmission code to my ATmega64, before that I even tried it on Arduino UNO(programmed and uploaded via Atmel Studio). I was able to serial print the data on Arduino serial monitor, I also checked out my FTDI and it is working fine as mentioned in above comments. Rx-Tx and Tx-Rx of the FTDI and ATmega64 respectively (even tried the other way too). Baud rate 9600, everything else all set in Tera Term for serial output read. I checkout out blick code as well successfully, just to make sure my MCU is working fine. I have posted the code below for reference,

 

#include <avr/io.h>

#include <avr/interrupt.h>

#define F_CPU 16000000

#define BUAD 9600

#define BRC ((F_CPU/16/BUAD) - 1) //page 173 baud rate calculation

#include <util/delay.h>

 

int main(void)

{

    UBRR0H = (BRC >> 8);//baud rate setting registers

UBRR0L =  BRC;  //UBRR0H and UBRR0L

UCSR0B = (1 << TXEN0); //| (1 << TXCIE0); //transmission enabling

UCSR0C = (1 << UCSZ01) | (1 << UCSZ00); //setting up the parity

 

    while (1) 

    {

UDR0 = '8';

_delay_ms(1000);

}

}

 

I am trying to read through Tera Term as my serial monitor but it's all blank, the same configuration worked for rest but not in this case, I am stuck with what is the issue. 

I am a newbie with this #101, please share your thoughts. Thanks in advance.

Last Edited: Fri. Nov 17, 2017 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We see a lot of these types of questions about serial ports.

Do you have a 16MHz xtal on your M64?

What fuse settings are you using?

How have you verified your M64 is running at 16MHz?  (hint: blink led 1/2 sec on, 1/2 sec off)

Do you have power (5v) on all VCC and AVCC pins

Do you have ground on all gnd pins

Do you have 0.1uf caps from vcc/gnd  avcc/gnd pin pairs?

In addition to the TX/RX pins, do you have a common ground with your pc?

 

Do you have any equipment to help you toubleshoot your problem, Logic analyzer or o-scope?

Post a picture of your setup, we may spot the problem.

 

Jim

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

Thank you for your quick response.

Yes, I have 16MHz xtal for my M64

fuse setting is 0xFF for lfuse, hfuse unchanged (based on the online calculator)

Yes, my MCU is running at 16MHz, I have checked it as well with blinky code.

Yes, I have 5V on all VCC and AVCC pins

Yes, I have ground on all gnd pins

Yes, I have 0.1uf decoupling capacitors between VCC and Gnd pins

Yes, I have a common ground with PC. 

 

I have programmed my MCU using USBASP programmer and after that, I took off the programmer and I connected the FTDI to my M64. Unfortunately, I don't have any lab equipment. In fact, I programmed Arduino UNO to read analog voltages across source, ground and other pins for now. 

 

Well, my apologies but the setup is in between of other circuitry, so I suppose it will be all messy wiring if I take picture. But, I think that I will redo the whole setup onto a separate breadboard and try to do it again, if it still doesn't work I will post that picture. Anyways, please enlighten me if I am missing anything else. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice use for the UNO!  The M64 is an old avr, i forget, is it the one with the m104 fuse set by default or is that the M128.....  

IF all else fails, start with a clean setup.  

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the FT232, there is a pin (TEST, pin 26) that MUST be tied to ground. Got bit by that one on my first board with FT232.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excuse me, but did you try to send and receive from and to your PC, by linking together RX and TX (loop back). It does not solve for wrong clock on the AVR side (which has been hidden), nor common ground with the avr. But it is the 1rst -very trivial-  check I do...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did try doing that, linking Rx to TX and it works pretty well. There must be some other issue on the MCU side only, which I am trying to rectify based on above responses.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
The M64 is an old avr, i forget, is it the one with the m104 fuse set by default or is that the M128.....

Both the mega64 and the mega128 have the fuse (which is called "M103C" (for mega103 compatibility)).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose the default fuse setting was lfuse 0x67 I guess(I have to check once I go back on Monday), with that, it used the internal 8MHz oscillator, with 0xFF lfuse M64 uses my external 16MHz oscillator. Based on the online fuse setting calculator mentioned in above comments and other forums. I will redo the circuitry separately as you said and let you know. Thank you.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose I grounded it, I will try to recheck it and as suggested by other members, I will redo the circuitry neatly and separately from my other circuit blocks. I will reverify my connections and test the new setup keeping in mind your comment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an FT232R breakout board (https://www.digikey.com/product-...)

I have tried to connect Tx-Rx and read data, everything on FT232R side is working fine.

 

TEST pin-26 is already grounded based on the schematic. I grounded all the ground pins and connected VCC's to VCC pin along with decoupling capacitors 0.1uF.

 

I have tried to include the m103 compatibility also, apart from that, my other fuse settings are lfuse-0xFF, hfuse:0x98 and efuse:0xFD (based on the online calculator:http://www.engbedded.com/fusecalc/).  I have rechecked all my connections and as I mentioned in earlier posts, my blinky is also working fine with external 16MHz Osc. for my m64.

 

Right now, I don't have enough resources to solder the breakout board with the header pins so I somehow managed to fix it onto the BB (I have tested Arduino mini pro using this FTDI and it worked fine). I tried to keep the wiring simple but as it's a prototype underway so it's a bit messy. I have attached the picture below for reference, hoping the wiring is clear to you all.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an FT232R breakout board (https://www.digikey.com/product-...)

I have tried to connect Tx-Rx and read data, everything on FT232R side is working fine.

 

TEST pin-26 is already grounded based on the schematic. I grounded all the ground pins and connected VCC's to VCC pin along with decoupling capacitors 0.1uF.

 

I have tried to include the m103 compatibility also, apart from that, my other fuse settings are lfuse-0xFF, hfuse:0x98 and efuse:0xFD (based on the online calculator:http://www.engbedded.com/fusecalc/).  I have rechecked all my connections and as I mentioned in earlier posts, my blinky is also working fine with external 16MHz Osc. for my m64.

 

Right now, I don't have enough resources to solder the breakout board with the header pins so I somehow managed to fix it onto the BB (I have tested Arduino mini pro using this FTDI and it worked fine). I tried to keep the wiring simple but as it's a prototype underway so it's a bit messy. I have attached the picture below for reference, hoping the wiring is clear to you all.

 

Please ignore the yellow wirings on the left side of the MCU, those are for USBASP interfacing.

Attachment(s): 

Last Edited: Mon. Nov 20, 2017 - 10:09 PM