[avrdude-dev] [bug #21954] verify fails for masked ('x') bits

[Matthijs Kooijman]

Follow-up Comment #1, bug #21954 (project avrdude):

I'm running into a similar problem: Using my STK500 ISP programmer, the unused
bits get written as 1, but read as 0, so I must use e.g. 0x3f when writing the
lock byte to prevent a verify error.

However, on my JTAG3ICE in ISP or JTAG mode, the unused bits get written and
read without any extra processing. Since the hardware fixes thes bits to 1,
and they should be written to 1, I must write 0xff to prevent verification
errors.

In general, this makes the value to use for the lock byte dependent on the
programmer to use, which is a pain when multiple boards are involved too (like
in the Arduino environment).

I've had a look at the code, here's what I found:

 - STK500 uses the avr_read_byte_default(), which uses the configured read ops
from avrdude.conf and avr_get_output() to just set values for the used lock
bits in the value read. Since the value starts out as 0, any unused bits
remain 0 (even though they're 1 in the hardware). The read op for m2560 for
example, looks like this:

        read            = "0 1 0 1  1 0 0 0   0 0 0 0  0 0 0 0",
                          "x x x x  x x x x   x x o o  o o o o";

e.g., only 6 bits are used, the upper two are ignored.

 - The write op for m2560 looks like this:
        write           = "1 0 1 0  1 1 0 0   1 1 1 x  x x x x",
                          "x x x x  x x x x   1 1 i i  i i i i";

   e.g., the upper bits are always written as ones.

 - jtag3 uses its own read byte function, that does not use the read and write
ops from avrdude.conf. Instead, it just sends a fixed "CMD3_READ_MEMORY
MTYPE_LOCK_BITS" command, which returns the full lock byte. It then returns it
without further processing.
 - jtag3isp only uses the read op from avrdude.conf partly: It constructs the
command to send through the STK500 protocol with it, but then the command
result is just a single byte, not the full ISP response.

An obvious solution would be to either not do any masking at all (just read
and write full bytes, it seems the read command actually returns the full lock
byte, with 1s for the unused bits), or default unused bytes to 1 to match the
hardware. However, this is bad for backward compatibility - Anyone using e.g.
0x3f with the STK500 will suddenly see his verifies breaking. On the plus side
- it's probably a good idea to set the unused bits to 1 on the cmdline as
well, in case you ever change parts and a previously unused lock bit is now
used, at least it will remain unlocked.

A better approach is probably to explicitely mask out the bits during
_verification_, so it doesn't matter if you specify them as 0 or 1 on the
commandline. This keeps compatibility with either current approach, and makes
things less error-prone. Figuring out which bits are unused can probably
happen from the read or write ops, or perhaps an explicit mask would be nicer?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21954>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/