Tracking address when writing to flash

0
votes

My system needs to store data in an EEPROM flash. Strings of bytes will be written to the EEPROM one at a time, not continuously at once. The length of strings may vary. I want the strings to be saved in order without wasting any space by continuing from the last write address. For example, if the first string of bytes was written at address 0x00~0x08, then I want the second string of bytes to be written starting at address 0x09.

How can it be achieved? I found that some EEPROM's write command does not require the address to be specified and just continues from lastly written point. But EEPROM I am using does not support that. (I am using Spansion's S25FL1-K). I thought about allocating part of memory to track the address and storing the address every time I write, but that might wear out flash faster. What is widely used method to handle such case?

Thanks.

EDIT: What I am asking is how to track/save the address in a non-volatile way so that when next write happens, I know what address to start.

1
memoryembeddedflash-memoryeeprom
did you read the datasheet? the commands start with an address then you can have one to 256 bytes. So you know what address you started with you know how long the string is so you know where you are in the page when you start another command you know what address to use. Not sure what your question is. You have to pre-check the string lengths anyway to make sure you dont exceed any limits be it the limit for the part/page or the spi controller you are using may have a limit on how many bytes per command you can send, etc. So you always know the start address and length. – old_timer
That device you named is not an EEPROM. Its a serial NOR flash. – Brian McFarland
@dwelch The data is not being written right after another. The system collects data through bluetooth and it writes to flash whenever it is free and confirms the data it collected is safe to be written. That can be a while after the previous write. Like you said, yes I know where I am at the page at that moment when write happens. what I am asking is how to remember that address so that I can use it as a starting address when next write happens. I am not if this my explanation is clear enough.. – Megool
@BrianMcFarland what are the differences between the two? Is serial NOR flash different than EEPROM when it comes to implementation in C? – Megool
Write some sort of end-of-file token after the string. When the next string is written, erase the token and rewrite it after the new string. After reset, during bootup, read the buffer from the beginning until you find the token to determine where to continue writing. If the strings are ASCII then use the EOF character for the token. If the data is binary then devise some sort of escape sequence to identify the end-of-file token. – kkrambo

1 Answers

0
votes

I never worked with this particular flash, but I've implemented something similar. Unfortunately, without knowing your constrains / priorities (memory or CPU efficient, how often write happens etc.) it is impossible to give a definite answer. Here are some techniques that you may want to consider. I don't know if they are widely used though.

Option 1: Write X bytes containing string length before the string. Then on initialization you could parse your flash: read the length n, jump n bytes forward; read the next byte. If it's empty (all ones for your flash according to the datasheet) then you got your first empty bit. Otherwise you've just read the length of the next string, so do the same over again.

  • This method allows you to quickly search for the last used sector, since the first byte of the used sector is guaranteed to have a value. The flip side here is overhead of extra n bytes (depending on the max string length) each time you write a string, and having to parse it to get the value (although this can only be done once on boot).

Option 2: Instead of prepending the size, append the unique "end-of-string" sequence, and then parse on boot for the last sequence before ones that represent empty flash.

  • Disadvantage here is longer parse, but you possibly could get away with just 1 byte-long overhead for each string.

Option 3 would be just what you already thought of: allocating a separate sector that would contain the value you need. To reduce flash wear you could also write these values back-to-back and search for the last one each time you boot. Also, you might consider the expected lifetime of the device that you program versus 100,000 erases that your flash can sustain (again according to the datasheet) - is wearing even a problem? That of course depends on how often data will be saved.

Hope that helps.