device signature wrong

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

Hello, this is my first attempt to make a AVR project.
So far I have trouble communicating with my atmega32

I use a USBtinyISP with avrdude
this is what I get in CMD:

avrdude -c usbtiny -p m32

Quote:

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x535353
avrdude: Expected signature for ATMEGA32 is 1E 95 02
Double check chip, or use -F to override this check.

avrdude done. Thank you.

So far I have tried adding the -B option but it doesn't work. Anybody have an idea what could be wrong ?

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

A new mega32 will be running at 1mhz. You need 125khz ISP clk to talk to it. I dont know how to tell avrdude to set the clk freq. In avrstudio, theres a dialog box.
Is mega32 a dip on a breadboard, or a ready to program dev board? If its a bare dip, need to add stuff like bypass caps, make sure all vcc and the avcc pin is connected, etc.

Imagecraft compiler user

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

I tried a few things and I am starting to think that maybe I connected something wrong. This is how my setup looks now.

I also put in two capacitators between ground and vcc of 22pF and 10 µF.

I still get the 0x535353 code from avrdude

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

You have a very strange way of drawing a 6-pin ISP header.

The convention is pin#1 at top left hand corner viewed from above often with a printed legend.
The pcb copper side is obviously reversed. So pin#1 is top right and you mark with a square pad.

try:

avrdude -c usbtiny -p m32 -B5

I am not sure about how the usbtiny firmware responds to a chip with no clock. A virgin chip runs off its internal clock. Your 'experiments' may have deflowered the chip.

If the above command does not work. (after you have verified your wiring), I will compile the usbtiny firmware and try it for myself.

Your capacitors are 'unwise'. Put a 100nF (0.1uF) capacitor beteween VCC and GND.

David.

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

Hello,

