MEGA168 signature 0xFF,0xFF,0xFF after debugwire session

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
#1
Posted by gahelton: Mon. Jan 21, 2008 - 10:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although I have had more than my share of dead MEGA's from debugwire mishaps, this is a new one for me.

After exiting a debugwire session (which appeared to end smoothly), I went back to the STK500 to program some fuses. Although the STK500 would connect, the signature read from the device was 0xFF,0xFF,0xFF. The fuses, flash, and EEPROM would program/verify just fine. But signature was wrong. After checking the usual suspects like ISP clock rate, etc, the signature still wrong.

How can the signature get erased ? Are the signature bytes hard coded or is it in a "protected" flash or eeprom area ? Also, it appears as if the OSC calibration value is also erased (0xFF).

I know that the ultimate resolution will be to replace the part. Has anyone seen this before ?

Thanks

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Jan 21, 2008 - 10:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to re-enable ISP mode. To do this start a debugwire session and the option to then switch the _RESET pin from DW to ISP mode is on the dialo accesed in the dialog form the bottom of the Debug menu

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Mon. Jan 21, 2008 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The debugwire session appeared to end normally before the problem. Looking at the fuses, the "Reset Disabled" fuse is not checked. "Debug Wire enable" is also not checked.

If reset was not enabled, or debugwire was still enabled, I would not be able to erase/program/verify flash and EEprom with ISP.

When an attempt to go back into debugwire is made, Studio asks to re-enable debugwire. When the attempt is made, Studio reports "An device with SPI signature 0xFFFFFF was detected".

Debugwire will not reconnect with a bad device signature.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Jan 21, 2008 - 11:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It can only be in one of two modes - either DWEN or SPIEN. So try to contact it via dW and ISP and use whichever works to switch to the other

Top
kevin123
kevin123's picture
Level: Hangaround
Joined: Sun. Jan 20, 2008
Posts: 208 View posts
Location: Canada
Posted by kevin123: Tue. Jan 22, 2008 - 02:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have seen something similar happen on an ATmega48, except it was not after a debug wire session but after reprogramming via ISP mode.

Similar to what you are seeing, the signature bytes were always being read as 0xFF, 0xFF, 0xFF. The micro still functioned normally, could be erased, verified or reprogrammed. The only abnormal thing was the signature always being read as 0xFF, 0xFF, 0xFF. Fuses could all be verified as normal.

At the time it happened, I seem to recall finding an errata document or some other document that confirmed the signature could be erased under some circumstances. I can't seem to find anything about it right now.

Top
kevin123
kevin123's picture
Level: Hangaround
Joined: Sun. Jan 20, 2008
Posts: 208 View posts
Location: Canada
Posted by kevin123: Tue. Jan 22, 2008 - 02:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The errata in the ATmega8 datasheet has the following on page 296:

Quote:
3. Signature may be Erased in Serial Programming Mode
If the signature bytes are read before a chiperase command is completed, the signature may be erased causing the device ID and calibration bytes to disappear. This is critical, especially, if the part is running on internal RC oscillator.
Problem Fix / Workaround:
Ensure that the chiperase command has exceeded before applying the next command.

Maybe something similar is possible on other AVRs as well. This errata does seem to confirm the signature is stored in flash and not hardwired.

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Tue. Jan 22, 2008 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's what I know.

1. The chip is fully functional. Reset is enabled, SPI is enabled, DW is disabled. The part will erase, program, and verify through ISP (confirmed by reading results to a file and verifing).
2. Problem is not with ISP clock (see #1).
3. Signature bytes and OSC CAL value are all erased.
4. It is possible to erase signature and OSC CAL values (see #3).

Whatever causes this problem, rare as it may be, it is real.

Searching on this site, I have found at least 4 other instances nearly identical to mine.

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=36227&highlight=invalid+signature

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=54071&highlight=signature+bytes+calibration+byte+overwritten

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=40282&highlight=atmega64%2A+signature

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=40395&highlight=chip+shows+wrong+device+signature

If these values are in a reserved area of flash or eeprom, and can be erased, then they can be programmed as well. Obviously, the signature bytes are not hard wired and can be programmed at the factory. Now the question is HOW ???

Top
zurca
zurca's picture
Level: Rookie
Joined: Wed. Sep 26, 2007
Posts: 41 View posts
Posted by zurca: Tue. Jan 22, 2008 - 10:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have seen the same problem .

To calibration you can use Ap note 53/54/55 and software (asm ) suplied by Atmel.

Top