Fri 02 May 2014 07:43:50 AM UTC, comment #1:
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?
|