[avrdude-dev] [bug #42267] jtag3isp fails to read lock and fuse bytes directly after changing lock byte

[Matthijs Kooijman]

Follow-up Comment #7, bug #42267 (project avrdude):

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


    _______________________________________________________

Reply to this item at:

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

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