Programmer not responding under Debian Etch

Hi there,

I'm having trouble uploading to an Arduino Diecimila board from Linux (Debian Etch). I can upload to the board just fine from my Win XP machine at work, so I think that rules out a board fault.

I've worked my way through the troubleshooting guide and not found the solution, so I'm posting here as suggested.

The board is sat on a non-conductive surface and I'm sure I've got the right serial port (dmesg output indicates that this serial port is created when I plug in the board). Being a Diecimila I don't think I need to press reset to make the upload work (and it works without on the WinXP machine). The board serial number is Q2124 and it came from Cool Components in the UK.

Here's my verbose output for an attempt to upload the blink example:

Binary sketch size: 1098 bytes (of a 14336 byte maximum)
hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168 -cstk500
v1 -P/dev/ttyUSB0 -b19200 -D -Uflash:w:/home/lwr20/arduino/arduino-0011/examples
/Digital/Blink/applet/Blink.hex:i 


avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "hardware/tools/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : /dev/ttyUSB0
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

After I click upload, there is a pause (while the program compiles), then I see the L led flash once, then the Tx and Rx leds flash 3 times, pause, then the Rx flashes once more. The Tx and Rx flashes seem to correspond with the sending of 0 [30] [20] and the final Rx flash seems to correspond to the Q [51] [20]

Speculating as to what might be wrong: it seems we have a communication problem between the Arduino IDE and the board. Perhaps the baud rate is wrong (but I see that 19200 is the norm for a Diecimila). Perhaps my serial drivers are broken and we can send to the port but not receive from it?

I think I'll try flashing the board at work with a program which sends and receives data over the serial port and see if I can see the data going both ways on the linux machine. Unless someone has a better idea?

Thanks in advance,

Lance.

Additional after reading more forum posts: I'm running it as root to avoid any problems with permissions. The arduino IDE is 0011 alpha. There is nothing else plugged into the board apart from the USB cable.

I'm going to presume that you are connecting to your Diecimila through the USB port, instead of trying to implement something RS-232ish.

I'd suggest you (re)connect the Diecimila and "immediately" do a 'dmesg' from the command line - the last few lines of that will tell you if your system is actually seeing the Arduino, or not. From my system:

[851321.862108] usb 1-2.2: new full speed USB device using uhci_hcd and address 33
[851322.020113] usb 1-2.2: configuration #1 chosen from 1 choice
[851322.022988] ftdi_sio 1-2.2:1.0: FTDI USB Serial Device converter detected
[851322.023036] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected FT232RL
[851322.023192] usb 1-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

You're looking for that FTDI bit; if you're not seeing it, edit the permissions on your USB connections to allow you to use it (you may have to include yourself in the tty/uucp group~~).~~ I run Ubuntu, and ran into something that sounds similar to what you're going through; in my case the problem turned out to be a USB hub I had between my system and the Arduino. All I had to do was disconnect the hub, reconnect it, and everything kicked right in. Hope this helps... /me

Thanks for the tip DMerriman. Unfortunately, my dmesg output shows the same messages as your system, so I don't think we have the same problem.

As promised above, I flashed the arduino with my comms test program at work and tried plugging it in. I can post the program if anyone thinks they might find it useful, but it basically replies to any characters it receives with "I received xxx" where xxx is the integer representation of the received byte, and also sends a different string once every second. The idea here was to see what the arduino is receiving (if anything) and to ensure that I would definitely see something.

Anyway, I've plugged the board in and tried tail /dev/ttyUSB0. This produced no output, but I could see the Tx leds pulsing periodically. I then tried cat /dev/ttyUSB0 - this showed the periodic output and also a whole lot of "I received " messages (which I was surprised about). Does anyone know why catwould do this?

A quick google turned up CuteCom - a gtk based Linux program for talking over serial ports to hardware boards like the arduino. My first attempt to talk to the board failed. I was using 9600, 8N1, Hardware flow control. I finally got it to work by turning off flow control. All of this was done as my normal user - so permissions don't seem to be the issue here.

Here's the bit that really confuses me though - I tried the arduino IDE again on the off-chance - and successfully uploaded the Blink example into the arduino! I was able to upload variations of this program just fine. Right up until I unplugged the arduino.

Now I'm back a square one. I've tried re-creating the steps above (as far as I can now that I'm stuck with the blink program in the arduino instead of the comms test program), but I can't seem to find the trigger.

My current theory is that something in the above chain of events changed the state of the USB serial port to make it work. If I can figure out what, perhaps it can be added to the port initialisation code somewhere...

Lance.