AVR Freaks :: View topic - Weirdness when trying to program lock bits?

Weirdness when trying to program lock bits?

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum

Author

Message

rahji

Posted: Oct 23, 2007 - 06:07 PM

Joined: Feb 21, 2007
Posts: 40

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:

Code:

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

Code:

$ 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

theusch

Posted: Oct 23, 2007 - 06:19 PM

Joined: Feb 19, 2001
Posts: 19075
Location: Wisconsin USA

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.]

rahji

Posted: Oct 23, 2007 - 07:04 PM

Joined: Feb 21, 2007
Posts: 40

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

theusch

Posted: Oct 23, 2007 - 07:22 PM

Joined: Feb 19, 2001
Posts: 19075
Location: Wisconsin USA

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

rahji

Posted: Oct 23, 2007 - 07:59 PM

Joined: Feb 21, 2007
Posts: 40

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

rahji

Posted: Sep 25, 2008 - 01:49 AM

Joined: Feb 21, 2007
Posts: 40

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/

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum