question: reset device

[danielhrisca]

Hello,

I'm having trouble with an USB device and I don't know if I'm doing the correct sequence to reset it.

At some point during the operation we get a read timeout; the cleanup code call dispose

if self.device is not None:
    self.device.reset()
    usb.util.dispose_resources(self.device)

Next the device is created again, searching it by the serial number

# first loop to reset the device
for device in usb.core.find(find_all=True):
    try:
        if device.serial_number.strip().strip('\0').lower() == self.serial_number.lower():
            device.reset()
            usb.util.dispose_resources(device)
            break
        else:
            print(device.serial_number.strip().strip('\0').lower(), self.serial_number.lower())
    except:
        continue
else:
    raise Exception("Device with serial {} not found".format(self.serial_number))
    
# second loop to keep the handle
for device in usb.core.find(find_all=True):
    try:
        if device.serial_number.strip().strip('\0').lower() == self.serial_number.lower():
            self.device = device
            break
        else:
            print(device.serial_number.strip().strip('\0').lower(), self.serial_number.lower())
    except:
        continue
else:
    raise Exception("Device with serial {} not found".format(self.serial_number))

The init code works and we get the device handle, but any further write attempts end up in a protocol timeout with this traceback:

  File "lib\site-packages\pyxcp\master\errorhandler.py", line 398, in inner
  File "lib\site-packages\pyxcp\master\base.py", line 174, in connect
  File "lib\site-packages\pyxcp\transport\base.py", line 153, in request
  File "lib\site-packages\pyxcp\transport\usb_transport.py", line 147, in send
  File "lib\site-packages\usb\core.py", line 408, in write
  File "lib\site-packages\usb\core.py", line 984, in write
  File "lib\site-packages\usb\backend\libusb1.py", line 842, in bulk_write
  File "lib\site-packages\usb\backend\libusb1.py", line 938, in __write
  File "lib\site-packages\usb\backend\libusb1.py", line 602, in _check
usb.core.USBTimeoutError: [Errno 10060] Operation timed out

Do you have any suggestion about what I could try?

Thank you!

Edit

• pyusb version 1.1.1
• python 3.7.9 x64
• windows 10 x64
• libusb 1.0.24

[jonasmalacofilho]

[...] the correct sequence to reset it. At some point during the operation we get a read timeout; [...]

Is "during the operation" the call to the Device.reset? I'm confused because next you said that dispose_resources is called during cleanup, but the code you show wouldn't behave like that if reset triggered an exception.

[...] any further write attempts end up in a protocol timeout [...]

I see that the real code unconditionally calls set_configuration. This can cause a soft reset and in my experience can also lead to timeouts.

• PyUSB FAQ: How (not) to call set_configuration() on a device already configured with the selected configuration?
• libusb: Caveats: Configuration selection and handling

[danielhrisca]

Is "during the operation" the call to the Device.reset? I'm confused because next you said that dispose_resources is called during cleanup, but the code you show wouldn't behave like that if reset triggered an exception.

Compared to the "real code" I've added the reset calls in the connect and closeConnection methods, so the reset is done when connecting to the device (in the hope of bringing it out of a potential unusable state) and at the disconnect (again to not leave it in an unusable state)

I see that the real code unconditionally calls set_configuration. This can cause a soft reset and in my experience can also lead to timeouts.

This call has not caused problems so far, but I will never the less read the documentation that you have linked.

To add more details:

• the USB device is running an XCP server (slave device)
• at some point during the operation the device encounters an internal error and it gets stuck in a state were it continuously sends a service request command "Slave reset request"
• using the code changes mentioned above I was that the device HW reset is triggered

[danielhrisca]

The device in question had a custom control command that issued an internal FPGA reset. This had to be executed otherwise the device would not communicate as expected over the Pipe end points. So the generic usb device reset could not have helped.