avrdude: AVR device not responding


16 posts
by JimW » Wed Dec 05, 2012 7:11 pm
I've had a working Gertboard for several weeks now, programming the ATMEGA quite happily with the Arduino IDE on the RasPi.

However, I'm now unable to re-program the ATMEGA. I'm getting:-

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

..when I do an 'Upload using programmer'. The connections haven't changed and I've tried using avrdude (and avrsetup) to reset the fuses - they come back with a similar message. Tried power cycling & toggling the RESET up and down but it is still unresponsive.

Have I fried the flash with too many updates? (I thought they were good for a few 1000 re-programs - and I don't think I've quite managed that yet) or is there anything else anyone can suggest?
Posts: 4
Joined: Sun Oct 28, 2012 8:01 am
by alexeames » Wed Dec 05, 2012 9:39 pm
Could this be the old serial port connected issue? I've not had it, but some people have had issues programming the ATmega while the serial wires/jumpers are connected.

Try programing it again with just the wires from the Gertboard to the ATMega attached and see if it works. :)
Alex Eames RasPi.TV HDMIPi.com RasP.iO
User avatar
Posts: 2064
Joined: Sat Mar 03, 2012 11:57 am
Location: UK
by ExEc » Thu Dec 06, 2012 8:41 am
Hi There

Same problem here

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

I’ve tried to upload a program just with the 4 wires connected only…and nothing.
Tried to setup the chip again and the same message appears.
Use a different SD card and nothing.
Reinstalled ATmega software…no…no.
Tried on a second Pi…same results….
Last thing I tried was to connect ATMega directly to the Raspberry pi GPIO pins and guess what…same message again…

So I’m thinking it’s a problem with the actual ATmegachip, I’ve ordered a replacement so I can check if that is the case.

In the mean time I’d like to know if there any way to reset the ATMega chip.

Any help to solve this would be really welcome as this is driving me crazy!!

Cheers
Posts: 2
Joined: Sat Aug 18, 2012 6:43 pm
by JimW » Thu Dec 06, 2012 10:11 am
Hi thanks for the suggestion. I've pulled the serial jumpers that were in place and still nothing. The only stuff I now have jumpered between the Pi and the Gertboard are the 4 connections to the programmer header.
A replacement ATmega is on the way - but any less drastic ideas are still welcome...
Posts: 4
Joined: Sun Oct 28, 2012 8:01 am
by JimW » Thu Dec 06, 2012 6:03 pm
It certainly seems that the ATMega is the problem. I've re-connected the SPI pins to the ADC/DAC on the Gertboard and the Pi talks to them just fine.

As for reset, the RESET line on the ATMega is used as part of the programming. The RESET for the ATmega is pin 5 on the programming header (J23). Pulling it briefly to 0V will reset the ATmega; holding it at 0V initiates the Serial Downloading programming mode. This is done for you by avrdude using one of the Pi's GPIO pins
Posts: 4
Joined: Sun Oct 28, 2012 8:01 am
by plugwash » Fri Dec 07, 2012 11:48 am
I'm not sure if it applies to the one on the gertboard but IIRC it's possible to program AVRs into a state where you can't use ISP to reprogram them :(
Forum Moderator
Forum Moderator
Posts: 2235
Joined: Wed Dec 28, 2011 11:45 pm
by panik » Fri Dec 07, 2012 1:42 pm
plugwash wrote:I'm not sure if it applies to the one on the gertboard but IIRC it's possible to program AVRs into a state where you can't use ISP to reprogram them :(

