From MacOS Catalina Unable to update Pytrack firmware | dfu-util: Cannot set alt interface zero

[askpatrickw]

Host is MacBook Air running Catalina PyCom: GPY & Pytrack

Firmware from Repl: (sysname='GPy', nodename='GPy', release='1.18.1.r2', version='v1.8.6-849-f652205 on 2018-10-18', machine='GPy with ESP32')

I ran the following command to check the boot state of the pytrack and then update the firmware: lsusb && dfu-util -D pytrack_0.0.8.dfu

I got the following output and the

Bus 020 Device 001: ID 04d8:f014 Microchip Technology, Inc. 
Bus 128 Device 004: ID 05ac:027a Apple, Inc. 
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 04d8
Match product ID from file: f014
Opening DFU capable USB device...
ID 04d8:f014
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
dfu-util: Cannot set alt interface zero

I've tried this with the GPY mounted. With it not mounted. Same result.

Others are reporting this in the forum as well with no response. If the steps are wrong on the site, happy to test new ones. tx!

[fer112233]

Same problem here

[dhavalhparikh]

Hi! Was anyone able to figure this out? I'm facing the same issue.

[dhavalhparikh]

@askpatrickw Hi! were you able to figure out a solution for this? I don't have access to a windows system so I'm also stuck on this issue..

[dhavalhparikh]

@Xykon @catalinio: Just tagging you for more visibility! I'm trying out the wiPy + pyTrack as a potential viable solution for one my company's products but I cannot resolve this issue and cannot try out any of the pyTrack examples. Could you please suggest what should be done here?

Thank you!

[catalinio]

hi,

We are aware of this problem, on MacOS due to a security update the dfu-util update is stuck. I never saw it happen on Windows/Linux/Raspi OS. Afik, Pytrack/Pysense/Expansion v3.1 boards have, from factory, the latest firmware, so they don't need updating. You could try in System Preferences/Security&Privacy/Privacy a few things:

1. Developer Tools -> add Terminal
2. Full Disk Access -> add sh/Terminal, or even dfu-util itself Additionally, reinstalling dfu-util, or starting it as sudo could be some options.

thanks, Catalin

[dhavalhparikh]

Hi @catalinio Thanks for getting back to me on this. I'll try it out and see if it works. Otherwise, I'll just use a RPi to flash it!

Thanks, Dhaval

[dhavalhparikh]

Hi @catalinio Some updates: MacOS wasn't able to upgrade the firmware so I used my RPi and it worked without any issues. My pyTrack wasn't shipped with the latest fw. When I tried to run the examples, it gave me a version error. That's why I had to update them.

Thank you, Dhaval

[macfreek]

I was planning a project with my PyTrack v1.0 that I never used before, but can't even get the example code to work. When I try, I get the following exception:

ValueError: Firmware out of date

Which was raised in lib/pycoproc.py

I was able to upgrade the firmware of my FiPy to 1.20.3.b0, but can't update the PyTrack firmware. When I try, I get the dreaded dfu-util: Cannot set alt interface zero. (Running macOS 10.14.6, so the error also occurs on Mojave, not just Catalina = macOS 10.15).

Is there any way to proceed?

[macfreek]

Hi @catalinio ,

In April you wrote:

Afik, Pytrack/Pysense/Expansion v3.1 boards have, from factory, the latest firmware, so they don't need updating.

My board had firmware version 1, and the example code requires version 6. (latest is version 8). So I fear this statement is not entirely true for earlier purchased boards.

Also, you wrote:

We are aware of this problem, on MacOS due to a security update the dfu-util update is stuck.

Can you elaborate a bit here?

I kind of assumed that Pycom would have reported this bug upstream, but the only mention at https://sourceforge.net/p/dfu-util/ I found was in https://sourceforge.net/p/dfu-util/tickets/86/. Perhaps I overlooked things, since that bug only reports the Cannot set alt interface zero error in December, while it was discussed here in April.

Could you point me to the right upstream bug, or -if this is the right upstream bug after all- provide the dfu-util maintainers with some background information, so they might fix it, or at least help the libusb maintainers fix it? Note that the bug at dfu-util is currently marked with needsinfo, and a security update is not mentioned.

[ricpan]

I'm on Big Sur and I'm getting this error:

