eeprom emulation use and best practices

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

I am using the AtsamC21 series of processors and possibly need to use eeprom emulation for storage of a few bits of info (no pun intended, lol) that only change a handful of times over the device's life.

 

I read app note AT03265 about using the Eeprom Emulator Service, but it appears to be part of ASF3, not ASF4 (Atmel Start).  I know ASF4 offers the Flash component, but other than the driver_example.c, I am not seeing any guidance on how to use it specifically as an eeprom - not to mention, the Eeprom Emulator Service has a much more straight forward and eeprom "like" implementation.

 

All that said, I have placed a 24FC01T eeprom on the board, but would love to not use it to both reduce component count and avoid chasing another component in these "supply chain issue" times.

 

To reiterate, all I am trying to store are a few flags in non-volatile memory for settings that rarely change - is it best to do it with the ASF4 Flash component, and if so, how so?  Or is there an Eeprom Emulator Service like component for ASF4 I am missing? Or is it best to use a dedicated eeprom IC?

 

TIA

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

atmegatron wrote:
I read app note AT03265 about using the Eeprom Emulator Service, but it appears to be part of ASF3, not ASF4 (Atmel Start).

Maybe create a basic ASF3 project using it, then merge that into your START stuff ... ?

 

(I know nothing about START).

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You might not need eeprom emulation (based on "settings that rarely change") and the SAMC21 has a separate RWW flash area, there is a start.atmel.com example "RWW Flash".
/Lars

 

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

The "RWW Flash" Atmel Start example is verbatim the example in the driver_examples.c when the Flash component is included in a Start project.

 

Is there an app note on using the Flash component and this example?  It doesn't make it clear if the NVMCTRL_EEPROM_SIZE fuse needs to be set, and if so, to what for the example.  It doesn't make clear the difference between _flash_write and _rww_flash_write - and rww_flash_write is not listed in the ASF4 API Reference Manual.  Also, while the BOOTPROT fuse keeps the bootloader NVM area safe from accidental overwrites during flash updates, what's to keep the bootloader code from accidentally overwriting the eeprom flash space other than being in the upper rows of the NVM address space?   

 

An app note and some clarifications would go a long way.

 

Regarding the data to be stored, I need to store a serial number (never changes) and a few config flags the customer will set once, which should be well inside the useful life of the flash.

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

You will have to read the datasheet I think, summary:

  • No fuse for the RWW area.
  • Separate address space for RWW (not in the upper rows of NVM).

 
About _rww_flash_write, looks like it just validates the address provided and calls _flash_write.

atmegatron wrote:
which should be well inside the useful life of the flash.

Yes, should be ok. Just don't erase the chip when programming (or debugging)

/Lars