[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: [avr-gcc-list] Lock bits
From: |
Anton Erasmus |
Subject: |
Re: Re[2]: [avr-gcc-list] Lock bits |
Date: |
Wed, 05 Jan 2005 10:48:36 +0200 |
On 4 Jan 2005 at 23:53, interia wrote:
> Hello,
>
> Tuesday, January 4, 2005, 9:26:23 PM, you wrote:
>
> GD> "Larry Barello" wrote:
>
> >> More likely, however, is that you accidentally selected an external
> >> clock option which effectively kills the chip.
>
> GD> The OP said "[I] can also use JTAG". Messing up the clock fuses
> does not GD> prevent the JTAG interface from working. You can set
> another clock mode GD> with a JTAG interface and recover. This is
> because it uses its own clock GD> and does not need the main MCU clock
> to run. This is not documented, but GD> Atmel have confirmed that it
> is so.
>
> GD> However, the OP also talks explicitly about lock bits and not
> fuses. He GD> does not say whether or not the fuses are messed up as
> well. It should be GD> possible to erase the chip and clear the lock
> bits with either the SPI or GD> JTAG interfaces. I have certainly
> done this, though not specifically with GD> an ATmega128. He reports
> that this does not work. This could be explained GD> by both the SPI
> and JTAG interfaces being disabled, in which case, yes, GD> parallel
> programming seems the only way out.
>
> GD> Graham.
>
> I looked into datasheet and found that the only way to clear lock
> bits is "chip erase" command in parallel programming mode with +12V
> supply applied to /RESET pin. There's been no problem with clocking
> because I had to use external clock when I was checking Configuration
> and Security bits. Thanks Larry.
>
On the ATMega128 I have no problem in clearing the lock bits by doing a full
erase
using the JTAG port. (The JTAG port must just not be disabled). AFAICR it also
worked on the ATMega16 and ATMega32.
Regards
Anton Erasmus
--
A J Erasmus