I/O Error on Windows 10

[h3rm1t-ms]

I was trying to get my GreatFET Ne set on Windows 10 but getting errors while doing so. I followed the steps mentioned in https://greatscottgadgets.github.io/greatfet-tutorials/windows.html .
Here are the scenarios:
Scenario-1:

1. Installed greatfet tools through PIP in Anaconda Python 2019.10(Python version 3.7.4), installed usb drivers (libusb-win32 (v1.2.6.0)) through zadig. However the command greatfet info gives the following error.

C:>C:>greatfet info
Exception ignored in: <function _AutoFinalizedObjectBase.del at 0x000001E873448438>
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\lib\site-packages\usb_objfinalizer.py", line 84, in del
self.finalize()
File "C:\ProgramData\Anaconda3\lib\site-packages\usb_objfinalizer.py", line 144, in finalize
self._finalizer()
File "C:\ProgramData\Anaconda3\lib\weakref.py", line 572, in call
return info.func(*info.args, **(info.kwargs or {}))
File "C:\ProgramData\Anaconda3\lib\site-packages\usb_objfinalizer.py", line 104, in _do_finalize_object_ref
obj._do_finalize_object()
File "C:\ProgramData\Anaconda3\lib\site-packages\usb_objfinalizer.py", line 71, in _do_finalize_object
self._finalize_object()
File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 604, in _finalize_object
_lib.libusb_unref_device(self.devid)
OSError: exception: access violation writing 0x0000000000000024
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\Scripts\greatfet_info-script.py", line 11, in
load_entry_point('GreatFET==2019.9.1', 'console_scripts', 'greatfet_info')()
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\commands\greatfet_info.py", line 94, in main
devices = GreatFET(find_all=True)
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\greatfet.py", line 31, in GreatFET
return GreatFETBoard.autodetect_all(**board_identifiers)
File "C:\ProgramData\Anaconda3\lib\site-packages\pygreat\board.py", line 105, in autodetect_all
subclass_devices = subclass.all_accepted_devices(**device_identifiers)
File "C:\ProgramData\Anaconda3\lib\site-packages\pygreat\board.py", line 151, in all_accepted_devices
if cls.accepts_connected_device(**identifiers):
File "C:\ProgramData\Anaconda3\lib\site-packages\pygreat\board.py", line 179, in accepts_connected_device
raise e
File "C:\ProgramData\Anaconda3\lib\site-packages\pygreat\board.py", line 168, in accepts_connected_device
potential_device = cls(**device_identifiers)
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\boards\legacy.py", line 76, in init
if self.HANDLED_BOARD_IDS and (self.board_id() not in self.HANDLED_BOARD_IDS):
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\boards\legacy.py", line 112, in board_id
response = self.vendor_request_in(self.REQUEST_READ_BOARD_ID, length=1)
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\boards\legacy.py", line 236, in vendor_request_in
value=value, index=index, timeout=timeout)
File "C:\ProgramData\Anaconda3\lib\site-packages\greatfet\boards\legacy.py", line 223, in _vendor_request
request, value, index, length_or_data, timeout)
File "C:\ProgramData\Anaconda3\lib\site-packages\usb\core.py", line 1043, in ctrl_transfer
self.__get_timeout(timeout))
File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 883, in ctrl_transfer
timeout))
File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 5] Input/Output Error

2. Also restarting the laptop somehow replaces the libusb drivers with winusb (WinUSB (v6.1.7600.16385)) drivers.
3. Opening Command prompt as administrator as using the above command still gives the same error.

Scenario-2:

1. Did a clean install of python 3.8 (64 bit) on a new system with Windows 10.
2. Installed libusb drivers through zadig.
3. Installed greatefet through pip.
4. The greatfet info command now gives the following error message.

