Expected signature for ATmega328P is 1E 95 0F. Double check chip, or use -F

I'm trying to burn a bootloader for an Arduino Pro or Pro mini using an Arduino Uno in ISP mode.
When I run the sketch I get this error:

avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
User configuration file is "/Users/roberthancock/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.wchusbserial1420
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack


eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude: Device signature = 0x1e9405 (probably m169)
avrdude: Expected signature for ATmega328P is 1E 95 0F
Double check chip, or use -F to override this check.

avrdude done. Thank you.

Error while burning bootloader.

The chip on the board reads Mega328P AU so I would have expected it to work OOTB but....
I tried changinmg the avrdude.cong signature which is:

#------------------------------------------------------------

ATmega328

#------------------------------------------------------------

part
id = "m328";
desc = "ATmega328";
has_debugwire = yes;
flash_instr = 0xB6, 0x01, 0x11;
eeprom_instr = 0xBD, 0xF2, 0xBD, 0xE1, 0xBB, 0xCF, 0xB4, 0x00,
0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF,
0x99, 0xF9, 0xBB, 0xAF;
stk500_devcode = 0x86;

avr910_devcode = 0x;

signature = 0x1e 0x95 0x14;
pagel = 0xd7;
bs2 = 0xc2;
chip_erase_delay = 9000;
pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
"x x x x x x x x x x x x x x x x";

chip_erase = "1 0 1 0 1 1 0 0 1 0 0 x x x x x",
"x x x x x x x x x x x x x x x x";

timeout = 200;
stabdelay = 100;
cmdexedelay = 25;
synchloops = 32;
bytedelay = 0;
pollindex = 3;
pollvalue = 0x53;
predelay = 1;
postdelay = 1;
pollmethod = 1;

by default to

signature = 0x1e 0x95 0x0F

but get the same message.

Any ideas?

And how to I use the -F verb to override the check if necessary?

Thanks for any advice.

And they always read the same, wrong signature? Not like, random (indicative of bad/loose wiring or something like that)?

That is extremely weird, if so.

Just an FYI, that avrdude.conf entry is for the ATmega328. There is a separate entry for the ATmega328P, which has a different signature from the ATmega328.

However, before messing with the signature, I would answer DrAzzy's question about whether it reads the same signature on every upload. If the signature is changing then there are more appropriate fixes than faking the signature.

Dr Azzy. Yes. Always the same error.

Pert. Second, and this is weird, there is NO ATmega328P definition in this avrdude.conf.

This is from Arduino IDE 1.8.9.

I attach the conf file for confirmation.

avrdude.conf.zip (32.7 KB)

BTW, this was on MacOS but to confirm I repeated on Windows 7 and EXACT same problem with ARD IDE 1.8.9.

Did somebody forget to include definitions for the ATmega32P-AU in the avrdude.conf file?

It's at line 8589. It looks different from the definition for ATmega328 because it's able to use the ATmega328 definition as a "parent", so that it only needs to define the few differences (as far as avrdude is concerned) between the two parts.

Thanks,

OK I see that, but something is not working with this code and set up. I have checked the pin connections at least twice.

This is getting frustrating and I see quite a few people over the years have had the same problem but no clear solution.

Can you advise how to use -F verb to force the upload. I have not found instructions anywhere.

If you're set on going that route, just edit the signature in avrdude.conf. That will be easier than doing the -F.

Sorry pert, but what's to edit?

Both definitions for the 328 and 328P are already present in avrdude.conf but neither is functioning for the 328P AU on my board!

No idea what else to do.

Any suggested workaround welcomed.

Because the '328p on the board is reporting that it's a '169p.

If this behavior is consistent, and you're always getting the same ID, that strongly suggests defective or mismarked parts....

It's hard for me to believe it's mismarked because the ATmega169P is a 64 pin part. So they would have had to put the ATmega169P die in a 32 pin leadframe. I'm not sure that's even possible. If it were, I can't imagine the wire bonds would happen to correspond from one pinout to another to make it even work enough to report a signature, unless the swap was done deliberately. That surely wouldn't have been Atmel or Microchip so we would be talking about counterfeiters. But why would a counterfeiter go to all that trouble to make a chip that will be obviously messed up to the customer the first time they try to program it? It seems like they would be much more likely to just relabel any chips in the appropriate package they could get their hands on for cheap or free (as happened to SparkFun a while back). Or if they have the ability, just make slug chips with no die in them.

So my take is that it's more likely to be defective.

What's the story with this board nekton123? Where did you get it? Have you ever used it successfully or was it DOA? Are you wanting to burn the bootloader because you can't upload to it?

The board (supposed ATmega328P, 8 MHz, 3.3 V) was bought direct 2 weeks ago from China via Aliexpress. When it first arrived, I thought the on-board LED heartbeat pulse was odd with just one pulse at power-on and then nothing. And I have been unable to upload any sketch since new and there is no access via a FTD1232 serial I/F.

I thought maybe it had been delivered without a bootloader so connected it to an Arduino in ISP mode to burn the bootloader and when the flash starts, the LED on the suspect board does pulse several times.

I agree the bootloader burn response seems to be suggesting it is a 169 MCU, but the chip is clearly marked Atmel MEGA328P AU.

One thing I have noticed is that since the first attempt to burn the bootloader, there is now no single-pulse heartbeat on the board LED at power-up with just Vcc and GND connected, which I think is symptomatic of not having a bootloader. Could attempting to burn a bootloader have removed a damaged bootloader, leaving it without a bootloader?

The only time the onboard LED flashes now is when connected to the Uno in ISP mode as the bootrom burn is attempted and fails.

