Hello
I have the following setup 1)Hardware - a STM32F4xx Keil dev board type circuit 2)Middleware RL-USB with a composite configuration - Msc and Cdc connected to a Windows computer and 3:) RL-FLash FS (using a SD card running in native mode). It all running under RL RTX.
Everthing just about works... but when i use File I/O routines such as fcheck, ffind etc - (via the Usb Cdc interface) - it does not work. I tried fcheck - it comes back with a 1 - an error.
I did have this all working - I patched the ST USB device firmware together to make a composite driver, reworked the various ST routines and using the RL-Flash FS and got it all to work. When I say it worked - I don't mean having simultaneous access to files. The idea was to copy a file across using windows and then using a hyperterminal CLI interface to (with the Cdc interface) re-program the STM32Fxx flash. Ok so if was working why did I change it - well I was really hopping to use the Keil middleware in the project and then there is a very good chance there wont be any funny stuff. I had "funny stuff" on my ST code - sometimes - when hooked up to certain HP laptops.
I have tried variation on this theme - but it's not working.
.... FAT_VI *mc0; Media_INFO info; __task void init (void) { CreateMailboxes(); t_TerminalTask = os_tsk_create (TerminalTask,5); t_LedTickTask = os_tsk_create (LedTickTask,5); os_evt_set(EVENT_BOOTUP_COMPLETE,t_LedTickTask); t_I2C1Task = os_tsk_create (I2C1Task,5); t_PowerManagmentTask = os_tsk_create (PowerManagmentTask,2); t_ADCTask = os_tsk_create (ADCTask, 2); os_evt_set(EVENT_BOOTUP_COMPLETE,t_PowerManagmentTask); usbd_init (); mc0 = ioc_getcb (NULL); if (ioc_init (mc0) == 0) { ioc_read_info (&info, mc0); usbd_msc_init (); } usbd_connect(__TRUE); while (!usbd_configured ()); os_tsk_delete_self (); }
Any ideas? Does the RL-FS work with either the USB Msc or using the File I/O routines like fopen, fclose etc - but not both. There is a polling mechanism in the the Usb Msc to check if the drive is ready/available so it would seem to me that this is a viable possibility?
Many Thanks Peter
What I was trying to convey, is that when a host is accessing an MSD device, the access is through reading and writing sectors. The host gathers information on what sectors to read/write by reading the file system structure(s) on the MSD device. On the device side, there is some code that understands MS-DOS file systems, and this code *also* gets it's information from the file system structure(s) on the device. These structures are dynamic [the directory and the FAT will change if a file is being written to]. So, when one "master" [let's say the host] is writing to some sector of the FAT to update it [for example], and the other "master" [the device] is *also* trying to update the FAT at the exact same time, then the usual result will be file system corruption.
The way "big time O/S's" take care of this, is they control the MSD device in the kernel, and they make sure that one file-system operation is completed before allowing another-- so, in a way [which is different depending on Windows or "other" O/S], they manage the coherency issues. Because there is no way for the firmware on the device and the software on the host to communicate, then there is no way for each of them to obtain exclusive use of the file system on the device's flash memory, and so-- there is no way for both the host and the device to be manipulating the file system on the SD card at the same time [without possibly introducing file system corruption].
Yes, I am aware that you can control how Windows manages a certain external MSD device, but it only does this based on the file system serial number on the device-- so the settings end up in the registry, and if you plug in an identical device [with a different file system serial number], you then have to change the settings for *that* device as well. I hate to be a "knit picker", but you cannot expect anyone other than a power-user to even know that these settings exist, and to remember to set them each time a new device is plugged in [even if it is the same type of device]. That is why I tell the Windows users of *my* device to always use the "safely remove device" operation before they unplug the device-- this saves everyone the pain and misery of having to change the settings [and possibly getting it wrong-- and maybe even damaging something else in the process]. I think the Windows default "write-back" policy was unwise-- and the "other" O/S's [wisely] chose to use "write-through" policy on all removable drives-- and yes, it slows things down, but it makes things more reliable when you have an untrained user [which is what you will have 99% of the time]. If Windows had a default "write-through" policy on removable drives, it would still allow a power user to change this to "write back" if they wanted to. I don't want to get too deep into this, because it is off-topic. I only mentioned this because I ran into this problem when developing my device and had to chase down what was going on-- and so, I was trying to save the OP some time and trouble.
One way to solve the OP's problem [if he absolutely needs access to the files on the SD card while the host is plugged in], is to implement some kind of protocol that reads/writes files by requesting this service from the host through the serial channel [or another additional channel of some sort]. I don't pretend to understand everything that the OP wants to do with this device, so this may be inappropriate-- it's just an idea.