The problem:
I have a weather station project going on and I'm planning to use my Linux box for data logging. I have ATMega168 writing data to its USART, FT232R doing USB serial (see my first SMD soldering here: https://www.robotshop.com/letsmakerobots/node/23323) and Ubuntu Linux logging data. Here's a simple picture of the setup:
Weather station data logging test setup
I my test I only sent data from ATMega and was reading it with Linux. There was nothing going back (or at least this was how I wanted it to be for now). I had tested this with windows already and it seemed to work just fine.
When I tried data logging with my Linux box it just froze totally. I got no weird errors, not even a kernel panic on console, and I had to do hard reset. Looking at /var/log/messages after the crash I see this:
Nov 23 23:42:06 vivica – MARK –
Nov 23 23:46:01 vivica kernel: [ 9880.990129] usb 1-2: new full speed USB device using uhci_hcd and address 4
Nov 23 23:46:01 vivica kernel: [ 9881.186429] usb 1-2: configuration #1 chosen from 1 choice
Nov 23 23:46:01 vivica kernel: [ 9881.193300] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
Nov 23 23:46:01 vivica kernel: [ 9881.193421] usb 1-2: Detected FT232RL
Nov 23 23:46:01 vivica kernel: [ 9881.193678] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
Nov 23 23:50:29 vivica syslogd 1.5.0#5ubuntu3: restart.
Same stuff is in syslog and kern.log. FT232R gets detected and attached to ttyUSB0 and then there’s nothing until I hit reset button and system reboots.
One thing that I notice that was different from Windows tests was that “from comp to ATMega” led was lit (meaning that there was something going from Linux to ATMega even though there shouldn’t be).
How to repeat this (in my setup):
- Open 2 terminals on Linux box (I did this through SSH)
- Connect FT232R to Linux via USB cable
- On terminal 1 run:
$ stty 500000 cs8 -parenb -cstopb -ixon < /dev/ttyUSB0
$ cat /dev/ttyUSB0 > data.txt - On Terminal 2 run:
$ tail -f data.txt - Power up ATMega (ATMega starts writing data to USART at 500 kbauds).
- Wait for crash. Last time I tried it took about 20 seconds.
How to fix this:
- Use different serial port configuration (with stty command). -echo seemed to be the crucial option (and it explains why “from comp to ATMega” led was lit on my FT232 board). Here’s the stty command that works for me:
$ stty 500000 cs8 sane -parenb -cstopb -ixon -echo < /dev/ttyUSB0
Now my test setup has been running almost 12 hours and it’s still alive with about 1.5GB of data transferred. So the problem seems to be solved.
Edit: Just a couple of minutes after I posted this serial comms got broken. Reason was FT232R being disconnected and reconnected immediately after that. This caused /dev/ttyUSB0 to disappear briefly and cat (command, not animal 
stopped. I’m not sure what caused this one. I might have nudged things so there might have been a loose cable or something. Or maybe FT232R chip got reset. Anyway, this is not a major problem because when FT232R was reconnected it was working fine again. So I can recover just by waiting ttyUSB0 to appear again and then resume data logging.
Update Nov 26, 2010:
Ok, it seems that the crash was fixed with an update. I was running Ubuntu 9.04 server (kernel version 2.6.28). After updating to 10.04 LTS (kernel version 2.6.32) the test case that crashed the whole system runs just fine. It’s been running about 17 hours now so I believe the crash has been fixed (it only took seconds to crash before). Well, it was about time to upgrade because 9.04s support ended about a month ago.
I also got some explanation why serial port was acting differently on that particular machine (data coming back from PC). It looks like server version on Ubuntu has different default values for serial port than desktop version. I was wondering why my Linux box send something back to ATMega but now it’s pretty clear: Server version has echo enabled (and some other things) by default so it echoes everything back to ATMega. This also makes some sense when you think that you are running a server. All of a sudden all those memories from “calling a BBS with a modem”-times start to come back 
So basically the only thing that really went wrong was the crash itself and that was fixed with software upgrade. Other “weird” serial port issues were fixed by setting correct configuration (disabling echo).