C:>greatfet info
Traceback (most recent call last):
File "C:\Program Files\Python38\Scripts\greatfet_info-script.py", line 11, in
load_entry_point('GreatFET==2019.5.1', 'console_scripts', 'greatfet_info')()
File "c:\program files\python38\lib\site-packages\greatfet-2019.5.1-py3.8.egg\greatfet\commands\greatfet_info.py", line 125, in main
devices = GreatFET(find_all=True)
File "c:\program files\python38\lib\site-packages\greatfet-2019.5.1-py3.8.egg\greatfet\greatfet.py", line 31, in GreatFET
return GreatFETBoard.autodetect_all(**board_identifiers)
File "c:\program files\python38\lib\site-packages\pygreat\board.py", line 105, in autodetect_all
subclass_devices = subclass.all_accepted_devices(**device_identifiers)
File "c:\program files\python38\lib\site-packages\pygreat\board.py", line 151, in all_accepted_devices
if cls.accepts_connected_device(**identifiers):
File "c:\program files\python38\lib\site-packages\pygreat\board.py", line 168, in accepts_connected_device
potential_device = cls(**device_identifiers)
File "c:\program files\python38\lib\site-packages\greatfet-2019.5.1-py3.8.egg\greatfet\board.py", line 86, in init
super(GreatFETBoard, self).init(*args, **kwargs)
File "c:\program files\python38\lib\site-packages\pygreat\board.py", line 245, in init
if self.HANDLED_BOARD_IDS and (self.board_id() not in self.HANDLED_BOARD_IDS):
File "c:\program files\python38\lib\site-packages\pygreat\board.py", line 274, in board_id
return self.apis.core.read_board_id()
File "c:\program files\python38\lib\site-packages\pygreat\comms.py", line 1106, in method
return self.execute_command(verb_number, in_format, out_format, name=name, class_name=class_name,
File "c:\program files\python38\lib\site-packages\pygreat\comms.py", line 1261, in execute_command
return self.comms_backend.execute_command(self.CLASS_NUMBER, verb, in_format,
File "c:\program files\python38\lib\site-packages\pygreat\comms.py", line 768, in execute_command
raw_result = self.execute_raw_command(class_number, verb, payload, timeout,
File "c:\program files\python38\lib\site-packages\pygreat\comms_backends\usb.py", line 317, in execute_raw_command
self._hold_libgreat_interface()
File "c:\program files\python38\lib\site-packages\pygreat\comms_backends\usb.py", line 152, in _hold_libgreat_interface
raise IOError("timed out trying to claim access to a libgreat device!")
OSError: timed out trying to claim access to a libgreat device!
3.

[ktemkin]

Sorry for the lack of response on this -- this must have slipped through the cracks. Assigning this to the engineer who handles user support; hopefully he'll get back to you in the next few days. :)

[grvvy]

Sorry for the (continued) lack of response. Has this been resolved?

[Microsparky]

I am having the same issue (Scenario-2) on a Windows 10 Enterprise machine. I'm not sure if its related but on that machine Device Manager detects the GreatFET device as two interfaces: GreatFET (Interface 0) and GreatFET (Interface 1). On another Windows 10 machine I had no issues but Device Manager only detected the GreatFET as a single composite device.

Edit: @GravesJake

[BJamin99]

I am having the same issue (Scenario-2) on a Windows 10 Pro machine. I am using Python 3.9.2. Also, my GreatFET device shows up as two interfaces: GreatFET (Interface 0) and GreatFET (Interface 1). Using libusb-win32 or libusbk has the same issue.

[BJamin99]

I've found a potential solution, although I'm not sure if it works in all cases, or just with the little that I've tested. As can be seen in Scenario-2, the issue seems to be when trying to claim the USB interface. This uses the pyusb claim_device method. Looking at the documentation for this method:

        PyUSB users normally do not have to worry about interface claiming,
        as the library takes care of it automatically. But there are situations
        where you need deterministic interface claiming. For these uncommon
        cases, you can use claim_interface.

Quite possibly GreatFET could fall into these uncommon cases, but for the testing I'm doing with I2C this does not appear to be necessary. At least this an issue on Windows. I can use GreatFET on Linux without encountering this issue. If it is not necessary for any code to grab the interface on any platform, my "fix" would be to comment out/remove line 317 in libgreat\host\pygreat\comms_backends\usb.py (may also remove the release in the "Finally" block too?):

    # Grab the libgreat interface, to ensure out libgreat transactions are atomic.
    #self._hold_libgreat_interface()

But since this doesn't appear to affect Linux, a more targetted approach modifies the _hold_libgreat_interface method in libgreat\host\pygreat\comms_backends\usb.py, specifically the exception handler. Currently the exception handler treats a "None" errno the same as EBUSY and EACCES. The workaround is instead to just return if the errno is None:

            # If we have EBUSY (linux) or EACCES (macos) try again.
            if e.errno in (errno.EBUSY, errno.EACCES):
                pass
            # If we have None (windows), just return 
            elif e.errno in (None, ):
                return
            else:
                raise

At least for my limited use case this works and limits the scope of the actual change. As a note, I'm using libusbK 3.0.7.0 for both GreatFET interfaces that show up.

[BJamin99]

Had a look at this again. Messing around with zadig, managed to get it to work without having to modify the source as I described above. In zadig (2.7) I set the driver for "GreatFET (Interface 0)" to "libusbK (v3.1.0.0)" and the driver for "GreatFET (Interface 1)" to "WinUSB (v6.1.7600.16385)". It seems like if both are set to libusbK, or if only "GreatFET (Interface 1)" is set to libusbK, then the claim access error is thrown. If just "GreatFET (Interface 0)" is set to libusbK, then it works. It seems that "GreatFET (Interface 1)" is the issue and setting it to not use libusbK hides it from pyusb.

[BJamin99]

OK, that works for a few functions, but trying to use the logic analyzer found that this is not the complete solution. Looks like somehow the Windows composite driver (usbccgp) took over the "device" and split it into two interfaces. Interface 0 has 0 endpoints, which works fine for switching the LEDs, doing GPIO, and i2c for example, but doesn't work for the logic analyzer, which is looking to use endpoint 1. Endpoint 1 is in the Interface 1 device. To fix this, in Zadig, under options, unselect "Ignore Hubs or Composite Parents" ("List All Devices" should be selected). Then the "GreatFET (Composite Parent)" will be available in the drop-down box. Select that (it should have usbccgp as its current driver). Replace that driver with libusbK. It will warn about doing this. After doing this change there is just one device for GreatFET and the logic analyzer can find its endpoint.

[straithe]

@h3rm1t-ms are you still experiencing this issue?

[straithe]

I'm going to close this as there hasn't been a response in a while, but please re-open this issue or open a new one if you still need assistance.

[lswind59]

The comments from BJamin99 was fundamental to resolve the same problem for me (Pulseview don't see GreatFET one board). I reopen the issue to thanks BJamin99 and to "reinforce" google findings of this solution.

[antoinevg]

Tx @BJamin99 !

Fixed in: greatscottgadgets/libgreat#38

[antoinevg]

Hopefully, this is fixed in: https://github.com/greatscottgadgets/greatfet/releases/tag/v2024.0.0

Please re-open if this is not the case!