The most common-as-muck SPI EEPROM, few hundred bytes or more - Page 1
Forum section: electronics / projects

author: peter-h
author_rank: Super Contributor
timestamp: January 21, 2021, 11:40:13 am
content: For many years I have been using the 93c46 chips, and bit-banged the interface. They are cheap - down to 10p or so.Now I am working on an ARM 32F417 project and want something for SPI.It is difficult to work out what are the "common" chips these days. Many years ago you could phone up a disti and ask them, but now they don't have anybody who knows what a resistor is. They work wholly in the world of part numbers, only...This project has a AT25PE16 2MB flash chip but that's used to implement a FAT file system, but I want something writeable one byte at a time. Also I want NV storage for versions which won't have this flash chip. And I don't want to always have a battery/supercap so the 32F NV storage (the "backup domain") is no good either.

author: iMo
author_rank: Super Contributor
timestamp: January 21, 2021, 12:25:00 pm
content: FRAMMRAMNonvolatile, practically unlimited endurance, the same pinout and SPI protocol as the flash mems. Single byte accessible. Fast as SRAM.

author: Yansi
author_rank: Super Contributor
timestamp: January 21, 2021, 12:55:58 pm
content: You have enough FLASH memory in the MCU already, so what are you looking for?

author: peter-h
author_rank: Super Contributor
timestamp: January 21, 2021, 03:08:03 pm
content: Can this be written one block (say 4k) at a time, while the code is running?Normally you cannot write any part of own flash while running code out of it. I think the 32F may offer two ways around this- if you have the 2MB version, you can run code from one half of it while programming the other half- if you try to program the same (the currently executing, or the only) 1MB block, it doesn't actually crash the CPU but you get a few million wait states generatedwhich will mess up a lot of running codeRe FRAM / MRAM, can anyone suggest really popular parts?

author: iMo
author_rank: Super Contributor
timestamp: January 21, 2021, 03:16:50 pm
content: For exampleFRAMs..

author: peter-h
author_rank: Super Contributor
timestamp: January 21, 2021, 03:25:49 pm
content: I looked up a few. They are either pricey or not stocked (Mouser.com) or both. For example CY15E016Q-SXA is about 10x the price of an old-style serial EEPROM.

author: wraper
author_rank: Unknown
timestamp: January 21, 2021, 03:42:25 pm
content: If you want it cheap, you will need to use I2C. While small capacity SPI EEPROMs do exist, they are neither that common, nor nearly as cheap.https://octopart.com/search?q=25LC010&currency=USD&specs=0

author: peter-h
author_rank: Super Contributor
timestamp: January 21, 2021, 04:05:01 pm
content: The 25LC010A-E/SN (128 bytes) is fine at 30pUnfortunately the I2C lines have got used up for other stuffI would still really like to hear of any way to store stuff in say a 4k block in the CPU, while code is running normally.Actually one can get a fair idea with say mouser.com by looking at their stock levels.Some are cheap eg.CAT25020YI-GT3M95040-RDW6TPat ~15p.This is the cheapest: CAT25010VI-GT3Also I wonder if there is a ~128 byte device which can be written all 128 in one SPI operation. Most can do 16 bytes, but doing all 128 would be nice, especially with a 20MHz SPI clock. It means one can store the stuff at power-down, when power fail is detected.

author: Alex Eisenhut
author_rank: Super Contributor
timestamp: January 21, 2021, 04:20:44 pm
content: Quote from: peter-h on January 21, 2021, 04:05:01 pmI'm just drive-by commenting here, but how is that a problem? I2C uses device addresses.

author: langwadt
author_rank: Super Contributor
timestamp: January 21, 2021, 04:26:08 pm
content: Quote from: peter-h on January 21, 2021, 04:05:01 pmwhat's wrong with bitbanging I2C ?first hit on google for a spi eeprom is:https://www.digikey.dk/product-detail/en/stmicro/M95128-RMN6P/497-8606-5-ND/1664180~$0.30 and a 64byte page write in one operation

author: ejeffrey
author_rank: Super Contributor
timestamp: January 21, 2021, 06:22:11 pm
content: Quote from: peter-h on January 21, 2021, 03:08:03 pmThe standard way to deal with this is to put your interrupt handlers in SRAM. It's not completely general, sometimes you simply can't operate entirely from SRAM for the time it takes to handle a flash erase/program cycle, but if it works it's hard to beat the price.Erase cycles take a lot longer than program cycles so if you can arrange to always have some erased flash ready to go (say if you have periodic idle times) then the effect on latency doesn't have to be nearly as bad.

author: jmelson
author_rank: Super Contributor
timestamp: January 21, 2021, 10:27:15 pm
content: I use the SST 25VF010A to download FPGAs, that is a 1 megabit SPI serial EEPROM. They must have smaller devices that would be a bit cheaper, too.Jon

