Organizing data in flash

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys !

I need help regarding organizing data in flash. I use Atmel AT45DB081D serial flash.

Here is datasheet, on page 4 you have Memory Architecture Diagram.
http://www.atmel.com/Images/doc3...

I plan use this flash to store data in wireless applications. For start need to store following data: DI changes, AI values, RTC interrupts, Watch-dog resets and perhaps other.

One information should be 16 bytes long and it looks like this:
0-7 bytes - inf. of what happened (DI changed, RTC interrupt...)
8-15 bytes - [8-14] time when something happened
[15] inf. if this message was sent (colledted) wirelessly to data sink

Now, the question is how to organize this data in flash.

My first idea is to store similar events in particular sectors e.g. all DI schanges in sector 1, RTC interrupts in sector 2.
I don't know what if sector 1 is full of unsent data, what then?
Should I remember the last page number (in another sector) in which I stored data for every event that happened?

As I said, my messages are 16 bytes long (I hope that's enough for the future) I have last 8 bytes free (unused) per page. One of these 8 bytes is for checksum and other 7 are free.

I also have to implement mechanism to delete data that has been sent.

I should reach unsent data as quick as possible not to spend too much time reading one page after another.

You see that I have a lot of questions/problems and I hope form above text you understand my problem.

First of all, will this falsh satisfy my needs or do I have to look for something else?

Any advice, recommendation or link is very appreciated !

Thanks !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First thought: why 8 bytes for the time? If you use "unixtime" (http://en.wikipedia.org/wiki/Unixtime) you can specify any time/date from 1st Jan 1970 12:00:00 to 19th January 2038 in 4 bytes accurate to 1 second. It's true that when we reach 2038 there will be the "year 2038 problem" (http://en.wikipedia.org/wiki/Year_2038_problem) which is likely to be FAR bigger than the "millenium bug" but it's a while until we get there!

Anyway for the rest of the data is the accumulation sequential? If so just use fixed size records written back to back - a record that contains all 0xFF (erase state of AT45) will mark where the next free space is.

Also note a feature of flash is that for any byte you can make 1 to 0 bit changes without needing to erase the page. So if you use a byte as an "active" flag containing 0xFF then you can later set that byte to 0x00 without needing to erase a page/sector to mark that entry as "sent so now dead".

I guess if you just work up sequentially through the storage doing this there might eventually come a point where you hit the end of the storage space. In this case you might want to perform some kind of "garbage collection" to now defragment the part inactive array of records (though I'm assuming the only "active" ones left are the ones near the top end that have not been sent over the wireless yet?). Such a "garbage collection" could be a very lengthy process so the system may need to be able to be inactive for seconds/minutes while it occurs (though very irregularly).

Another option is to add some kind of sector indexing system to the storage array - a bit like FAT on an SD card. In fact you really could use FAT but note that the downside is that the file allocation table and the directory sectors could get a lot of rewrite activity.

In fact you probably want to keep wear levelling and bad block avoidance in the back of your mind. Flash arrays may have dropped sectors or ones that wear out from too many erase/write cycles. In part this is why AT45 have the extra 8/256 or 16/512 sized sectors. The additional 8/16 bytes to be used for ECC to spot/correct errors and aid in a wear levelling and bad block avoidance strategy.

(personally, unless making huge industrial quantities this is why I'd find SD/MMC so appealing as all this stuff is hidden and you can just treat the storage as a "clean" array as the on-board controller handles the bad blocks and wear levelling).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for advices Cliff!

clawson wrote:
First thought: why 8 bytes for the time? If you use "unixtime" ...

OK !

clawson wrote:

Also note a feature of flash is that for any byte you can make 1 to 0 bit changes without needing to erase the page.

I didn't know that.
I red datasheet of http://www.atmel.com/Images/doc3596.pdf
and obviously I missed this very important thing.

But looking again in datasheet on every place where write data is mentioned the page must be first erased and then programmed.

So could you explain this in more detail?

Is this some kind of combination of standard flash r/w commands ?

Thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So could you explain this in more detail?

Try doing two writes to a page with out an erase in between. In the second data just change some 1 bits to 0. Then read the page back. I *think* you'll find it will have updated OK (raw flash does!). What you won't be able to do is make any 0->1 transitions in this way.

In reality what you'd really do is write a page at some point then later read that page content back out - change the flag byte then rewrite the page. The flag state should change (as long as it's 1->0)