Re: [Uisp-dev] lock bits

[Marek Michalkiewicz]

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