Welcher ATXMEGA hat kein EEPROM Bug

Benutzt keiner einen ATXMEGA ^^

> Benutzt keiner einen ATXMEGA ^^

Denke ich nicht dran, schließlich benutze ich PICs.

Wenn du bei Atmel in die Erata schaust, werden nur der A3/D3 und 256A3B 
aufgeführt.
Verwende doch den A1. Bei mir auf dem XPLAIN Board ist der A1 drauf. Der 
scheint das Problem nicht zu haben

Welchen Bug meinst du?

Rev.E (aktuelle Revision)
EEPROM page buffer always written when NVM DATA0 is written

Rev.B
EEPROM page buffer always written when NVM DATA0 is written
Writing EEPROM or Flash while reading any of them will not work

Den Workaround für Rev.E Bug würde ich nicht als umständlich bezeichnen. 
Und den für Rev.B... der ist nicht gerade schön, aber kein Beinbruch.

Matthias Sch. schrieb:
> Der Bug betrifft auch aktuelle A3 - die Revision scheint dabei egal zu
> sein, zumal ich noch keinen Weg gefunden habe, diese im Chip zu lesen.

Enthält die Signature Row nicht diese Information?

Ich hatte mich mal vor 1 Jahr damit genauer beschäftigt. Ich hatte mit 
dem JTAGICE MKII und den AVR Studio das Register der Revision 
ausgelesen.

Im Degugmodus kann man ja in den µC alle Register aulesen und ich hatte 
die Revision B

Wenn ich richtig informiert bin, dann muss man bei der aktuellen 
Revision auch noch das Workaround druchführen.

Den µC in den Sleep setzen und nur 1 Interrupt aktivieren und die 
anderen deaktivieren halte ich schon für sehr viel mehr als einen 
kleinen Workaround, zumal ich auch nich in den Sleep Modus schalten 
möchte.


ich bin der Meinung das der A1 auch von diesem Problem betroffen ist, 
aber ich kann noch mals ins Errata schauen.

Ich verstehe leider nicht warum Atmel dieses Problem mit der Revision E 
nicht behoben hat. Zwischen Revision B und E gibt es so gut wie keine 
Verbesserungen.


Ich werde mir mal die neuen U Typen anschauen. Hoffentlich sind da die 
Bugs weniger geworden.

Beim A1 steht das im Datenblatt unter Errata

EEPROM page buffer always written when NVM DATA0 is written
If the EEPROM is memory mapped, writing to NVM DATA0 will corrupt data 
in the EEPROM page buffer.

Problem fix/Workaround
Before writing to NVM DATA0, for example when doing software CRC or 
flash page buffer write, check if EEPROM page buffer active loading flag 
(EELOAD) is set. Do not write NVM DATA0 when EELOAD is set

Ich weis nicht ob dies das gleich Problem ist wie bei den A3 Revision B

Wenn ich dort einen Wert in den EEPROM schreiben will hängt sich der µC 
auf

Revision G vom A1 macht es auch nicht gerade besser. Da muss ich extra 
den Clock von 32MHz auf 2MHz umstellen um in den EEPROM zu schreiben 
oder ich muss das Workaround mit dem Sleep Modus benutzen.

Also stimmt es nicht das der A1 keine Probleme mit EEPROM hat.

EEPROM erase and write does not work with all System Clock sources
When doing EEPROM erase or Write operations with other clock sources 
than the 2 MHz RCOSC, Flash will be read wrongly for one or two clock 
cycles at the end of the EEPROM operation.

Problem fix/Workaround
Alt 1: Use the internal 2 MHz RCOSC when doing erase or write operations 
on EEPROM.

Alt 2: Ensure to be in sleep mode while completing erase or write on 
EEPROM. After starting erase or write operations on EEPROM, other 
interrupts should be disabled and the device put to sleep.

Doch der Bug aus Rev. B für den es den Sleep Workaround gibt ("Writing 
EEPROM or Flash while reading any of them will not work"), der ist in 
Rev. E behoben.

Der Workaround für den Bug in Rev. B und E ("EEPROM page buffer always 
written when NVM DATA0 is written") ist wesentlich einfacher.

> Doch der Bug aus Rev. B
> Der Workaround für den Bug in Rev. B und E

Alles auf A3 aus deinem Erstposting bezogen.
Mit dem A1 bringst du weitere Spieler aufs Feld :)

Ich habe mal mal der ATXMEGA U Serie mit den USB Full Speed Serie 
geschaut. Dort wird ja nur über 1 Bug im Errata beschrieben.

Somit ist dies der µC mit den wenigsten Bugs auf der Welt ^^

Hat einer mit der U Serie bereits Erfahrung gemacht? Gibt es dort 
Nachteile gegenüber der A3 ohne U Serie?