I have checked the wiring, and it is exactly as I drew it. (#1 pin is left corner on the pcb)
I have tried adding the -B5 command but it did not work.
I also tried other values of -B with no results.

Is the scheme I used correct ?

edit: added the 0.1 µF capacitor still the same error

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

I compiled the usbtiny firmware to run on a usbasp hardware.

If you have a 'too fast' SCK, the usbtiny will respond with "initialisation failed"
A 'slightly too fast' SCK will reply with bit errors in an almost good signature.

I really cannot see how you could get "53 53 53". It is not even an echo from a badly synced SPI.

The -B# switch works fine with usbtiny.

Edit. Avrdude seems to tell usbtiny to use 10us SCK period if you omit a specific -B# switch. So it should cope with virgin AVRs.
David.

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

So it is not a construction error but a timing error.
Could I maybe solve the problem by adding an external oscillator ?

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

I have no idea what the problem is.

1. your wiring must be correct, or else you would get "initialisation failed"

2. it will not even look for the signature if "initialisation failed".

Please could you quote the avrdude version.
Windoze or Linux.

Please quote your actual command, and the full response.

David.

e.g.

C:\src\usbtinyisp\spi> avrdude -c usbtiny -p ATmega128 -U flash:r:m128_read.hex:i -B1

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9702
avrdude: reading flash memory:

Reading | ################################################## | 100% 19.47s

avrdude: writing output file "m128_read.hex"

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avrdude -c usbtiny -p m32 -B5

avrdude: AVR device initialized and ready to accept instructions 

Reading | ################################################## | 100% 0.02s

avrdude: Device Signature = 0x535353
avrdude: Expected Signature for ATMEGA32 is 1E 95 02
         Double check chip, or use -F to override this check

avrdude done. Thank you.

I am using windows 7, 64 bit. avrdude Version 5.10

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

I am very confused. This does not look normal to me at all.

Has your mega32 been through the wars?

Do you have any other AVR chips?

I presume that the usbtiny pcb was commercially built i.e. good soldering.

If you are in Europe, email me, there are some other things to try for curiosity. I suspect the chip is broken.

David.

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

I had this exact same problem tonight, lol. What happened in my case was that I was specifying

avrdude -c usbtiny -p m32

when I should have been specifying

avrdude -c usbtiny -p m324p

...because the MCU I purchased was different than the one in the tutorial I was following.

While you can suppress that error by passing the -F flag to avrdude from the command line (or inserted into your Makefile), I suspect that there is a simple enough explanation. At least in my case this was the problem--and I got the identical message you yours, as I recall. So I would check to make absolutely sure that you are using an Atmega32 MCU. In my case, I *thought* that is what I had purchased from the place that put out the tutorials I am following. However they've changed the controller to the 324P device, so you need to pass that to avrdude instead. I checked the Atmega manuals on the two devices--and the port configuration appears to be identical. But avrdude did not at all like passing the m32 parameter to the m324p.

TB

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

Quote:
At least in my case this was the problem--and I got the identical message you yours, as I recall.

If you got:

avrdude: Device Signature = 0x535353 

I would be very interested to know.

David.

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

I am pretty confident that the expected signature hex value was identical, but I do not know if that was the identical device signature (in hex). But the message was indeed identical otherwise. So if the actual hexadecimal value found by avrdude is of importance in this situation, then it could very well represent a different situation indeed. I suppose that I could simply change the parameter in avrdude back to "m32" and try it again, and then report back a bit later this morning.

TB

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

The Signature is extremely important.

M0_bre happened to have a very strange value returned.
In fact every single byte that he read was a 'S' 0x53.

If you have had a similar response, I would be very interested. Whatever the single value.

Note that you often get 0x00 when you have the SCK freq too high for your AVR.
Or you get 0xFF if your wiring is wrong.

As part of the checks made by avrdude, it tests for the echo from AC530000 (enter program mode).
It expects to see 00005300 when the comms are in sync.
Most software simply checks for the 0x53 in the third byte. This is why M0_bre was getting 'initialised OK'

If you ever get 'initialisation failed', you should stop immediately. Never use the -F switch.

Note that you can have good comms and a valid but wrong chip Signature. e.g. if you said it was a m32 and you were using a m324.

David.

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

I think your pinout is wrong.

Here a sample of what I used in a recent project and it does work.

Attachment(s): 

Markus

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

The pinout is the same as I have connected it, I have tried the -p m324p but it still gives 0x535353. I will go to the shop monday and test this atmega and/or buy new one. I'll be sure to let you know

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

I just happened to think...if the OP is on Windows 64 bit, is it possible that this is a (Windows) driver-related issue for usbtiny?

There is a fellow in TX who posts some MCU programming tutorials on his website (newbiehack.com), along with accompanying YouTube videos. While the programmer he uses is the Pocket Programmer from Spark Fun, it uses the usbtiny drivers. But in Windows7 64-bit, at least back when he made the video earlier this year, he reports that there was some sort of problems with the usbtiny 64-bit drivers. He posts a solution, and this is what I used to install the drivers on my Win7 64-bit system. It works just fine for me--but I never tried it without using his fix.

Anyway, I have no idea if this is could be the issue for the OP or not...but it might be worthwhile to check out the first two or three videos on that website. I think the problems were apparently related to the signing of the original Windows drivers, but I am not entirely sure as I did not research it at any length. I simply used his method, and everything works.

TB

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

I have used DSEO to put a signature in the driver, as far as I can see the driver is accepted.
I will try it on XP to see if it gives a different reading.

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

Well, if the driver was signed, then this may not be the germane to your problem at all. But all I had to do was rename a .dll and a .sys file, and then drop them into the folder I got with the driver from SparkFun. Once that was done I installed the usbtiny driver in Legacy mode from that folder. It's a pretty simple process, but quite different than the normal driver installation process. Here's a link to the page on SparkFun where you can get the driver.

http://www.sparkfun.com/products/9825

This issue is discussed at the bottom of the page there.

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

you won't believe this, today I got the new atmega32, I put it in,

avrdude -c usbtiny -B5 -p m32

signature: 0x535353
again tried it on different operating systems.
Maybe someone can post a simple scheme with an ISP header on it (like the one I posted earlier)

Last Edited: Fri. Jan 6, 2012 - 12:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Either your usbtiny firmware is corrupted or the USB driver is corrupted.

I can see no reason for any SPI call to return a constant 0x53. Even if you have misplaced wiring, open-circuits, short-circuits ... . You would either get garbage or 0xFF / 0x00.

Open Device Manager and uninstall the usbtiny.
Then unplug and re-insert the usbtiny. Install the drivers again.

If this fails: The obvious thing is to try your usbtiny on another PC. Or perhaps under Linux. Unlike many Windoze drivers, Linux just works.

David.

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

Hello David,

I tried linux and xp on other pc´s. Your comment pointed
me towards the usbtiny hardware so I checked all joints on the tiny device. Then I noticed I had 2 resistors bypassed with 2 wires ( read somewhere these could be bypassed for some reason ) I removed them both and I could reach my atmega!! finally.

Thanks all for your help,
Mike

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

Go on. Put us out of our misery.

What two wires?
I believe you have V2 schematic.

David.

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

I circled the problem area. In the tutorial is this picture, but the resistors need to be in place.

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

You have carefully obscured the resistor numbers. I am guessing R4, R7 from the V2.0 schematic. Should be 1k5 but 0.0R should be fine too.

So your 'solution' is a mystery to me!
If you are ok now, you should be happy.

David.

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

I understand this is an old topic, but having the same exact issue on an arduino mini with a SMD Atmega 328P

 

The device is recognized and I can read fuses and other stuff but signature comes out as  0x53, 0x53, 0x53.

 

This one has the bootloader installed and I can use arduino with it via the usb<->serial interface but uploading with AVR dude gives me an error as the signatures dont match

 

Counterfeit MCU?

Last Edited: Sun. Mar 27, 2016 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While the signature is usually the proof that ISP is connected if you are SURE that the ISP is working then you can override avrdude's sig check using -F (though usually this is ill advised). 

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

Read message #22.    I have no idea what M0_bre or I were talking about.   But it seems to be something with the Usbtiny hardware.

 

I can't understand why anyone would use usbtiny when Chinese Usbasp are so cheap.

 

From memory,   I built the usbtiny firmware for a mega8 and it runs just fine.   

 

David.

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

I had a similar problem but with the signature being read as 0x666c61.

 

Turned out the chips was in the socket the wrong way around.