We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
I am using RL_ARM to creat/modify file in SD card. My ARM processor is LPC2368.
After formatting from PC or from ARM processor (using fformat)the SD card, new files are creating fine and content are available.
But when previous file are available with same name & i am using fopen function with write mode ("w") then some cases new file is creating but not possible to access from Windows OS showing "file or directory corrupted and unreadable".
Please give some feedback.
Hi
I am using RL-ARM 4.12 with LPC 2468 writing files to SDCARD and seem to have data integrity issues, I have posted a request to support on this. Check disk returned issues with reported file sizes.
Hi Darren,
Not clear to me what you means.
I am using RL-ARM version V3.21. Is any problem with that perticulor Version ?
Hi,
Sorry I do not know about earlier versions, just commenting on my and the OP message.
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...