Freek Dijkstra

Here is a better lsusb output, run on both Linux and macOS. Indeed similar. Both when the device is in normal mode and DFU mode. As you can see, if has a different USB product ID in DFU mode. To make it a bit frustrating for me, the device switches back from DFU mode to normal mode in 7 or 10 seconds. So it gets a different Device ID on the bus. That's why I used sudo instead of chown/chmod on /dev/bus/usb/xxx/yyy -- the yyy changed too often (whyyyy indeed) For whatever reason, dfu-util fails on...

Here is a better lsusb output, run on both Linux and macOS. Indeed similar. Both when the device is in normal mode and DFU mode. As you can see, if has a different USB product ID in DFU mode. To make it a bit frustrating for me, the device switches back from DFU mode to normal mode in 7 or 10 seconds. So it gets a different Device ID on the bus. That's why I used sudo instead of chown/chmod on /dev/bus/usb/xxx/yyy -- the yyy changed too often (whyyyy indeed) For whatever reason, dfu-util fails on...

Love to help, but lsusb on mac and Linux are not really cooperating today. Here is the relevant line for the device-logs: pysensense-v1: - Pycom pysense extension board - DFU implementation: Closed source. - https://docs.pycom.io/updatefirmware/expansionboard/ - Tested by Freek Dijkstra For some reason, lsusb seems a wrapper around system_profiler, and -v just returns the output of system_profiler. So included the output of pyusb, which seems more in line with other reports. As for testing on Linux,...

FYI, the issue seem to have been pinpointed to a bug in libusb, and a fix is available. We now have to wait till the fix is merged into libusb, and perhaps till a new release of libusb is made. @tormod I can imagine a workaround in dfu-util (simply ignore the return value if it is 32), but prefer that libusb releases a new version soon.

Note however that I actually don't know what microcontroller I'm talking to. Pycom provides both developer boards (based on an ESP32) as well as extension board (with additional sensors), where these developer boards can be plugged in. Some of these extension boards can be firmware updated as well. That's the situation I'm describing. So these extension boards have a microcontroller as well. Unfortunately, while Pycom is clear on the specs for the microcontroller on their development board (the ESP32),...

@notthetup, @gijsio: Could you check my findings? That this issue occurs with a Prolific chipset, regardless of macOS version? I wonder if the issue reported by Gijs is different from the issue reported by the OP, since the OP mentioned a Tomu, and I am not convinced this has a Prolofic driver. I can't find it for sure, but a Silab CP2102 makes more sense on the Tomu, since the ARM is from Silab, and there seems little space for another chip. What do you get with the Python script that @tormod p...

FYI, see https://github.com/libusb/libusb/issues/838 A preliminary conclusion: I think that the issue is triggered by devices that have a Prolific PL2303 controller. That would include nearly all $10 USB-to-serial cables. The issue already occurs when such a cable is plugged in the USB port (no need to connect the other end to anything else). MacOS version does not seem relevant. Thanks for guiding me the right direction. What do you think of the suggestion made by mcuee, "A simple fix will be changing...

FYI, I can replicate it with pyusb, and adding a delay in front of the call does not make any difference. I very much like to test another device, but as said, this is the first time I use dfu-util. This may be a silly question, but I don't know which devices I can use. So I tried a few the following code on a few different devices. TLDR: I no longer get a pipe error, but an access denied error. dev = usb.core.find(idVendor = 0x04D8, idProduct=0xF014) print(dev) dev.set_configuration(1) dev.set_interface_altsetting(0,...