macOS 13 Ventura finder drag&drop flashing fails

[microbit-carlos]

Workaround

Information about the current workarounds can be found in this article: https://support.microbit.org/support/solutions/articles/19000139995-finder-error-100093-when-using-drag-and-drop-to-transfer-a-micro-bit-hex-file

Issue Description

Tested in a MacBook Pro 13 2018 x86 upgraded to macOS 13 Ventura (but some of these tests have also been carried out in an Arm Mac with the same results).

Using micro:bit V1 with DAPLink 0249, and V2.00 with DAPLink 0255.

• Finder drag&drop flashing of Intel or Universal hex files doesn't work
  • with: The operation can’t be completed because an unexpected error occurred (error code 100093).
  
• A not very large Intel Hex copy via terminal cp command works
  • MICROBIT.hex.zip
• But a larger Intel Hex doesn't work
  • intel-v2.hex.zip
  • It takes longer than usual for the cp command to return/end and then DAPLink shows the 504 error, which indicates some kind of "time out".

From https://krypted.com/lists/comprehensive-list-of-mac-os-x-error-codes/ , the error code 100093 seems to be kPOSIXErrorENOATTR for Attribute not found.

Using the cp command to copy a hex file into the MSD drive sometimes prints the following message:

cp: hex_file.hex: could not copy extended attributes to /Volumes/MICROBIT/hex_file.hex: Attribute not found

So this point to perhaps some fs attributes or metadata being written or read causing this issue.

[jaustin]

Can confirm on an M1 mac running macOS Version 13.0 (22A380)
In finder I immediately get :

"The operation can’t be completed because an unexpected error occurred (error code 100093)."

I then get a long delay (during which the old program keeps running), then after some time, the device unmounts, returns with a FAIL.txt and micro:bit is showing a 504 error.

Contents of Fail.txt

error: The transfer timed out.
type: transient, user

Workarounds for micro:bit

(for any micro:bit users finding this bug through Google, here are some workarounds:)

https://support.microbit.org/support/solutions/articles/19000139995-finder-error-100093-when-using-drag-and-drop-to-transfer-a-micro-bit-hex-file

• web USB still works in Chrome from the MakeCode or Python editors - see the micro:bit web USB guide
• You can use rsync at the terminal instead of the system copy application to copy hex files to the board (works with intel hex and universal hex). For examples

rsync ~/Downloads/microbit-smile.hex /Volumes/MICROBIT/

[microbit-carlos]

DAPLink MSD drive is a "fake" volume, which ignores most of the file system operations other than file writes, as it can then flash a target microcontroller if a .hex or .bin file are copied into the DAPLink drive.

This is a common mode of operation for tools in this category. I've tried the following and the issue is also present on these products/tools/platforms:

• RP2040 ROM bootloader: Cannot drag a UF2 to RPI-RP2 on macOS Ventura raspberrypi/pico-sdk#1081
• J-Link running on the interface chip from Nordic nRF52840-DK board
• J-Link firmware running on a micro:bit interface chip
• OpenSDA running on a FRDM-KL27Z board
• nRF52 UF2 bootloader running on the target nRF52840 MCU in a Nordic nRF52840-DK board

I haven't personally tested these, but these report from other platforms have the same issue:

• Adafruit's UF2 bootloader: macOS 13.0 (Ventura) Finder gives error when uploading UF2 files adafruit/uf2-samdx1#193
• MicroPython: FYI - Deploying .uf2/.hex firmware via mass storage broken on macOS Ventura. micropython/micropython#9794

[microbit-carlos]

Some additional data captured by @martinwork:

My tests were with V2.21 or V1.3B attached to a USB A port, I get 504 for any file dragged to the MICROBIT drive, and the mac log contains

UVFSService LFSAD: loadADHeader: magic is wrong: 0, 0, 0
DesktopServicesHelper TCFURLInfo:TranslateRawPOSIXError 93 -> 100093

System logs captured while connecting micro:bit: connect221.txt, connect13B.txt

I experimented with cp in the terminal, and see

cp: microbit-testq.hex: could not copy extended attributes to /Volumes/MICROBIT/microbit-testq.hex: Attribute not found

cp shows the message above, does some flashing (perhaps not enough) and micro:bit eventually shows 504. cp -X does the same, but without the message. I used xattr -c the clear the extended attributes for a file. With that file, both cp and cp -X do the same with no message and trigger error 504.

Here's a log from macOS Catalina, for connecting a V2.21. I edited out a lot of messages, most of which seemed to be informing all interested parties of the new disc. catalina221.txt

[martinwork]

Thanks @microbit-carlos. I was trying to figure out which bits of what I saw were still useful after the new info from @jaustin and yourself!

[microbit-carlos]

No problem, thanks for capturing the data!

I've got a couple of USB wireshark captures as well, haven't had a chance to look into them yet, but leaving here in case somebody wants to give it a go:

• cp-waitforunmount-remount.pcapng.zip
  • This is running a cp intel-v2.hex /Volumes/MICROBIT, after about 12 seconds it doesn't transfer any more file data.
  • Usually at this point DAPLink is meant to unmount and remount the MICROBIT drive, but it doesn't do that until the end of the capture around the 30 seconds mark more or less.
  • This flash ends in a 504 error
• rsync.pcapng.zip
  • This is running a rsync intel-v2.hex /Volumes/MICROBIT, with a successful flash.
• drag-n-drop-only.pcapng.zip
  • This is using finder to drag and drop a hex file into the MICROBIT drive, so about 6 seconds of data.
  • I suspect the interesting bits will be right in the middle, as most of the time in the capture is me dragging the file on macOS and then navigating to the wireshark window to stop the capture

The micro:bit USB address would be 226.x.x, so you can use the usb.src matches "226" filter to see only the relevant data.

[manpowre]

I just found a solution atleast temporarily, also theres a new ventura setting Settings > Privacy & Security > Allow accessories to connect. I chose always on it. annoying with this when connecting peripherals and OS constantly bug about connection.
cp -X blink.uf2 /Volumes/RPI-RP2

[microbit-carlos]

You should be able to use a terminal and the cp -X command, or rsync.
More info for the RP2040 workaround here: raspberrypi/pico-sdk#1081 (comment)

[jaustin]

Here's the micro:bit knowledge base workaround article. https://support.microbit.org/support/solutions/articles/19000139995-finder-error-100093-when-using-drag-and-drop-to-transfer-a-micro-bit-hex-file

I'm about to add a section explaining how administrators of managed Apple devices can delay updates, too.

[aallan]

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

[jaustin]

Similar to @aallan's workaround in raspberrypi/pico-sdk#1081, I've been using a short automator script for micro:bit work - not at all sanitised for arbitrary use, but is safe enough for people to use themselves in their own trusted environment. It gives you an app you can drop a hex/UF2 file onto. Works nicely on the dock as a drop target...

Create an Automator project that's an "Application", then configure it like this screenshot (use /Volumes/MICROBIT/ for a micro:bit device or /Volumes/MBED for older mbed devices)

(For RP2040 devices I think you'd want the following but I haven't got one to hand right now to test...)

[willlordarm]

Platform: Apple Macbook Pro M1, MacOS 13 (22A380)

Tested drag and drop with LPC1768 ('Mbed board') and NXP K64F. LPC1768 fails completely. K64F gives me the same error @jaustin reported - The operation can’t be completed because an unexpected error occurred (error code 100093). - but the binary appears to be flashed correctly to the board.