ASF: SAMD20/SAMD21: EEPROM Emulation

The EEPROM emulation driver from the ASF provides pretty much all that is required to properly use the feature. Some of the lower level details like configuration are a little unclear from their documentation.

The emulated EEPROM is for the most part just normal flash memory that your application code is also stored in. The emulated EEPROM is addressed at the end chip’s flash memory where a FUSE byte defines “protected” regions of memory.

So as a quick breakdown of how things work, the SAMD20’s flash is organized as rows and each row consists of 4 pages of 64 bytes.

d20-eeprom-rows

The NVM (Non-volatile memory) operations allows single page reads and writes but erases destroy all four pages in a row. The EEPROM emulator druver Atmel provides deals with row erases and page reads/writes by juggling data for you in a safe manner and it’s the biggest reason to use their API. Application note AT03265 provides a more detailed description.

Chip Configuration

In order to actually use the EEPROM emulation, the SAMD20 must be configured for EEPROM correctly in its fuses. There is a fuse setting called NVMCTRL_EEPROM_SIZE which can be seen with a programmer device like shown below:

d20_fuses

The default value is 0x07 which equates to no eeprom section being configured. The datasheet provides the possible values for the setting in Table 20-3.

d20-eeprom-sizes-table

The logical step is to simply need to update NVMTRL_EEPROM_SIZE with a value from the table to allocate an EEPROM section.  HOWEVER due to how the ASF driver operates you must have a total of three rows MINIMUM. The reason for the minimum is because the driver needs to reserve a master and a spare row for itself and then it needs at least one row for actual data. Thus the smallest amount of rows allowable with the fuse is with setting 0x04.

Actual EEPROM Size

Atmel’s EEPROM emulator is not the most “space” efficient for storage available in the end. If there are four rows allocated with the fuse bit. Two are gone for the driver’s own usage. The last two rows have a total of 64 bytes * 4 pages total.

However, due to how the driver works. Only two of the four pages are actually usable for data. The driver keeps a backup copy of two pages in the same row.

Also, there is a four byte header at the top of every page. This header means that you only get 60 of the 64 bytes total.

So in the end from the two rows there are only four pages of storage. This provides 240 bytes of EEPROM.

Allocated # Rows Actual EEPROM Size(bytes) WITH ASF DRIVER
4 240
8 720
16 1680
32 3600
64 7440

 

Usage

The actual usage of the emulated eeprom service is just as easy as the application note describes.

The first snippet configures the EEPROM. If it fails to init the EEPROM and gets stuck in the while loop. You must likely did not properly perform the steps above to enable the fuse bits.
Otherwise it will hit the second trap when the EEPROM is “fresh” i.e. it has never been used before or it is corrupted. In either case it needs to be erased and setup for use.

void configure_eeprom(void)
{
	/* Setup EEPROM emulator service */
	enum status_code error_code = eeprom_emulator_init();
	if (error_code == STATUS_ERR_NO_MEMORY) {
		while (true) {
			/* No EEPROM section has been set in the device's fuses */
		}
	}
	else if (error_code != STATUS_OK) {
		/* Erase the emulated EEPROM memory (assume it is unformatted or
		 * irrecoverably corrupt) */
		eeprom_emulator_erase_memory();
		eeprom_emulator_init();
	}
}

Reading data is as simple as:

	uint8_t page_data[EEPROM_PAGE_SIZE];
	eeprom_emulator_read_page(0, page_data);

Data is read from page 0 into the page_data buffer on demand.

Writing back data is also simple:

	eeprom_emulator_write_page(0, page_data);
	eeprom_emulator_commit_page_buffer();

That writes back the buffered data to page 0.

  • Govi

    Nicely explained. Thanks!

  • aricbeaver

    Thank you for this explanation. The ASF examples are usually not very technically detailed. In the SAMC21 EEPROM emulation example they say to set the NVMCTRL_EEPROM_SIZE fuse = 0x05 but the results in a BAD_FORMAT error code when using eeprom_emulator_init().

    • mroszko

      That’s completely normal for the first time after reprogramming. eeprom_emulator_init attempts to simply configure the NVM and then verify the eeprom is setup.
      BAD_FORMAT is returned when it cannot verify the memory is setup.
      This is expected because the EEPROM memory is flash memory and programming will erase it.

      eeprom_emulator_erase_memory() not only erases the EEPROM section but also sets it up anew.

      I should probably elaborate that better in the post :3

  • MJ

    Is there a way to prevent flash programming from erasing this portion of the NVM where the EEPROM emulaiton is set? Makes it hard to debug when I am expecting the EEPROM data to persist as I fix other issues in the code.

    • MJ

      I found the setting in Atmel Studio. In the Project Tab under Tools->Programming Settings use “Erase only program area” instead of “Erase entire chip”. This will protect the EEPROM area from erasure.

  • Iván

    Hello. I have read the SAM21 datasheet and the application note related to the EEPROM emulation, but functions such as eeprom_emulator_erase_memory are the same code that the one used to write using NVMC to write in normal FLASH??? I don’t know yet if I have to write normally as if a normal write to FLASH and the emulation drivers does its job or if I have to implement a EEPROM emulation scheme manually coded by myself. Once I program the FUSEs I don’t notice any difference. Any help will be really appreciated. As I am seeing it is needed to use totally different functionality for EEPROM and FLASH if emulation is pretended, so if everything is SW I don’t understand the use of the FUSEs. Best regards. Iván