MSC, change flash disk dynamically

[CmManuES]

Hi,
I am using tinyusb with an ESP32-S2. I mounted 2 FAT partitions in flash. Both partitions are displayed on the PC as a USB disk if I connect the ESP32-S2 to the PC (in the file manager under windows) via USB. I can move/copy files in both directions etc.
It works really well.
Now my question:
Can i dynamically choose which of the two mounted partitions is displayed on the PC?
I want the following scenarios:
USB connection to PC is only used to charge the battery, the user must activate the data connection to the PC on the ESP32-S2 via the menu and can end the data connection to the PC again.
The user can select which partition is visible on the PC as a USB disk (always only 1 partition at a time).
Do you have any advice on how I can do that?
Thanks for your support.

[hathach]

I don’t know about the menu and user selection part, but for USB MSC, you only need to redirect the read10/write10 to the selected partition.

[henrygab]

Hathach is correct for the simple case. One caution: This isn't enough, if the goal is to enable changing which partition is loaded dynamically (without removal / reinserting the device).

---

Dynamic Partition Swapping

If you want to allow the exposed partition to dynamically switch while the device is connected (but still "always only 1 partition at a time"), additional logic is necessary.

Specifically, you must emulate error codes sufficient to cause the host PC to recognize transitions between "no media mounted" and when you have valid media.

Switching from mounted to no mounted media is trivial ... just report no media to the TEST UNIT READY.

Switching to mounting of a media is more complex, because you have to track if the error codes were reported to the host PC, and typically, there are multiple Sense/ASC/ASCQ that must be reported for all operating systems to recognize that any previously cached media contents are no longer valid. Thus, the code needs to track whether the error code sequence was fully reported:

For example:

StateEnum	SK	ASC	ACQ	Notes
-1	02	3A	00	Medium not present
0	06	29	xx	Device was reset
1	06	28	00	Not ready to ready (medium changed)
2	00	00	00	No error

From state -1 (no media), a new volume arrival would transition to the next state (and thus error to be reported) until reaching the "no error" state.

For example, transitions from one partition to a second partition would change as follows:

• StateEnum = 2: Prior partition is mounted, OS caches data for performance
• StateEnum = -1: Request for new partition causes transition to "no media present"; After this Sense/ASC/ASCQ is reported, transition to ...
• StateEnum = 0: This error helps some OS detect media changes; After this Sense/ASC/ASCQ is reported, transition to ...
• StateEnum = 1: This error is most specific to indicate media was swapped out; After this Sense/ASC/ASCQ is reported, transition to ...
• StateEnum = 2: New partition is mounted, reads/writes directed to the new partition

But of course, nothing can be that "simple". :) Some commands are excluded from the above error reporting (INQUIRY, etc.). So even the above is not a complete answer.

More abstractly, for storage devices, there are classes of errors that must be reported to the host. Failing to report these might cause the host to not detect that the media has changed, and thus to continue to use previously cached data, potentially resulting in corruption. Fun!

---

[cr1901]

So even the above is not a complete answer.

More abstractly, for storage devices, there are classes of errors that must be reported to the host. Failing to report these might cause the >host to not detect that the media has changed, and thus to continue to use previously cached data, potentially resulting in corruption. >Fun!

So what would a complete solution look like (in prose/limited to one OS if space is a concern)?

[henrygab]

A complete solution would be much more complex. It would track a plurality of classes of asynchronous errors (e.g., media change notification, device reset, power state changes, etc.). Some of those asynchronous errors would overwrite other errors of lesser importance in that class of errors. Each of the supported commands would have a mask indicating which (if any) of those asynchronous errors should be reported (thus typically causing the command to fail, and forcing the host to retry).

That's not a complexity that is typically needed. A simple MSC device has few mandatory commands; INQUIRY might be the only command needing asynchronous error reporting. My state machine example might be "good enough", if the only asynchronous state change to be handled is a virtually inserting / removing media.

Moreover, it's quite possible that non-compliant devices (those that don't follow this rule) already existed in sufficient quantity, such that larger code bases were forced to workaround devices which ignore this particular rule. Said another way, perhaps the rule exists, but has no practical effect for Windows, Linux, etc. ... but still may affect embedded OS or the like.

[hathach]

thank you @henrygab for putting detail explanation. These definitely needs quite a bit of trial and error to figure it out.