Help please! "AVR device not responding"

Development Boards MicroMod
1

I’m following along with the SparkFun “Beginning Embedded Electronics” tutorial using the following equipment:

ATMEGA168-20PU purchased locally

AVR-PG1B programmer from SparkFun

I have hooked everything up as shown in the following images:

http://flickr.com/photos/27681363@N08/s … 134384438/

When I try to program the CPU, I get the following error:

> "make.exe" program
avrdude -p atmega168 -P COM1 -c ponyser  -v -v  -U flash:w:blink_1MHz.hex 

avrdude: Version 5.5, compiled on Jun  9 2008 at 14:32:04
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "C:\WinAVR-20080610\bin\avrdude.conf"

         Using Port            : COM1
         Using Programmer      : ponyser
         AVR Part              : ATMEGA168
         Chip Erase delay      : 9000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no        512    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     16384  128    128  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : SERBB
         Description     : design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts

bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ]
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ]
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ]
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ]
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ]

[...many more lines of the same snipped...]

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

make.exe: *** [program] Error 1

> Process Exit Code: 2
> Time Taken: 00:00

I’ve checked everything I can think of, including:

  • The power supply seems to be working fine. I get 4.98 to 4.99V everywhere between the power rails, and also between, for example, ground and the VCC and AVCC pin on the CPU.

  • Both GND pins on the CPU are connected to ground.

  • The reset pin on the CPU is being pulled high, and measures 4.98V.

  • The ISP connector seems to be hooked up correctly. I even went so far as to measure continuity between the 5x2 connector and the DB-9, and to check the schematic of the AVR-PG1B.

  • If I hook the ISP connector up to my WiTilt, I am able to program it with the “blink_1MHz” program, and it works fine.

  • I substituted a second ATMEGA168-20PU, with no change.

I’m at a bit of a loss to say what’s going wrong. I am using a 12K resistor to pull up the reset pin, instead of 10K, but tried a 1W 10K resistor, just in case, without any change.

I’d appreciate any suggestions you guys can throw out there. I’m inexperienced with embedded processors, and indeed with electronics generally, so it could be I’m just missing something basic. Thanks!

Michael

2

schematic of what you intended to have?

and triple check vs. what you built?

3

stevech:
schematic of what you intended to have?

I don’t really have a complete schematic, but it’s up to the end of Lecture 2 in the “Beginning Embedded Electronics” tutorial here:

http://www.sparkfun.com/commerce/tutori … p=1&page=2

Essentially, the power supply follows this schematic (minus the diode and switch):

http://www.sparkfun.com/commerce/images … upply6.jpg

The rest follows this one:

http://www.sparkfun.com/commerce/images … ogram4.jpg

The 10K pull-up resistor on the CPU reset has been changed in the photo to 12K (couldn’t find 1/4W 10K anywhere yesterday), but using a big 1W 10K doesn’t change the result. The reset switch has also been eliminated, and a couple of filtering caps have been added, as in this photo from the tutorial:

http://www.sparkfun.com/commerce/images … -Wired.jpg

and triple check vs. what you built?

I’ve done too many double/triple checks to count. I spent about six hours yesterday going over everything in detail. I’ve also checked continuity and voltages with a multimeter, just to make sure it’s not a problem with the breadboard or power supply. Everything seems to be in order.

4

I just started the tutorial two days ago. I’ve had various problems, like forgetting to hook up the reset pin of the programmer, switching the MISO, MOSI and CLK pins (they are different on the ATmega168 than the ATmega8 in the picture)

