• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 39 subscribers
  • Views 1468 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.

SimpleLink Filesystem Bug on CC3200

user4107981
Prodigy 40 points
Other Parts Discussed in Thread: CC3200

Hi,


I've observed a strange behavior on my CC3200 and I'm wondering if this is a known issue, a planned behavior or a bug.

I want to realize a file which contains a hash table. So I have random read and write accesses over the whole file.

Now my routine:

I create the file with a file size of 2048 byte.

My allocated file size is also 2048 byte.

Than I write something at offset 1024 with length 64.

Now my allocated file size is only 1088 byte, and I'm not able to read data behind the offset 1088.

It seems that the SimpleLink co-processor shrinks the file size to the end of my write operation.

This behavior seems a little bit strange for me, because I created the file with a size of 2048 byte.

Is this a planned behavior, or did I forget a flag during file creation?

Best regards

Nils

  • 0
    TI__Guru 64455 points

    Hi Nils,

    You are describing a scenario where you try to read beyond the location originally written to. What is the intention of such operation?

    Basically, the file system behaves in such a way that you cannot read boyond what you written. In your case, writing 64 bytes to offset 1024 means you have valid data up to offset 1088 (file system is not protecting from possible holes below this offset. This is the responsibilty of the user to make sure the data is valid). This is why you are not able to read beyond offset 1088. I believe you should get an error, -15 (OUT_OF_RANGE).

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 40 points

    Hi Shlomi, 

    my basic idea was to create a file which contains a couple of information arranged in a hash table. With this hash table, I want to speed up my information access on the flash and I want to save write cycles, to take care of flash cells.
    I compute a hash sum of my information and than I am able to read directly at the address where a assume my information in the flash. The same behaviour I want to use in an update situation. I change my values, compute the hash sum, and write directly on the right position. So I don't have to read my whole "big" file and on an update, I don't have to write the whole file.

    In my use case, I want to keep track of all files in the flash. I want to have an overview of my files, and I want to be able to delete them. 

    So I decide to create a own file where I store all my filenames. To make this layer performant, I choose this hash table idea for my implementation.

    You can find my source code here: https://github.com/polybassa/WyLight/blob/Master/cc3200_gcc/common/wy_fs.c

    The current file is not fixed, but you can see the idea from it.

    Very strange for me was that behaviour, that I create a huge file (sl_FsOpen(FS_CREATE...) ) and allocate everything with default values (sl_FsWrite(...)). Then I have a file size of 2048 Byte. Now I write something in the beginning of my (address 128) file and than my complete file size is only 128 + 64. What happens to my  already stored information, for example at address 1024. Does the SimpleLink API remove everything or is my information still stored, but not accessible? 

    Nils

  • 0 in reply to user4107981
    TI__Guru 64455 points

    Hi Nils,

    I see your point now. There is a long discussion on this feature on this E2E. The problem with SFLASH devices is that before writing to a specific offset, the entire block needs to be erased. Thus, the already stored data is erased. However, the file system as of today does not read-modify-write by its own. It simply erases the entire file upon openning it for write. The only solution is for the upper layers (user implementation) to apply the read-modify-write.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 40 points

    Hi Shlomi,


    thank you very much for this clarification. Now I have a better understanding of the internal SimpleLink FS behavior.

    It would be great, if you can add information like this to you API documentation. I'd read almost every document that you provide for documentation of the CC3200 and couldn't find notes that indicate such a behavior.
    The SimpleLink filesystem API looked like a higher layer for me, so I expected that I can use it without taking care of the SFLASH behavior. Similar to stdio.h functions.

    Best regards,

    Nils

  • 0 in reply to user4107981
    Prodigy 40 points

    Hi Shlomi,

    one more questions, is it possible to get a file list from the SimpleLink Co-Prozessor which show's all existing files in the SFLASH, similar to "ls" or "dir" on a command line.

    Best regards

    Nils

  • 0 in reply to user4107981
    TI__Guru 64455 points

    Hi Nils,

    No, this option does not exist on the file system.

    Shlomi