Boarduino and FTDI TTL-232

[Entropy]

I received a USBTinyISP as a Christmas present, and just got my Boarduino with an FTDI TTL-232 cable in today.

Both the USBTinyISP and the Boarduino are now assembled, and both appear to be working properly. I'm slowly brushing away the cobwebs from my AVR skills (the last time I did any microcontroller work was over five years ago when I took ECE 476 at Cornell in Spring '02), and so far everything is working except one thing:

I started working with the serial port, and while I can receive things from the AVR on my PC (I currently have a test app that prints "!" at 10 Hz, and I can see this on my PC), I cannot send anything to the AVR.

Attempts to communicate between the Boarduino and the TTL-232
1) If I upload the ADABOOT bootloader and try to upload anything using the instructions at http://www.ladyada.net/library/arduino/bootloader.html, I get "could not communicate with programmer" errors.
2) If I try to use a basic loopback program on the AVR (programmed using the TinyISP), nothing gets looped back.
3) Anything else that I try to do involving sending serial data to the AVR does not work.

To eliminate the possibility that I'm just doing something wrong when playing with the AVR, I have tried the following:
1) Jumper the RX and TX lines of the TTL-232 together, look for signs of loopback in a terminal program. Nothing in HyperTerminal (Windows) or seyon or komport (Linux).
2) Reconnect the TTL-232 to the Boarduino. Wire an LED and series resistor, ground one lead of the LED (i.e. wired to light when something is sourcing +5v). Probe the TX and RX lines on the Boarduino with a jumper connected to the series resistor, and the LED lights on both lines when no terminal program is open (at least in Linux, did not test this in Windows). If any terminal program is opened, LED on RX line turns off.
3) Reconfigure LED wiring so it lights when the jumper coming from the series resistor is grounded. When connected to TX line of the AVR (RX for the TTL-232), it blinks when data is being sent by the AVR. When connected to the RX line, it is on solid if a terminal program is open. It is off if no terminal program is open.

As far as I can tell, whenever a terminal program opens the serial port, the TTL-232 is grounding its (orange) TX line (RX on the Boarduino), and keeping it grounded. Data is not sent. When no terminal program has the port open, it is kept at +5V. The (green) RTS line behaves EXACTLY the same way.

Any idea why this is happening? Am I botching some setting in komport or seyon?

[timv]

I'll be interested to see what Ladyada has to say because she's the authority on this stuff. But everything you describe points to a bad FTDI adapter. Loopback isn't working on either platform, and I didn't see any other case in your description where bits successfully made it from the USB end of that cable to the TTL end. That's a pretty thorough set of tests and it looks like you know what you're doing.

GMR2Davy

[Entropy]

Yeah. Based on FTDI's schematic and the behavior (TxD from the cable mimics the behavior of RTS#), I'm wondering if there's a solder bridge between pins 30 and 32 on the IC.

There doesn't appear to be a nondestructive way to pop the case open on the USB plug end though, so I have no way of checking this.

I also haven't tried using a different PC - I'll try one of my laptops tonight and see if there is any difference, although I suspect that will not change anything.

[adafruit]

er, just to make sure:
can you run portmon (available from sysinternals) on windows and make sure you're sending data on the serial port? (its worth checking )

[Entropy]

Seemed to be writing data to the port.

It freaked out when I tried loopback.

I did decide to try using my laptop instead, and loopback worked on that machine. I was using minicom there, as that was what the machine already had installed. I tried installing minicom on my desktop, and lo and behold, minicom works fine under Linux with the FTDI cable on the desktop too. I then uploaded a program to my AVR that required receiving data from the PC via serial, and it worked.

So either:
Minicom is doing something that komport, seyon, avrdude, and HyperTerminal are not doing that is required, or
Minicom is not doing something that the others are doing that makes the FTDI chip angry.

I was out most of the night so couldn't investigate further. Time to dig through the source of minicom and komport or seyon tomorrow... I'm not going to bother with HyperTerm under Windows, I have no real reason to use it, it was just a data point.

Do you know of any equivalent to Portmon for Linux? It may be easier than digging through minicom and seyon's source code...

(I would rather not use minicom, as it REALLY wants to be run as root and is a nightmare to use as a mortal user, most other terminal programs are much easier to get configured to run properly as a mortal.)

[rglenn]

Are you trying to use the auto-reset function on the Arduino? I think that the TTL 232 cables use RTS# for reset on the Arduino, and there were some issues with that, as the Diecimilla boards use the DTR line.

-Randy

[timv]

rglenn wrote:

I think that the TTL 232 cables use RTS# for reset on the Arduino, and there were some issues with that, as the Diecimilla boards use the DTR line.

