Weirdness when trying to program lock bits?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can someone explain this to me?

I use this command: avrdude -p m8 -U lock:w:0xcf:m

and after "writing" and "reading", I get the following verification error:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xcf != 0x0f
avrdude: verification error; content mismatch

and, in fact, it appears that even though I tried to set it to 0xcf, it really set it to 0x0f

$ avrdude -p m8 -U lock:r:lock.txt:h
$ cat lock.txt
0xf

I'm using an stk500v2, atmega8 (I've tried several of them), and the same thing happens with any value I write for the lock bits (ie: the value changes). If I use avrdude to erase the chip, I'd expect the lock bits to be 0xff and again, it's 0x3f instead. The same thing happens with the Arduino bootloader script, which uses uisp instead of avrdude.

Am I missing something silly here??

Thanks for any help,
Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As the upper two bits in the byte are unused, I wouldn't fuss with them. Yes, the datasheet does indicate that they have a "1"/unprogrammed value. But it could even be the ISP firmware being chip-aware and masking off the unused stuff.

What value do you see in the AVRstudio window as the "raw" value read from an erased chip?

[I happened to have a mega8 mounted on my STK500, so I checked the lock byte reads & writes. AVRstudio does indeed show 0xff on both read and write.]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot for the help.. I see what you mean and I should've really thought about the difference between the value I was getting and the expected value. I see now that the first two bits are the difference and I didn't realize that only the 6 lower bits matter in that value until you mentioned it and I found it in the datasheet.

I looked at AVRstudio in Parallels (I'm using a Mac) and I'm not sure where the "raw" value that you mentioned is, but it does say "Reading lockbits .. 0XCF .. OK!" in one of the dialogs.

It's interesting that your STK500 shows 0xFF and mine doesn't. Maybe our boards are different versions? I like the theory that mine is masking those other two bits. Makes me feel like the mystery is solved, but it's still strange and also annoying to get errors from avrdude and uisp.

I haven't even checked to see that the rest of my script worked - I had assumed that it was failing when it encountered those errors but maybe (hopefully) they're just warnings that it is continuing past.

Thanks again,
Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mine is an old Mega8 -- ATMEGA8-16PI date code 0250 so 5 years old.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Mine is an old Mega8 -- ATMEGA8-16PI date code 0250 so 5 years old.

Oh, I meant the STK500. Maybe yours is older than mine or vice versa? Mine is definitely known as stk500v2 to avrdude and not stk500.

Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in case anyone comes across this thread.. here is a blog post i created when i found the solution to the problem i was having:

http://www.rahji.com/wordpress/2007/10/23/burning-the-arduino-bootloader-with-an-stk500v2/