• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 663 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Block boundaries in flash files and no-erase writes

Paul
Prodigy 20 points
Other Parts Discussed in Thread: CC3200

Files created with sl_FsCreate have a size that is a multiple of 4K blocks less 512 bytes.  I assume that 512 bytes is meta information about the file.  Which block are those 512 bytes taken from and what part of the block?  I would assume that the first 4K block has the first 512 bytes reserved So offset "0" is actually 512 bytes into the block.  The first full physical block of 4K would then be at offset (4096-512).  Is this correct?  I could also imagine it being the last 512 bytes of the last block.

It has been a few years since I worked with flash devices, but I recollect that once a block is erased (all set to the same bit) that you can write the block several times, but only in one direction.  The flash I worked with erased to all 1 bits, meaning you can change a 1 to a 0 with a write but not a 0 to a 1.  This is useful as you can "append" data without doing an erase cycle, preserving the life of the flash.  Using a file to record 16 byte events means you could write up to 256 events without needing to actually erase the block.  This is a huge savings on erase cycles.

In my application I want to save state information every minute.  That is 1,440 writes per day.  At 100,000 erase cycles I would wear out the block in 69 days, as opposed to 48 years if I don't need to erase for each appending write (assuming 16 byte state).

I have found precious little information about the filesystem, such as basic file layout, what happens when you do successive writes into the same block, and so on.

  • 0
    Guru 21435 points

    Hi Paul,

    The file system is proprietary and information is not provided, which I believe is due in part to security concerns. There is no way to append, you will need to read/erase/write to perform append.

    Here are a few suggestions, some of which could be combined to increase the longevity. But first of all some bad news, the file system only supports 128 separate files -

    Suggestion 1: Instead of creating one large file by performing read/erase/write, you could instead write for example 100 separate files for your 16 byte events. You could do this by appending a number onto the filename. And when it was time to start again, you would then erase/write with the same filename. I am unsure where this would all end up, but if there is only enough space for this file, then it would likely over-write the location of the previous file. And then you would use a mechanism to join the 100 files together in what ever client you are using (taking into account the time or file append number - which should be stored in memory).

    Suggestion 2: You can use up to a 16MB serial flash, which will give you 31 times (31 x 512KB) more space than the 1MB serial flash.

    Suggestion 3: Look into using the SD/MMC peripheral of the CC3200. This may offer a better solution for so many writes, you may also get append without having to delete. You will also have the capacity for more space.

    Suggestion 4: Though I am no expert, there are some serial flashes which offer 1,000,000 erase cycles. This offers 10 times more writes. Whether they are supported you will need to make sure they support JEDEC specification SFDP (serial flash device parameters), see link above for more details.

    Glenn.

  • 0 in reply to Glenn Vassallo
    TI__Guru 64455 points

    Hi Paul,

    As mentioned, SimpleLink device does not support append operation. Few notes:

    • on a flash device you can't write or modify a byte without erasing an entire block (in our case 4KB)
    • the SimpleLink device does not have enough RAM memory resources to store a content of the entire user file to allow managing simple read-modify-write method

    With this in mind, you can use several files where each file holds number of states and in this way to reduce the wareout rate of the flash. The main disadvantage with this approach is the low utilization of space (each 16 bytes would consume a 4KB block).

    Another option is to keep the file openned for write. This way you can write the data to their designated offset (as long as the same offset is not written twice). The main disadvantage with this approach is that you loose the fail-safe since the FAT is updated upon closing a file.

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 20 points

    Thank you both Shlomi and Glenn,

    Seems like the best thing would be to have additional flash that the system does not know about.

    Interestingly enough, in driverlib/flash.c, there is the routine:

    FlashProgram(unsigned long *data, unsigned long addr, unsigned long count)

    In the description is:

    Each word in a page of flash can only be programmed one time between an erase of that page; programming a word multiple times will result in an unpredictable value in that word of flash.

    So it seems at some level this is possible, the only question is how I would find the address in flash of a file.  This is not the most critical part of my application, I may just end up risking the loss of data on unplanned reset (e.g., power interruption, watchdog goes off, etc).

    Unfortunately it is not clear that there are any corresponding read routines.  This probably could be done by writing a low level flash driver, but I don't think I will spend my time there.

    <soapbox>
    Making a filesystem format proprietary really does not help security at all (security through obscurity), it just makes it annoying.  Sadly, I have seen that happen all too often.  If the reason is the just don't want to open source the code, that I can understand, but that doesn't mean you don't have any documentation.
    </soapbox>

    I guess since data is only written on close, you can't take advantage of knowing the layout.  Seems they didn't look to far for applications of this flash beyond the minimum of what they needed to program and load /sys/mcuimg.bin. At least they make that much accessible from the application.

    But thanks again for the responses.  I appreciate it and learned from them.

  • 0 in reply to Paul
    TI__Guru 64455 points

    Thanks for the feedback,

    Initially, the intention was to use the file system internally, mainly for system files. However, with time this service has been offered to host application for storage purposes. I agree the file system is not as flexible as could be expected but I believe it serves the basic operations for embedded devices. Nevertheless, we are looking very seriously into improving the file system based on feedbacks from users. For example, adding append() API, listing of existing files, free space, etc.

    I'm closing this thread for now. If you have additional queries related to file system you can add a link to this post.

    Regards,

    Shlomi