Sun 04 Aug 2013 04:33:21 PM UTC, original submission:
There are several issues I have found with using avrdude's erase-rewrite cycle counter (-y) functionality with ATxmega parts. (I have only confirmed this with an ATxmega128A3U, but I strongly suspect the issue would be the same for other ATxmega models.)
The ATxmega parts appear to support both an atomic write operation and a "split" write operation for the EEPROM, where an erase occurs automatically only for the atomic write. The EEPROM byte writing operations issued by Avrdude for the cycle counter appear to trigger a split write operation on the device, meaning that an explicit byte erase must be performed beforehand. This is not done by Avrdude, as it only supports a page erase.
This behavior can be observed by doing a complete erase of the EEPROM, and then manually writing a value to the cycle counter address (-Y). Any value chosen will be written successfully. Any subsequent values written will only switch bits from 1 to 0. Here is an attempt to write 15 (0x0F) and then write 240 (0xF0):
The last row of data from a hex dump of the EEPROM after the first and second operations above is:
Note that the last 4 bytes should be 0x000000F0 after the second operation, and not 0x00000000.
In my local copy of avrdude, I have crudely hacked in a byte erase prior to a byte write for the EEPROM as a proof of concept, and confirmed that it works as expected for the AVR Dragon programmer.
The JTAGICE3 programmer has other issues on top of this. There is a buffer overrun (that I will submit in a separate ticket), and an attempt to hack in similar support yields bizarre behavior where after issuing a MTYPE_EEPROM (0x22) write command, an error comes back saying that the MTYPE_SPM (0xA0) write command failed. It's probably best if I don't submit my attempted fixes, to let the experts craft the correct solution for this reverse-engineered communication protocol.
|