EEProm write time

The short answer is yes. Amit has explained why.

That, I think, leaves you with two options.

The first is to design a hold-up supply for the longest write time. this involves not just a single write but presumably also the write of a checksum and maybe a mirrored copy as well. That's some security against corruption. This size of supply is likely to be expensive.

The second is to use a faster external non-volatile memory. My preference would be FRAM since its write times are in nS and it has a very high endurance. That means your hold-up supply can be much smaller. This can be put on the SPI bus and with 20MHz write speeds your write window becomes quite small. You could also use SPI based EEPROM, your write time would increase by 5 or 6 orders of magnitude and your write routines need to have waits added but it would still be orders of magnitude faster than the on-board memory.

Robert

If you feel like a doing lot of work you could use an IIC EEPROM/FRAM but it is slower.

I have changed idea, I use the flash instead the EEProm, the program time is 300 µsec maximum.

At the power up, I read the Flash and after I execute a mass erase  in this way, when I need to write the maximum time is 300 µsec.

Correct ?

According to my experiences, a maximum of 300us for Flash/EEPROM programming seems a little low. Most of the Flash I came across specifies several milliseconds. BTW, EEPROM is today just a kind of 'specialised' Flash, with single byte access and trimmed for higher durability (erase/write cycles). But otherwise they are usually the same.

Another point to note - Flash performance very much depends on temperature. Expect the maximum write cycle time for tempreratures near the specified limit. Also, wear increases the write cycle time, and chip operation at elevated temperatures also increases Flash wear. The good thing is - you can expect the guaranteed number of erase/write cycles even at maximum temperature. And if your devices are less temperature-stressed, Flash endurance is much higher - usually one order of magnitude for each 10 deg. less.

But foremost, I would evaluate the "worst"-use-case for your device, i.e. how often it can be turned on/off during your specified life time, and how many erase/write cycles would be required to guarantee it's function. I witnessed companies taking this too lightly, being punished subsequently by largely increased field returns. And as a side note, include caps (electrolytic capacitors) in this use-case evaluation. They are usually the sole energy storage for Flash writes after mains-off events, and significantly loose capacity when aging.

TI's approach to their EEPROM peripheral seems not so close to the hardware. I'm not quite sure what "Program time for 32 bits of data - space available" means as a last consequence, but surely this looks like the best case, with no previous erase of the cell required. Rather look at the "not so sunny" cases, which specify 30/60ms as average and 900/1800ms as maximum. I think your application must be able to deal with this times, too.

Perhaps some TI guy can explain what such cryptic phrases like "Program time for 32 bits of data - requires a copy to the copy buffer, copy buffer has space and less than 10% of EEPROM endurance used " really mean. To me, it looks like a Flash-based emulation, with lower bus priority than instruction fetch cycles (core access to Flash).

For a commercial device, I would abstain from using it for anything more than occasional changes. And that's not said to bash TI - other vendors provide similiar EEPROM quality ...

Still occasionally raising a hand to say that that it ain't necessarily so seems worthwhile even if not fruitful.

But it might put you on the hit list ...

f. m. said:

But it might put you on the hit list ...

And - one suspects - that would not be "first time" for we three...

"Proceed by Refinement" lives/thrives.   (somewhere - but not this "cost-down centric" thread)