Re: [avr-gcc-list] uisp - atmega16 "dead" after setting high/low fuses

[Joerg Wunsch]

Rieker Flaik <address@hidden> wrote:

> "Maybe
> I falsely set some Lock-Bits a while ago", I thought

Btw., lockbits are always erased upon a chip erase, so that's never
going to be a problem when reprogramming a device.

>   In my design I use a external crystal. So I tried to set the
> fuse-bytes accordingly:

The fuse byte values make sense, assuming you are goin to connect an
external crystal of at least 1 MHz.

> What could be the problem?

Assuming uisp actually programmed the fuses correctly (Eric already
told you it's been out of maintenance for many years now), can you
somehow assure the crystal oscillator is actually running, e.g. by
probing with an oscilloscope?

Failing that, can you locate some external clock source (in the low
MHz range), and feed it into XTAL1 to see whether you can resurrect
the controller that way?

Finally, JTAG might be an option to resurrect the chip(s), as JTAG
programs the device using its own clock.  For the ATmega16, you could
quickly hack one of those cheap JTAG ICE mkI clones together, using
another ATmega16.  But obviously ;-), this requires a safe method to
program ATmega16s first, so that's only a possible fallback once you
found your mistake, in order to recover the now dead ATmega16s.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)