More on File system and CompactFlash on MCF5485EVB board

[Chris Xenophontos]

We've resumed work on Compact Flash interface to Coldfire MCF5485EVB on our
application.

After fixes to driver, and some other updates, we have been successfully
able to mount FAT32 dos filesystem, list, read/write files etc.

One problem we're seeing is random corruption after writing files.

Our test approach is as follows:
-Format compact flash card as FAT32 using PC, copy some test files on it
(8K through 2M) containing known data, i.e, tstfil1 = 512kbytes,  etc.

-In test app on Coldfire target with rtems 4.10.2, we verify mounting of
compact flash, then, using RTEMS console, we can list files, etc.

-We logoff console - test app begins to run.

-Test app then creates a reference buffer and populates it with known data
that is identical to, say, tstfil1 on compact flash card.

-Using open() and read(), the test app reads tstfil1 from compact flash,
into a separate test buffer on target, and successfully does a byte compare
against reference buffer.  tstfil1 is then closed.

-Test app then creates a new file (tstfile2) on compact flash, and writes
the buffer (reference buffer) to tstfile2 using write().

-tstfile2 is then closed, and test buffer is cleared.

-tstfile2 is re-opened, read into test buffer and successfully compared
against original reference buffer.

However, when removing compact flash card from target, and reading it on a
PC, tstfil2 seems to have a 512-byte block that is corrupted - more
specifically, it seems to be a data block data from another file(!) on the
compact flash.  Otherwise, diff tool shows identical contents between
tstfil1 and tstfil2.  Other times, errors are more sporadic, and seems to
be more of a problem with files larger than 512K.

We're using basic file open, read and write functions in this application.
 Libblock and ATA/IDE are used in our application with DOSFS, also a custom
low-level driver used for compact flash access.

Sorry for long-winded description - any help is appreciated!

thanks
Chris Xenophontos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20121214/5de410a5/attachment.html>