EEPROM in Photon or Argon?


#1

Hi,
I couldn’t find any info about it. I need about 100 bytes of custom storage area, with reasonably low latency (<1ms full write of 100 bytes), that I can do more than 2 million write cycles. (i.e. every minute for 5 years).


#2

I’m not sure if the EEPROM meets your requirements, but is there a reason that you can’t just use the the backup RAM (with a coin cell on VBAT to keep the data in case of power loss)?


#3

The EEPROM feature isn’t actually an EEPROM, it’s emulated using two pages of flash memory on the STM32. Onboard flash is readable at full speed, code executes out of flash and is not copied to RAM, for example. Writing will be slower.

The wear calculations are a bit more complicated than they would seem. For example, writing to EEPROM location 0 a hundred times doesn’t involve 100 flash erase cycles. It is actually dependent on the size of the data.

The EEPROM size is 2047 bytes and there’s a roughly 2x overhead. And it’s stored in a 16K flash sector, so there’s about 12288 free bytes in the sector.

Say you’re writing 10 bytes of data to a given EEPROM location. Given the 2x overhead, that will use 20 bytes of flash. Thus the first 614 times you write the data, you won’t cause a flash erase because you keep using up the free space in the sector of flash.

In other words, for a 10 byte write, the wear is one erase-write cycle for every 614 times you put data to the EEPROM, not every time you write. And there are two flash sectors, so the wear on each sector is half that.

Flash sector erase is slow - about 800 milliseconds. You can take over control of this to schedule it at a time that’s not timing-critical. if desired.


#4

Yeah, emulated EEPROM could do a job, but I worry about reliability and slowdown. System is not time critical, but stopping for 0.8s once a day or so is not nice at all. It can be probably worked around in software, but it just makes it more complex.

I want to reduce number of parts. I would prefer not to need to use external battery or EEPROM or SRAM. The size and the cost is paramount in my application. I guess I might need to use external RTC with built in EEPROM or SRAM and small super cap I guess, if there is no better option.

I also spotted FRAM module on Adafruit pages, that looks super cool, fast and billions of cycles allowed, and retains content without power. And it is pretty large small in size and package, and big in memory size (32KB) - https://www.adafruit.com/product/1895 . That would allow me to store more data in memory log, if I loose wifi connection, server is down, or just want to contact server less frequently and upload data samples less frequently in batches (should be more efficient on a network, server and battery, by using less wifi, and allowing to sleep longer).

So the answer to my original question is “no”?


#5

The Adafruit FRAM seems ideal for your application. I’ve used it and it works well. There are libraries for the Particle platform already.


#6

Awesome. I spotted there is also 128KB in DIP package. I will take that! https://www.digikey.ch/products/en?keywords=865-1276-ND

There are even bigger capacities in small SMD formats. But for prototyping DIP is prefered :slight_smile:

PS. Actually forget about bigger capacities. They are in nasty packages, and very expensive, and require SPI.


#7

@baryluk, Fujitsu also has an I2C version of the 1Mb FRAM in a 8-SOP package.


#8

Is SPI a problem for Photon or Argon? Too fast? Too much power consumption? No dedicated SPI controller and bitbanging is problematic? Too many wires? Curious.


#9

@baryluk, SPI is fine on the Photon: and will be just fine on the Argon. My suggestion for an I2C FRAM was because of the statement you made


#10

Thanks everybody. I will use Adafruit FRAM board for prototyping. Or find some nice RTC with few KB of EEPROM or SRAM that is battery backed. I only need few hours or days of storage in case of power failure. Most RTC modules will hold SRAM content on battery for months from simple battery. Few days from a supercapacitor (actually self discharge of supercap is a limiting factor).


#11

I thought you said you wanted to minimize external components? The Photon already has an RTC and a few kilobytes of battery backed RAM, so why not use that as I originally suggested?


#12

What I get from your suggestion is that there is no RTC or memory on Photon, and I interpreted that I need to use battery to fully power and fully operating device to preserve even some small amount of data. If I would know there are special methods built in, I wouldn’t be asking my question in the first place. EEPROM without battery would be much better, but because RTC is going to be handy in my application (but not critical), having a small 3V coin battery is actually fine.

I guess all I was searching is this page: https://docs.particle.io/reference/firmware/photon/#backup-ram-sram- It couldn’t be easier! 4KB should be enough for me!

References: http://www.st.com/content/ccc/resource/technical/document/application_note/6e/ed/f1/f7/3e/3f/4c/5c/DM00026574.pdf/files/DM00026574.pdf/jcr:content/translations/en.DM00026574.pdf


#14

I can verify that the Adafruit FRAM works great. My application writes to it up to 15 times per second and it keeps up just fine. I’ve had units using it in service now for over 2 years and haven’t had one problem.