Duemilenove + ArduinoISP cannot program 328p's?

Hi all,

I've been struggling for a while to program a few Atmega328p's with ArduinoISP, to no avail. I'll summarize my attempts and configuration:

  • Wired the 328p as per the ArduinoISP tutorial page (bottom left image on that page)

  • On manually running AVRDUDE (either the one bundled with Arduino 0018 for Windows - under Windows 7 x64) or the one that comes with WinAVR-20100110), I get the following:

(command is avrdude -pm328p -cstk500v1 -b19200 -PCOM6 -v)

...

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.14s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

...

I've tried including -B1.0 and leaving it out, using -F, raising the speed to 57600 (both modifying ArduinoISP to match that, and without), to no avail.

This message, from what I've read so far, is typical of wiring errors, but when I re-wire things to an Attiny85 (which, I know, is rather different), I can program it with no issues whatsoever - same Arduino, same breadboard, same jumper wires, same everything. Also, the error changes - sometimes the read signature is 000000, but sometimes it's 00ff00, ff0000 or some other combination.

At some point, I was under the suspicion that the Atmega328 on board the Duemilenove was answering instead. Found something about putting a 110 Ohm resistor between Reset and 5V to prevent this, however this has not worked either.

I've tried this with three different Atmega 328p chips (all from SparkFun, but different batches), to no avail.

A couple of months ago I was able to successfully program an Atmega168 with this exact setup. So my question is: is there anything inherent in ArduinoISP or my (stock) Duemilanove that prevents it from programming Atmega328p's?

TIA,

Ramón

I know very little about avrdude commands, but here is my experience with SparkFun...

I "supposedly" bought a preflashed ATmega328 from SparkFun as a backup, but it also had problems. I ended up making the ICSP parallel cable and manually flashing it.

I swapped it into my "2009" board for all the work. After the parallel port ICSP flashing, it seemed to be OK.

My P4 system could then use the serial flash upload for sketches from the IDE. If I moved it over to my Phenom system, it BARFS BADLY. If I swapped back in the ATmega328 that came with the "2009" board, it "mostly" works... but the Phenom is cranky where my older P4 is not.

I haven't been able to figure out why the Phenom has such problems. I've tried different USB cables on different ports directly plugged into the motherboard. I also compiled and replaced avrdude that comes with 0019. Nothing makes any difference. I don't use USB much, but my MP3 player and my card reader have never had any problems.

So... based on my experience, I'd recommend trying to flash in an official Arduino board with NOTHING else hooked up just for simplicity's sake. Try flashing the ATmega328 that came with the Arduino (that is, a non-SparkFun AVR) just to see if it responds. I'd also recommend trying a different computer just to see what happens. Maybe something would show up.

To compare my 2 AVR's, this is the command I used (swapping them in the "2009" board):

cd <ARDUINO>/hardware/tools
./avrdude -C ./avrdude.conf -p m328p -c dapa -P /dev/parport0 -v

(obviously I'm linux and your windoze, but I think you can figure out the differences)

I'd recommend trying to get the read to work before the write (which kinda looks like what you're doing).

I noticed your command lacked the "-C avrdude.conf" file. That might make some difference.

From there, I'm out of ideas. Hopefully someone else can add something. Good luck.

Modat7, you made my day :slight_smile: You're gonna laugh at this, I swear :slight_smile:

A while ago, I had a bad experience prying off the 328 in my Duemilanove, out of using the wrong tool for the job. For fear of damaging my 328, I vowed not to remove it from the socket again... I deemed it not necessary. (...)

After reading your post, it dawned on me that I had not validated the FTDI programmer (or any other I own for that matter) against the Duemilanove that shipped with my Arduino. So I wired it up following the instructions in this page: http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html, which I had read before; and took note of the default fuse settings as per your recommendation.

Next, I carefully removed the 328 and replaced it with one I had received from SFE. Lo and behold, the programmer could talk to it... My "virgin" 328 was in fact fused up the way Arduino expects it to be! I even managed to load the bootloader and some odd blink default firmware is now running on the 328.

I feel like an idiot :slight_smile: All this time testing and after posting here I came to the conclusion that the chips were not fused properly, and was on the verge of buying a 16 MHz crystal to validate that. I fully forgot that you are meant to use your Arduino board as a prototyping platform!

