FAT file writes on STM32F105 corrupt the file system.

[JPesc]

I implemented a USB MSD using an external SPI flash device on my STM32F105 board. Windows can see this drive, format it, and use it. Besides being slow, it works perfectly under Windows.

The FAT file system driver on the board can open and read files placed onto the drive by Windows, but when the ST attempts to write and create files, it corrupts the entire drive.

I thought it might be because the ST FAT system uses only 8.3 filenames. I could not get the long filename driver function to work correctly.

[Tesla DeLorean]

>>I thought it might be because the ST FAT system uses only 8.3 filenames.

FATFS will use whatever configuration settings you choose. You might have to add in a couple unicode support files from the FATFS libraries.

More probably something is getting corrupted by the write routines, or the lack of stack or buffering.

Don't expect WINDOWS and FATFS to be able to access the media concurrently.

[JPesc]

You wrote "Don't expect WINDOWS and FATFS to be able to access the media concurrently."

Does this mean that I would not be able to write to a FAT while the device was mounted by Windows?

[Tesla DeLorean]

You'd get a lot of cache coherency issues, which would likely snarl of the file system structures pretty quickly. Presumably you're not throwing MEDIUM CHANGED like SENSE CODES

[JPesc]

I did add the Unicode support files. If I remember correctly, it wouldn't even build without them.

Since Windows seems to be able to write the FAT files just fine, it seems less than likely that my low-level flash writing routines are at fault. Since the ST can READ FAT files (written by Windows) just fine, that also suggests that the ST FAT driver structures are correct.

Would lack of stack or buffering show more obvious signs? My debugger usually flags stack problems, which I have not seen here. Where should I look for a possible write problem?

[Tesla DeLorean]

>>Where should I look for a possible write problem?

You'd perhaps instrument things so blocks you write output a CRC computation, and you check that against subsequent reads of the same block. When different stuff comes back, you have a problem.