How Can an Application recover from USB detatchment?

[Todd]

We have an application that continuously receives data from 16 USB full speed devices. Every few days, one of the application's USB handles times out during a USB operation.  I captured the event with a TotalPhase Beagle.  The OS starts asking one of the hubs for status and then ends up resetting and enumerating the hub.

My question is, how should an application recover from this?  The application uses Borland C++.  The device hardware uses the Cypress EzUSB FX2 IC.  The  host OS is Windows 7.  I'm not an expert yet on Borland or USB but I need to know a direction to dig in and approach the problem.

Should the application be listening somehow to the OS to see that a USB handle has gone stale and the application needs to ask for a new handle?  Does the OS try to 'fix' the USB handle after it gets the USB device back on line?

(We have several systems and they all behave the same way.)

I would greatly appreciate any advice or direction!

Thanks!

[Jan Axelson]

The host controller will reset and re-enumerate a device after multiple failures at the transaction level, for example, if an endpoint doesn't respond to a token packet with ACK, NAK, etc.

The host controller knows nothing about handles or other application-level protocols.

The reset is the host's attempt to fix the problem.

The true solution is to find out why the errors are happening and fix it. The TotalPhase analyzer should show the error that is causing the reset.

If the host application attempts a transfer and discovers that the handle is closed, the application can attempt to obtain a new handle for the device.