FYI - Deploying .uf2/.hex firmware via mass storage broken on macOS Ventura.

[jimmo]

Apple appear to have implemented a change in "Ventura" to the way extended attributes are written which is causing it to fail on devices that present a "virtual" USB Mass Storage device.

This affects:

• Deploying a .uf2 file (e.g. to Raspberry Pi Pico and other RP2040-based devices).
• Deploying a .hex file (e.g. to micro:bit, or other DAPLink / ST-Link based devices)
• Copying files (e.g. .py, .mpy) to Pyboard v1.x and D and other STM32 devices that present the MicroPython filesystem over USB mass storage. (Also a small number of other non-STM32 boards such as the Arduino Nano Connect). (Edit: see below)

Note that tools like mpremote, Thonny, rshell, etc should be unaffected as they do not use USB Mass Storage.

For more info see:

• Cannot drag a UF2 to RPI-RP2 on macOS Ventura raspberrypi/pico-sdk#1081
• macOS 13 Ventura finder drag&drop flashing fails ARMmbed/DAPLink#982

I understand the workarounds for now are:

• Use Terminal and copy the .uf2 or .hex file using cp -X file.py /Volumes/.../
• Use picotool to deploy the .uf2 firmware to a Pico

I don't have a Mac so if people have specific advice or suggestions please let us know below!

[dpgeorge]

From my understanding of this issue, devices that expose a read/write block device over USB MSC (eg pyboard v1.x, pyboard-D) are not affected. But I have yet to confirm this.

[dhalbert]

I have tested this on Ventura 13.0 with a CircuitPython board. As described, dragging a file in the Finder to the UF2 "fake" drive fail with 100093, but dragging to the CIRCUITPY drive seems to work fine.

[jimmo]

Thanks -- I did wonder this (because surely the extended metadata is still a filesystem write and then would read back successfully) but was having a hard time figuring out from the reports on Twitter and couldn't confirm myself. I've updated the title/description for this post.

[aallan]

We've now written this up as a blog post, https://www.raspberrypi.com/news/the-ventura-problem/.

[jimmo]

Thanks @aallan -- Did you see the above note from Damien & Dan? Contrary to what I said on Twitter (based on my misunderstanding of what I had read), it sounds like the CircuitPython/MicroPython use case isn't affected, so I think this part should be removed from the blog post please.

But it’s also going to affect copying files to Pyboard other STM32 devices that present the MicroPython filesystem over USB mass storage, in addition to a small number of other non-STM32 boards such as the Arduino Nano Connect.

Hope you get a speedy resolution from Apple!

[aallan]

Did you see the above note from Damien & Dan?

Yup. Post has been updated.

[lurch]

This has now been fixed (for UF2 files at least) in the latest Ventura update - see https://www.raspberrypi.com/news/the-ventura-problem/

[aallan]

Drag-and-drop of UF2 files for Raspberry Pi Pico and other RP2040-based boards has been fixed as of macOS Ventura 13.1. The fix does not resolve the issue where .hex files >1MB fail to write as file blocks are still out of order.