USBD_MSC demo (SDK v15.2.0) - why are filesystem operations not allowed while the USB is plugged in?

[Boris Matešin]

A while ago I was experimenting with the usbd_msc demo, trying to get the firmware working as RAM-disk-only storage, without any permanent storage like Flash or SDC. While that was easy enough to modify, there's one thing I can't figure out.

In each fatfs wrapping function listed in the main.c file, there's a check whether the USB cable is still connected (m_usb_connected) which prevents the filesystem operation from being executed. The variable m_usb_connected is modified by the usbd event handler on connect and disconnect.

Is there any practical reason for this prevention of file operations? The system I'm trying to integrate with normally uses a USB stick, so it likely does not logically disconnect from the USB device until it's physically pulled out.

If the filesystem absolutely must not be modified while USB is connected, can I externally (i.e. through a FET) disconnect the VBUS line to get the nRF82840 to detect a disconnect event, do my filesystem operations, and then return the VBUS line to its normal state?

[Turbo J]

Boris Matešin said:

Is there any practical reason for this prevention of file operations?

Yes: The Host (PC) Cache. Basically all sectors the host has read are cached, and won't be read again until the device is disconnected.

In other words: Writing to the storage while connected to PC will most likely result in a corrupted file system.

The SCSI sublayer supports "removable" media in theory, but I don't think this is currently available in the NRF example implementation. This would allow to "virtually" remove the sorage media when the NRF MCU needs read or write access.

[Boris Matešin]

Thank you for the explanation, I didn't consider it from that angle.

Would it make any sense to move the file-access-lock flag (currently m_usb_connected) to change on the SUSPEND and RESUME USBD events instead? I've noticed that when the nRF board gets logically disconnected (by using the Eject nRF52... option in the host OS tray), the usbd reports an APP_USBD_EVT_DRV_SUSPEND event - is this a guarantee that the host OS will no longer access the filesystem?

Also, does your warning apply to both read and write operations, or just writing? In other words, would it be safe to perform a directory listing or a file-read while still connected to the host? (I'm assuming that's a maybe since at the very least, the file-access date would be affected)

[Turbo J]

USB SUSPEND and resume are not save, unfrotunately: Consider S3/S4  host power states (Suspend to RAM/Disk).

Reading is also highly discouraged as the host may use write cache. This is rarely used on USB stuff, but still possible without any notification to the device.

There is a good reason why android no longer uses USB Mass storage mode. If you needed access from both ends, consider using USB PTP.

[Boris Matešin]

Thanks for the detailed info. I'll see if the other end of the USB connection can be adapted to power off USB on completion so I can handle it more cleanly.