Turning off MSC storage for the Arduino Nano RP2040 Connect

[scruss]

Without building a custom image, is there any way to turn off the Nano RP2040 Connect's pesky MSC storage? On a pyboard, I can add

pyb.usb_mode('VCP')

to boot.py. I don't see how to do this for the RP2040 board.

I just lost all of my board's filesystem contents to the inevitable MSC foul-up, and I need to make it stop

[robert-hh]

Without building a custom image, is there any way to turn off the Nano RP2040 Connect's pesky MSC storage?

AFAIK, no. There was PR #8814 to make to customizable, but that was not finalized and closed. You can try to eject the drive. Maybe that helps.

[scruss]

ejecting the drive takes its contents with it, sadly

[peterhinch]

I wonder if it's possible to do this at the PC? A udev rule, maybe?

FWIW you've had more joy than me with the Arduino Nano RP2040 connect. Despite a lot of help from Jimmo, I never managed to get MP working. I threw it away in disgust after wasting hours on the damn thing :(

[scruss]

I got it for free in the 2024 Open Hardware Summit swag bag, and damned if I'm going to be beaten by a free thing. It's not quite the worst Arduino I've worked with, but the Intel Galileo was quite the thing.

I wish I had a coherent "how I got this thing (mostly) working [except for the MSC crashiness]" guide, but I found that the daily UF2 would upload but the v1.22.2 release would stall. The esptool.py nonsense was required to update the wifi firmware to something fit-for-purpose

[robert-hh]

There is a tool called espflash.py by @iabdalkader at https://github.com/micropython/micropython-lib/tree/master/micropython/espflash to make uploading the NINA GW easier. Works pretty well together with mpremote mount. Then you do not have to deal with espflash.py.

[iabdalkader]

The flash storage size has been increased, very recently, based on requests here #13512. Following that change, some users reported the filesystem was broken, that might be why your filesystem was corrupted too. I think this change breaks existing filesystems because USB MSC reports the bigger filesystem size, while the filesystem itself is not aware of the change. I could be wrong though and it's just MSC/OS sync issue.

[scruss]

Mine is running 1.22.2, so gives me the 8 MB MSC storage. Which had been so corrupted all my computers opened it read only. There is also no way to format the filesystem from inside MicroPython (or seemingly access it from mpremote)

Please, please, please reconsider having mandatory MSC on the RP2040 Connect. It is totally unreliable.

[mattytrentini]

What is CircuitPython doing differently then? I'm certain it would have been reported if there were MSC issues there...

Maybe try running CircuitPython on it and see how it behaves?

[robert-hh]

What is CircuitPython doing differently then?

Exclusive write access prevents at least corruption. The challenge is still to tell MicroPython if the PC updated the files. I've added a similar mechanism for the MIMXRT MSC support, but closed that PR a while ago, hoping to have that implemented in a Python code USB driver.

@scruss There is also no way to format the filesystem from inside MicroPython

You can do that using os.mkfs():

import os
import rp2
bdev = rp2.Flash()
os.VfsFat.mkfs(bdev)
fs = os.VfsFat(bdev)
os.mount(fs, "/")

[scruss]

Maybe try running CircuitPython on it and see how it behaves?

Just as dismal. I've loaded the CircuitPython UF2, and I can't keep the external filesystem stable on any machine I try it on.

[iabdalkader]

This port doesn't support a USB mode like the stm32 does (MSC+CDC etc..), so I can't think of an easy way to disable MSC right now. But it sounds like you may have a different issue, a hardware issue maybe ? Since even the exclusive access in CircuitPython doesn't help. FWIW I've never had any issues with MSC like that.

[scruss]

Even when I've unmounted the host MSC filesystem, I can't see any files on the RP2040 Connect:

mpremote devs
/dev/ttyACM0 501593006887891c 2341:025e MicroPython Board in FS mode

mpremote a0 ls
ls :
           0 nano2040/
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
UnicodeError: 

The nano2040 entry appears to be unreachable. But I can edit files using mpremote, and install persistent packages with mip

[andrewleech]

From the repl, what do you get with an os.listdir() ? Is there perhaps a file after the nano2040 folder that has unicode in the name that might be tripping up mpremote?

[scruss]

os.listdir() gives the same as mpremote:

>>> os.listdir()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeError: 

ilistdir('/') hints that there's a folder called nano2040, but it's unreachable:

>>> for i in os.ilistdir('/'):
...     print(i)
... 
('nano2040', 16384, 0, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeError: 

>>> os.listdir('nano2040')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] ENOENT

There's a filesystem there alright:

>>> os.statvfs('/')
(4096, 4096, 2042, 2038, 2038, 0, 0, 0, 0, 255)

I can create a file with write(), write to it, close it, read it back, stat() it: just not find it in the filesystem. I don't understand this at all.

This on v1.22.2

[robert-hh]

Just as dismal. I've loaded the CircuitPython UF2, and I can't keep the external filesystem stable on any machine I try it on.

There may be a hardware problem with that board. Otherwise I have no clue what it is. Lacking a board I cannot make own tests. And for just a short test and then staying in the drawers the board is too expensive.

You could try the most recent v1.23 preview, but I do not expect any changes. I assume that you already tried to erase the flash and start over.

[scruss]

After doing flash_nuke and installing 1.23.preview, I get this on soft reboot:

>>> 
MPY: soft reboot
Traceback (most recent call last):
  File "_boot_fat.py", line 12, in <module>
OSError: [Errno 19] ENODEV
MicroPython v1.23.0-preview.358.g8762fe8b4 on 2024-05-07; Arduino Nano RP2040 Connect with RP2040
Type "help()" for more information.

So _boot_fat.py looks to be missing from the Arduino Nano RP2040 Connect

[robert-hh]

That looks like progress, even if it may not seem so. The error is raised by _boot_fat.py and tells, that it did not find a FAT file system in flash. Once you get a REPL prompt, you can re-create the file system, using:

import os
import machine, rp2
bdev = rp2.Flash()
os.VfsFat.mkfs(bdev)
vfs = os.VfsFat(bdev)
os.mount(vfs, "/")

Note: _boot_fat.py is embedded into the firmware, so it cannot be missing.

[scruss]

Thanks, Robert - this ultimately fixed it. I don't know where the old corrupted flash image came from, but it's now booting and running reliably