Re: [avr-chat] avrdude : chip not responding

[Brian Dean]

Hi Vincent,

On Wed, Aug 31, 2005 at 11:30:16AM +0200, Vincent Trouilliez wrote:

> Just got my ATmega32 chip, fired up avrdude to try and see if the chip
> is alive, but avrdude says it's dead ("not responding", he says :-/ ).
> 
> I issued this command : 
> 
> ------
> address@hidden:/media/Hoary_Home/vincent/Electronique/avr$ sudo
> avrdude -p m32 -c bsd -e -F -E noreset
> -----
> 
> and got the followinf response from avrdude: 
> 
> -----------------------------------
> avrdude: AVR device not responding
> avrdude: initialization failed, rc=-1
> avrdude: AVR device initialized and ready to accept instructions
> 
> Reading | ################################################## | 100%
> 0.00s
> 
> avrdude: Device signature = 0xff0103
> avrdude: erasing chip
> avrdude: AVR device not responding
> 
> avrdude done.  Thank you.
> --------------------------------------


> It says it's not responding, but at the same time it gives me the
> chips's signature, which I thought was built-in each chip ?

The '-F' option means Force, and causes AVRDUDE to keep plowing
through no matter what, even if it thinks it can't talk to the device.
This option is intended for cases where AVRDUDE is not smart enough to
do the right thing and the developer knows better.

But in this case, it really does sound like there is a comm problem
with your chip, especially since you tried UISP and it gives the same
results.  So you've tried two seperate and independent programs and
they both fail.

Must be hardware.  Double check:

        1) grounds - chip grounds; make sure your parallel port cable
           ground is also connected to the chip ground.

        2) chip clock source - make sure you have one; assuming your
           chip has never been programmed before it is most likely set
           to run from the 1 MHz internal oscillator.  But just in
           case, you might want to add a crystal and a few caps or a
           resonator across the XTAL pins.

        3) /RESET pin - make sure it is tied to VCC through a 10K
           resistor - not directly connected to VCC.

           Also, make sure the /RESET pin of your parallel port cable
           is connected to the /RESET pin side of the resistor, not
           the VCC side of the resistor, otherwise your parallel port
           will not have enough oomph to change its state in order to
           enter program mode

        4) MISO/MOSI - make sure not to mix them up

        5) SPI pins in general - make sure there is not some other
           external device loading them down which is preventing the
           parallel port lines from changing their state

        6) VCC - make sure you have power!

When you do actually find the problem, it will probably be one of
those head smacking moments where you say "Of course!".

-Brian
-- 
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/