Re: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses
Rieker Flaik rieker_fl...@arcor.de 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses
Hi Rieker, I think 'AVR Freaks' might be a better place to know more about device troubleshooting. HTH Anitha -Original Message- From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org [mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On Behalf Of Rieker Flaik Sent: Saturday, February 26, 2011 1:33 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses Hi, I did a ATMega16-Hobby-Project a while ago. Today I changed the source code, compiled it and tried to upload the hex-file into the chip. But it wasn't possible because uisp couldn't even detect the chip-model. Maybe I falsely set some Lock-Bits a while ago, I thought and took a second ATMega16 from my cubicle of electronic equipment and tested it with: uisp -dlpt=/dev/parport0 --rd_fuses -dprog=dapa I remember that it showed the correct chip-model and the default values for all fuses. In my design I use a external crystal. So I tried to set the fuse-bytes accordingly: HIGH_BYTE: 7 OCDEN On Chip Debug1 6 JTAGEN JTAG 1 5 SPIEN Serial Programming 0 4 CKOPT Oscillator Option0 3 EESAVE EEPROM is preserved 1 2 BOOTSZ1 Boot Size0 1 BOOTSZ0 Boot Size0 0 BOOTRST Reset Vector 1 0b11001001==0xC9 LOW_BYTE: 7 BODLEVEL Brown-out 1 6 BODENBrown-out enabled 1 5 SUT1 Start-up Time 1 4 SUT0 Start-up time 1 3 CKSEL3 Clock 1 2 CKSEL2 Clock 1 1 CKSEL1 Clock 1 0 CKSEL0 Clock 1 0b==0xFF did a: uisp -dlpt=/dev/parport0 --wr_fuse_h=0xC9 --wr_fuse_l=0xFF -dprog=dapa and the device was gone :-( Even a uisp -dlpt=/dev/parport0 --rd_fuses -dprog=dapa doesn't work. What could be the problem? Thanks, rieker ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses
Uisp is not maintained anymore. I would suggest that you use avrdude, which can also be found on the Savannah web site. -Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Rieker Flaik Sent: Saturday, February 26, 2011 1:03 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses Hi, I did a ATMega16-Hobby-Project a while ago. Today I changed the source code, compiled it and tried to upload the hex-file into the chip. But it wasn't possible because uisp couldn't even detect the chip-model. Maybe I falsely set some Lock-Bits a while ago, I thought and took a second ATMega16 from my cubicle of electronic equipment and tested it with: uisp -dlpt=/dev/parport0 --rd_fuses -dprog=dapa I remember that it showed the correct chip-model and the default values for all fuses. In my design I use a external crystal. So I tried to set the fuse-bytes accordingly: HIGH_BYTE: 7 OCDEN On Chip Debug1 6 JTAGEN JTAG 1 5 SPIEN Serial Programming 0 4 CKOPT Oscillator Option0 3 EESAVE EEPROM is preserved 1 2 BOOTSZ1 Boot Size0 1 BOOTSZ0 Boot Size0 0 BOOTRST Reset Vector 1 0b11001001==0xC9 LOW_BYTE: 7 BODLEVEL Brown-out 1 6 BODENBrown-out enabled 1 5 SUT1 Start-up Time 1 4 SUT0 Start-up time 1 3 CKSEL3 Clock 1 2 CKSEL2 Clock 1 1 CKSEL1 Clock 1 0 CKSEL0 Clock 1 0b==0xFF did a: uisp -dlpt=/dev/parport0 --wr_fuse_h=0xC9 --wr_fuse_l=0xFF -dprog=dapa and the device was gone :-( Even a uisp -dlpt=/dev/parport0 --rd_fuses -dprog=dapa doesn't work. What could be the problem? Thanks, rieker ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
