Re: [Uisp-dev] lock bits

[Theodore A. Roth]

Thanks for the explanation Marek. I will rethink what I'm doing taking 
this into consideration.

Ted Roth

On Sat, 1 Jun 2002, Marek Michalkiewicz wrote:

>Hi,
>
>> I've been digging through the code for handling lock bits. The way it is 
>> implemented now seems a bit inflexible to me. It looks to me that it's an 
>> all or nothing approach, i.e. you can only set all the lock bits with the 
>> "--lock" command and you can't clear them (except with a chip erase???).
>
>Lock bits are special, and supposed to work that way (can only change
>some bits from 1 to 0, only chip erase can change them all back to 1).
>
>> I'm currently trying to implement the new command line options for writing
>> fuses (done) and lock bits. What I'd like to see happen is simply
>> "--wr_lock=0xfd" where the value should correspond to the bits described
>> in the data sheets for the devices. Basically, if you are looking at the
>> data sheet for a device, you should be able to figure out your byte value
>> and pass it straight down to the device. Also, reading the bits should 
>> just dump what you expect from the data sheet instead of having to 
>> translate.
>
>The problem I was trying to solve (no perfect solution, I admit) is that
>some chips (such as the 8535) have a single "read fuse and lock bits"
>command which returns the lock bits in different positions (bits 7, 6)
>than in the "write lock bits" command.  Newer chips are more consistent
>(don't mix fuse and lock bits in a single read command), older chips
>don't support reading lock bits directly at all (you can only tell the
>chip is locked if you see 0x00, 0x01, 0x02 as signature bytes - newer
>chips like ATmega163 can be identified even if locked).  So, at least
>part of that mess is Atmel's fault :)
>
>I'd suggest to still support the simple --lock option to write reasonable
>default lock bits for any device.  The magic to move lock bits read from
>the device to the same places allows verifying them (read and compare
>with written values, but note that it's OK to write 1 and read back 0
>because that bit could already be programmed).
>
>Ideally, it should also be possible to refer to all these bits by their
>names (just like the check boxes in Atmel's GUI programmer software),
>but that may be quite a lot of work...
>
>Marek
>