author: Kjelt
author_rank: Super Contributor
timestamp: January 21, 2021, 10:43:47 pm
content: ST M95020-WMN6TP 0,15 for 256 bytes orM95640 8kb eeprom spi about 0,20 each less if you order a reelAt tme.eu

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 22, 2021, 03:09:08 am
content: I just bought some 64k SPI EEPROMs from microchip. Part number 25LC512-E/P at about $1.50/ea. I'm using them for permanent data storage where each byte is only written to once and only 4 bytes per day.

author: Berni
author_rank: Super Contributor
timestamp: January 22, 2021, 06:52:41 am
content: If you need to write often and fast then FRAM is the way to go.As for finding what is a common part, the easiest way is to go to a big distributor like DigiKey and sort by stock. They won't keep a stock of like 100k chips without knowing from past experience that the parts sell like hot cakes. An extra check is also putting the partnumber into OctoPart to see if lots of other distributors also carry stock in the thousands.But when it comes to paged flash memory you don't need to always rewrite the whole page. You ONLY need to erase whole pages, but the writing can be done byte by byte (flipping bits from 1 to 0). Its also the erase operations that degrade the cycle life of flash. So if you only need to store 4 bytes in the 4KB page you can just start at 0, then for the next write clear the bytes 0 1 2 3 with 0x00 and write the new value at offset 4 5 6 7.. etc and keep doing that until you get to the end of the 4KB page. At that point you erase the page to set all of it back to 0xFF and start from the beginning again. This way you get fast writing (its the erase that is slow) and have extended the flash endurance by 1024 times so even a shitty 10 000 cycle flash can then take 10 000 000 cycles. And best of all this flash is free since you are probably not using 100% of the flash for the code.

author: Kjelt
author_rank: Super Contributor
timestamp: January 22, 2021, 07:03:11 am
content: Quote from: Berni on January 22, 2021, 06:52:41 amHe first has to do the math, often is too vague.How many bytes over lifetime will he write and will a device erase the entire page or just those bytes, that results in nr of erase cycles.Then choose a matching component.Even the cheap spi eeproms mentioned above have a 100 year data retention with a whopping 4 million Write cycles at 25 °C and with a €0,20 price tag dirt cheap compared to fram.

author: peter-h
author_rank: Super Contributor
timestamp: January 22, 2021, 10:17:51 am
content: Yes indeed these are very good points. The AT25PE16 2MB flash we have is rated for 100k cycles which is fine for storing anything human-generated (files, button push data, etc) but would not be much good for storing something say every second.One sees this issue with putting an SSD in a winXP machine. It lasts about 1 year (24/7) before it bombs with NTLDR cannot be foundSeen this across a number of PCs. Years ago I spent a lot of time on this and found XP writes to the registry every second. Presumably laptop versions of XP, with SSDs (and some did exist) had an OEM mod done. But laptops are ok anyway because they (usually) get used sporadically. I thought SSDs contain a controller which remaps blocks as each one reaches the max count, but evidently not - at least not without some OS co-operation (the TRIM command or some such).And same issue for the on-CPU flash.So there is a good use scenario for little serial eeproms.

author: voltsandjolts
author_rank: Unknown
timestamp: January 22, 2021, 10:24:51 am
content: Quote from: peter-h on January 22, 2021, 10:17:51 amWriting to the same address(es) every second, your eeprom would be scrap in a couple of months.The problem doesn't go away, you just kicked it down the road, and not far enough.

author: Berni
author_rank: Super Contributor
timestamp: January 22, 2021, 11:00:41 am
content: Quote from: peter-h on January 22, 2021, 10:17:51 amEEPROM has similar issues as flash and needs the writes to be moved around with a similar trick to avoid wearing out a single tiny area by repetitive writes. But if you take the example of moving a 4 byte write across a 4KB page to get 1024 times more endurance, doing that to a 100k write cycle flash gets you 100M cycles. This is about 3 years of continuous writing every 1 second. Dedicate 64KB of flash to it and you get 1.6G cycles and you get 50 years. Quite inefficient at that point but hey if you have leftover flash in the MCU then its free, so still cheaper than any chip on the market.And if you really need to write to memory like once every 1ms then buying a FRAM chip for about 1 USD is not that big of a deal. Alternative is a large value capacitor that can keep the CPU running to write to memory only at power loss, cost of the extra parts to do that is probably similar.

author: Kjelt
author_rank: Super Contributor
timestamp: January 22, 2021, 03:00:00 pm
content: And you have to consider the use case.Writing data every second than probably the relative value of that data is not very high.What is probably more important is that the written data is not corrupt (checksum or other integrity checks).In those use cases it can be more proficient to store a certain amount of data in RAM only to write it to external memory when that buffer is full.But these things have to be worked out on each usecase.In a previous company I worked for the data was stored in ram in a circular buffer of 5kB and each time there was a full flash page worth of new data (2kB in that example) it was written to external flash, read back and verifiedn only then the bookkeeping of the flash filesystem was updated and the data erased from the circular buffer.Worst case scenario the last 2kB of data was lost and that was found acceptable by the product owner and clients at that time since this would only occur during a brown out and in that case there was a higher potential of a corrupt external memory.