FWIW: I'm using that exact same setup, FTDI TTL-232 and Boarduino, and it works for me on both XP at work and Ubuntu at home.

The only issue I had was that none of the Linux apps had the correct RTS/DTR handling implemented. (It's just one line for both on the FTDI. There aren't enough wires on it to have separate lines.) I had to patch RXTXComm and Avrdude to get auto-resetting to work correctly. I documented those changes here:
http://www.ladyada.net/forums/viewtopic.php?t=4703

Entropy wrote:

I did decide to try using my laptop instead, and loopback worked on that machine.

OK, that changes everything. So the cable isn't plain old hosed. But something's wrong.

Do you know of any equivalent to Portmon for Linux? It may be easier than digging through minicom and seyon's source code...

Not offhand, but I've just started using minicom to troubleshoot something unrelated (can't talk to USB GPS receiver) and it doesn't seem so bad to me. Ctrl-a then 'z' pops up a very usable menu system.

I had to run it once as root to set up the default port and comm parameters, then I'm fine as plain old me. What's giving you trouble? You shouldn't have to be root after that if your udev script is correct. (Your user account needs to be a member of the "dialout" group, which the device /dev/ttyUSB0 will be assigned to.)

But I wouldn't want to hack that source either. Avrdude is pretty small in scope and easy to understand. If you really want to try writing test code, I'd suggest looking at it and just pulling out the bits of code you needed to operate the port. I think everything you'd need is in the file "ser_posix.c". I can guarantee you that those routines work correctly with the TTL-232.

If you want to take a look, I'd suggest using the source for the patched version bundled with the Arduino-0010 app:
http://www.arduino.cc/files/avrdude-5.4-arduino-0010-src.tgz

[Entropy]

Are you trying to use the auto-reset function on the Arduino? I think that the TTL 232 cables use RTS# for reset on the Arduino, and there were some issues with that, as the Diecimilla boards use the DTR line.

-Randy

I have it wired on the Boarduino, but it's been the least of my priorities. I haven't noticed any "random resets" so far and that is my biggest worry. (I'm using AVR-GCC and programming the ATMega as a normal AVR with a USBTinyISP in most cases instead of using the Arduino environment, and that works perfectly.)

Even when doing things that unusual RTS/CTS behavior should not have effected (such as a loopback test), things were not working with seyon or komport - the data line was getting tied to ground permanently when either app would open the serial port. Yes, I did disable flow control in both applications (and in minicom too). I realize that RTS/CTS/DTR actually are needed if hardware flow control is enabled.

Hmm, I wonder if perhaps while I was disabling hardware flow control in seyon/minicom, it wasn't actually being disabled? I have noticed that it seems that in minicom, I had to completely close and restart the app after first configuring it in order for it to work. Maybe there are certain times where the FTDI driver is ignoring configuration commands...

[timv]

Do you know of any equivalent to Portmon for Linux?

I don't know portmon, but you can get very detailed logging with:

Code: Select all

echo "Y" > /sys/module/usbserial/parameters/debug
echo "Y" > /sys/module/ftdi_sio/parameters/debug
[so some serial stuff...]
dmesg | tail -500 | less


All except the dmesg as superuser of course.

[adafruit]

Are you trying to use the auto-reset function on the Arduino? I think that the TTL 232 cables use RTS# for reset on the Arduino, and there were some issues with that, as the Diecimilla boards use the DTR line.

-Randy

I have it wired on the Boarduino, but it's been the least of my priorities. I haven't noticed any "random resets" so far and that is my biggest worry. (I'm using AVR-GCC and programming the ATMega as a normal AVR with a USBTinyISP in most cases instead of using the Arduino environment, and that works perfectly.)

Even when doing things that unusual RTS/CTS behavior should not have effected (such as a loopback test), things were not working with seyon or komport - the data line was getting tied to ground permanently when either app would open the serial port. Yes, I did disable flow control in both applications (and in minicom too). I realize that RTS/CTS/DTR actually are needed if hardware flow control is enabled.

Hmm, I wonder if perhaps while I was disabling hardware flow control in seyon/minicom, it wasn't actually being disabled? I have noticed that it seems that in minicom, I had to completely close and restart the app after first configuring it in order for it to work. Maybe there are certain times where the FTDI driver is ignoring configuration commands...

yeah. minicom has to be quit & restarted and then double check again. the cables are tested out of the factory so im kinda guessin' its a flow issue! call the plumber

[Entropy]

Given up on seyon and komport for now - minicom is working now, and it's less hassle to use it than to get a preferred terminal emulator fixed, especially now that I have permissions set up to allow non-root use.