USB MSC mass storage mode as devel tool

[jgriessen]

I've heard warnings about using USB MSC when also wanting to do data logging to the flash memory.

Is there any gotcha for using it to develop code? I'm meaning a work flow like:
1. turn on pyboard,
2. leave pyb.usb_mode() at default ,
3. on the USB host machine write to the flash via the mounted filesystem of the target pyboard,
4. test code running by soft reset,
3.
4.
3.
4.
iterate code development.

If your code has bursts of high priority interrupts that might slow the REPL
when they happen, is it OK for files? Has anyone seen any file corruption in this way
of using where no writes are done by the pyboard?

Suppose later you do want to develop a data logging app, what is necessary to avoid file corruption?
Is closing a file every time it is written to enough?

Looks like some good suggestions for closing that file on purpose here:

Re: uasyncio: best way to write to a file from a coroutine viewtopic.php?f=2&t=4771

[dhylands]

I started out doing things that way, and that's what prompted me to start using rshell.

Most of the time things work out ok. Occaisonally, my file would be corrupted. Before rshell, I used shell https://github.com/dhylands/upy-shell which runs on the pyboard. It would let me examine the files from upy's perspective (i.e. cat a file) and let me verify that the file looked ok.

Once I wrote rshell, I've rarely ever had to use shell and pretty much use rshell to do all of my file copy/repl work.

To avoid corruption when writing to a file, disable MSC.

[jgriessen]

So there is occasional file corruption when only doing file writes to USB MSC from the host computer, and only doing soft reset or hard reset from micropython?

If this is the status of USB MSC, is there a plan by the main developers to upgrade it so USB MSC will be a valid selling point for code development? It's hard to sell people on something that seems well documented, but leaves out crucial details so you end up stuck in a development swamp until hearing differently from Dave Hylands and Peter Hinch. If that is how it is, the required documentation is in multiple places and not all referenced, and so slows micropython uptake.

[chrismas9]

I have not had problems copying source files to Pyboard as long as you allow a short delay after a write before a hard or soft reset. The red LED comes on during write from host. Wait for it to go out before doing anything else.

What will corrupt the drive is allowing writes from Micropython while connected as MSC USB device. If you want to test data logging during code development use an SD card for logging. You can turn MSC off and switch back to MCU flash when you finish debugging. Otherwise Edgell is a safe alternative if you don't have SD.

MSC USB mode provides a simple out of the box experience for new users and I can't see it being disabled.

[dhylands]

The design of USB Mass Storage assumes that the host has exclusive access to the file system.

The only way to guarantee that no corruption occurs is to turn off access to the filesystem from the pyboard while the host is accessing it.

[jgriessen]

The only way to guarantee that no corruption occurs is to turn off access to the filesystem from the pyboard while the host is accessing it.

OK, good! that means I can use it for code development as long as I don't want to do data logging.