That definitely applies to the AVR on the Gertboard as well. However, that can only happen when setting the fuses. And only when setting the SPIEN bit. Wrong clock settings are recoverable with some effort and a selection of different oscillators. It can not (read: shouldn't) happen when simply uploading firmware with the Arduino IDE or otherwise. I find AVR's in general to be pretty sturdy. Most of them even survive my stupidity and abuse. True, some don't.

9 times out of 10, it is what the error states: wrong connections. I see it a lot too. Usually, 'double check and try again' solves the issue.
Posts: 267
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands
by JimW » Fri Dec 07, 2012 5:03 pm
It's most likely my ATMEGA had got into an 'unprogrammable' mode. I've plugged in a new one and everything is working fine again!

Unfortunately my Gertboard is now attached to a wall in a downstairs cupboard and not on the bench any more, so any in-depth diagnosis of the exact problem might be difficult. Hopefully it shouldn't need re-programming much more (which is when the problem started).
Posts: 4
Joined: Sun Oct 28, 2012 8:01 am
by Gert van Loo » Fri Dec 07, 2012 8:49 pm
The Gertboard has a feature to, theoretically, revive some ATMega devices. I have never tried it, but read about it before developing the board. According to the posts on the Atmel website you can revive most dead devices if you apply a external clock. Therefore there is a hole marked as "J71" which is connected to the ATmega clock-in pin. So you have to generate a clock (e.g. wiggling a GPIO pin) and connect that to J71. According to the posts some devices might be programmed and rescued from their 'no-clock deadlock' state. There are some rules like the CLK must be N-times the SPI clock rate but I don't know the details.
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2031
Joined: Tue Aug 02, 2011 7:27 am
by ExEc » Fri Dec 14, 2012 6:29 pm
Just received my ATMEGA replacement yesterday, plug it in and everything is working fine again... :D

Anyway I’d like t give an opportunity to the bricked ATmega and try to fix it as Gert mentioned on previous post.

I’ve done some research and found the following link:

http://www.seanet.com/~karllunt/fixavr.html

Which bring some ideas on how to tackle it, but still got some questions I hope someone can help me with?

First one, Gert mentioned about this J71 header to connect an external clock signal that can ge generated using a GPIO signal, this is diretly connected to XTAL_IN (1) or pin 9 on the ATmega chip so the question is: Can I connect this external signal diretly or do I need to remove the Cell resonator first? Or should I try to do this off the Gertboard on a piece of Breadboard?

The next thing is, which frecuency should I use to put the ATmega onto programming mode? On the link above they use 50kHz and an SPI of less than 12.5kHz (SPI <= ¼ ouput freq) but I´m not sure is those values apply (can be achieved) here, form what I´ve read on the SPI:
https://projects.drogon.net/understandi ... pberry-pi/

Would it be better a 4Mhz for the external signal and 1Mhz for the SPI?


The Third question is, once everything is set up what should I do? Run “avrsetup” (Gordon´s modified version of arvdude)?
Posts: 2
Joined: Sat Aug 18, 2012 6:43 pm
by gordon@drogon.net » Fri Dec 14, 2012 6:46 pm
Have you upgraded the Pi recently? ie. apt-get update;apt-get upgrade?

I've noticed recently that a new version of the aruduino IDE has been released and that has overwritten the boards.txt file and the programmers.txt file..

Unfortunately my setup script is too clever for its own good and took backups of those files - and if they exist, it won't overwrite them again..

So I'm working on a new version of it all that's a bit more sensible in its approach.

So it might be worthwhile checking, removing the .bak files that my setup script created and re-installing it..

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1514
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by Gert van Loo » Fri Dec 14, 2012 7:27 pm
Can I connect this external signal diretly or do I need to remove the Cell resonator first?

A signal on that pin will override anything coming through the resonator.
Alternative: a trick I sometimes used for patching is to plug the chip in the socket but before bend one pin out so 'misses' and sticks outside the socket.
That gives you all connection except the clock in. No need for a separate board. But you then need some nifty way to drive that pin e.g. wrap a thin wire around it.
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2031
Joined: Tue Aug 02, 2011 7:27 am
by arcanon » Sun Dec 16, 2012 5:26 pm
Oh my word, this is amazing! It works and event with software PWM clock simulation.

So I bought my own atmega8L 8PU to use with the rasberry pi (cheap skate ;)), but then I messed up by programming the wrong fuses. I intended to just use the internal clock, but instead I used the same settings as was given in boards.txt for the atmega8 on the adrunio, which has an external clock. Hence the problem. Now the chip thought there was a clock on pin 9, but there wasn't. And you can't program the fuses to fix this without a clock from somewhere. This I all learn as a I go. So reading this thread I did this in a python script:

import time
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(15, GPIO.OUT)
state = True
while True:
GPIO.output(15,state)
time.sleep(0.001)
state = not state

