Monthly Archives: June 2014

ASF: SAMD20/SAMD21 External interrupts in standby and the side effect of debugging

The EIC driver in the ASF for the SAMD20 defaults to using GCLK_GENERATOR_0. Unforunately I overlooked this little configuration when I was trying to use EIC in standby. So when I debugged, I could get external interrupts in standby, if I didn’t debug, my interrupts would not fire at all (while my RTC was fine). Fixing this was simple.


The root cause of the problem is in standby, all clocks are turned off and only the GCLKs are that are configured to remain on still run. The debugger appears to not allow clocks to turn off while debugging and thus peripherals will work even with clock configuration issues. However without the debugger it will fail.

Also, the EIC needs a running clock in standby if you want edge detection based interrupts to occur or if set to logic level interrupt with filtering. Purely logic level interrupts do not require a clock.


So my solution was because I was running GCLK2 in standby for the RTC, I configured the EIC to use it. This brings two benefits

1. My signals are not time critical, the 32khz clock has no effect on my application’s performance

2. Less power consumption from slower clocking and less gclks

Power saving in my application was critical so every microamp I saved is great.

So the simplest place to “fix” the configuration is to go into conf/conf_extint.c and change the GCLK define to GCLK_GENERATOR_1 in case of using the RTC.

Otherwise you can either

  1. Enable the GCLK_GENERATOR_0 to run in standby
  2. Configure another GCLK that will run in standby by editing conf_clocks.h. You can consider running it from the 32khz clock if you don’t have response time requirements.

And tada, you get external interrupts in standby outside of debug.

Additional Note

In conf_clocks.h

Check to make sure your 8mhz clock or 32khz clock that you are using to run your gclk is also enabled to run in standby or else the gclk won’t run.

also make sure your OSC32K is enabled in the first place(that’s not default)
# define CONF_CLOCK_OSC32K_ENABLE true


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.


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:


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.


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



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) */

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);

That writes back the buffered data to page 0.