I think I may have been "sold a pup" by some cowboys on Aliexpress.

Oh well, live and learn.

Thanks for your advice.

My thought is that at this point you might as well try faking the signature just to see what happens. However, you should be aware that this might end up permanently bricking the microcontroller or maybe it will seem to work at first but will turn out to not be reliable. If you're fine with that risk, I can provide you with instructions.

However, I would first like to see if DrAzzy has any opinions on alternative solutions for this before proceeding as they are much more knowledgeable on this stuff than I am.

The board (supposed ATmega328P, 8 MHz, 3.3 V) was bought direct 2 weeks ago from China via Aliexpress.

Probably fakes. I would just throw them away and buy from a more reputable seller.

Even if you figure out a way to program it, the chances are excellent that it will not work for your application.

This is a somewhat old story, but totally relevant: Counterfeit ATMega328s identified (and links therein).

JFSAG, I found this page about OSX and avrdude/atmel ICE controller.

I followed the kext install procedure and now I get a different message when trying to burn the bootloader.
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
User configuration file is "/Users/roberthancock/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.wchusbserial1420
Using Programmer : stk500v1
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack


eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 3
Firmware Version: 4.4
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

Error while burning bootloader.

Notice how it is different from this previous section:

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 3
Firmware Version: 4.4
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us

versus the earlier

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

Why the difference? Not only are voltages, etc., different but the Topcard: Unknown found in the earlier attempt is now absent. Could Topcard be a reference to a Shield?

There is a homebrew version of avrdude for macos so I'll try the CLI to -F the burn

jremington:
This is a somewhat old story, but totally relevant: Counterfeit ATMega328s identified (and links therein).

That is a fascinating story. I'm glad SparkFun made the effort to document it so well. I had mentioned it in #10 but didn't take the time to dig up the link so thanks for that. However, there is an important difference. The die in SparkFun's counterfeit chips ended up being some completely unrelated silicon, which I'm certain avrdude would not have been able to communicate with enough to be able to read a signature. I'm guessing they were used by the counterfeiters simply because they were cheap or free and had the right IC package. They only needed to relabel the chips and find someone to sell them to.

I agree with you that likely the smartest thing is to throw it away, but if it were mine I'd still go ahead and override the signature check purely out of curiosity.

Any ideas what CLI might work:

Mac-mini:~ roberthancock$ avrdude
Usage: avrdude [options]
Options:
-p Required. Specify AVR device.
-b Override RS-232 baud rate.
-B Specify JTAG/STK500v2 bit clock period (us).
-C Specify location of configuration file.
-c Specify programmer type.
-D Disable auto erase for flash memory
-i ISP Clock Delay [in microseconds]
-P Specify connection port.
-F Override invalid signature check.
-e Perform a chip erase.
-O Perform RC oscillator calibration (see AVR053).
-U :r|w|v:[:format]
Memory operation specification.
Multiple -U options are allowed, each request
is performed in the order specified.
-n Do not write anything to the device.
-V Do not verify.
-u Disable safemode, default when running from a script.
-s Silent safemode operation, will not ask you if
fuses should be changed back.
-t Enter terminal mode.
-E [,] List programmer exit specifications.
-x <extended_param> Pass <extended_param> to programmer.
-y Count # erase cycles in EEPROM.
-Y Initialize erase cycle # in EEPROM.
-v Verbose output. -v -v for more.
-q Quell progress output. -q -q for less.
-l logfile Use logfile rather than stderr for diagnostics.
-? Display this usage.

avrdude version 6.3, URL: http://savannah.nongnu.org/projects/avrdude/
Mac-mini:~ roberthancock$ avrdude -p m328p -C /Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -c stk500 -p /dev/cu.wchusbserial1420 -F -e -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex
avrdude: error at /Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf:1133: programmer type jtagice3_updi not found
avrdude: error reading system wide configuration file "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
Mac-mini:~ roberthancock$

programmer type jtagice3_updi not found

It is there on line 1133

;

programmer
id = "xplainedpro_updi";
desc = "Atmel AVR XplainedPro in UPDI mode";
type = "jtagice3_updi";
connection_type = usb;
usbpid = 0x2111;
;

Attempt to burn the bootloader in the Arduino IDE. After the process fails, examine the contents of the black console window at the bottom of the Arduino IDE. There you will find the avrdude command(s) generated by the Arduino IDE. You can copy the command(s) and then add the -F to them. The tricky thing is that the Arduino IDE's Burn Bootloader process is done in two commands. The first sets the fuses on the target microcontroller according to the boards.txt definition for the board currently selected from the Tools > Board menu. The second command flashes the bootloader file to the microcontroller. The signature verification failure is causing the Arduino IDE to fail at the first command so you won't see the second command in the console. That's why I said it would be easier to just temporarily change the signature value in avrdude.conf. After that, you can let the Arduino IDE do all the work.

Since you seem bound and determined to do this one way or another, I'll go ahead and help you out. Please be aware that you do this at your own risk. I take no responsibility if it bricks your board. To fake the signature verification check into passing, change line 8592 of avrdude.conf from:

    signature		= 0x1e 0x95 0x0F;

to:

    signature		= 0x1e 0x95 0x05;

Save the file and then do a Tools > Burn Bootloader in the Arduino IDE.

nekton123:
programmer type jtagice3_updi not

It's because your avrdude.conf is not compatible with the "homebrew version of avrdude" you're trying to use. Arduino has a specially modified version of avrdude and their avrdude.conf file is written specifically for that version of avrdude.

Thanks pert. I take full responsibility for killing the board.

Fingers crossed.