I purchased the [jumper wires so I could color code the pins.

After getting partly through the tutorial, it helps you configure the IC for a crystal. The pictured location was different too, so I couldn’t get it to do anything until I had the crystal in the right place and with those capacitors. I guess my crystal was being stubborn without them. See my [picture, pins 7 and 9 on the front.

Edit: The spec shown above isn’t the ATmega168, which is what the kit sells you. See below:

[

Also, for giggles, try removing your resistor on the reset. When using the programmer, I have it wired directly to the pin. I don’t know if it is supposed to, but my chip is always in a state of reset when the programmer is plugged into a parallel cable, but it still allows me to program it.](Atmel 2545S datasheet pdf)](http://josh.mainelan.net/wp-content/uploads/2008/09/nark_patrec1.jpg)](http://www.sparkfun.com/commerce/product_info.php?products_id=8431)

5

Narkaleptic:
I’ve had various problems, like forgetting to hook up the reset pin of the programmer, switching the MISO, MOSI and CLK pins (they are different on the ATmega168 than the ATmega8 in the picture)

I’d love to be wrong about that one–because it would sure explain the CPU not listening to me–but I think I’ve got the connections in the correct place for the ATMega168. If you don’t mind taking a quick look at my photos to see if it looks sensible to you, I’d sure appreciate it.

The spec shown above isn’t the ATmega168, which is what the kit sells you.

I actually picked up the CPU from a local source, not SparkFun. One of my concerns has been that, although the part numbers match, perhaps there is some programming that SparkFun does before sending the CPU. That’s not the case, is it? It’s my understanding these things can be programmed using ISP straight from the factory.

A little more information: I attached an LED to various pins on the CPU to see what happens when I program it, and here’s what I found:

RESET (pin 1 on CPU): Normally high, but goes briefly low when programming.

SCK (pin 19 on CPU): Normally low, but goes briefly high when programming.

MISO (pin 18 on CPU): Always low, even when programming.

MOSI (pin 17 on CPU): Normally low, but goes briefly high when programming.

From this information, I surmise that avrdude is pulling reset low, sending serial clock pulses, and communicating on MOSI, but the CPU is not responding on MISO. Does that sound right?

I also tried pulling SS high, thinking that perhaps if the CPU is acting as a slave, it needs to be selected. However, this does not seem to make any difference.

Edit: Reading the datasheet, I realized that SS has to be pulled low on the selected slave. Pulling the pin low on the CPU also seems to have no effect.

Edit again: Of course, SS should be completely irrelevant when programming using the SPI pins. Just thought I’d give it a try.

Michael

6

After doing a little more digging in the ATMEGA168 datasheet, it definitely seems like the right signals are getting to the CPU. At least, the low/high patterns I noted previously are in line with what should be happening, except that the CPU is supposed to echo back on MISO after receiving the second byte on MOSI. That, combined with the observation that the programmer works fine with my WiTilt, which also uses an ATMEGA168, leads me to believe that the programmer is working properly, and is hooked up to the correct pins on the CPU, but for some reason the CPU is not responding.

I’ve checked and re-checked the connections many times. In fact, I thought perhaps I’d made some invalid assumption about the breadboard, so I looked into it and discovered that I don’t need to have the four jumpers on the power rails, with my particular breadboard. But everything else checks out.

I tried removing the resistor from the reset pin, as you suggested. This had no effect. Looking at the schematic for the AVR-PG1B, it appears that the same resistor is actually built into the programmer, pulling the reset pin high unless the reset pin 3 of the DB9 connector is high, in which case the reset pin is grounded.

This is getting super frustrating, because the circuit is unbelievably simple, and I feel like I’ve checked everything a hundred times, in as many different ways as I can think of. I’ve certainly spent more than 10 hours at this point trying to figure it out, and feel like I’m running out of new ways to check things. If anyone can find an error in the photos above, it would make me a very happy person.

I’ve swapped the CPU a couple of times to make sure it’s not the source of the problem, but there was no change. However, the more I check this thing, the more I wonder if I’ve just completely misunderstood something about programming the CPU, perhaps I have the wrong part, or perhaps I’ve just got a pair of defective units. This seems highly unlikely, but you know how it gets when you’ve checked things a hundred times. You can’t quite see it in the photos, but the part number on the CPU is “ATMEGA168-20PU”. The text is a lot more faded than in photos on, for example, the SparkFun website, which makes me that much more suspicious of this possibility. Does anyone else have one of these units where the text is barely legible unless the light is just right?

Again, thanks for any help you guys can offer. I’m just about at wits’ end, and any help is appreciated.

Edit: Looking at Narkaleptic’s photo, it appears the text is hard to read there, too. The part is probably fine. I write software for a living, and know how often users jump to the conclusion that there’s a problem with the software, when it’s really a problem with how the software’s being used. It’s just, I can’t imagine what the heck I am doing wrong!

Michael

7

Narkaleptic:
I’ve had various problems, like forgetting to hook up the reset pin of the programmer, switching the MISO, MOSI and CLK pins (they are different on the ATmega168 than the ATmega8 in the picture)

This comment has me somewhat confused. To my eye, the relevant pins (1, 7, 8, 17, 18, 19, 20, and 22) for the ATMega168 and the ATMega8 are identical:

http://www.atmel.com/dyn/resources/prod … oc2486.pdf

http://www.atmel.com/dyn/resources/prod … oc2545.pdf

Am I missing something? Thanks!

Michael

8

I got it working! I decided to try adding a 20 MHz oscillator, mostly because I’m really running out of options for what the problem could be. I added the oscillator and capacitors, hit the “program” button, and it worked like a charm. I now have a happily blinking LED.

This does raise one question in my mind. I thought the fuses were set, by default, to use the internal oscillator. Why would the chip, out of the box, require an oscillator?

Thanks to everyone who offered suggestions as to what might be wrong. I’m new to microcontrollers, but have a great deal of programming experience, and look forward to contributing what I can to this community.

Michael

9

Hi Michael,

I ran into the same problem as I was going through the tutorial, except that I built my own programmer and I’m using an ATMEGA8. I still have this problem after 4 days of troubleshooting. I’ve also checked everythjng about 100 times (in my case the programmer adds many more unknowns :wink: )

I tried adding the ossillator but it didn’t make a difference. Are you sure you didn’t make more than one change before it started working? Or was it just the ossillator?

10

cahofmeyr:
Hi Michael,

I ran into the same problem as I was going through the tutorial, except that I built my own programmer and I’m using an ATMEGA8. I still have this problem after 4 days of troubleshooting. I’ve also checked everythjng about 100 times (in my case the programmer adds many more unknowns :wink: )

I tried adding the ossillator but it didn’t make a difference. Are you sure you didn’t make more than one change before it started working? Or was it just the ossillator?

Well, it wasn’t exactly the oscillator, so much as the fact that the folks I bought the ATMega168 from had set the fuses to something other than factory defaults. In my case, the setting happened to be compatible with a 20 MHz oscillator, and that solved my problem.

Are you following a particular design with your programmer? Can you post photos/schematics of your entire setup? Having recent experience, I know how frustrating this can be, and would be happy to help as much as I can.

One other thing… Where did you buy your ATMega8 from? If I ran into this kind of problem again, I think the first thing I’d do is call the supplier and make sure the fuses have not been changed.

Edit: I’ve added a photo of the working breadboard the my Flickr photostream. A direct link is here:

http://flickr.com/photos/27681363@N08/2 … 1/sizes/l/

Note that my breadboard does not require jumpers in the middle of the power rails, so I removed them between the old photos and the new one. Other than that, I think the only real change is the addition of the oscillator and related capacitors.

Michael

11

Well, it wasn’t exactly the oscillator, so much as the fact that the folks I bought the ATMega168 from had set the fuses to something other than factory defaults. In my case, the setting happened to be compatible with a 20 MHz oscillator, and that solved my problem.

I saw an oscillator in quite a few programmer schematics, so for a moment I considered the possibility that the AVR might be dependent on an oscillator while it's being programmed, but I guess that's unlikely; the targets in those schematics were obviously just set up to use an oscillator beforehand. I'm not familiar with these things yet :wink:

Are you following a particular design with your programmer? Can you post photos/schematics of your entire setup?

I'm pursuing Plons's PPPD:

http://www.aplomb.nl/TechStuff/PPPD/PPPD%20English.html

I’ll post a new topic with schematics and photos.

Where did you buy your ATMega8 from? If I ran into this kind of problem again, I think the first thing I’d do is call the supplier and make sure the fuses have not been changed.

I bought it from a local electronics store in South Africa. They actually specialize in PICs and the ATMEGA8 is the only Atmel chip they stock. They don't stock any Atmel programmers either. Thus I'm pretty sure they won't change the fuses yet I don't know who they're sourcing it from.