how to get an EEPROM like functionality ?

Official Hardware Classic Zero
1

I love working with the EEPROM on Atmega's.
I use it for "machine"- and or user-settings, that have to remain when power off,
and that have to remain when uploading a new firmware (flashing) the MCU.

since the Zero has no EEPROM one can use the flash as a kind of EEPROM.
BUT:
the flash memory (and so the "emulated" EEPROM) is erased when Arduino uploads a new sketch,
right ?

is there any method to overcome this disadvantage,
so that the "EEPROM"-content survives the uploading of a new firmware ?

for example a (automated) procedure like:
download present "EEPROM"-content (special section in flash memory ?) from the MCU,
and merge it with the new flash-content (new firmware),
BEFORE uploading the new flash-content,
or something like that ? :wink:

In the Atmel ASF Framework there is described a
"SAM D20/D21 EEPROM Emulator Service "
see this document:
--> http://www.atmel.com/Images/Atmel-42258-ASF-Manual-SAM-D21_AP-Note_AT07627.pdf
on page 118 and further
But unfortunately to be honest I don't understand exactly what's described there...
From my understanding it's a way to preserve the "EEPROM" Data in the most upper-Section of the Flash and then to use a special FUSE-bit to prevent overwriting it (?)
(see attached screenshot - an exerpt from the pdf mentioned above)

further documents:
--> http://www.atmel.com/images/atmel-42125-sam-d20-eeprom-emulator-service-eeprom_application-note_at03265.pdf
--> http://asf.atmel.com/docs/3.17.0/samd21/html/group__asfdoc__sam0__nvm__group.html
--> http://asf.atmel.com/docs/3.17.0/samd21/html/asfdoc_sam0_nvm_exqsg.html
--> http://asf.atmel.com/docs/3.17.0/samd21/html/asfdoc_sam0_nvm_basic_use_case.html
--> http://www.atmel.com/images/atmel-42114-sam-d20-d21-non-volatile-memory-driver-nvm_application-note_at03247.pdf

EEPROM-Section.png
EEPROM-Section.png480×540 2.65 KB

2

Dirk67:
the flash memory (and so the "emulated" EEPROM) is erased when Arduino uploads a new sketch,
right ?

right.

Dirk67:
is there any method to overcome this disadvantage,
so that the "EEPROM"-content survives the uploading of a new firmware ?

I didn't tried this yet: when you upload using the programming port OpenOCD should be smart enough to erase only the piece of Flash that is being programmed (well actually there is a bug in the upstream OpenOCD so a bit more than needed is erased but this is not important now), so if you store your data far enough in the flash space it should survive the upload. I repeat, I didn't tried this yet...

The same cannot be accomplished by programming on the native port with bossac for now, because bossac erases the whole flash regardless.

Dirk67:
for example a (automated) procedure like:
download present "EEPROM"-content (special section in flash memory ?) from the MCU,
and merge it with the new flash-content (new firmware),
BEFORE uploading the new flash-content,
or something like that ? :wink:

Well this may work indeed, a lot more complex to implement :slight_smile:

Dirk67:
In the Atmel ASF Framework there is described a
"SAM D20/D21 EEPROM Emulator Service "
see this document:
--> http://www.atmel.com/Images/Atmel-42258-ASF-Manual-SAM-D21_AP-Note_AT07627.pdf
on page 118 and further
But unfortunately to be honest I don't understand exactly what's described there...
From my understanding it's a way to preserve the "EEPROM" Data in the most upper-Section of the Flash and then to use a special FUSE-bit to prevent overwriting it (?)
(see attached screenshot - an exerpt from the pdf mentioned above)

this could work too, basically the samd21 allows you to set the last piece of Flash as an EEPROM RWW (Read-While-Write) emulation area, quoting the datasheet:

21.6.5.3 NVM Write
The NVM Controller requires that an erase must be done before programming. The entire NVM main address space and
the RWWEE address space can be erased by a debugger Chip Erase command. Alternatively, rows can be individually
erased by the Erase Row command or the RWWEE Erase row command to erase respectively the NVM main address
space and the RWWEE address space.

so it seems that the eeprom RWW area is protected from normal "Erase Row" command. OpenOCD is able to change this setting: Flash Commands (OpenOCD User’s Guide) (search for "at91samd eeprom").

3

hmmmm .....
so I think Arduino will not implement this in future, right ? :wink:

maybe it's easiest way to use a small cheap ($0,20) external I²C-EEProm* (within my application),
and then being independent of what bootloader ("methods of flashing") is used and so on...

*(e.g. http://www.atmel.com/products/Memories/serial/i2c.aspx)

4

Well, I'm working on a library to ease the use of flash memory on the Zero, here is the source code if you want to experiment with.

Disclaimers:

  1. this library do not implement an EEPROM-like API because it requires more work to handle writes in a way that don't "wear out" the flash;
  2. this API is experimental and may change without notice;
  3. at some point a completely different EEPROM library may arise based on Application Note by Atmel
  4. it's barely tested :stuck_out_tongue:
5

yes,
thanks again @cmaglie
the linked Application Note by Atmel is very interesting indeed...

again there is written something of fuse-settings in 8.1.1 on page 19

8.1.1 Prerequisites
The device's fuses must be configured to reserve a sufficient number of FLASH memory rows for use by the
EEPROM emulator service, before the service can be used. That is: NVMCTRL_FUSES_EEPROM_SIZE has to be
set to less than 0x5 in the fuse setting, then there will be more than 8 pages size for EEPROM. Atmel Studio can
be used to set this fuse(Tools->Device Programming).

I wonder, if this fuse settings prevent any Bootloader / or programming device/procedure
from writing to that section (?)

6

Dirk67:
wonder, if this fuse settings prevent any Bootloader / or programming device/procedure from writing to that section (?)

Yes, it should.

Quoting myself:

it seems that the eeprom RWW area is protected from normal "Erase Row" command. OpenOCD is able to change this setting: Flash Commands (OpenOCD User’s Guide) (search for "at91samd eeprom").

7

@cmaglie: Thanks for writing the library. The example apps you wrote worked well on my Zero.

While I appreciate the effort you put into the library, it appears as though your library may be all that exists for the Zero for some time to come. With that in mind, it would be helpful if you could improve the documentation on it. It would be nice if there was a README in which you did a brain dump so that myself and others could get a better understanding of what your library does, and how best to use it.

I read the Atmel application note (which was useful) but struggled to see the link to your library.

In particular, I have the following questions:

  1. How much flash storage is available on the Zero (min & max)
  2. Are the default fuse settings protecting any part of the emulated EEPROM?
  3. How does one change fuse settings to protect EEPROM? (file name/location and changes to make)
  4. Optimization strategies. Data in multiples of 60 bytes look optimal - agree?
  5. An additional example app would be useful, one showing min/max EEPROM size and variable values like page size, row size, EEPROM used/free etc.

I know I'm asking a lot, but in my defense I also write Arduino libraries:

Regards,

Peter

8

My reading of the manual (http://www.atmel.com/Images/Atmel-42181-SAM-D21_Datasheet.pdf, pg 43) is that the ATSAMD21G18 doesn't have any emulated (RWW) EEPROM, it just has 256k of flash? Am I right?

Also, @cmaglie - what address does your code write at - it isn't that clear to me?