Uploading sketches to Atmega328+Uno bootloader+FTDI FT232RL

Using Arduino General Electronics
#1

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.

FT232RL.PNG|926x530

ATMEGA328.PNG|323x101

#2

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

ATMEGA328.PNG|1239x618

#3

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 ?

#4

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.

#5

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 ?

#6

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.

#7

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…

#8

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
#9

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?)

#10

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.

#11

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

#12

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.

#13

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.

#14

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

#15

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 ?

#16

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

#17

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