Device Signature Becomes 0x000000 After Programming Microcontroller

Development Tools Uploading
1

Hi all,

I am presently trying to program to an ATMEGA 1281 using MCUdude's MegaCore repository.

I've been having this weird issue which was originally intermittent, but is now consistent. Whenever I program the ATMEGA 1281, the device becomes unresponsive. I have tried the following configurations.

Programmer: Arduino as ISP
Task: Programming bootloader for internal oscillator.

Programmer: Arduino as ISP
Task: Programming Blink.

Programmer: Pocket AVR Programmer
Task: Programming bootloader for external oscillator.

If I attempt the to bootload the device I receive:

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

         System wide configuration file is "D:\Programs\Arduino\hardware\MegaCore-master\avr/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : usbtiny
avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f
         AVR Part                      : ATmega1281
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         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    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
           flash         65    10   256    0 yes    131072  256    512  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 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 : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9704 (probably m1281)
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xfc"
avrdude: writing efuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.06s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xfc:
avrdude: load data efuse data from input file 0xfc:
avrdude: input file 0xfc contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xf4 instead of 0xfc (double check with your datasheet first).
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xd6"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd6:
avrdude: load data hfuse data from input file 0xd6:
avrdude: input file 0xd6 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xf7"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xf7:
avrdude: load data lfuse data from input file 0xf7:
avrdude: input file 0xf7 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATmega1281 is 1E 97 04
Error while burning bootloader.

If I attempt to program:

avrdude: verification error, first mismatch at byte 0x0000
         0x62 != 0x0c
avrdude: verification error; content mismatch

To which further attempts to communicate to the device returns:

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

To my understanding this means that the two devices can communicate, but somewhere along the lines it fails verification, and dies.

I have attempted this through the command line as well, but to no avail. I have tried changing the baud rate. What's more, the programmer consistently has failed while programming efuses. I have tried searching for the issues for days, and can not find a solution. The voltages rails are staying at approx 4.9V during programming. (I have verified this with a multi-meter, will double check with oscilloscope.)

In short, my question is has anyone had an AVR device fail to communicate directly after successful communication. If so, what was your solution? Furthermore, does anyone have an idea of if these controllers are recoverable?

Note: I'm using the latest version of Arduino 1.8.6

This is an extension of my original post about the issue, however, the scope of the issue has changed.

2

The fact that you can write to the fuses, and then it goes to signature 0x000000 is a dead giveaway: You're setting the fuses to use a clock source other than the internal RC oscillator, but said clock source is not present or not working. This causes the chip to fail to respond to future programming attempts.

I see that you're setting it to use a crystal. Do you have that crystal connected? Are the loading caps present and properly connected? Doublecheck that it's connected to the right pins, that the connections to crystal and loading caps are short and not connected to anything else nor shorted to gnd/vcc/eachother.

3

It was the clock; thanks!

For those of you who may have this problem in the future; the device was operating fine, and then decided to kick the bucket. My understanding from various readings is that the AVRDUDE checks to see if the bootloader had been installed. If it fails to recognize a bootloader it will install default settings onto the device, that being the 16 MHz external clock. Having a clock I assumed that this was not the issue; however replacing the clock seemed to have resolved the issue.

However, I'm now getting verification errors again:

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

avrdude: verification error, first mismatch at byte 0x1fc00
         0xff != 0x01
avrdude: verification error; content mismatch
Error while burning bootloader.

@DrAzzy I've seen you post about this issue in 2016; is there a resolution to this yet?

4

Your understanding of what avrdude does when you do "burn bootloader" is totally wrong.
Burn bootloader does two things, as separate programming procedures:
Enters programming mode, sets fuses and lockbits according to the board definition you have selected.
Exits programming mode. This latches the fuse settings made above.
Enters programming mode, erases flash, and writes whatever bootloader is specified for the selected board definition.
Exits programming mode.

After each programming operation, it verifies the data.
("selected board definition" includes other sub-menus in tools to set clock speed, etc, if applicable). It does not check for presence of a bootloader or look at the current settings of the chip in any way - it blows away what is there and programs the fuses and bootloader for the board you've specified.

The verification error looks like it's failing to actually write the flash at all (ie, the first byte it reads back for the start of the bootloader is 0xFF (blank flash) instead of 0x01 (presumably the first byte of the bootloader).

Verification errors can have a number of causes. I'm not sure what's going on here. it looks like the lock bits aren't being set to prevent flashing or anything, so I'm not sure what to suggest.

5

Thanks for the info!

As per not writing flash, I'm not sure that that is the case. I have the blinking LED that is characteristic of a successful MegaCore bootload.

I'll start reading/experimenting to see if there is a solution.

6

THANK บอลออนไลน์:DDD