cc3200 sl_FsWrite() to update data

Vincent,

Append operations are not supported by the file-system - The user is expected to write the contents of the entire file every time he intends to append something.

BR,

Praneet

Hello Praneet,

I haven't worked with the file system yet, but not having an append sounds troubling.  What if you are data logging or doing any work with an existing file?  With the limited RAM, you may not be able to load the file to it and make changes since your code is there.

What would you recommend as a way to implement an append function?

Thanks,

Thanks Greenja,

That's exact question I like to ask too ; )  The append operation is infrequent, so I don't worry much about the flash's wear and tear. But I need a large file to hold potential data ( for example, up to 1M, when the flash change to 16MB).

Hmm... we are looking to do a similar thing  (using sFlash for logging data) so will be interested in brainstorming solutions.

I guess, theoretically, we could have a separate file per log entry, but that sounds horribly inefficient.  Or we could look into writing directly to the sFlash, without using the simple link API.  I'm curious if others have other ideas.

(Also, fwiw, I'm having problems opening a new file for writing, but I am going to play around with that a little more and will post a new thread if I don't figure it out...)

Mark Goodrich said:

I guess, theoretically, we could have a separate file per log entry, but that sounds horribly inefficient. 

Unfortunately the file system of the flash can have a maximum of 128 files, so separate log entries will not suffice for many logging applications

See details under 5.8 Memory of the Data Sheet - http://www.ti.com/product/CC3200/datasheet/detailed_description

Glenn

Thank you all for highlighting these important points.

The File System of the SimpleLink is intended for system usages such as, booting information, system files, configuration files, preferred Networks, status files, HTML files and also other user data files.
The File System has been designed to be fail safe, which means it will take care of keeping the last valid instance even in cases of failures during write.However the file system has some constrains such the inability to append or change data in an existing file without reading the entire content first.

Some possible workaround for this constrain in use cases such as the data collection (logs) could be to split the content into small files and every time to access one of the small files, to open it for write and close it only when all the bunch of logs were written. As long as the file is opened to write you can append the logs to this file but you should be aware that in case of a power-fail you can lose the logs in this last file.

A few points for thought:

1. On a flash device you can't write or modify a byte without erasing an entire block (in our case 4KB), erasing a block takes relatively long time
2. The write endurance of a typical flash device is about 100K cycles
3. The file system does not implement any wear levelling mechanism so if you consider writing frequent data like the logs, splitting the write into several files could assist in this manner and allow to implement simple cyclic mechanism
4. The SFLASH is been used for the system/device purposes. The File System enable sharing the SFLASH with the user application, but the application must go through the File System APIs otherwise the data on the SFLASH might be corrupted
5. We are using the SFLASH for data collection in number of systems and as long as the guidelines are kept things are working nicely

Barak

Hello Barak,

Thank you for providing a workable solution to this.  I have some questions.

1.  Are you saying that you cannot write a byte or word to the file even if you have a 4k block erased?

2. If the file system is fail safe, then why wouldn't the last write be copied to the last byte or word?

3. On a 128MB SFlash or larger, is there a restriction on the file size?

4. Is there any restrictions on the SFlash size we use?

5. If for whatever reason we don't want to use the file system for storing user data and applications,

   a)  can this be done through custom code

   b). Is it the entire flash that may get corrupted, just the file system or just our user data and application.

6. Does the API support management of a file system on a SD card?

Thanks,

Hi Greenja,

In current APIs of the file system, you can't change data in a file even if it is located in erased area.

The file system can use a SFLASH of maximum 128Mbit and could store total of 128 files. The maximum theoretical size of a file is 128Mbit but this size is not practical since there is an overhead of the file system (FAT tables) and you must keep place for the service pack and other system files.

There is no option to use the SD card for this file system, but you can connect an SD card to the CC3200 and maintain your own file system on it.

In the current system the SFLASH is managed by the Networking sub system. The Networking sub system is a real time system and accessing the SFLASH must be limited in time. Having two Masters (the application and the networking sub system) might lead to timing and other issues that could cause a data corruption on the SFLASH.

Barak

Please add these limitations to the documentation.  (can't append, can't change bytes, workarounds?)

swru368.pdf SS14 contains no such indication of these limitations.(!arghhh!)

Or if you want it in the form of a question:

WHY ARE THESE LIMITATIONS NOT IN THE DOCUMENTATION?!

WHY ARE THEY NOT DISCUSSED/ILLUSTRATED IN THE example/file_operations/main.c?!