Re: [avr-chat] avrdude doesn't write lock bits with JTAG ICE mkii on 328P target

[Joerg Wunsch]

"Daved" <address@hidden> wrote:

> "-CC:\Program Files\arduino-0017\hardware/tools/avr/etc/avrdude.conf" -v =
> -v -v -v -pm328p -cjtag2isp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m =
> -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

Well, 0x3F is just *no* lock bits at all.  What are you going to
achieve?

> It tries to write the the lock bit but fails the read back
> verification.

Exact error message?

> 1. Is this limitation for the mkii as well?

"mkii" is not the name of a programmer, it's a version.  There's a
JTAG ICE mkII, and an AVRISP mkII.

If you are referring to the JTAG ICE mkII: yes, this "limitation" is
the same.  In other words: the debugging functionality (which is the
other part of what the JTAG ICEs can do) is *not* supported by AVRDUDE
(but requires AVaRICE).

> 2. Since the JTAG ICE mkii is capable of programming the lock bits
> and = fuses (I can do it with AVR Studio), why isn't this
> functionality = supported in avrdude?

Of course, it is.

I don't have an ATmega328P handy, only a design with an ATmega48
sitting nearby:

avrdude -p atmega48 -P usb -c jtag2isp  -B10  -U flash:w:vfd20.hex -U 
lock:w:0x3f:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e9205
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "vfd20.hex"
avrdude: input file vfd20.hex auto detected as Intel Hex
avrdude: writing flash (2792 bytes):

Writing | ################################################## | 100% 3.65s

avrdude: 2792 bytes of flash written
avrdude: verifying flash memory against vfd20.hex:
avrdude: load data flash data from input file vfd20.hex:
avrdude: input file vfd20.hex auto detected as Intel Hex
avrdude: input file vfd20.hex contains 2792 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.90s

avrdude: verifying ...
avrdude: 2792 bytes of flash verified
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.05s

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

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Btw., there are two suspicious things in your commandline:

.. You are erasing the device (-e), but are *not* programming the
  flash afterwards.  That does not make much sense.  If you are
  only about setting fuses and lock bits, why not let the flash
  alone then?

.. If you were really about programming lock bits (rather than
  specifying an expensive no-op, running through a complete
  programming cycle without altering them), programming the lock
  bits *only* makes sense if specified as the very last operation
  on the command-line, because otherwise, the device is "sealed"
  afterwards, and any subsequent programming attempts will fail.
  (This assumes you are about programming the standard lock bits
  rather than the bootloader bits.)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)