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
Funny stuff, like coherency?
True simultaneous access is going to be impossible to achieve, you have to be able to arbitrate access between one or the other. You might want to look at how you can block access to the microl-controller side, and recognize and emulate the SCSI commands/status so that Windows can successfully "Eject" your volume, and see when it returns.
I just finished a similar project. Simultaneous access by two different threads is near impossible with an MS-DOS filesystem. To make matters worse, Windows uses "write back caching" for external hard drives-- so until you do a "safely remove device", the MS-DOS file structures on your SD card will be in an unknown state. [Mac, Linux, and the *BSD's all use "write-through", and will not have *this* problem, but you still can't do what you are asking.]
In short, the MS-DOS filesystem on the SD-card cannot have two masters-- you can use your on-board MS-DOS file system while the host is not connected, but must close everything safely an relinquish control to the file system when the host cable is plugged in. It is not even safe to perform "read-only" operations as the file structures will be in an unknown state while the host has control.
Sorry about that... It's just the way it is...
Thanks for that Ken - I figured that out - the the Keil RL File system is "MSDOS like" and does not support "simultaneous" access like the big daddy OS's like Windows,Linux etc. My work around was to have 3x separate standalone programs all residing on the STM32 flash - 1.the main app - 2. the flash loader (that used the USB Cdc interface for the CLI and the SD Flash Card running in FAT mode) - and 3..... a standard USB Msc interface to the SD card (using the SCSI interface?)- and using windows to copy flash images and so on. It works fine... but I guess that's the trade of for a small operating system (RTX) - having to reboot between the 3x apps - fortunately that is only for firmware upgrades - and shortly I will have the whole GSM/3G connection running to remotely do this. But thanks for your insight :)
1) Windows allow write-back cache to be turned on/off as the user decides. So it depends if removable media requires any 'safe removal' or not - at least as long as people doesn't try to remove the device/card while the access light is flashing.
2) Linux doesn't allow two masters either. There might be some variant of more or less cooperative file locking involved. But for this specific situation it would be solved by networking the file system. I.e the Windows machine knows it doesn't own the file system and that it can't just read in everything and cache the original data and any potential changes in memory. And the Windows machine sends the commands about what changes to do, and let the Linux machine perform the changes - which means the Linux machine has 100% knowledge of all changes.
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.