3

I'm currently developing an application for an ST32 (STM32F103xC) using Micrium OS-II. So far it's all gone smoothly, but I've hit a block now and can't proceed.

The board is configured to act as a USB storage device using the SD card so that the host PC can copy files saved out on the device. This works fine, inasmuch as can see the files currently on the SD card in a Windows Explorer.

However, when I try to use FATFS to create a file in my program, f_open() returns FR_NOT_READY. In order to investigate further, I built some sample code that writes files to SD and it works fine. So I moved the writing code around in my program, and I found that if I called f_open before I started the OS multitasking tick, it worked correctly - I could open a file and write to it. Putting the code immediately after the enabling of the tick (but before tasks have been created) goes back to getting FR_NOT_READY.

I am not sure I know what this means. Are there limitations on where I can write to files? Do I have to disable multitasking when writing? (Ouch, surely not?) Is it simply that I can't write to an SD card I am currently using as a USB device?

Julian Gold
  • 1,246
  • 2
  • 19
  • 40
  • Might it be something to do with _FS_REENTRANT being set to 0 in the ffconfig.h file? – Julian Gold Nov 14 '13 at 10:33
  • Nope, still broke. Would appear to be something to do with USB interrupts confusing the SD card code during FATFS operations. – Julian Gold Nov 14 '13 at 14:42
  • Does this device have a dedicated SD-card controller or have you had to resort to SPI? – Martin James Nov 14 '13 at 17:40
  • Yeah it has an SD controller. It looks very much like the USB interrupts (which need to be serviced promptly) kill the file system so even locking resources doesn't help. I am now of the opinion these things can't exist simultaneously without having a genius coder to hand. – Julian Gold Nov 15 '13 at 10:14
  • 1
    On my LPC systems, I have the SD-card interrupt on FIQ. It's handler uses no stack, just the swapped register set, to read/write the 512-byte buffers to/from the SD controller FIFO. It's quick enough to allow the USB to still work OK. When the FIQ handler has read/written all its data, it sets the VIC to generate an 'ordinary' software interrupt that signals a semaphore upon which the SD-card driver thread is waiting. – Martin James Nov 15 '13 at 17:34
  • @MartinJames: The interrupt architecture on Cortex-M3 is very different to ARM7 - there is no FIQ. – Clifford Nov 15 '13 at 20:53
  • Whose filesystem and USB library are you using? – Clifford Nov 15 '13 at 20:56
  • People seem to be overlooking that there are two distinct problems: the mechanics of servicing both SD & USB interfaces, and then the problem that you can't have the SD card mounted to two distinct pieces of file system code at the same time unless both are truly read-only. So not only are their "mechanical" interrupt/timing/reentrancy problems with the implementation, but also the current goal is not achievable without a drastic change of strategy. – Chris Stratton Nov 15 '13 at 23:41
  • @Clifford the code I am using is the board support code from PowerMCU. It's a bastardized version of the code from ST. I have basically smashed two of their demo apps together (one for USB, one for SD/FATFS). – Julian Gold Nov 18 '13 at 13:15

1 Answers1

5

Indeed, you cannot expose the SD card as a mass storage device to an external USB host, and also mount it locally as a file system at the same time.

To clarify a bit further - actually you could attempt to do this with simple arbitration of access to the hardware, but you'd soon incur inconsistency if not data corruption, as each piece of file system code would assume that it had freedom to modify the file system, no requirement to immediately commit changes in a consistent manner and safety to assume that any filesystem data it has cached in memory is still valid, because nobody else could change the storage blocks without telling it.

If you want two hosts two access the storage volume, you would need to implement something with the multiple-client consistency protections common to a network file system - something which FAT is definitely not an example of.

Enumerating your options, the following should be possible:

A) Interface SD card and USB, expose SD card as a mass storage device without local access

B) Interface SD card and use it with local filesystem code; also have a USB interface for some other purpose without mass storage mode.

C) Interface SD card and USB, manage SD card as a local filesystem and grant the PC access via a network file sharing type mechanism which manages consistency

D) Support more than one of the above, but as independent modes which cannot be active at the same time and require substantial effort to switch between.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117