After a bit more prodding, Atmel writes:

> Yes, adding a delay is the proper way to solve this problem. Atmel
> Studio adds a fixed delay of 20ms after writing the fuse and lock bits
> using ISP interface.

So it seems that a delay is the way to go, it should perhaps even be extended to 20ms.

Just compiled svn trunk and did a quick test, seems that the delay
solves this problem for me as well.

Atmel has replied to my case with:

> I understood from the bug report given in the following link that in
> AVRdude there is no proper delay after the write routine which makes the
> read operation failed. Hence, there might be no error with the JTAGICE3
> firmware. Please try the workaround which suggests adding some delay
> after the write routine in AVRdude and verify whether the problem gets
> sloved.
> https://savannah.nongnu.org/bugs/?42267
>
> I tried to program the device using Atmel Studio 6.2 using JTAGICE3 tool
> and I am able to write and read the lock bits successfully. As the read
> /write operation works fine with Atmel Studio I thing that there might
> be no error with the JTAGICE3 firmware.
>
> As AVRdude is a third party tool we are unable to comment on it.

Which doesn't really tell me if this behaviour is expected and/or if they
also consider the delay a workaround. I haven't replied yet, since I
discovered a bit more below.

Looking more closely at how things are implemented, I noticed that
avrdude pretty much sends raw ICSP commands to the JTAGICE3, which get
sent as-is over the SPI bus. This made me wonder if the firmware is
involved at all, or if it is the hardware messing this up directly.

I connected a logic analyizer to the ICSP lines and found out that the
incorrect 0xff reading comes directly from the target - the firmware is
just passing it through. Perhaps the older firmwares that do work
without the workaround have a delay themselves, either explicitly to
fix this, or implicitly because of slowness in the implementation?

Looking at the code, I also noticed that there was already a workaround
for the fuse bytes, where program mode was exited and re-entered after
programming a fuse byte. You replaced that workaround with the delay,
which seems to work as well. Removing both workarounds shows that fuse
bytes also return 0xff shortly after writing them, making it likely that
this problem is the same for both fuse and lock bytes.

I suspect the old workaround was based on this (from the 328 datasheet):

> The fuse values are latched when the device enters programming mode and
> changes of the fuse values will have no effect until the part leaves
> Programming mode.  This does not apply to the EESAVE Fuse which will take
> effect once it is programmed. The fuses are also latched on Power-up in
> Normal mode.

However, that doesn't say reading the fuses needs re-entering programming mode,
just that they won't take effect until you leave programming mode (so not
leaving programming mode is probably a good idea, in case you change e.g. the
clock speed).

Having said all that, it seems that adding a small delay like now is
probably a reasonable way to make sure things work. I'll ask Atmel if
they can confirm that such a delay is necessary, since it doesn't seem to be
documented anywhere I could find.

For the record, here's the SPI dumps with and without the fix. Everything is
identical, except for the timings and the last byte.

With fix                                          Without fix
Time [s],Packet ID,MOSI,MISO                      Time [s],Packet ID,MOSI,MISO
0.056597700000000,,0xAC,0x00                      0.056595600000000,,0xAC,0x00
0.057665400000000,,0x53,0x00                      0.057663300000000,,0x53,0x00
0.058733100000000,,0x00,0x53                      0.058731000000000,,0x00,0x53
0.059800800000000,,0x00,0x00                      0.059798700000000,,0x00,0x00
0.276508800000000,,0x30,0x00                      0.271037000000000,,0x30,0x00
0.277577000000000,,0x00,0x30                      0.272105800000000,,0x00,0x30
0.278645800000000,,0x00,0x00                      0.273174600000000,,0x00,0x00
0.279714500000000,,0x00,0x1E                      0.274243300000000,,0x00,0x1E
0.281239800000000,,0x30,0x00                      0.275737700000000,,0x30,0x00
0.282308600000000,,0x00,0x30                      0.276806400000000,,0x00,0x30
0.283377300000000,,0x01,0x00                      0.277882100000000,,0x01,0x00
0.284446100000000,,0x00,0xA8                      0.278950900000000,,0x00,0xA8
0.285893000000000,,0x30,0x00                      0.280338600000000,,0x30,0x00
0.286961200000000,,0x00,0x30                      0.281406800000000,,0x00,0x30
0.288030000000000,,0x02,0x00                      0.282475600000000,,0x02,0x00
0.289098700000000,,0x00,0x02                      0.283544300000000,,0x00,0x02
0.290716300000000,,0x58,0x00                      0.285061600000000,,0x58,0x00
0.291784500000000,,0x00,0x58                      0.286129800000000,,0x00,0x58
0.292853300000000,,0x00,0x00                      0.287198600000000,,0x00,0x00
0.293921000000000,,0x00,0xCF                      0.288267400000000,,0x00,0xCF
0.295528900000000,,0xAC,0x00                      0.289807600000000,,0xAC,0x00
0.296597100000000,,0xE0,0xAC                      0.290881700000000,,0xE0,0xAC
0.297665900000000,,0x00,0xE0                      0.291950400000000,,0x00,0xE0
0.298734600000000,,0xCF,0x00                      0.293018700000000,,0xCF,0x00
0.310333700000000,,0x58,0xCF                      0.294517300000000,,0x58,0xCF
0.311401900000000,,0x00,0x58                      0.295585000000000,,0x00,0x58
0.312470200000000,,0x00,0x00                      0.296653700000000,,0x00,0x00
0.313538900000000,,0x00,0xCF                      0.297722500000000,,0x00,0xFF

Hmm, I see. However, even though this might be the firmware's fault, it seems unlikely that this will be fixed on that end (especially for the older hardware, I'd expect). Closing this as invalid and ignoring the problem doesn't seem like a great idea, since then things will still be broken for anyone using avrdude with this hardware. When manually running avrdude, the obvious workaround is of course to not verify the lockbits, but for example running inside the Arduino IDE, I don't think this easy (and probably not possible without also disabling verification of the full binary). Having to disable verification isn't so nice anyway...

What's the problem with adding a workaround in avrdude? Sounds like it could just be added for the affected hardware (if the code structures allows this, not sure). Alternatively, adding a small delay for all hardware doesn't seem like a big burden?

Ideally, you'd not add workarounds for broken hardware or firmware to any software, but that's unfortunately often impossible. If the Linux devs would have used this filosophy, I don't think the Linux kernel would still exist today ;-p

I just did some quick testing with avrdude 6.1, which also shows the same problem.