so run that and put it into the background (ctrl+z, "bg 1"). Connect pin 15 to pin 9 of the atmega8. Now the calculation above says the SPI comms must be 1/4 the speed, so then I did

avrdude -vvvv -c gpio -p atmega8 -U lock:w:0x3F:m -U lfuse:w:0xe4:m -U hfuse:w:0xda:m -i4000

And that worked! In truth I tried doing it faster with time.sleep(0.00002), but the values that came back were unreliable (dev number was almost right but not quite). Then when I slowed it down again, it was just right.

Thanks for the hints!

extra debug info. When I first "killed" the chip I learnt you can use -vvvv to get a lot of debug info and often I was seeing this:

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

As far as I know this is the sent command and then the received command. So I knew the chip was doing something, but it just died after a short while. Then I tried to redo the fuses, but obviously that did not work because it had no clock. When this worked, it looked like:

avrdude: Calibrating delay loop... calibrated to 91 cycles per us
bitbang_cmd(): [ AC 53 00 00 ] [ 80 00 53 00 ]
avrdude: AVR device initialized and ready to accept instructions

Reading | | 0% 0.00sbitbang_cmd(): [ 30 00 00 00 ] [ 00 30 00 1E ]
bitbang_cmd(): [ 30 00 01 00 ] [ 00 30 00 93 ]
Reading | ################# | 33% 0.79sbitbang_cmd(): [ 30 00 02 00 ] [ 00 30 00 07 ]
Reading | ################################################## | 100% 1.19s

avrdude: Device signature = 0x1e9307
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 E4 ]
avrdude: safemode read 1, lfuse value: e4
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 E4 ]
avrdude: safemode read 2, lfuse value: e4
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 E4 ]
avrdude: safemode read 3, lfuse value: e4
avrdude: safemode: lfuse reads as E4
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DA ]
avrdude: safemode read 1, hfuse value: da
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DA ]
avrdude: safemode read 2, hfuse value: da
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DA ]
avrdude: safemode read 3, hfuse value: da
avrdude: safemode: hfuse reads as DA
bitbang_cmd(): [ A0 01 FC 00 ] [ 00 A0 01 FF ]
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am
by Tfantonsen » Thu Mar 07, 2013 7:59 pm
Thou art my hero! :D

Bought a ATMega329p to connect to the Pi and in order to minimize the setup I intended to use the internal 8MHz clock, but with no external clock I couldn't burn the fuses :(

Thanks to you (and even more Gordon), I was able to burn the fuses:
avrdude -p m328 -c gpio -v -U lfuse:w:0xE2:m -U hfuse:w:0xD9:m -U efuse:w:0xFF:m -i4000
and using the ATmegaBOOT_168_atmega_328_pro_8MHz.hex bootloader uploading by Arduino IDE.
This setup could run and ATmega chip without further components, even though I have a resistor (on 3v3<->Reset) and a lowpass filter(on ARef and AVcc).

Thanks
RasPi Model B
Using the RasPi as a 'poor mans 'scope/logic analyzer: http://www.raspberrypi.org/phpBB3/viewtopic.php?p=327908#p327908
Posts: 5
Joined: Sat Jan 12, 2013 9:16 pm
by sccb1g10 » Tue Aug 06, 2013 11:00 am
I`ve tackled this problem yesterday and after few hours of trying to see what is wrong and finding some complicated solutions, mine seemed to be very easy, similar to what someone posted earlier.
Before jumping into complicated ways of repairing this, make sure there is no jumper connected outside of what you need to get started with programming. My Gertboard had jumpers attached at B1 to B4 from someone`s earlier application and this seemed to stop the AVR chip from being recognised. Now it seems to work fine

Silviu
Posts: 1
Joined: Tue Aug 06, 2013 10:51 am
by yvonnezoe » Fri Feb 07, 2014 3:43 am
I've managed to solve it today :) Now my first Arduino Blink test works perfectly! yay!

http://raspberrypiwonderland.wordpress.com/2014/02/07/atmega-works-for-gertboard-and-raspberry-pi-yay/
Just started my Raspberry Pi journey >> http://yvonnezoe.wordpress.com
Posts: 127
Joined: Thu Feb 14, 2013 2:10 am