RL-ARM File System problem during file creat

I have a found a number of problems with FlashFS writing to SDCARDS over the past year, most of which have been due to directory corruption of one form or another.

For instance until version 4.12 renaming a long file name could delete an entire subdirectory or a file.

However finding the exact cause of a problem is time consuming and you need to be able to show it is Keil's problem for them to fix it. I have likely spent around a month or two on these issues for them, which is not something that you would expect from such a costly product.

I also have to say we still appear to get directory corruption. For example we recently had a root directory which showed the files . and .. which I believe should only appear in subdirectories. We have also experienced files being put in a parent directory when the required subdirectories does not initially exist (most of the time the directory is created normally). Come to think of it these might actually be related problems!

Basically it appears to have been very poorly tested and maybe still unreliable.

In fact I personally feel I have performed much of the testing for them.

Stuart.

I have a found a number of problems with FlashFS writing to SDCARDS over the past year, most of which have been due to directory corruption of one form or another.

For instance until version 4.12 renaming a long file name could delete an entire subdirectory or a file.

However finding the exact cause of a problem is time consuming and you need to be able to show it is Keil's problem for them to fix it. I have likely spent around a month or two on these issues for them, which is not something that you would expect from such a costly product.

I also have to say we still appear to get directory corruption. For example we recently had a root directory which showed the files . and .. which I believe should only appear in subdirectories. We have also experienced files being put in a parent directory when the required subdirectories does not initially exist (most of the time the directory is created normally). Come to think of it these might actually be related problems!

Basically it appears to have been very poorly tested and maybe still unreliable.

In fact I personally feel I have performed much of the testing for them.

Stuart.

Hi Stuart,

Hummm....

I am also getting lot of problem regarding file handling. Though I am not sure it is my problem or FlashFS.

Now I am getting if number of character is more than 512 bytes in a file,the file is unreadable by a PC. But for less than 512 byte then it is OK (RL-ARM V3.21). Don't know ...

Is 512 bytes the size of a sector?

If so, doesn't this suggest that the bug is something to do with having >1 sector...?

Block size of SD card 512 Byte.

Sector size 32 X 512 byte.

So it looks like a bug with handling >1 Block, then!

Not getting ....

Do you have any solution? FlashFS must handle multiple block write or read....

No - but don't you see this as a big clue as to where you should be looking to fix this...?!

Yes I got the solution for file size. I introduce a delay in "mci_write_sect" function in MCI_LPC23xx.c file. The delay is added after MCI_DATA_CTRL loadded with 0x99. Upto 16K byte data i have chacked.

But still after 9th times file open & write, file getting corrupted .

See here:

http://www.keil.com/forum/docs/thread17127.asp

FlashFS has a problem with too frequent opening and closing of files when working with SD cards. Or maybe it is a configuration issue - I don't know - it would be nice if Keil responded to my question...