Uploading sketches to Atmega328+Uno bootloader+FTDI FT232RL

Hello everyone,

I am working on transferring my project from Arduino board to a PCB board. I want to be able to upload sketches via USB.
I am using the FT232RL as a USB interface and Atmega 328 ( very similar to Duemilanove).
The schematic :

I am having an issue with the RS232 communication. It looks like I have a cross talk issue and I am not able to identify the source.
Here is a basic test sketch I uploaded to the uC before physically transferring the chip to the board.

void setup() {                
  Serial.begin(9600);
}

void loop() {
  if (Serial.available()>0)
  {
    String cmd;
    cmd=Serial.readString();
    Serial.print(millis());
    Serial.println(" : " + cmd);
  }
  delay(1);
}

When I send ant character, I receive this infinite loop :

67067 : 1
68079 : 67067 : 1

69101 : 68079 : 67067 : 1


70133 : 69101 : 68079 : 67067 : 1



71175 : 70133 : 69101 : 68079 : 67067 : 1

It looks like the Transmitted bytes from the uC are somehow read on the Rx pins. I checked my connections for shorts but didn’t find any.
Can someone take a look and help me find the issue.

ATMEGA328.PNG

Here is a board screen capture for your review as well…

That sketch on this Arduino Uno : http://forum.arduino.cc/index.php?topic=295654.0 results in this:

6692 : Hello World

11862 : Test

17201 : 123abc

That is a normal result.

Do you use Arduino IDE 1.6.1 ? Do you have somewhere the (no longer needed) Java RX TX library installed ? Could you try it on another computer or other Operating System ? Would the FTDI chip keep the data in a buffer ? I don't know if that is possible. Are you sure the TEST pin is connected to GND ?

Thanks for the reply. I tested the sketch on an Arduino board and it actually works just like you mentioned. Based on that I excluded the fact that it could be a software issue.

To upload the sketch, I put the Atmega in an Arduino uno board, upload the sketch and test it with serial monitor. Then I remove the Atmega and put in the other board ans test with serial monitor again. The result I get is what I have posted.

I actually used a milling machine to make the board. I cleaned it probably and made sure all connections are clean and short free.

That means that the combination of the FTDI driver on the computer with the FTDI chip causes the serial buffer not to empty or refill ? Looking at your serial output, it could be some kind of echo. Perhaps there is a path between RX and TX ?

Software is not my specialty so if I am way out in left field just ignore my suggestion:

Could it have anything to do with your use of millis() ?

Usually people create a unsigned long variable and store the initial millis() value to that and thereafter store millis() to a variable which is used for serial prints, like this:

 void loop(){
  Serial.print("Time: ");
  time = millis();
  //prints time since program started
  Serial.println(time);

You could try doing it this way.

Peter_n:
That means that the combination of the FTDI driver on the computer with the FTDI chip causes the serial buffer not to empty or refill ?
Looking at your serial output, it could be some kind of echo.
Perhaps there is a path between RX and TX ?

I tried unistalling and reinstalling the drivers from FTDI website with so success. I bought these chips fron Digikey so I think there is no doubt they are authentic.
If it was a buffer issue, I should be receiving the same reply over and over again. In this scenario, I am receiving a new timestamp everytime as if the Rx and Tx were shorted. I checked every single line for shorts but couldn’t find anyt issue…

raschemmel: Software is not my specialty so if I am way out in left field just ignore my suggestion:

Could it have anything to do with your use of millis() ?

Usually people create a unsigned long variable and store the initial millis() value to that and thereafter store millis() to a variable which is used for serial prints, like this:

 void loop(){
  Serial.print("Time: ");
  time = millis();
  //prints time since program started
  Serial.println(time);

You could try doing it this way.

I followed your suggestion but with no luck. I removed the millis() completely and uploaded this sketch :

void setup() {                
  Serial.begin(9600);
}

void loop() {
  if (Serial.available()>0)
  {
    String cmd;
    cmd=Serial.readString();
    //Serial.print(millis());
    Serial.println(" received : " + cmd);
  }
  delay(1);
}

Same issue, here is what I receive:

 received : 1
 received :  received : 1

 received :  received :  received : 1


 received :  received :  received :  received : 1

I am working on transferring my project from Arduino board to a PCB

What does this mean ? Does it mean the original code works correctly on an arduino board ? Have you tried a loop-back test (jumpering tx to rx ?) Are any characters you received the ones you sent ? (or is the received character random?)

Do you have a linux computer, a mac, or even an Android phone ? Those use a different driver. I would like to exclude the driver for being the problem.

I still see an echo. Suppose you send a "1". The Arduino receives: "1". The Arduino transmits: "received : 1". That string is somehow echoed back into RX. So the Arduino receives: "received : 1". And the Arduino transmits: "received : received : 1" and so on.

Based on your observations I would use a meter to compare piinnt to point continuity checks of an UNO to the " suspect" PCB.

raschemmel:
What does this mean ?
Does it mean the original code works correctly on an arduino board ?

Yes it does. as you cansee, it’s a very simple code that I use to test the RS232 frunctions.

raschemmel:
Have you tried a loop-back test (jumpering tx to rx ?)

I did, it does not work and that’s why I suspect it to be more than a software/driver issue.
This is also weird: without ATMEGA328 ( uC removed from dip socket) the FT232 does not echo when Tx-Rx are shorted.

HOWEVER

With ATMEGA328 the Tx function ( board-> PC ) looks like working properly. But, the Rx have this echo issue coming from the FT232.

raschemmel:
Are any characters you received the ones you sent ? (or is the received character random?)

raschemmel:
Characters are not random. it is what I send, I will try on a different OS as per Peter_n suggestion.

Peter_n: Do you have a linux computer, a mac, or even an Android phone ? Those use a different driver. I would like to exclude the driver for being the problem.

Will do that and let you know !

Peter_n: I still see an echo.

Absolutely right

Peter_n: That string is somehow echoed back into RX.

That's what I want to troubleshoot. BTW, when I remove the Atmega from the board and short Rx-Tx on the FT232, the communication does not echo anything. I used hyperterminal and serial monitor.

general electronic question:

I am using SMD ceramic capacitors all across. I noticed that sparkfun are using smd polarized caps for the 10uF. I beleive these are tantalum caps and I used 0805 packaged ceramic cap for that perticular one. This is the only difference I can see between my board and their breakout board

SF schematic: |500x297

My schematic: |500x258

The biggest suspect is the RX and TX signals between the FTDI chip and the ATmega chip. Perhaps the 1k resistors are part of the deal and mix two signals. I think you need an oscilloscape and measure at four points: the RX and TX on both sides of the 1k resistors.

Could you make a photo of that ?

Peter_n: The biggest suspect is the RX and TX signals between the FTDI chip and the ATmega chip. Perhaps the 1k resistors are part of the deal and mix two signals. I think you need an oscilloscape and measure at four points: the RX and TX on both sides of the 1k resistors.

Could you make a photo of that ?

I think I can.

I am also working on making a breakout board with the same components. This will exclude the Atmega and makes it easier to troubleshoot shortings

A quick update on this issue. I still don't know the issue with my original board. I think the way the Rx-Tx lines were routed caused some kind of cross talk. ( Red circle)

I designed a breakout board similar to SF one and made it with desktop milling machine then tested with an arduino pro mini clone. I was able to upload sketches and have a working RS232 communication. I used the same smd components ( same caps and Res). Here is some pics for the results, regarding the other board, I beleive that I will have to rework my routing and add some distance between the Rx and Tx line and avoid any overlap.. |500x332 |500x332

|500x332