logger and MSC with fatfs

[michele77]

Posted on October 11, 2012 at 17:16

Hello experts and sorry to bother you once more.

I implemented a FW for a STM32F102CB that combines logging and USB MSC (Mass Storage Class). I took the USB MSC from STM32_USB-FS-Device_Lib_V3.3.0 and modified mass_mal to use this SPI layer: http://cba.si/stuff/fatfs_diskio_sdcard_spi.c The logger has a dual buffer and simply writes the full buffer using this code:

if
(bLogOpen) {
fres = f_write(&fLogFile, &(ppuLogBuff[1-iWhichBuff][0]), DBUFF_HSIZE, &iWritten);
if
((fres != FR_OK) || (iWritten < DBUFF_HSIZE)) {
bLogOpen = FALSE;
}
else
{
if
(iSynchPack == 0) {
fres = f_sync(&fLogFile);
if
(fres != FR_OK) {
bLogOpen = FALSE;
}
}
}
} 
else
{
InitLog();
}

I am facing an issue that I think being related to an access conflict. Both serial port logging and USB MSC access the microSD card with SPI (no DMA anywhere). If I disable logging when the USB cable is plugged in, the PC will recognise the microSD, I can browse it, and everything seems to behave normally even though the write speed on the SD card is very slow (about 120kBytes/sec). If I keep logging onto the SD card regardless of the USB cable being connected or not, then the PC does not enumerate the card or says it's empty and so on. As I said above, I suspect that whilst I am flushing the log file the interrupt service routine of the USB will kick in and find the SPI middleware in an inconsistent state. If that would be the case, I could flush the stream at higher priority than the USB ISR, but it just does not sound right. I would like the STM32 to keep logging even if the USB cable is plugged in so that my customers can extend the battery life of the logger simply by plugging a battery pack to the USB.. and even browse the contents without necessarily stop the logging. Any suggestions? What other code could I post to describe this situation better? Best wishes, Michele #usb-msc-spi-fatfs-logger

[Tesla DeLorean]

Posted on October 11, 2012 at 17:43

Sounds more like you want some ownership semaphores on the SPI/SD read/write code, and to stall out the SCSI READ, WRITE, etc commands on the USB Mass-storage side. You could force all media access through a single thread/task.

Your far bigger problem however with allowing two independent tasks to use the FAT file system is one of coherency. If Windows caches, and writes back stale or modified data to the file system structures you're going to have real problems not trashing the content. The device could throw errors and not ready status, or indicate zero logical units, to allow USB to power the device whilst not permitting access to the media. You could also perhaps report as being read-only, and throw media-changed status as required. It all gets rather deep and complicated.