avrdude device signature problem

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having fun with the Lufa library right now but am having a problem with avrdude and the device signature check not being consistant.

I am using a USBasp programmer and my AVR is soldered to a breakout board (attached). I rebuild this schematic on a breadboard.

http://www.sparkfun.com/datasheets/DevTools/AVR/ATmega8U2_Breakout-v11.pdf

When I plug my programmer in and immediately enter

avrdude -p atmega32u2 -c usbisp

it checks out fine but when I do it again, even 1 second after, it gives some crazy device signature like "0x10ffff" (this number changes every time).

The strange thing is I also have a atmega8u2 and it does the same thing.

I found someone with a similar problem and it was a timing issue so I thought it might help to get a new crystal. I replaced that and the 22 pf caps with new ones of different brands, it didn't help.

I then read this in the data sheet

Quote:
This Crystal Oscillator ....may be more susceptible to noise in noisy environments.

So I looked around and started turning things that might be noisy off; baby monitor, power supply, etc- didn't help. I went to the other side of the house- nada. Trimmed the leads on capacitors and the crystal so they are flush with the breadboard- nope.

I thought maybe it was my programmer so I pulled out some over AVR's I had and the atmega8 and atmega328 checked out fine- I don't think its my programmer. (note: these are not compatible with lufa and thus wont work for me here)

So, I am unable to program either my atmega32u2 or my atmega8u2 because of this problem and I don't know what to check next. Any ideas?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your SMD adapter looks as if it has pads for decoupling capacitors. I would solder them first.

Congratulations on your nice layout and photo.
You could improve on the crystal and 22pF placing, but I have seen worse arrangements on breadboards.

I presume you are using a Chinese 'usbisp' version of usbasp firmware. this senses the SCK speed automagically. I am happier to be in control !

Incidentally, electrolytics do not do much good for an AVR. You need closely placed ceramic 100nF capacitors.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David!

I will add some ceramic capacitors. Looks like I can turn my metaboard into a USBasp programmer very easily. I will do these things and get back to you.

Thanks
Hyrum

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I added some little blue (I don't know if its ceramic or polyester film) capacitors to the board, one for each vcc pin, but it didn't seem to help. I also started modifying my metaboard so it will be a USBasp programmer and ordered some smd capacitors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I still haven't figured this out. The metaboard programmer I built never worked. I bought one more avr, an atmega32u4, which is doing the exact same thing.

I was thinking about buying either a new programmer or a logic analyzer or maybe both. I was thinking about the AVR Dragon for the programmer and this logic analyzer.

http://cgi.ebay.com/ws/eBayISAPI...

If anyone has any comments for a noob I would be glad to hear them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am very surprised by this behaviour. In my experience the Chinese 'usbisp' firmware is very good at determining the best SCK frequency.

You can always replace the firmware on your usbasp with the standard fischl.de/usbasp firmware. Avrdude sets the SCK frequency according to your instruction.

A Dragon is an excellent purchase. It can program and debug all your AVR devices.

Regarding your Ebay link. IMHO it looks crap.

If you want a Logic Analyser, look at IkaLogic or Saleae. There are also Chinese Saleae clones.

Are you sure that your crystal oscillator is working reliably on the breadboard?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just tried two usbasp devices with a ATmeg32u2.

The www.betemcu.com board behaves like yours. i.e. first connect gets correct Signature. Subsequent connects fail. The same happens with the Chinese ProgISP_1.72 GUI program.

The LcSoft Studio board works fine.

Running the official usbasp firmware works fine too.

I suspect that the betemcu board is trying to be too clever somehow.

If you can confirm that you are using a betemcu board, I will investigate with a Logic Analyser.

A workaround is to unplug and re-plug the usbasp for each session.

I guess that the final solution is to replace the firmware. Of course you need another ISP programmer first !!

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

Thanks so much for looking into this for me! Yes, I am using a betemcu programmer and unplugging it each time works for me. I didn't try that because I thought that the poor connection would damage the chip.

I have an AVR Dragon on the way from Digikey so there is no need to look into it if you are busy. Its enough for me to know that the betemcu acts funny with these mcu's.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Once you have your Dragon, you can change the firmware on the betemcu board.

I had a look. First time it sends AC 53 to enter ISP mode. Connects fine.
Second time it sends AC 00 which obviously fails. It then goes into the idiotic 'insert extra SCK pulse' sequence and then try AC 53.

The current usbasp firmware still has this idiotic procedure. Can anyone justify it ?

An AC53 must immediately follow /RST going low to enter ISP mode.

Incidentally, the betemcu board works fine with other AVRs. The only difference with a ATmega32U2 is that the 3rd Signature byte has bit7 set. This seems to be a feature of USB AVRs.

I will see what happens with a AT90USB1287 chip.

David.