Using XMega EEPROM with GCC

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone with experience in the subject?

I am experiencing several problems when using functions available in header.

I know there is an issue with XMega A3/D3 EEPROM, but I am not using the hardware revision affected by these problems.

So if someone was able to use eeprom_write_block and eeprom_read_block with no problems, please let me know to point me in the right direction
:?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out the eeprom tutorial in that forum and maybe it can be adapted for an xmega.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought latest AVR-LibC has eeprom support for X? That is:

D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\avr\i
nclude\avr>grep ATxmega eeprom.h
#elif defined (__AVR_ATxmega16A4__)
#elif defined (__AVR_ATxmega16D4__)
#elif defined (__AVR_ATxmega32A4__)
#elif defined (__AVR_ATxmega32D4__)
#elif defined (__AVR_ATxmega32X1__)
#elif defined (__AVR_ATxmega64A1__)
#elif defined (__AVR_ATxmega64A1U__)
#elif defined (__AVR_ATxmega64A3__)
#elif defined (__AVR_ATxmega64D3__)
#elif defined (__AVR_ATxmega128A1__)
#elif defined (__AVR_ATxmega128A1U__)
#elif defined (__AVR_ATxmega128A3__)
#elif defined (__AVR_ATxmega128B1__)
#elif defined (__AVR_ATxmega128D3__)
#elif defined (__AVR_ATxmega192A3__)
#elif defined (__AVR_ATxmega192D3__)
#elif defined (__AVR_ATxmega256A3__)
#elif defined (__AVR_ATxmega256A3B__)
#elif defined (__AVR_ATxmega256A3BU__)
#elif defined (__AVR_ATxmega256D3__)

Maybe you need to upgrade your toolchain? The above is from the AVR-LibC that forms part of Atmel Studio 5 (aka "AVR Toolchain")

But tell us more about what doesn't work. Maybe show the shortest simple test program that illustrates the issue you have?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Coincidentally, I was having a trouble today reading from the first location of the EEPROM, the eeprom read function was returning a wrong value. The strange thing was that the debugger did show the correct value.
I tried with another microcontroller and it seems ok.

Although, I don't think I had written to that location that many times for it to stop working...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
at the end I discovered my problem. Despite my initial guess, I am indeed using a buggy hardware, the infamous "release B". So I have to use the method described in note AVR1008, putting the MPU to sleep before writing EEPROM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update. It seems I was right this time. By using NVM commands instead than mapped EEPROM, I was able to read and write EEPROM with no problems.
XMega could be a GREAT processor, too bad for so many hardware bugs... :-(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kalbun wrote:
Update. It seems I was right this time. By using NVM commands instead than mapped EEPROM, I was able to read and write EEPROM with no problems.
XMega could be a GREAT processor, too bad for so many hardware bugs... :-(

I have written code for both EEPROM_read and write..Writing it works..but when it comes in reading, it always returning the last written data..

Can you give me you those functions..

Thanks in advance!!!!!!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the same problem:

Quote:
I have written code for both EEPROM_read and write..Writing it works..but when it comes in reading, it always returning the last written data..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

XMega could be a GREAT processor, too bad for so many hardware bugs...

The new "U" suffix models have a very short errata list. I assume that means that using EEPROM is again viable.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.