thanks , it does not change the port..
well after some try and error I found that its way reliable if I connect as root!
not a big deal IMHO I can live with that.. ( $user is already a member of ‘dialout’ group BTW)
I have the feeling the problem is when I reboot/disconnect the BP it does not unmount its storage partition properly!
[39500.181630] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[39503.123568] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
firmware issue then?
In the meanwhile I will unmount this before I unplug etc..
I use a BP 6 so it’s slightly different but both my computers(debian13) and pis( basically Debian) seem to work. I’ve been using tio with the BP just because picocom connection string is a bit longer.
Tio has a good reconnect method and you just need to type tio /dev/ACM0.
it got a sensible default (115200) but in the buspirate case it doesnt matter. the BP only pretends to be a USB→Serial device and due to that the baudrate is ignored. the “send buffer” is where the firmware is recieving it already
Hi @xchris - I unaware of any issues with the current firmware under linux.
The firmware is cute about making the internal storage write only when you attach via a terminal. That requires the storage to detach and reattach. Could your system be choking on that?
yes I understand that is the procedure on those pico’s - and I have a handful of them that I can attach/detach without any storage corruption.
I used the BP for a while - on the firmware v1 , as it came - and I plugged/unplugged it without any issue , the issues started when I updated to the latest one, but now I know that I need to unmount the storage first before unplugging the BP, so far this works (and I can connect to it without sudo)
Following up on this to add some background, since @ian’s point about the detach/reattach lines up with what’s in the “USB Mass storage and local FATFS conflicts” thread, and I think it explains both symptoms @xchris is seeing, not just the FAT warning.
Modern desktop Linux (and Android) both auto-discover new storage volumes. On a typical Debian/Ubuntu/Fedora desktop, udisks2 (backing GNOME Files, KDE’s Dolphin, etc.) automatically tries to mount and index any new block device it sees, including the BP5’s internal flash. Android does the same via its MediaProvider service, which on first-ever mount of a new volume additionally creates a whole set of standard folders (DCIM, Music, Android, etc.) on it, not just indexing existing files. Both are “helpful” background behaviors most users never notice with a normal USB stick.
The BP5’s ownership handoff doesn’t account for this. Per the other thread, the switch to firmware-owned storage is triggered by tud_cdc_n_connected(0), i.e. the moment a terminal app opens the CDC port, and it performs a hard USB-level detach/reattach at that point, regardless of what the host OS happens to be doing with the storage volume at that exact moment. @henrygab pointed out there that there’s currently no delay/safety window if the host was actively writing when the terminal connects, which matches @xchris’s “Volume was not properly unmounted” message.
Why this might hit screen/minicom but not tio: if the detach/reattach affects the whole composite USB device (not just the MSC interface), the CDC serial device node can briefly disappear and re-enumerate too, possibly with a new device number. tio has built-in reconnect handling (Waiting for tty device..) specifically for this kind of situation, but screen and minicom just hold a file descriptor open and error out or hang when the underlying device vanishes mid-session. That would explain the “hit and miss” behavior @xchris described, without needing to assume a hardware or firmware defect.
Suggested quick test @xchris: try tio /dev/ttyACM0 instead of screen/minicom for a session or two, if the connection survives reboots/reconnects reliably there, it’d confirm this is a terminal-app-vs-USB-re-enumeration issue rather than something wrong with your BP.
Thank you so much for the extra detailed explanation.
Unfortunately we’re kind of stuck with this behavior to make the dual access (USB disk and Bus Pirate access) work. The alternative is something like the Android system (MIP?), but its not an open standard (patents I assume?) and I understand several OS don’t support it?
If the check if anything in flight/delay a bit would help I can implement that.
That makes total sense re: MTP, definitely not worth the platform-support headache just to fix this edge case.
A short “anything in flight, wait a bit” check before the detach/reattach sounds like a solid first line of defense, and would likely resolve this for most people without any other changes needed.
That said, in case the delay ends up not being fully reliable in practice (e.g. on slower/busier host systems where “briefly” isn’t brief enough), it might be worth keeping the config option to disable Mass Storage entirely I proposed a while back in mind as a fallback. For users like @xchris and myself who mainly use the terminal and don’t rely on host-side disk access day to day, that would remove the race condition completely rather than just narrowing the window, since there’d be nothing for the host to be “in flight” with in the first place. It’d also help Android users specifically: Android’s MediaProvider creates a whole set of standard folders (DCIM, Music, Android, etc.) the first time it sees a new volume, not just when you use it, so being able to turn off Mass Storage entirely would prevent Android from ever trying to claim and populate the BP5’s internal storage in the first place.
Both seem like good options to have, not an either/or, just flagging the second one as a good escape hatch if the first doesn’t fully solve it in practice. Thanks again for looking into this!
I formated the internal storage via the ‘format’ command (now it ID the storage name as “BUS_PIRATE5” as like “5000-xxxx”) I did some reboots (reboot command) and survived any corruption. but the storage is still corrupted
[25333.371334] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
when I disconnect it (unplug) without ejecting the storage first…
So ok, I can live by ejecting this before unplug, or better set an fstab rule like:
storage-off would help me, too when i use it as a flashrom adapter for a longer project and dont need the capability, too. saves me to close folder windows on connects (happens also on binmode leave when i need a regular SPI command to unfuck something mid-session)
For background, I owned the Microsoft Windows device drivers disk.sys, classpnp.sys, and cdrom.sys (over the course of about a decade), including the transition where Plug’n’Pray transitioned to Plug’n’Play. I was also indirectly involved with PTP and MTP, although only as a reviewer.
There is no way to avoid the “Volume was not properly unmounted”, if allowing it to be mounted R/W. The media is literally being surprise-removed. One of the first things many FS implementations do when opening FAT is to set the dirty bit. If the surprise removal occurs, that bit is going to stay set, so you’ll get the warning. @xchris – Does it mean anything got corrupted? No … just that the volume is suspect. Yes, this is annoying; See next items.
For linux, explicitly disabling automount for at least the buspirate MSC device is an excellent choice. (Thanks, @Joe !)
Windows should just work. If not, ensure the policy is set to “Quick Removal”, else you have to wait about 30 seconds after the last write, to be sure the FS cache was flushed to the device. Example instructions to find the setting … which you want to be “Quick Removal” (which was the default for me in Win11).
Joe is correct that implementing MTP is problematic for IoT (static allocation) devices. It requires keeping a database of identifiers that does not change unless/until the file contents change. Oh, and the volume ID must change and never be re-used. And each file’s identifier must persist, but never be re-used (e.g., same name with different contents must be different identifier). Some of the requirements are just not fun, and hard to implement safely without either a TRNG, or a battery-backed RTC and per-device unique ID. All that was done to allow the host to efficiently cache thumbnails, even when a device gets removed for a week between uses. And most hosts don’t cache things efficiently anyways. Oh, yeah … and hosts can only download the entire file at once, so if they don’t cache stuff, performance suffers. While there are a few options for linux, how many are cache-optimized? Likely none, resulting in terrible performance. And this is coming from someone who was a FAN of PTP and MTP. So, yeah … hard pass on implementing it. (And good luck finding one that doesn’t dynamically allocate memory all over the place … not really a great option for BP.)
Maybe someday I’ll implement MTP coherently, in C99, with only static allocations and a fancy technique to comply with the unique identifier requirements. But not today. <edit … I was half-joking; I don’t think it’s realistic to do so efficiently with only static allocations>
I’m also a Linux daily driver user. I use minicom pretty exclusively and occasionally end up with a BP that won’t connect as OP describes.
Yes, running the serial terminal as root works, but that’s kind of a sledgehammer. What cleans things up is to disconnect the BP, close the serial terminal and restart the udev sevice. In Ubuntu, that would be sudo systemctl restart udev.
I see @Joe’s udev rule and I think I’m going to use that - great idea! It’s easy enough to manually mount the volume when I need it.
As @henrygab points out, this is a thorny issue with multi-endpoint USB devices and the way things like minicom work.
I’ve gotten into the habit of not unplugging a BP when minicom (or other serial programs) are connected and rarely have issues. Usually it’s human error where I yank the wrong cable from the hub when working.