dfu-util -D expansion31_0.0.11.dfu dfu-util 0.10

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2020 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 04d8 Match product ID from file: ef99 Opening DFU capable USB device... ID 04d8:ef99 Run-time device DFU version 0100 Claiming USB DFU Runtime Interface... dfu-util: Cannot set alt interface zero: LIBUSB_ERROR_OTHER

Any suggestions? Thank you.

[tormodvolden]

That the issue appeared after security upgrades seems anecdotal to me. Are you sure it was not after an upgrade of libusb past 1.0.22? This would fit with other observations in https://sourceforge.net/p/dfu-util/tickets/86/ . This can be tested by building the old libusb releases (although I don't know if 1.0.22 still works on very latest macOS).

Please run dfu-util (0.10) with the -v -v -v option to see what libusb is doing "under the hood".

[macfreek]

The issue is not related to macOS Catalina.

The issue was pinpointed to a bug in libusb that has been present in libusb versions 1.0.23 and 1.024 in the macOS-specific code. A fix is available.

We now have to wait till the fix is merged into libusb, and hopefully a new release of libusb is made.

In te mean time: the workaround is to downgrade libusb to version 1.0.22, or use a different operating system.

(@catalinio, @gijsio: could you update the title of this bug accordingly?)

[gijsio]

Thanks a lot Freek! I will attach the script I use on macOS to downgrade libusb to 1.0.22 here (Remove the .txt extension at the end). Anyone can use the following in the terminal to downgrade

cd to location of libusb.rb
brew unlink libusb
brew install libusb.rb
brew info libusb

The last command should return something like this, where the star (*) indicates the linked version.

libusb: stable 1.0.24 (bottled), HEAD
Library for USB device access
https://libusb.info/
/usr/local/Cellar/libusb/1.0.22 (29 files, 508KB) *
  Poured from bottle on 2020-12-28 at 14:44:03
/usr/local/Cellar/libusb/1.0.24 (22 files, 516.4KB)
  Poured from bottle on 2020-12-18 at 13:22:31
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libusb.rb
License: LGPL-2.1-or-later

(unfortunately I cannot change the title) libusb.rb.txt

[macfreek]

FYI, the fix was just merged to libusb. It will probably take a while before it trickles down in a new release of libusb and subsequently distirbutions of dfu-util. The fix is scheduled to be in libusb 1.0.25 release.

Thanks a lot Freek!

Hi @gijsio, @catalinio: you're welcome, but the real credit should go to @tormodvolden, since he spend a lot of his time maintaining dfu-util, and helping me chase this bug. I have some benefit (I can further tinker with my PyTrack and PySense), while he is (and the libusb maintainers are) doing it voluntarily.

That said, I did encounter another issue with a DFU upgrade the pysense on Linux. Unfortunately, I decided not to pursue that issue. (But will tinker with the PyTrack, my original intention). Do you think there is a possibilty you can help @tormodvolden chase the questions he had? Either by running a test on his request, or providing him with an extension board, so he can test for himself?

[wang70880]

I run the similar issue on Raspberry Pi 4, which runs Ubuntu 20.04 on it.

My device is ATUSB bought from sysmocom, which uses dfu-util 0.7 to write the flash. After installing dfu-util 0.7, I run the following commands to flash atusb firmware into it.

$ sudo dfu-util -l

dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
 Found Runtime: [20b7:1540] devnum=0, cfg=1, intf=1, alt=0, name="UNDEFINED"

$ sudo dfu-util -v -D ./atusb.dfu

dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Opening DFU capable USB device... ID 20b7:1540
Did not find cached descriptor
WARNING: Can not find cached DFU functional descriptor
Warning: Assuming DFU version 1.0
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...

Cannot set alt interface zero

Any idea or comment? I will appreciate that!

[macfreek]

Hi @wang70880 - the bug you mostly likely encountered was chased and resolved in Januari 2021. dfu-util version 0.7 was published in 2012. Unfortunately, libusb 1.0.25 (which contains the fix) has not been released yet.

So as noted above, your options are:

1. use dfu-util on a platform that never never affected by this bug (Linux of Windows)
2. download and compile both libusb and dfu-util yourself. Follow the links for some guidance.
3. download an older version (1.0.22) of libusb. See for example the homebrew script from gijsio above.