Seeing lockbits in hex from avrdude

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

The -v option gives, for example:

Quote:
...
avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DC
avrdude: safemode: efuse reads as 1
avrdude: safemode: Fuses OK

avrdude done. Thank you.

at the end of the run. What I'd also like to see is, for example
Quote:
avrdude: safemode: lock reads as C0

I've messed around with:
Quote:
-U lock:r:con:r
-U lock:r:-:r
...but these all show the ascii character on screen rather than readable hex

If I use

Quote:
-U lock:r:"lock.out":r
...then looking at the file in Notepad++ (a PITA to launch and look) I see the ascii character if printable, or the hex code if not.

Any ideas on how to just get the lock bits on the screen, in hex, just like the other fuses?

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

..and another problem :(

With

Quote:
-U lock:w:0xc0:m
...I get
Quote:
avrdude: reading input file "0xc0"
avrdude: writing lock (1 bytes):

Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.06s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xc0:
avrdude: load data lock data from input file 0xc0:
avrdude: input file 0xc0 contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

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

Ideas on that one?

Full avrdude line is

Quote:
avrdude -c usbasp -P usb -p m168 -U flash:w:"projectx.hex":a -U eeprom:w:"projectx.eep":a -U lock:w:0xc0:m -v

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

Re lock bits:

Look in your avrdude.conf file.
You will see that for most chips are

write: "01011100 111xxxx xxxxxxxx 11iiiiii"
read : "01011000 0000000 xxxxxxxx xxoooooo"

So whatever you write in the lock bits always has bits 7, 6 set. They should be ignored for most chips anyway.
When you come to read the lock bits, avrdude will mask out bits 7, 6.

So if you want to clear all the lock bits, mask out the top bits yourself. e.g. instead of 0xC0, use 0x00.

The alternative is editing all the lock_read entries in avrdude.conf. This is especially risky since one day Atmel may start using bits 7, 6.

There is a similar anomaly with the "efuse" entry. A chip like the Tiny2313 only uses one bit. Yet the conf entry masks out all the other ones when writing, no mask on reading. If you want to play safe with 'unimplemented' fuse bits, you should write 1 (unblown) to these bits. When the conf says mask out unused bits, it is writing a 0 (blow).

David.

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

Thanks David

Further investigation showed that

Quote:
avrdude -c usbasp -P usb -p m168 -U lock:w:0xc0:m -v
despite the error message, was in fact setting the lock bits as required (all lock bits set (=0)) by checking with my STK500 on AS4 immediately after avrdude'ing - which showed them as being 0xc0.

But

Quote:
avrdude -c usbasp -P usb -p m168 -U lock:w:0x00:m -v
also works as required (all lock bits set and STK500/AS4 reports them as 0xc0)...but no avrdude error messages on write or verify. Yay :)

Happy New Year, and thanks for all your help in 2011!

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

I did not understand how to clear the lock bits. Which bits I have to clear in avrdude.conf so one can´t read the hex file?

Last Edited: Sun. May 10, 2015 - 01:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can only remove lock protection by erasing the whole chip.

 

So you typically: erase, program flash, program fuses, program lock.  e.g.

 

avrdude -e

avrdude -U flash:w:file.hex

avrdude -U hfuse:w:0xDE:m

avrdude -U lock:w:0x0F:m

 

The actual value that you put in to the lock depends on which chip and which features.

 

You probably write the fuses before the flash.    However,  writing to the lock should always be the last step.

Note that some lock values will prevent you reading back.   So you can't verify afterwards.   Hence you write and verify flash before you set locks.

 

Think first before you do anything.    Then put the commands in a batch file.   Then you don't have typos.

 

David.