Thanks for your patience and your help. Time to remove the bootloader - on to way more interesting stuff :wink:

Glad things worked out. :slight_smile:

I've been curious to try FTDI bit-bang and "Arduino as ISP", but my parallel cable has worked nicely for ICSP. Since I'm running linux, I'd have to learn the manual avrdude syntax for the FTDI method... and that scares me a little. It's moving up on the list, though, as parallel ports disappear.

For the future record of someone searching the archives... It's my understanding that "Burn Bootloader" from the IDE menu will properly set the FUSE bits on a virgin or semi-trashed AVR and then flash the bootloader. This is what I was comparing in my previous post using avrdude between my two mentioned AVR's (and they matched perfectly).

I've also had some scary experiences pulling chips out of sockets. I don't have a chip puller, so I just use a small flat blade screwdriver. Way back I learned the trick: as the screwdriver nears the end of the chip, hold down the blade flat against the socket, hold down the already pryed up end of the chip against the screwdriver shaft, and gently rock it back to pry up the final end. As many have already noted, DIP sockets aren't intended for mass usage, but one can get away with periodic usage like this.

Actually, I had deferred building my parallel programmer precisely because it requires me to take out my old laptop from the closet and boot it into Linux to use it. But I had to be sure it wasn't the programmer(s) messing up my setup.

A tip about FTDI bit-banging: you'll read all over the Web that people remove the four solder blobs on the Duemilanove, replacing them with all sorts of headers. You can actuall attach jumper wires to a piece of four female headers (to ease grip and alignment), and press it firmly against the board; that works for me. I don't mind using a soldering iron, but prefer to keep my tools about as 'stock' as possible.

As for the bootloader, that was in fact my first attempt, precisely to e fuses without having to deal with Avrdude; however, when an AVR is fused to use an external clock source, Avrdude tends to fail to validate its signature, or so I recall. So I guess that technique can help recover from some, but not all, incorrect fuse settings situations.

And I fully echo your comments about the DIP socket - I also favor a small flat head screwdriver, but I also fear doing this, while sparingly, is the leading candidate reason to eventually have to replace my Duemilanove with an Uno. Though hopefully not before someone makes it clear how to program the Atmega using the AVR chip that replaces the FTDI.

Finally, you can bring out a standard ICSP cable from either the FTDI or Arduino itself running ICSP, which could lead to a lot less Arduino DIP socket wrenching. :slight_smile:

In taking note of your clock comment, I also ran across this in my notes. When doing linux parallel port ICSP, udev doesn't seem to create an entry for my parallel port. I never figured this out, but the command is an easy fix:

mknod --mode=666 /dev/parport0 c 99 0

The permission bits are a bit open for my taste, but it usually isn't a problem for a single user system. Some laptop serial/parallel drivers are funky and need extra kernel drivers built in (like for my old Thinkpads). Keep an eye out for that.

I've considered making a dedicated FTDI cable for bit-bang mode, but this is very low on my priority list since my parallel cable works. I've seen the chips for about $5. It would probably be easier for now to just do the headers like you said. My finished project PCB I'm designing has an ICSP header on it so I shouldn't have to stress the 28pin DIP socket too much on my 2009 dev boards.

Did you end up doing your FTDI flash by command line? or the GUI mentioned in the earlier link?
If by command line, was it similar to this page?
"http://itpedia.nyu.edu/wiki/Bootloading_the_Arduino--Using_Only_the_Arduino!"
Note the '!' has to be present for that link to work.
If it was different, would you mind posting your commands for the record?

I used no GUIs - plain old avrdude. Indeed, my command for flashing using FTDI is pretty much the same as the one from the site you linked. I had run into that site before, and the one thing that doesn't work for me from those instructions is that you can't just "download" avrdude and have it work, at least not under Windows; WinAVR from January of this year (the latest version as of this writing, AFAIK) does not support the FTDI chip "as is". I downloaded a patched version for Windows from the site I linked before. In this other site: On ATMega328 Bootloading With FTDI Bitbang Method – Kerry D. Wong, you can find links to methods for patching avrdude under Linux. After that, and modifying the avrdude.conf, all should go well.

Thanks, that's a good link. Turns out it links back to the Playground. I added it to the page so it should help others in the future.

http://www.arduino.cc/playground/Hacking/AvrdudeFTDIBitbang