13

Sometime in the past, I was burning bootloaders on a fresh batch of four ATmega328-PU using the Arduino IDE (notice there's no P after 328 - it's the slightly cheaper non-picopower version of the MCU, not to be confused with the ATmega328P-PU with a P), and was surprised with the following message from avrdude:

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

That means avrdude thought the chip was not what its label said. Then I changed the chip type on my Arduino IDE to ATmega328P-PU and avrdude burned the bootloader without complaints. What that means is that the chip was labelled as one MCU and internally it responded as another, slightly different.

What I would like to know is:

  • How rare is this event? Has anyone had a similar experience? (Original question, off-topic)

  • Is it possible to fix this? How can I fix the signature so that avrdude recognize the chip correctly?

This is a cross-post from EE.SE. I posted this question there but didn't attract much attention, so I wanted to see if anyone from our community had a similar experience.

Improve this question
1
  • 1
    It seems that your vendor simply mislabelled some 328P's (which is what this signature represents) as 328s.
    – microtherion
    Commented Jan 8, 2015 at 20:04

3 Answers 3

Reset to default
4

While browsing sparkfun, i have found several news posts that show their struggle with mislabeled chips. Here are a few:

Sparkfun had received a questionable shipment if ICs from a new seller in china. They decided to test them before sending them into production, and none of their test boards worked. Using nitric acid, they were able to remove the case of the ICs and fould a hunk of metal that looked like copper.

In another article, they dissected some suspicious ICs from Atmel, and found an ON semiconductor silicon wafer inside. The chips were not functional ATmegas, but they did have silicon, unlike the other ones.

Improve this answer
3
  • 3
    Can you flesh this answer out a bit? Summarizing the articles you linked to would be a good start - right now, if sparkfun goes down for any reason your answer will be worthless.
    – Shog9
    Commented Feb 15, 2014 at 3:22
  • @Shog9 Why? The question is way off base. This answer is a summary of instances of people receiving mislabeled chips (essentially people sharing experiences). Who is this going to help?
    – asheeshr
    Commented Feb 15, 2014 at 7:58
  • I could ask you the same, @AsheeshR - why worry about an answer when the question is the problem? Anyway, thanks for adding the detail, TheDoctor.
    – Shog9
    Commented Feb 15, 2014 at 8:29
3

Not the preferred way to fix things and certainly not the first solution to consider, but you can consider programming the signature bytes. Before attempting this be absolutely sure you really want to do this and you have investigated what is involved to undo this. This may involve changing configuration files on your computer ...

Anyways the way to set the controller's signature bytes is as follows (untested, I don't have a spare AVR lying around):

avrdude -p atmega328 -c arduino -P /dev/ttyUSB003 -b 19200 -v -U signature:w:0x1E,0x95,0x14:m
Improve this answer
2
  • 2
    I know this is very late, but I don't think it's a good idea to let this stand as the accepted answer unchallenged: The signature on an atmega328 is not writable, and to my knowledge, the signature is not writable on ANY atmega or attiny.
    – microtherion
    Commented Jan 8, 2015 at 20:01
  • 2
    Out of interest, I tried the above approach, which avrdude accepted in a sense: avrdude: writing signature (3 bytes) - however it failed to do it: avrdude: verification error, first mismatch at byte 0x0002: 0x14 != 0x0f
    – Nick Gammon ♦
    Commented Aug 25, 2015 at 21:32
1

There are several different flavors of ATMega328. The most commonly found in Arduinos Uno (et al) is the ATMega328P, which is Atmel's "picopower" version; this one has the 0x1E950F signature that AVRDude expects when it's tasked with programming an Arduino Uno. Gee, figure that.

Less common is the base model ATMega328 (no suffix) and the ATMega328PU, both of which yield a 0x1e9514 signature instead of the expected 0x1E950F.

As to commonality... that depends upon the crowd with which you run. If you are Arduino through-and-through, never use any boards that aren't teal-colored, then it's extremely uncommon for you to find a non-ATMega328P. If, on the other hand, you run in my gang and build all manner of cool stuff on funny-colored boards that don't have staggered header pin spacing in one spot... then it's very common to get non-p '328s.

There are workarounds. There was for a while a variant ArduinoISP_Multi that would translate a 0x1e9514 signature to a 0x1E950F signature, permitting you to gleefully program your breadboarded or otherwise non-teal '328 boards exactly as if they were genuine Arduino Unos. For whatever reason that "sketch" can no longer be found.

You can also edit avrdude.conf (with backup, please!) such that it (AVRDude) expects the signature that your '328 coughs up. The backup is particularly important because you may want someday to program "real teal". The avrdude.conf file can be found in your Arduino installation at ...\hardware\tools\avr\etc.

OR... wait! There's MORE! All for one money! You can also write your own hardware profile for non-P '328s and put it in your Arduino "sketchbook"'s hardware directory, then draw from that as a custom board definition. Aw, shucks... it ain't that hard! Really! I've written several of those for my own board designs.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.