EEPROM in SAM D20

Discussions around product based on ARM Cortex M0+ core.

Moderator: nferre

pozz
Posts: 67
Joined: Fri Jun 13, 2014 2:55 pm

EEPROM in SAM D20

Fri Jul 04, 2014 2:21 pm

I'm using EEPROM emulation available in ASF. I understood this support is completely software: user data is stored physically in the Flash memory, the same memory of the code.
If this is true, why are there fuses to set the size of Flash dedicated to EEPROM emulation? I can't get this point.

I'm using EEPROM to save in a non-volatile way some user configuration settings. I have a big (about 500 bytes) C struct with all parameters. At startup I read the struct and put in RAM where I make all the changes. When the user wants, the struct is written to the EEPROM (actually, Flash). So I never read or write a single byte or a part of my struct.
In this simple case, should I need the EEPROM emulator? Isn't simpler to directly save the struct in Flash as is, without the overhead of the emulator (that arranges the data in rows and pages)?

Writing to the EEPROM/Flash is dangerouse, because the operation could be interrupted for many reasons, first of all the power supply. It is very simple to leave with a corrupted data. How to prevent this dangerous situations?
I think the best is to save new data in a completely different part of Flash/EEPROM and write *atomically* just one byte that says which of the two sections is active.
Is it the only approach?
mkwired
Posts: 4
Joined: Tue Feb 25, 2014 11:39 pm

Re: EEPROM in SAM D20

Mon Jul 07, 2014 7:39 pm

To set the fuse, use the Device Programmer tool found under the Tools main menu item from within Atmel Studio.

I would not recommend trying to write to the FLASH area of the chip without using the ASF code without a good reason.  I would recommend reading at least pages 4 and 5 from the following app note.

http://www.atmel.com/Images/Atmel-42125 ... T03265.pdf
pozz
Posts: 67
Joined: Fri Jun 13, 2014 2:55 pm

Re: EEPROM in SAM D20

Mon Jul 07, 2014 8:21 pm

I would recommend reading at least pages 4 and 5 from the following app note.
From that app note I found:
Emulated EEPROM is exempt from the usual device NVM region lock bits, so that it may
be read from or written to at any point in the user application.
I think this is the only reason some EEPROM fuses exist: region lock bits aren't applicable to the EEPROM section. But I think Flash memory dedicated to EEPROM emulation isn't physically different from the rest of the Flash memory.
I would not recommend trying to write to the FLASH area of the chip without using the ASF code without a good reason.
Why? I think all the mess with EEPROM emulator derives from the fact the library should provide a byte-based interface, similar to the read/write access of a typical EEPROM.

In my application, as I described, I don't need a byte read/write access. I have a big struct (500 bytes) and I want to load that struct into RAM at reset and save it to the Flash when the user wants (typically when he changes some configuration setting that must be remembered after a power cycle).
In this scenario, I don't think I need all the EEPROM emulation service of ASF... what do you think?

Return to “SAM D20 Cortex-M0+ MCU”

Who is online

Users browsing this forum: No registered users and 2 guests