MCF52259 flash write cycles

[njk909]

I have an external flash device (4Gb NAND) that I want to use as a giant circular buffer to store/record sensor data over time.  I want to store the location/pointer to where I'm at in that buffer onto the onboard MCF52259 flash so that when I power cycle the device I can read the location and resume writing to my external NAND where I left off so I don't overwrite any data.

I'll be recording new data and updating my memory pointer every 100ms, so at that rate, I would burn out the 100,000 write cycles in the onboard flash pretty quickly if I kept writing my memory pointer to the same static location in the MCF52259 flash.

Would the best way to handle it be to spread the counter over an entire block?  i.e., count up to, say, 1000 at each word location, and then move to the next word in flash?  Then at program start I could just read the onboard flash and look for where the first non-1000 value is (call this location_index) and resume writing my counter at that location_index?  Then the data would be written to the external flash at (1000*location_index)+counter_val_at_location

[Monica]

Nathan, were this answers helpful?

Please let us know!

Regards!

[TomE]

That's good advice from Stan. But since what you want is:

> use as a giant circular buffer to store/record sensor data over time.

Just as you can search through a FLASH sector to find the highest index number, you can search through the FLASH "circular buffer" to find the end of it. Store your "chunks"of sampled data in a structure with a header on it that has 32-bit incrementing "sample count". Make sure the "next" FLASH block is always erased (meaning you need to erase a new one when the previous one within a maximum erase-time of being full). Then on power up you just have to search the sectors for the last one that has a valid header and the highest sample in the first chunk in the block, then search through the chunks in that block to find the highest "sample count". The only thing to be careful of is that you may get powered down half way through a FLASH block erase, and it might not be erased properly. You can track this by having a bit in your sample chunk header which flags (in successive samples) "about to start erasing next flash block" and in the opposite state "next block erase not started or completed". So if it is in the "started" state in the newest sample you have to re-erase the next sector before you can store to it.

You'll need a large sample buffer in RAM as you can't store any data to the FLASH while you're erasing a block, as an erase takes a relatively long time. The chip we use has a sector erase type of 0.5 seconds "typical" and 3.5 seconds "max". You can't read the FLASH to run code from it or access any other data either.

Tom

[scifi]

No, you can't just count to 1000 in each flash word location. You are only allowed to write once into each word. Before you can write more into the same word, you must erase the whole sector. Each sector is 4096 bytes in size, IIRC. That means 1024 writes per sector before you have to erase it. So one sector will allow you to increase endurance by a factor of 1000. If you want to be resistant to power supply failures during sector erase, you have to use at least two sectors and switch from one to another once one of them fills up. So basically you can write consecutive values of the pointer into consecutive locations in flash. You also have to maintain a little metadata to distinguish between the active sector and the inactive sector. Well, this is the basic concept of EEPROM emulation. Search google for appnotes on the subject.

The interesting thing is that you don't have to store the pointer in on-chip flash. You can design the data storage format on NAND flash in such a way that the pointer value is easily extracted from the stored data. Then it should be easy to come up with an algorithm that would do it at power-up in reasonable time (something like binary search). It wouldn't be much more complicated than the EEPROM emulation described above.