bugAVR Downloader/UploaDEr - Bugs: bug #39690, Erase-rewrite cycle counter...


You are not allowed to post comments on this tracker with your current authentication level.

bug #39690: Erase-rewrite cycle counter non-functional for ATxmega parts

Submitted by:  David Glaze <djglaze>
Submitted on:  Sun 04 Aug 2013 04:33:21 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Postponed Privacy:  Public
Assigned to:  None Originator Name:  David Glaze
Open/Closed:  Open Release:  None
Programmer hardware:  Device type: 

Thu 05 Sep 2013 09:20:45 PM UTC, comment #2:

I think I got the single-byte EEPROM updates working now
(SVN r1208). Only tested for JTAG by now, hopefully will
also work on PDI.

Please give the SVN version a try if you can.

(I removed the erase cycle counter meanwhile, but single-byte
updates in terminal mode can be used to test this.)

Joerg Wunsch <joerg_wunsch>
Project Administrator
Tue 03 Sep 2013 12:05:45 PM UTC, comment #1:

Well, I asked about a couple of years ago whether anyone is
still using the erase cycle counter, and got zero responses.

I tend to remove that feature due to lack of usefulness.

I agree that EEPROM byte writes on Xmega are currently broken,
but I don't have the time to fix them right now. If you want
to work with me on this, please let's discuss that on the
avrdude-dev mailinglist.

I'll keep the bug report open as a reminder.

Joerg Wunsch <joerg_wunsch>
Project Administrator
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.

David Glaze <djglaze>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by djglaze (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-03 joerg_wunsch StatusNone => Postponed

    Back to the top

    Powered by Savane 3.4