I have just gotten memory-mapped EEPROM access working with an ATxmega256A3, and I'm looking for suggestions & consensus on the "right" way to support this.
Memory-mapped access for the EEPROM is great -- it's certainly convenient, and it's very cool to be able pass pointers in EEPROM to runtime like memcpy() or printf(). The only trick is in getting the starting offset of MAPPED_EEPROM_START (0x1000) right.
Using a macro to add the offset at each reference not only blows the convenience, but you lose type info. You must either cast or have macros for each type.
So instead EEPROM variables need to have the start offset built in. I tried doing this by modifying the linker script for the base of the .eeprom section:
eeprom (rw!x) : ORIGIN = 0x801000, LENGTH = 4K
This does work to get variable offsets correct. However, the AVR Studio debugger will not recognize this section as EEPROM data and so will not initialize the EEPROM. (The .eep file is correctly generated so in programming mode you can initialize the EEPROM.)
To work around this I created a struct for all my EEPROM data. I put one variable of this type in the .eeprom section (at its usual 0x810000 address) and initialized it. I created another section called .map_eeprom at 0x801000 and put another variable of the EEPROM struct there. It is this second variable I then reference throughout the program to access the EEPROM.
Is there a smoother solution to this? Should (would?) Atmel change the debugger so it can recognize EEPROM data by section name instead of a fixed address of 0x810000?