2024-08-08 09:31 AM
I am in the early stages of writing an application that writes audio data to an SD card and, on request from the RPi, writes the same data from the SD card to the Pi. The project requires that it's done this way, as I would like a copy of the data on the RPi and a 'hard copy' on the SD card without having to manually remove the SD card and copy over files via a card reader. I am working with an STM32F446RE and the SD card I'm using is 64 GB formatted as exFAT. I have code that properly creates a file and writes the data to it on the SD card. Now I just need to transmit this file over USB to the Pi.
Where I'm a bit lost is that I don't fully understand exactly how I will allow the Pi to read files off of the SD card while the STM32 is writing with FATFS. Other posts I have read from this forum suggest that it's not possible without incurring file overwrites or corruption on the card. Will I have to unmount the SD card from FATFS each time the PC tries to read the FAT on the SD?
As mentioned, I am in the very early stages of writing this project (no MSC code written) and am looking for any sort of guidance on this. Any sort of help or criticism works here. I have read through the USB MSC BOT document and am looking through FATFS documentation right now, but if anyone has other reading suggestions I will be happy to hear them.
Other posts recommend using an MTP device over MSC, but I don't see as that's possible with CubeMX as there's no proper device implementation supported.
Thanks for the help!
2024-08-08 10:50 AM
Main problem with concurrent usage is PC side caching, and insuring everything remains coherent and not corrupted. You really only want to have one owner in charge at once.
You can provide NOT READY type status via TEST UNIT READY commands, you can provide MEDIA CHANGED kind of reporting via REQUEST SENSE
https://github.com/STMicroelectronics/stm32_mw_usb_device/blob/master/Class/MTP/Src/usbd_mtp.c
There should be several examples of USB MSC Device's under the CubeF4 report for the assort EVAL and DISCO boards. These can create RAM drives off the device's SDRAM, cards via the SDIO/SDMMC peripheral
STM32Cube_FW_F4_V1.28.0\Projects\STM32446E_EVAL\Applications\USB_Device\MSC_Standalone\readme.txt
2024-08-08 11:52 AM
Hey there,
Thanks for your response. I've looked over the MSC Standalone example. I have a couple of questions about this, but as they don't pertain explicitly to my topic I'll look elsewhere for the answers. I do have a couple of follow-up questions about some other related things, though.
@Tesla DeLorean wrote:...
You can provide NOT READY type status via TEST UNIT READY commands, you can provide MEDIA CHANGED kind of reporting via REQUEST SENSE
Is this something supported in the existing MSC class software? Not sure I'm familiar with this way of doing things. I'll look into this further though.
As far as FATFS goes, could it be as simple as dismounting the SD card from FATFS before initializing the USB MSC device and starting the transfer process? That way only one owner is in charge at a time?
2024-08-08 01:21 PM
If the USB interface has only read access, the owner (STM32) can create a "snapshot", similar to VSS on Windows, snapshots on Linux filesystems etc. Then the remote party can access the card along with the STM32. No ready examples are provided by ST, though.
2024-08-08 02:08 PM - edited 2024-08-08 02:10 PM
This sounds like an interesting idea, though to be honest I'm unfamiliar with this concept and may need some help to understand it.
I've been looking around online and haven't been able to find an example of anyone doing this recently. Would this be similar to the STM 'fetching' data from the SD card and saving it somewhere in onboard memory for a short period of time? In that case I'm not sure as this would be feasible as at times I might have a lot of data to send to the RPi, possibly more than what the STM has in RAM :\
2024-08-08 02:16 PM
> Would this be similar to the STM 'fetching' data from the SD card and saving it somewhere in onboard memory for a short period of time?
Not quite. The snapshot only should contain consistent state of the FAT table at certain time moment. The file data is on the sdcard, as usual. The lifetime of snapshot can be long, if it is saved to persistent storage (maybe the same sdcard).
2024-08-08 08:19 PM
I think your point brings to light a big misunderstanding of mine regarding FAT filesystems. Is there only one FAT, and the STM32 and the PC don't have their own versions of the table?
And to reiterate what you're saying so that I understand it better, I just need a "current" version of the FAT, and that will guide the PC as to the correct ordering of files in the SD card?
2024-08-09 12:42 PM
Yes there is only one FAT. But it can be "virtualized" so that each side can think it is the only owner. The PC cannot access the SD card and its data immediately, it sees only what the STM32 presents to it.