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/ _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
