I'm fairly new with Arduino, but have successfully used it for a couple of projects. However, I am not able to upload a program. I am using a hacked cell phone cable and an ATMEGA chip on a breadboard.
I'm pretty sure the cable works: it passed the loopback test where you connect the Rx and Tx, and I get normal output in the serial monitor from the currently loaded program (a sketch to test PIR sensors).
So it would seem like the problem is with resetting the chip. However, the pin 9 LED blinks normally when I try to upload a sketch. I have also tried manually resetting the board, with no luck.
My OS is linux Mint, and I'm using the 1.6.7 version of the IDE. I've tried using the IDE as root as well as a normal user, with no luck. The breadboard setup is minimal: pullup resistor for pin 1, crystal and caps, and a "pin 9" LED.
I'm making a lot of assumptions here, and the rest of it is guess work:
You don't have any signal lines from the hacked phone cable to auto-reset the chip for an upload, so your only option is to do a manual reset at the critical moment just before the upload starts.
A circuit diagram would help, along with any error message received when you try to upload.
Reset needs a 10k pull-up, not pull-down. The reset line is reverse logic so needs a LOW pulse to activate. I notice that you have AREF tied to Vcc; this isn't recommended for normal use, as it's connected internally.
That's a mistake in the schematic. The resistor is actually pull-up.
I removed the voltage from AREF and tried to upload the blink sketch: no luck. Running the IDE from a terminal, I did get the following message when starting up (before attempting an upload:
Error parsing gtk-icon-sizes string: ''
This doesn't seem likely to be a problem, but perhaps I am wrong about this.
Also, if the serial monitor works, does this mean that the wiring is correct (except possibly the reset)? Or is it possible that the serial monitor would work with a mistake in the wiring?
If you're getting serial information to and from the chip then yes, it is powered-up and working. So that leaves reset and/or bootloader as the probable cause.
I think the error message is from your OS and not relevant to the problem.
I don't think resetting is the problem, as the chip is automatically reset when the serial monitor is opened. It also should have the bootloader, as I've successfully uploaded sketches in the past. I swapped in another chip which I bought from digi-key, which was fresh out of the package with a bootloader installed, and the upload also failed. But the old chip gives me a "not in sync" message, while the second gives me a "programmer is not responding" message in addition. I have some pro-mini boards around somewhere, but I can't find them.
A 0.1uF bypass cap across Vcc and Gnd would be a good idea, I did have problems myself where 328s were happy but 328p's refused to talk. If you're certain that the reset is happening, then probably the board selection vs bootloader doesn't match. Turn on verbose uploading and have another go, then post the results stating the board selected.
Well, here is the verbose output. Board selection: Duemilanove w/ ATmega 328
Binary sketch size: 1,056 bytes (of a 30,720 byte maximum)
/usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/tmp/build6787528459398039051.tmp/Blink.cpp.hex:i
avrdude: Version 6.1, compiled on Sep 11 2014 at 20:00:34
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
User configuration file is "/home/mhs/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [e0]
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [e0]
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xe0
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [e0]
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xe0
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
And here is the verbose response with the fresh chip.
Binary sketch size: 1,056 bytes (of a 30,720 byte maximum)
/usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/tmp/build6787528459398039051.tmp/Blink.cpp.hex:i
avrdude: Version 6.1, compiled on Sep 11 2014 at 20:00:34
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
User configuration file is "/home/mhs/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 57600
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: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
Wow. For some reason, I thought that UNO wouldn't work with a serial FTDI-type cable. I was wrong, and that fixed the problem. I also found my pro-minis, and they work fine too.
