UPDATE: This problem has been fixed in macOs Ventura release 13.1.
It is still the case that UF2 uploading does not work on nRF52840 boards that use an older UF2 bootloader (versions 0.6.2 and newer work). On those boards, the bootloader appears to fail quickly, allowing no time to copy the UF2. The bootloader can be updated by following the directions here. Otherwise, on these nRF52840 boards, including the Adafruit Circuit Playground Bluefruit, the Feather nRF52840, and the ItsyBitsy nRF52840, the only way to load a UF2 file is to use a non-Ventura computer.
It is also still true that copying .hex files larger than 1MB does not work (e.g., on the micro:bit). See https://github.com/ARMmbed/DAPLink/issues/982 for workarounds and further investigation.
The new macOS release 13.0 (Ventura), has trouble uploading files to “fake” USB drives that are used for firmware updates on microcontroller boards. These fake USB drives are presented by UF2 bootloaders and also ARMmbed DAPlink bootloaders. UF2 bootloaders take .uf2 files and are used on Adafruit boards, Raspberry Pi Pico boards, and many other manufacturer’s boards. ARMmbed DAPlink takes .hex files and is used on the micro:bit and other boards.
The problem is in the macOS Finder. Dragging a firmware file to the drive produces “error code 100093”. This error apparently occurs because the Finder is trying to copy extended attributes to the drive.
On some boards, you can work around the problem by copying the file using the command line in Terminal. Use the cp -X command (capital X). For example, to upload a Circuitpython UF2 file to a Raspberry Pi Pico, you would do:
% cp -X adafruit-circuitpython-raspberry_pi_pico-en_US-7.3.3.uf2 /Volumes/RPI-RP2
However, this workaround does not work on nRF52840 boards that use an older UF2 bootloader (versions 0.6.2 and newer work). On those boards, the bootloader appears to fail quickly. Copying a UF2 file does not work, which is indicated by the UF2 filename appearing in the BOOT drive. The bootloader can be updated by following the directions here. Otherwise, on these nRF52840 boards, including the Adafruit Circuit Playground Bluefruit, the Feather nRF52840, and the ItsyBitsy nRF52840, the only way to load a UF2 file is to use a non-Ventura computer.
The Raspberry Pi folks have posted a very thorough writeup of this problem on their blog: The Ventura Problem.
For further information and similar workarounds, see:
- https://github.com/raspberrypi/pico-sdk/issues/1081
- https://github.com/orgs/micropython/discussions/9794
- https://support.microbit.org/support/solutions/articles/19000139995-finder-error-100093-when-using-drag-and-drop-to-transfer-a-micro-bit-hex-file
- https://github.com/ARMmbed/DAPLink/issues/982
This problem has been reported to Apple. If it affects your work, we encourage you to report it too , using the macOS Feedback Assistant tool. There are complete instructions for using the tool in the Raspberry Pi blog post linked above. Mention the existing Feedback numbers in your report to help Apple link these reports together: FB11725030 (Raspberry Pi’s report), and FB11727161 (Adafruit’s).
This problem does not affect use of the CIRCUITPY drive once CircuitPython is running, or similar drives such as MicroPython’s PYFLASH drive. It only affects fake drives like the UF2 bootloader drives.
Update: For non-UF2 files, cp -X may fail if the file is larger than 1MB, according to a comment in the ARMmed/DAPlink issue above . This is because macOS may write the data non-sequentially. In that case use the rsync command instead. This shouldn’t be a problem for UF2 files as the file format is designed to avoid such problems: each block stores its own address as well as the total number of blocks so non-sequential writes don’t matter.